Bullet Catcher

I'm now back into C# and the hidden mysteries within. I'm discovering that using a class based language requires some advanced thinking before really siting down and getting to work. The issue is the way the different classes are structured controls how they talk to each other. I seem to have discovered this the hard way.
Things overall, are going very well. I'm learning the basic syntax of C# although I am finding it a little odd. Say for example, where in Odin's Crusty Beard is my fuggin "OR" conditional? I missing it obviously, because coding language couldn't be that stupid. It can't, can it?
I'm clearly on a tangent. Anyway, on structuring the code I tried a couple of different ways to organize how the Player Bullet Class will function. The first way was to think about it hierarchically. So thinking that Bullets come from the Player Sprite, they should be a sub-class of the Player Sprite. Turns out that was a stupid idea, because the code updates things based on a list. So when I add a new object (like a Bullet, or an Enemy) it adds it to the something I called the Sprite List. It's very similar to the Object Code that I built for Thief, but deep in the guts of the C# language. In any event, when I made the Bullets a subclass of the Player Sprite, it had no easy way to talk add any of those things to the list, because that list exists somewhere else.
Long story short, putting the bullet creation that far away from my Sprite Manager Class (where the List lives) made it very difficult to have it do anything useful.
So I reasoned, "Alright then, everything gets to start and end at the Sprite Manager, since it's the official Keeper of the List." So I reconfigured the code so that it could keep track of which way the player was facing, float that variable up into the air where it could be caught and bullets created. That, after a fashion, worked pretty well actually. Not initially of course as you'll notice from 3 posts ago, but I got it working yesterday. It's something that will come in handy later, since at least one of the mini projects in The Star Frog EP will create bullets that way. I threw it out though, since it has nothing to do with what I'm currently into - Paper Zeppelin.
When coded right, yes, I can float a value from a sub class and have other functions and classes do stuff with it. However, for my purposes here, I really need to create bullets based on vectors using the right stick. Yes, I know that right stick firing shooters are de riguer, but here it actually works in both context and mechanically.
To get that working, I just had the Sprite Manager have a peek at the sticks, figure out direction, and round off the vectors. So say, the stick is pointing up and to the right. That has a value of Y being less than 0 and of X being more than zero. Or in codish:


RightStick.Y < 0

RightStick.X > 0

So I rounded those off like this :

if (RightStick.Y < 0)

bulletDirection.Y = -bulletSpeed

if (RightStick.X > 0)
bulletDirection.X = bulletSpeed

That way, press a little or press a lot, the bullets all go the same speed in one of 8 cardinal directions. Then I make a bullet, add it to the List and booya, it dances like a drunk with neither pride nor rhythm. Which is to say, in a very entertaining way.

So, what have we learned here today? Well, I figured out how to create and update objects that just do their own little thing. I can use this to make enemies next. The difference will be in how they are created, either randomly (which I hate with a fury - being a design control freak) or by data tables (which I am very fond of). Then I be able to get collision detection working, which is the last piece of the game engine Triforce (Controls, AI, Collision Detection , which correspond to Courage, Power and Wisdom respectively).

Before any of that though, I need to figure out what enemies I need, how they act and how I'm going to going to generate them. So unlike Thief, I need a Design Document. I may even post it online - *gasp*!

Stuff inbound.

Sounding Off

After throwing several kinds of rage at my sound code, I've finally gotten it back to something bordering on working. Music turns on, turns off and generally plays well in the context of what's going on. It turns out that the code I had in place was working just fine. The problem stemmed from the fact that I was trying to call it all over the place. There's a call for the function (and for blood) at the beginning of the program, when you restart, when you pause and a bunch of other places. The issue was that these would all start doing their own little thing no matter what I told them to do. Also, it seemed like the software was calling versions of the music code. So the code would say, "Let's play music!" Then we would all dance. Then the code would say, "Let's play different music!" at which point new music would play, while the old music continued. I can't express enough how terribly wrong that is. The code says on a basic level to play music if there isn't already a song playing. It also says to stop playing music if it's turned off someplace. I then turn the music off right before calling the code. Those two conditions would seem to imply that you can't have two things playing simultaneously, unless they are somehow considering different versions of the same code.
As you can see, it was a very confusing bug.
I gave it the coup de grace by eliminating all of the calls except for the one in the game loop and the one on the Front Menu. It works great now.

-Odd, that story seemed to start off with fire and then kind of petered out at the end there. In case you're wondering why this took me so long to do, it was because I spent all yesterday being a Journalist and writing reviews and editorials for GamerRoad.com. I've been spending some time playing XBLI Games and passing judgement on them. Maybe, just maybe, having a review on the internet will bring somebody some kind of recognition. Although I do seem to review things kind of stupid. If you've ever read my critiques and thought to yourself, "Hey, I wish there were 600 more words like this," then, well, there you go.

(Sic) Sound Bored

Yesterday I was greeted in my email box with gifts, fabulous gifts! Our intrepid Composer has clearly been hard at work, I mean, check out all the new orange color in the Music section of the Big List over yonder =>. It's so colorful now. So right off the bat, the first 4 chapters and boss battles have music finished, in addition to musical cues for victory, death and Main Title musics. I've also a couple more living inside my laptop for story sequences that feature specific character themes.
I may post them, or link to them at the discretion of The Composer. Unlike art or any of the dumb code I post, the music could be used for other things without permission. So we'll see. you may just have to wait.
In any event this means that I, as promised, get to go back in and add the pieces lovingly to the overall framework. It's like I'm putting down ceramic tiles on a concrete tower. Then I ran into issues. You see, I hate the sound code in Blitz Basic. It gives me enough rage to transform into Hulk because it is implemented both poorly, and unlike the rest of the damn language. Sound channels are opened, closed, looped and gods know what else.
The biggest, stupidest issue has to do with the music wanting to overdub itself. Say you start playing a game and select a stage, the music comes on and sounds great. Now let's say you exit back to the main screen, the original music will continue to play plus the music for the main screen. For the occasional giggle, let's then say that you select a different stage, the music for that stage will begin playing over the music from the first stage you picked and the music from the main screen.
To try to fix it, I first tried to make sure that the my code was correct, which it seemed to be. I mean, it worked fine when I was playing midi files, but fell down with the far superior mp3 format. I then rewrote the entire function to consider the mp3s to be sounds instead of music. The difference is that sounds can be manipulated to a greater extent, but are loaded into memory instead of fetched from someplace on the drive. So I did that and I still got the same problem - overdub.
Oh, and the fact that the game kept opening mp3 files and thinking about them made the game slow down and play like ass. We mustn't forget that.
So I got to thinking that the music function wasn't getting the correct inputs, or it was being called incorrectly or something. So I hunted down all the calls and tried tweaking and modifying each one, to no further effect.
There's no moral to this story really. The code is still uncooperative and still wants to play way too much music at me. The stupid thing is, there is a lot of music and sound stuff that has to work right, and be robust enough to support additional shenanigans. The next stage, The Cliffs, a crazy scripted and need dynamic musical cues. That means that I need to be able to call changes to the background music from a script, which of course means that the background music needs to work right first.
I'll venture forth into that breach again later tonight.

-Before you post (ha, like anybody posts) yes, I know that I used the wrong "Board" in the title. I also know that, generally, an Editor would add the (sic) after a spoken misuse of a word, not two words previous. When these kinds of things happen, just consider the fact that I write pretty much for a living, so it's pretty much always intentional.
Or I didn't proofread. May be that too.

I Can C Clearly Now

Hah, a pun! I didn't even get to the body of the text before I started throwing puns like Ryu throws hadoukens. Right then, I'll try to get to the point, I figured out something that has been bothering me for days, the cause of my lack of progress or posts. I've been in the process of building the functions and classes that one day will form the backbone of Paper Zeppelin, the player controlled objects (yeah, plural - I'm dropping some multiplayer on ya) the enemy types and more specifically, the bullets. For now, as a test, I wanted to create new bullets ( with a Bullet Bill placeholder sprite) that would then travel in a direction based on the way the player objects are facing. The Epic Fail occurred when they would simply not go in any direction that wasn't down and to the right.
So into the code I went. "Maybe it's the bullet update code," I thought to myself as I went in and started making the little bullets fly in a bunch of directions. "Nope, that's not it. That seems to work. Maybe they're not being created correctly," I continued aloud, because I was home alone with my cat. That wasn't it either, since I could change the vectors manually to about anything, and I did. "We're not getting information correctly from the player then, *sigh,*" This, was what I was most afraid of. Basically, if my player controlled object wasn't talking to my other classes, then I was missing something fundamental about coding in C#. So if that was the problem, the progress towards enlightenment thus far, has actually been in the wrong way.
Either way, in I went, checking the Return functions and the other little bits of code, frustrated that it wasn't working correctly. Last night though, I came across the true problem - I screwed something basic. I discovered that if I were to define the direction the player is facing instead of using conditional statements, then it did it correctly. I'll rephrase that. When I told the code explicitly, "Hey, code, make this a 7, no matter what and don't argue about it," instead of, "Make it a 7 sometimes, and a 6 if it's a Sunday." Or, in pseudocode:

Defining looks like this -
facing = 7;

Conditionals look like this -

if Sunday = true
facing = 7

With that out of the way, the problem was that my conditional statements, were all stupid, like I coded them while snackered. I've never been so happy to have done something so dumb. My grammar was correct, my structure is correct, but I misphrased a sentence basically. Now, I just need to get the rest of those little piggies moving.

- In non-development news, I just wanted to say thanks to the several people that are now connected to me with a Facebook, um, tether? I've no shame really, and will probably approve anybody to be cool kids. For ease, my Facebook icon is the exact same one as my CID icon and my Gamasutra icon. Don't be bashful, besides there may be a time when I may be able to give something out to the Cool Kids.

Breaking Down

I've been doing some thinking recently about the term "Breaking Into the Industry." I've come to the basic conclusion, that I really don't much care for the term, because it is stupid. It stems of course from the whole idea that making games is a Rockstar profession full of long nights and groupies or something. Honestly, I'm not sure what people think, although I'll assume that stupid, asinine commercial with the phrase, "We just need to tighten up the graphics in level 3," doesn't help matters. Although, if you really want to know what it's like to be a game designer, just have a gander at the last 200+ posts here. This is about it really, except I pay for my own energy drinks and I work on a couch, not at a desk. But regardless, and I'll use some slightly slanted emphasis here, it's fucking difficult.
Lots of people think that making games is easy, like the douchbags in the commercial. Well, here's the thing, making crap is easy, making anything that isn't crap is very difficult. Sometimes, you try hard and you make crap anyway, but them's the breaks.
Anyway, people have this magical idea that being a game developer means epic Halo sessions or is somehow a land of proverbial milks and occasional honeys (wink wink, nudge nudge, say no more). This of course has the detrimental side effect of putting the whole thing on a pedestal, this thing that only a select few are capable of. But here's the thing, it's no that hard to make games. Making games for a living is another matter entirely - just have a peek at my Profile to see what I mean. But making them, not so much.
If you want to make games, or really if you want to do anything, just do it now. What's that you say? Can't program? Neither could I once, but I got over it. There is no "Breaking In," just keep chasing what you love doing and you'll get there eventually. There is no secret handshake and no hidden cabal. Certainly, you don't have to go on a bloody gameshow either.

- In something related, I've recently read that 90% of game jobs aren't advertised. This seems to mean that you know people that know people, a process which I find distasteful. The odd Shadow Market of jobs that lingers deep beneath the offerings of Monster or Craigslist. A secret underground that I previously knew nothing about. Some quick math shows that, if 10% of the available jobs have something that I'm qualified for once or twice a month, then the other 90% should have something that pops up once or twice a day. This is a resource that clearly needs tapping.
Of course, the logical entry point for such an underground market of creative meat would be the IGDA San Diego Chapter, but they are either A) in sleep mode or B) broken beyond measure. A damn shame really, although I think I lack the gravitas to pull together the chapter again, seeing as I lack the connections.
So since that's a big, fat, greasy bust, I'll need to look for other ways. So, *sigh*, I signed up for Facebook. I once had an account there, but discovered that I couldn't write out long winded passages like this one so abandoned it. I'll try to follow the signs and see what I can do.

-Hurray for mixed messages! The first half says, "There is no breaking in. If you make games, good job, you're a game developer!" The second counters with, "To get a job there is a secret society that one must first verify the existence of, like some kind of test." These seem contradictory at first blush, but the messages are distinct. One is a call to democratize game development, the idea that anybody could be a developer if they wanted to. The second is the cute trick of being paid to do it in actual dollars instead of gum or meatballs.
Instead consider them this way, be a game developer first, then try to find someone that would like you to do it for them (or find a way to pay yourself). Don't wait until you find somebody to pay you before becoming anything. I mean, if you won't do it for the love of it, why subject yourself to doing it at all?

Waste My Days

I'll get right to the point, which is to say that the thing from before, didn't work out. Funny story though goes with it. You see, my fear from yesterday seems to have been unfounded. I know this, because I did something quick, and impetuous; once I got the email that said, "Sorry," I asked "Why?" Then, I got a reply.
The reason was fine. I had effectively found myself in a Kobiyashi Maru situation. For those of you at home that have exactly zero idea of what the hells that is, it's an unwinnable predicament. So while I was a good fit, and on the short list for consideration, they found a perfect fit, with experience in the language that had also come recommended by someone that was already there. Regardless of indie cred, that's simply a Goliath that this David doesn't have the stones to beat - figuratively or literally.
I was struck with a fuggin cacophony of emotion (I love that word - cacophony, but I never get to use it in a sentence). First was an odd kind of pride. I consistently get callbacks and interviews. Not occasionally, but like a ticking clock. All of this stuff that I'm doing, is clearly the right way to be going. Keep at it, and I will get there, my long waited for Exodus.
The other, was the unJoy of not getting it. But now, looking back, I'm over it. The fierceness of my pride overpowering it like a lion made of fire. Besides, other pots cook still.

- Which brings me to a shameless plug. I'm soon to be contributing to GamerRoad.com, a new site that's less about roads and more about games. I've been given carte blanche to write about pretty much anything I want, so you'll see some of the kinds of things I rail on here. I'm also going to make the attempt to push a continuing XBLI Review feature, since the indie games get about zero publicity and very few on internet really make a point of trying them out. So look for that in the future.

- Finally, C# University is back in session. I've been, let's use the term "screwing around" far too much in Assassin's Creed 2, and I needs to get back into working on something that may throw dollars my way someday. I mean, classes and functions are built, I need to make them do something now though. Updates incoming.

Like a Book with Faces

I'm in the middle of some, let's say stuff, regarding the possibility of doing all of this and maybe getting paid for it. The idea is thrilling, especially given the pedigrees involved and the whole idea of the thing itself. I can't talk about it though, since it's still very much on a simmer, but maybe soon. However, I have a small dose of The Fear, just enough to keep me from being confident. That fear, comes from some Tea Tabling that I went and did.
First though, some history. In certain Nintendo circles, it is said that Saint Miyamoto will periodically come around, like the jolly guy he is, and visit with the game studios at the Big N. All smiles and joy, he will request to play the game said studio is working on, then meet with the Producer or Director or Planner or whatever. These meetings, taking place in Japan, are based around the possibly stereotypical, but just as likely archetypal, tea table. It is here, at these meetings he will ask a simple question, which destroys possibly years of effort, "When are you going to make the game fun?" When Miyamoto thinks your game is broken, it just is. So the team will frequently go back and try to make it better. Consequently, the Nintendo studios and their adjunct Producers have a mighty and terrible fear of being Tea Tabled.
Which is what I think I may have done. The problem is, when I do it, I may come across as a punk since I currently lack an AIAS Knighthood. But that's not the case at all, that's more to do with the way that I design anything. I think another story is in line here, for illustrative purposes.
The story goes like this : As part of this new thing I can't talk about yet, I was requested to play some Facebook games. So I went in a set up an account (which I may or may not let the rest of you have {"rest of you" really?}) and got to playing some "games." I quickly ran into an issue. The problem has to do with how they are constructed. They seem to fall into 2 broad categories. The first of which is a Mafia Wars style click-fest. Basically, it's something you can participate in without paying attention. Clicks are made, outcomes are calculated. That's it. There is no gameplay. Yes I know, Diablo was clicks and outcomes, but there was more to it. Upgrades, the loot heap, different abilities that you could use, levels to gain. In it, the clicking is a means to an end, not the end of the road. So they're screen savers for your brain. I moved on.
I then got into playing a little Farmville, which is like the base building portion of an RTS. Resources come in, buildings are constructed that provide additional resources, and you keep building until you like what you have. Having friends nets you more space somehow. It's all fine and good, but what is called by Designers as The Core Gameplay Loop (not to be confused with the Programming Game Loop, which is a different thing altogether) is Build, Harvest, Repeat. That's 3 things, with the occasional additional option of Shop.
In effect, the whole thing is totally self serving. You build stuff so you can build more stuff. There is no purpose, and frankly no point. Although now the Wife is totally hooked on Happy Aquarium and I have no idea why. It may have to do with the ability to teach her fish tricks, which possibly feeds the Poke-Cortex part of her brain. I keep asking anyway.
In any event, that's how the story goes, and that second part is pretty much what I said in email when I was asked what I thought about Facebook games, having not played them before. But I'm in an odd situation with this one. If I come on to make more games like the ones I played, then that's not really very good now is it?
The issue that I have, is one of bottom up design. I think I went into this before, but Bottom Up Design (also sometimes referred to as Inductive Design) is taking the vary small, and figuring out the very big. So as a Designer I'll usually start with a Core Mechanic, a very specific thing and I'll start building around it. So for Thief, I honestly started with the Triple Jump Mechanic - Jump, Double Jump, Dash. Then I built around things to do with that mechanic, and how to enhance it. So wall hangs, wall jumps, pits, lethal falls, all go into enforcing the jumping mechanics and exploiting them. The downside of this way of thinking, is that it is very easy to add stuff for no reason, since it is fully possible to lose sight of the overall vision when so much focus is put onto the details. On the other side, the basic parts of play tend to be better represented. It's more of a True Game approach, which is why I like it so.
The other kind of Design is Top Down (or Deductive Design) which is having a Big idea, and figuring out the pieces that should go with it. If I were to do this for Thief, it would start off as, "We have this Thief character who is trapped in a dungeon and needs to escape. Very acrobatic." So then we think he needs to climb and he needs to open doors and maybe he fights. Odds are, the game will look quite different than it does now. This isn't a bad thing per se, if it is done right. Big thinking tends to work best in arty "games" where the core conceit is as important to the whole as the mechanics. Nothing wrong with that, it's just not my bag.
Anyway, the clicky games all seem to come from the Top Down school of design. So they think, "We want to make someone a gangster, what do gangsters do anyway?" So they give an option to run missions, and give the whole thing a very gangster feel. But it's all just window dressing really. The same mechanics are also applied to a Car Racing game (try it, the "racing" isn't) and the only changes are that names of things and the coat of paint. It's sad really, which is why I tea tabled them.
But, and here's the kicker, they could be so much more. Facebook has an integrated community already, with preset groups, cliques and guilds ready to do something together. That right there, an open platform with built in multiplayer support is phenomenal. No getting servers to talk, nothing like that. It just is. That could be used for the powers of good.
Also, if making a game, give it a purpose. Give a player the option to do things for themselves (since it seems the "look at my giant farm" mechanic works for some reason) but then allow them to do something with it, something with tangible benefits. Give the Missions a reason as well, and most importantly, give the player a damn game to play while they do it. Click and payout is broken.
While I was looking at these, I was trying to find the reason they worked and started building my own. I'm not saying that I've gotten it all figured out just yet, but a Core Mechanic needs watering and love before it can grow.
I just hope that feathers haven't been ruffled, since my intentions are pure.

- In development news, I'm seriously considering another Combat tear down. The current system works rather admirably, and plays rather well, but Producer me is thinking about cutting it because it is so asset intensive. I may be able to do more with less, but every place I start gets me back to the first iteration, or the current one. A paradigm shift though would likely undermine the entire project though. I'll think about it some more.