The Shell and Cactus

Part 2: Design of Texas Quest Part 1

I am writing this document as part of the very infrequently updated Texas Quest tutorial series. I suppose I should put “series” in scare quotes there because at this point there is only one entry in the series until now. ;) If you can ignore that, then what I am trying to do here is describe the overall architecture of a side scroller game before getting into more details of the rendering, which was going to be next. The architecture is usually the really fun part anyways, as graphics are, to me at least, quite frustrating (see the previous blog entry, which I did actually figure out eventually).

I am going to assume the reader is familiar with my side scroller game Texas Quest or at the very least games like it such as Mario World, so I am not going to detail their features. Also this guide, while based on Texas Quest and my experience making that game, may of course be used for other side scrollers and maybe even other types of games. In fact that’s why I am writing it, so that someone else making a game will have a good head start. But realize that there are always many many ways to do things in programming, what I detail is one way, not necessarily the best or even quickest either.

I should also mention that Texas Quest is kinda my second side scrolling game. I did another one back in the Winter of 2001 and got pretty far with it until giving up. I developed a lot of the concepts for Texas Quest there, so no one should think I came up with this whole design on a first pass or anything.

Levels

Levels are perhaps the easiest part of a game to design because it is really quite obvious what is needed from them. The reason for that is when you know everything required you can just put something together that does exactly what you need. The design flows from the requirements, especially with the case of levels since they are not too complex. So we start with levels for that reason and for another reason we will detail in a bit.

The level architecture goes as follows: A level has one or more level areas, one of which is the primary or starting area. Other than that a level doesn’t have anything else… except what I like to call a starting script. This is optional, and dependant on how you want to do scripting in your game. But this is the kinda thing that lets you play a little scene when the level starts. So it is neat and adds something special to a game that people expect nowadays. Oh, and when I say scripting I don’t mean a scripting language either, just a script in that it’s a series of predefined instructions. In Texas Quest I just had a few pre-built script classes (e.g. Level3StartScript, Level5StartScript, etc, etc).

Now for level areas. These objects are the maps or areas that you visit and explore in a game. The reason we separate out the maps from the level is that we want a level to have many relatively independent areas to explore, such as in Mario Brothers when you go down a tube you are no just taken to a different part of the level, but a whole new area with its own map. That’s what we are modeling here. A level area has the following components:

• A matrix of tiles that is the map.
• A list of characters, their starting locations and starting information.
• Some reference to a background image to be used for the area.
• Some reference to a song or melody to be played in the area.
• A list of tile entry points.

I call all active game objects (e.g. not tiles) Characters. So a level area has to maintain a list of Characters and where they start at. Characters can be enemies or items, or neutral things like blocks or really anything else you want, and we will discuss them in much more detail later. What I want to make clear now is that you need a list of them in your level areas that at a minimum includes what the character types, starting locations, and starting information (e.g. for a Question Mark Box character, what it contains). I will detail the way I did this later. Entry points are one end of the links between level areas. They are the exiting end, and the entering end is characters such as pipes or doors. There should also be some way of telling which entry point is the starting one for this area if this is the primary level area for the level. I just use the first entry point in an array but something more elegant could be done as well.

So… next are tiles. Let me say the way I did this in Texas Quest is wrong. I didn’t use a Tile class (actually a Tile struct would be more appropriate anyways if you are using C#). I used three matrixes of tiles. Each matrix is of integers. The integers are indexes into one of three different pseudo-arrays of tiles images. The matrixes are used to draw the map. So one matrix is for the foreground, another for what I call the mainground, and the final is for the background. There is another matrix containing movement information. Its cells are of an enumeration type with three possible values: Freely, StopsAll, JumpThrough, meaning respectively, this tile can always be moved through, this tile can never be moved through, and finally this tile can be moved through when traveling horizontally, or moving up (e.g. jumping).

What you should do is have a Tile class (again struct if you are using C# like I did). It should have an integral type (probably byte or ushort depending on how many tile types you have… byte if you have 256 or less, ushort otherwise (unless you have more than 65 thousand, which is very unlikely I think)) for the background, mainground, and foreground (and other layers if you want them). Each of these should index the same tile image array. Do not use three different tile image arrays like I did in Texas Quest. That’s silly and is bad design ;) Then you should have the same enumeration type I had in Texas Quest, with those three possible values effecting movement through the tile (Freely, StopsAll, JumpThrough). This will make things more clean.

Interlude

Now that you have gotten your level design down, now comes the first hurdle I like to cross: getting a map editor working. This has been a really great way for me to go about games, because I get the first and main round of graphics work done without getting into Character animations or anything, and I can make sure the level architecture works and looks good. I highly recommend doing this before getting into the core Engine part of the game. That may seem more appealing and rewarding, and it probably is, but getting this core work done will help you in the long run.

Characters

OK, now for characters. We are going to cover what attributes make up a character here, without getting into event handling for character interaction toooooo much. But we will touch on some of the basics for it as we detail what makes up a character. As I stated above, characters are all active objects in the game. Pretty much every game object aside from tiles is a character. You (as in me in Texas Quest, or Mario in Super Mario World), enemies, blocks that might break, blocks that interact with the user in any way, coins, other items, and even special effects (like the sparkles that appear after you collect a coin). I am going to list the attributes of characters in three sets: type based, instance based, and a small set describing how a character is added to the map in the level editor.

All characters have a class, such as Tutrle, and that has some attributes with are pretty much constants, such as maximum speed. These are type based character attributes. Characters also have some attributes like location, which changes. Those are instance based character attributes. Pretty simple really. What I did in Texas Quest is create an abstract class called Character that has both sets of attributes defined but not implemented (since they are abstract). That means ever Character subclass has to implement these attributes, and the difference between the two is that the type attributes can be gotten but not set so they should be more like constants. In a previous game I wrote I created a class called CharacterType and a class called Character. The CharacterType class had the type attributes, and the Character class had the instance attributes (plus a reference to the CharacterType class). Then I was even so bold as to make a small scripting language that defined the character types via a rule script file. Such that all the important stuff about the characters was dynamic and built at runtime instead of in the code. It sounds great. But it was toooooooooooo much work. And I got bored with it and let it die eventually. It is muuuuuch easier to build your Character classes at compile-time than at run-time, especially when you get to event handling. So just take my advice here, and if you are working on your first game, do not be too ambitious!

OK, so back on track here are character attributes:

Character Type Attributes

• Horizontal acceleration. (Per a game turn, say 1/33 sec, this is how much right or left velocity may be added to the characters velocity/speed)
• Maximum velocity. (An upper limit on how fast the character may go irrespective of acceleration)
• Can jump (ever).
• Initial jump acceleration. (If the character can jump, this is the initial boost they get to start flying)
• Extra jump acceleration. (If they jump and hold down the jump keep this is the extra velocity they get each game turn)
• Extra jump time. (This is how long/how many game turns the extra jump acceleration may be applied after jumping)
• Max hit-points.
• Can think. (Relates to decision making which we will cover later)
• Affected by gravity. (Whether or not they are pulled down towards the bottom of the level)
• Is a player type character. (Is this character a player that should be attacked by enemies?)
• Is an enemy type character. (Is this character an enemy that can damage players?)
• Causes player hits. (Relates to event processing which we will cover more later; specifically whether this character will trigger hit events if it contacts a player type character)
• Causes enemy hits. (Similar to above, specifically whether this character will trigger hit events if it contacts an enemy type character)
• Causes other hits. (Whether this character will trigger hit events if it contacts a character who is neither a player nor an enemy type character).
• Cares about player hits. (Does this character care about hit events coming from players)
• Cares about enemy hits. (Does this character care about hit events coming from enemies)
• Cares about other hits. (Does this character care about hit events coming from others (non-players and non-enemies))
• Causes players to stop. (Should the a player character hitting this character stop, that is, it cannot proceed through this character)
• Causes enemies to stop. (Similar to above, but for enemies)
• Causes others to stop. (Similar to above, but for characters other than players and enemies)
• Is a bouncy surface for player characters (like a spring).
• Effect of freezing (none, minor, medium, major; This relates to the freeze special power of the main character)
• Display size. (Size of this characters image)
• Hit area size. (Size of this character hit area, generally same as the display size or somewhat smaller).
• Display to hit box X offset. (Difference between the X coordinates of the display box and hit area box for this character (see instance attributes for the boxes))
• Display to hit box Y offset. (Similar to above, but for the Y coordinates)
• Collection of animations for this character (we will get to this soon).
• Current animation.
• Current animation runner (we will get to this soon too).
• Effect color (a color that effects the display of this character).

Character Instance Attributes

• Id. (An integer to identify this character uniquely in the game world)
• Horizontal Speed.
• Facing (left, right, or none). (Direction the character is facing)
• Is in a jump. (Is the character in a jump right now)
• Can jump now. (Can the character make a jump right now. Usually relates to other attributes)
• Vertical speed.
• Time in current jump.
• On the ground. (Is the character on the ground, used to figure out if he can jump and if gravity should be applied)
• Is falling. (Is the character falling, like the above but used for animations as well)
• Is a ghost. (Meaning no character interaction can occur).
• State (normal, flashing/damanged, dead).
• Current hit-points.
• Is frozen. (This relates to the freeze special power of the main character)
• Current command (This relates to thinking, specifically this is what the character is currently doing)
• Display area. (Rectangle area on the map where this character should be displayed. Generally uses display location and size to create the rectangle.)
• Hit area (Rectangle area on the map where this character should cause hit events, kind of like its real physical area. Generally uses hit location and size to create the rectangle)
• Display top-left corner location on the map.
• Hit area top-left corner location on the map

Character Level Editor Attributes

• Add Z order preference (don’t care, behind, in front).
• Add Y position preference (on ground, on ceiling, floating).

Wow that’s quite huge huh? I think they are all pretty straight forward and its pretty obvious why they were needed. How I implemented my character classes was to have this base abstract Character class whose attributes I just listed, and then have a ton of concrete subclasses like Turtle, Coin, and Aaron (the main character ;) ). There are some classes between the two (StandardCharacter, Enemy, Item) that are also abstract but provide some common functionality for their subclasses. The line between type and instance attributes is blurred a bit because of this, since the concrete subclasses do not have to return constants from the type attributes. But they for the most part do. Almost all type attributes return constants in all concrete character classes. Instance attributes depend on the character state, so naturally should not.

In addition to these attributes, the Character class also has several abstract methods that I am going to detail here. I want this to be complete so that’s why I am putting these all here, but a large number of the methods relate to event handling and will really be examined better later.

Character Methods

• HitAreaTiles (). (Tiles are defined as 32x32 pixels in my game, this is the game world tiles that the hit area covers)
• Initialize (). (Makes sure animations are up and running, and everything is good to go. I did this because of the way I did levels, see below…)
• Duplicate (). (Clones the character, this is very important, again because of the way I did levels, see below)
• Texture (TextureStore). (Gets a reference to the texture from the game’s collection of textures to use during drawing, relates to DirectX)
• SetAnimation (AnimationPurpose, DirectionFacing). (Changes the characters animation)
• Think (Reason, Enviroment). (Relates to decision making, which we will cover later).
• DamagedBy (Character, Enviroment). (Method to inflict damage on this character by another).
• Freeze (TimeSpan). (Freeze this bad boy)
• OnHitBy (HitEventArgs) (Event handling method for being hit by another character)
• OnRanInto (HitEventArgs) (Event handling method for hitting another character)
• OnStartedFalling (CharacterEventsArgs) (Event handling method for when this character starts falling)
• OnBumpedCeiling (CharacterEventsArgs) (Event handling method for when this character is jumping and hits the ceiling)
• OnLanded (CharacterEventsArgs) (Event handling method for when this character if falling and lands on the ground)
• OnHitWall (CharacterEventsArgs) (Event handling method for when this character runs (horizontally) into a wall)

Now like I was saying about the characters and the level editor, the way I did the level architecture, specifically level areas, has each level area containing a list of characters. What I do is add an actual honest to goodness entire character to this list. That entire character is saved with the level. Most games probably use a character-stub for this, and as I said above you could probably get away with just putting a (type, location) into the list for your characters. Until you wanted to do things like set the item in a Question Box. Or set the number of coins in a Coin Bag. Or set the number of hit points of a Turtle. Or a million other things. I found it was just easier to put the whole character into the map so that all attributes can be modified. Then when the map is serialized and deserialzied the character comes with it (in .NET you have to set every character class with the SerializableAttribute before you serialize).

However this leads to the need for the Duplicate method. Once we have loaded a map with its level area’s and characters, we need to create an active set of characters running in the game. But if we use the same characters that came with the map, then when the player die’s and has to restart the level the map has to be reloaded again. To get around that silliness we can just clone every character from the map that should be in the running game when it is started, then if the character die’s or the level otherwise restarts we just trash the running character set and create it again, without having to reload the map.

Interlude 2

That’s quite a lot to digest so before I get any further I am going to take a break. If you have any questions, post them! Ill write the next part of the design soon (soon my time = a month or so probably, sorry :P)

# posted by Aaron : 11:30 AM