I’ve made a few games in my time. And made various parts of a few other games for other people. Most of the games that I’ve worked on have been pretty simple, but recently I’ve been working on some more complex ones, both in ActionScript and in Objective-C. And one of the things I’ve been struggling with as things get more involved is how to best architect these things.
After giving it a LOT of thought, one bit of insight I had is that we (meaning those of us who have been brought up in the Flash world) have picked up some really bad habits. Maybe we could label it “MovieClip-itis” or something. Its major symptom is making everything a Movie Clip, or in modern terms, making everything a Sprite. It’s ingrained in us. And I’m just starting to realize how bad it is.
Back in the day, we’d draw some graphics, select them, convert them to a symbol, type Movie Clip, select the symbol, open the Actions Panel, and start typing, “onClipEvent…” and put all the object’s behavior in there. Ugh. I know. Or, we’d double click the symbol, and start writing code on its internal timeline. Not much better.
Then we got AS2 and AS3 and we realized how bad that all was. So what did we start doing? We create a symbol, give it a class name, and then create that class, putting all the object’s behavior in the class: “class SpaceShip extends Sprite…” right?
I know there are some of you out there saying, “Not me. I use Flex Builder (or FDT or whatever), not the Flash IDE.” I use straight up code and embed or load in my graphics." OK, but I bet you are still doing “class SpaceShip extends Sprite” with all the spaceship behavior in that class. Maybe a few of you aren’t, but I bet a whole lot of you are. It’s my first impulse. Pretty much all of my books give those kind of examples.
So why is it bad? Well, I hate to label stuff like that “good” and “bad”, but in a nutshell, you are mixing game behavior and view. A sprite is a view. All it should really know about is display object stuff – its position, rotation, scale, color, alpha, what graphics it should be displaying, etc. It shouldn’t know about its speed, direction, fuel, ammo, shield, etc. Those should be part of a space ship model object. The model object is updated by the game loop or whatever system you have in place, and the sprite would simply read what it needed to from the model to display itself correctly. Or, depending on your architecture, some other type of controller object would read from the model and update the sprite externally. Theoretically, your whole game could run without a view, with you just watching values change in the debugger. This also makes it easy to re-skin a game, since you’re just changing out dumb views.
Again, I don’t want to pass moral judgements on software practices. I’m sure many a fine game has been written with all kinds of game logic in classes extending sprites and movie clips. But as your games get more complex, doing things this way is open to getting very messy. I could go into details, but you’ve probably already experienced this messiness. God knows I have. For me, it’s not so much about this being “bad” but the automatic, knee jerk reaction of creating view objects with game logic in them is DEFINITELY bad. It’s something I’m trying to break in myself. So thought I’d share it in case you are running into similar things.