I plan for networking to form an important part of Icefall’s gameplay: the game itself is not realtime multiplayer, however I plan for an ‘Auction House’, scoreboards/leaderboards/server-firsts, player-to-player mail, and other online community-type features.

BUT I have never worked with any networking code of any complexity before, and I determined that trying to ‘learn while I go’ during the Icefall development process would not be the best idea. Hence, Citadel!

Citadel is a ‘tower-defense’ game. For those unfamiliar with the concept, essentially an endless wave of bad guys (in this case, tanks, jets, armoured cars, and trikes) try to get to and destroy your tower. Your job is to build a system of defensive towers to prevent them from doing that. The towers themselves automatically aim and fire, the strategy lies in placing the right towers and walls in the right places to do as much damage to the invaders as possible.

Each wave of invaders is tougher than the last, and eventually they will overwhelm your defenses. However, each invader you kill will give you some credits to spend on additional defense, and you receive more credits for tougher invaders. So the object is to last as long as possible, try to save money for the strongest towers (the Tesla Coil), and ultimately get a big score.

As far as tower-defense games go, Citadel currently isn’t that sophisticated (it’s a beta version, after all!) and doesn’t have upgradable towers or multiple game types or anything like that, but it does have a unique feature that I couldn’t find in any other Tower Defense games anywhere: it can do multiplayer. Get a friend on a LAN, or over the internet (hook up a voice-chat program like MSN or Ventrilo!) and you can join forces to get the highest scores. It’s competitive co-operative: you share the same base and it’s game over when an invader reaches it, but who does the most damage to the creates gets the most credits for the kill, and the most score at the end.

NOTE: The invaders MUST ALWAYS HAVE *some way* to get through. Even if they have to go ridiculously long ways around crazily long mazes and queue up single file, it is against the rules of tower defense games to block them off completely. If you do that, it’s immediately game over!

Try the demo! If you don’t like it, that’s fine – but if it works (especially the networking part), or if it doesn’t work and you tell me about it and I work with you to make it work, then you’re helping me to make sure Icefall’s online components are awesome when they come out!

The Citadel Main Menu

Early into a Citadel game

Download the beta demo here and let me know in the comments what you think, if it works, or (more importantly!) if it doesn’t work, or (MOST importantly!) what your high score is

I had developed a lot of separate pieces of game infrastructure (random map generation, character creation, character death… etc), and over the last couple of days I have successfully integrated them all into the main Icefall build. This means that what I have now, for the first time, is a *fully* playable game! You start out creating a character, you can explore, find items, kill monsters, and be killed in turn.

There’s still thousands of features missing (I had thought I was pretty well progressed on the UI side of things, but now the framework is in place, I can see there are quite a few gaps I need to fill in) but now I have something that feels like a game, I can start iterating on it and trying it out.

The game has killed me several times already – I have added a few ‘tough’ monsters for the deep dungeon, but I haven’t really added any high-level equipment yet. So it’s possible for my character to be wearing all the best items in the game and still get owned by the monsters. This will be fixed as I add in more content

I didn’t meet my goal of having it completed over Christmas, but at least I have made significant progress. Overall, I’m pretty happy with how far along it is.

Finally, anyone who has played a roguelike will be very familiar with the death screen. Here’s Icefall’s current version (more information about how/when/why you died will be added in future):

The Icefall death screen quickly becomes familiar.

Any sufficiently complex game is going to have “assets”: data external to the main program that the game depends on to function. This includes “art assets” (textures, images, music, etc) as well as more application-specific “data assets” which contain data in a format unique to your application (e.g. Icefall has “item types” of all the different equipment players can find/buy/receive).

Handling art assets is relatively easy: you create/modify them in Photoshop (or equivalent), you save them as PNGs or JPGs, and you’re done! You might wrap them all up in a custom file format to compress/encrypt/streamline them, but that’s pretty simple and you can do that at the very end of development.

Data assets are different. There aren’t any programs around that can edit “Icefall item types” files. I need to write my own “Item Types Editor”, which understands this format and can load, modify and save it. This leads to two problems:

1. I have to spend time writing an Editor. (the actual format load/save code could be shared with Icefall itself, but there’s all the UI!).

2. If I ever change the “item types” format, all the data I’ve previously created is now in jeopardy. (What I typically do is modify the ’save’ code only, run the editor and  load each asset (old-code), and re-save it (new-code), then when that’s done I can modify the ‘load’ code.

Depending on the type of data asset, using Asset Text Files may be superior. I DON’T mean your game should store all of it’s data assets in plain text (yuck!). Here’s what I mean:

Whip up a simple plaintext ’syntax’ that stores all of the information you want to include in your data asset. Then,  instead of creating an “Editor” with bulky UI code, create a command line utility that can parse your plaintext files and spit out your compiled data asset files. If you borrow your main game code for load/save, all you have to write is the text parser, and that can be as easy as you like: you’re dictating the syntax it has to interpret.

The BEST part of this system is that it makes changing the format of the assets later on very very easy. Oops, I forgot a field for my item types? No worries. Add the extra field to your text file sources (bringing to bear the full power of your fantastic Programmer Text Editor / IDE you’re using – the programmers’ Photoshop), a quick change to the asset compiler to recognise the new format, and hit execute.

You get other benefits too: you can put ‘logic’ into your compiler without having to put it in you main game. (e.g. scale the values, dictate whatever “optional” or “Default” fields, anything!

It doesn’t work for everything (e.g. Icefall’s “Level Map” is huge and an Editor really is the right option for that) – but when it’s appropriate, I have found it works brilliantly.

Of course these ‘modern’ interfaces are much more work to get right than a classic keyboard-driven one. Even though I’ve spent more time on this aspect than any other, it’s still not perfect. Here’s an example I found yesterday:

Icefall Backpack user interface

Looks easy enough. To equip the Apprentice Jerkin, players can either click and drag it to their Character Sheet, or else right-click it to equip. The problem: there are two, identical jerkins in the player’s inventory. Click and drag works fine, but if you right-click the second one, a strange thing happens: the *other* jerkin is equipped instead, and disappears from inventory.

Why? Well, right clicking an item in Icefall triggers a codepath to essentially “Activate Item: Apprentice Jerkin”. It’s set up this way so that players can also drag equipment to their hotbar, and equip it directly from there. All good so far. BUT: internally, the inventory is stored as an array, and is stored from left-to-right, top-to-bottom. So when the “Activate Item” codepath is triggered, it goes looking for an Apprentice Jerkin to activate, and it finds the other jerkin (the one in the row above) first – so it activates it!

A rare situation, a completely logical consequence of the way I implemented right-click behaviour. Technically correct (There are no downfalls to the player if the ‘wrong’ jerkin is equipped: they’re identical by definition) and yet it feels completely wrong and would likely alienate a casual user. So I’m going to have to find a workaround

Icefall Character Creation, Nov 30 2009

Note: the “portrait” is currently a giant, upscaled version of the tiles used for the characters ingame. I would love to have larger character portraits, but my artistic skill just isn’t there…. hopefully I will find or convince someone at some point to help out

Class Selection

In Icefall, Class is a much more important choice than Race: Race has a few minor effects on stats, starting location, etc, but Class affects how you will approach the game: how you will defeat monsters and complete quests.

I strongly considered a “class-free” model, where the player starts with a generic character and shapes it over time just by their choices of equipment and ’specialisations’ (Titan Quest is a good example of this approach), but it made things too complicated, and you don’t gain too much in the approach anyway: in Titan Quest, if you don’t specialise correctly, you’ll end up a sort of “jack-of-all trades” type character who is not good enough at any one thing to get very far. So you may as well make the choice up-front, so that you and the game can work together to give you the type of experience you want. Choose a Ranger? Great, I’m going to give you some ranger-related quests.

Original Design

This screenshot is actually from the realtime Icefall prototype. I needed a quick way to change screen resolutions for testing, so this is it. Some interesting features: The green background would slowly sway while the dialog was open, and there was a shimmering gold border around whichever element had keyboard focus.

Revision

Fast forward to the turn-based rewrite of Icefall, and this is the original Video Options dialog. Some big changes: the background texture is more subdued, there is a panel on the left to select what type of options to view, and the gold-edge focus indicator has gone (now, the focused element is just highlighted a little more). Buttons and checkboxes have also had a minor makeover, e.g. the buttons are now rounded.

Revision 2

What changed here? The window frame! Gone is the ‘rusted steel’ frame from the top and bottom of the window, replaced with an ice-blue frame that encloses all four sides. I wanted to get more “ice theme” into the UI for the game, and at the same time I needed a UI frame that covered the left and right too, because not all UI elements use the slate background (the spellbook, for example, uses a ‘book’ background, and it looked a little strange with no enclosing frame). I also think this looks better than the previous one.

Current Design

Good, the rate-of-change of the dialog is slowing down, which means we’re getting closer to completion! The only change here is to the background of the listbox. The ‘green waves’ looked ok in the original version, but as the look and feel of the rest of the dialog evolved, it began to look more and more out of place. When the dialog frames turned ice-blue, it was a good opportunity to build on that existing colourspace and again lend more of an ‘icey’ theme to things by using a dark, ice-blue texture. This is what this dialog looks like in current builds. Hopefully, you agree with me that it’s the best looking of them all?

Textures are used for everything, from the mouse cursor, menus, fonts, buttons, to the game world itself, spells/action icons, monsters, equipment… everything.

Although my own main PC has 512MB of video (texture) RAM, not everyone does! And
following on from my minimum requirements post, I don’t really want someone’s video card memory size to be a limiting factor if everything else meets the requirements, so Icefall needs a way to manage things when there are more textures than there is video memory.

I don’t want each bit of code that uses textures to worry about whether they’re loaded or not, so the logical choice is to encapsulate all of the texture handling into one place: I call the class that handles this the TContentManager (”content” because it also handles sounds, fonts, music, etc.).

When the game code asks the TContentManager for a texture: the first thing it does is look to see if that texture is already available in video memory: if so, it just hands out a reference. Easy! If not, it retrieves the filename for that texture from Icefall’s ResourceDatabase, and attempts to load the texture from disk. If that fails, it looks at why it failed: if it’s D3DERR_OUTOFVIDEOMEMORY, the next step is to unload some other texture and try again, repeating until the load succeeds or we have no loaded textures left. (If it still doesn’t load, or if the texture load fails for some other reason, it’s goodbye Icefall).

Programmatically:

function TContentManager.GetTexture(ID: TTextureID): TLXTexture;
var
   HRes: HRESULT;
   NewTexture: TLXTexture;
   FileName: String;
begin
   if TextureLoaded(ID) then
      exit(Texture[ID]);

   FileName := ResourceManager.Textures[ID].FileName;
   repeat
      HRes := LXLoadTexture(FileName,NewTexture);
      case HRes of
         D3D_OK:
            Texture[ID] := NewTexture;
         D3DERR_OUTOFVIDEOMEMORY:
            UnloadTexture(0);
      else
         // Fatal error!
      end;
   until TextureLoaded(ID);
   result := Texture[ID];
end function;

UnloadTexture is a method that unloads a texture. It takes a TTextureID as a parameter, but passing 0 in this case tells the method we want it to choose a texture to unload itself. This is where it gets interesting.

Before I got to this, I originally had set up a few states so that they explicitly called TContentManager.UnloadTexture to release textures when the game left that state (e.g. the game would unload the ‘Option-selection’ texture when the player closed the Options dialog). However, this turned out to be sub-optimal for several reasons:

• Players might well leave and re-enter states (like Options) several times to accomplish whatever it is they’re trying to do.
• It doesn’t make use of extra video memory: it keeps loading from disk (or the disk-cache anyway) while the extra video memory stays idle.
• I had to explicitly declare what textures I was done with. Not a problem really but ‘just another thing’ that I had to do when changing states.

So now I no longer explicitly release anything. UnloadTexture always chooses the texture to unload that was least-recently used (a linked list makes this a very fast and efficient check – no timers or array scanning involved). In practise “least recently used” turns out to be about 97% optimal (when simulated against a 100% optimal algorithm which is permitted to see the future when deciding what to unload) so it’s virtually perfect – substantially better than my explicit declarations were.

If for some crazy reason the user doesn’t want Icefall consuming all of their video RAM*, I can chuck in a call to IDirect3DDevice9.GetAvailableTextureMem and trigger UnloadTexture if it’s below some specific amount. Alternatively, I could keep a sum of the amount of texture memory I’m using, and trigger UnloadTexture if that amount threatens to exceed 32MB or whatever (I haven’t decided yet).

The point is, if you find yourself manually balancing resources, it’s probably an excellent idea to profile your resource usage and see if you can find a pattern that will let you just automate the whole thing**. You’ll save yourself much time and your code will be cleaner and more flexible.

*Note: this only actually matters on Vista or Windows 7. Under the Windows XP model, multiple applications can’t share texture memory anyway. As soon as an application takes focus, DirectX invalidates all texture resources belonging to everything else (forcing them to reload from system-memory or disk when they get restored). The WDDM (Windows Display Driver Model) in Vista “understands” video memory, and can share it amongst applications. This is one of the reasons DirectX 10+ can’t be backported to XP: XP has no concept of video card resources.

**If you’re creating a game frame-rate locked or just frame-rate dependent, you might still need to explicitly acquire and release resources (e.g. between levels), because a 10ms pause at an unexpected point in your game could be noticeable or detrimental. Either that, or move the resource acquistion to another thread and have low-quality ‘emergency’ textures to display while the real ones load… this is a very common technique for FPS games.

With Icefall, I’ve already taken the decision to target Direct3D9 – I get a lot of extra capabilities compared to DirectX8, and it still works with Windows XP unlike 10 or 11… a pretty simple decision.

But what about in terms of video memory? And system RAM? What’s a realistic minimum these days? Icefall is a freeware, turn-based RPG, so by rights it shouldn’t require a leading edge PC, but I need a specific target to prevent limiting myself unnescessarily.

Howzabout 32mb video, and 512mb RAM? I think that fits most every PC you could buy in the last few years… and should be enough for some reasonable effects. Anyone got any thoughts on this?

My previous games (like the Five Hundred card game) didn’t require any installation at all: it assumed you had DirectX7 (the game just failed if you didn’t), and all of the files it needed were in the same directory as the EXE itself. You just unzipped it to wherever you liked, and double clicked the EXE to play. To uninstall, you just delete the folder.

Icefall is a little bit more complicated. All of the game’s data is still a relative path from the EXE itself, but this time it needs a specific Direct3D9 library installed (one that doesn’t ship by default with the rest of DirectX, but that other games may have already installed). So I need to include the DX Installer.

The Microsoft DX installer is smart enough to not overwrite a newer version of the same library (and you can only include the needed library – I don’t have to include the full DX9 100mb installer!), so I don’t need to worry about that stuff, but the question is, should I include this as an ‘optional’ installer that the user can run if Icefall doesn’t run immediately, or would it be less confusing to just make a full install program that all users run, and call this as a part of it (I could throw out options for the Start Menu etc. at the same time).

I’m leaning towards making a full installer, mainly because the DirectX library is designed to never be uninstalled (it’s a shared library, and other D3D9 apps might use it), and it would be very confusing for users to have an installer with no corresponding uninstaller… also, I may as well get with the program and use the Start Menu, registry etc. the way Windows programs are supposed to. Does anyone have any opinions on this?

Bonus trivia: I get quite regular emails about my Five Hundred game, since it made it onto lots of the large ‘freeware games’ websites and was quite well received at the time. One of the common questions people ask these days is “how do I uninstall it? It’s not in Add/Remove programs”. They must have forgotten that they never installed it in the first place, just unzipped. A few of them are still confused when I tell them to just delete it, so it’s clearly not what today’s users are expecting.

repeat
   Input;
   Update;
   Redraw;
until Quit;

The problem mainly comes in that middle section, Update. For any game, there are a variety of different states you can be in (main menu, options screen, credits, playing game) and for most games, “playing game” breaks down into a whole lot more states by itself. For my simple 500 Card Game, I had states “bidding”, “dealing”, “choosing kitty”, as well as playing. If you’re not careful, your Update procedure can end up looking like this:

Procedure Update;
begin
   case State of
      STATE_MENU:
         // wait for a menu click
      STATE_OPTIONS:
         // handle user input
      STATE_CREDITS:
         // roll some credits
      STATE_GAME:
         case GameState of
            GS_PLAYING:
               // handle user input
               // update some monsters
            // etc
         end;
      // STATE_ even more stuff:
   end;
end;

So far, so big and clunky. It gets worse when you have to handle nested state transitions: in my card game, someone could be playing, then go to the Menu and come back. So I had to have a variable ‘LastState’ that remembered where they were, so they could go back to it. But it’s worse than that, because they might go to the Menu, then go to the Options screen: and when they came back, they’d still want their current game to not be lost! My card game was simple, so I managed this as simply as I could: when entering the ‘menu’ state, the menu grabbed it’s own copy of LastState, and it restored this value when the other screens (Options, Credits etc) returned to it, so there was always a way back to the game. This was the simplest case, because every state had exactly one other state that it could be transitioned from (you couldn’t get to Options from Game without going through Menu).

For Icefall though, the stakes were raised. I wanted the Options screen accessible from in-game, as well as in the initial menu. And there are many more states that the game can be in, and some of them should not be returned to (e.g the “create character” screen), so rather than a gigantic and ugly Update loop, I went back to good old OOP and implemented a class-based state stack.

Icefall has a central “State Engine” that looks after the current state stack, handles transitions between them, and calls whichever state is ‘on top’ during the main loop. The State class looks something like this:

TIceState = class (TIceClass)
   constructor Create
      (StateEngine: TIceStateEngine;
       Transition: TStateTransition);
   procedure OnEnter; virtual;
   procedure OnLeave; virtual;
   procedure Update; virtual;
   procedure Redraw;
   // other useful state methods
   destructor Destroy; override;
end;

Essentially, for every state the game can be in, I have a corresponding class that defines it’s specific behaviour in Update. I can also do other ‘maintenence’ (e.g. ensure the right music is playing) by overriding the OnEnter and OnLeave procedures. The game can change states by constructing a new TIceState instance, passing it a reference to the state engine and describing the type of transition to use (e.g. whether to nest the state [for a trip to a Menu] or just progress to the new state with no way back [like a character create screen]). You can also leave a state just by destructing the class instance: the state engine will pop back to the next highest state on the state stack, or quit the game if there are no states left (e.g., you just hit ‘Exit’ from the Main Menu). 

The state engine takes care of nested states and transitions, and someone’s exact state in the game can be saved (if needed) by storing the entire state stack: while I’m unlikely to want the game to be saved while on the Character Create screen, it’s good to know I can safely save the game while in shops, or at any other point, without even worrying about special handling code to cover all the situations.

Another interesting thing I have done is move the game’s “loader” (the part that loads textures, sounds, music, fonts, databases) into it’s own state, and just made it the very first state that’s pushed onto the stack, and it takes a parameter to the state to transition to when it’s done. It takes the whole ‘loading’ step out of the main game code, which makes that much simpler, and I can make the loader just load the resources I’m going to need right now: some other state (like the credits) can always call it again later to load specific credit-y images.

I can also use the the same game engine to build other tools like the Map Editor: the only difference between the map editor and the game itself is that it compiles in a different set of states: when the map editor has loaded, it launches itself into a TMapEditorState instead of a TMainMenuState.

Overall, having a state stack is very flexible, quite simple to use and maintain, and overall a vast improvement from the ‘giant case statement’ I was using previously.

We’ll use another example from Icefall to illustrate the differences. Icefall has a central ‘world view’ that shows the player and their immediate surroundings (items, monsters, terrain, etc). The world view also shows animations (e.g. fireballs, weapons swinging, speech bubbles, etc) and it’s the animation code that we’ll be looking at in detail today.

I designed this feature around each animation being a class instance, with the class methods and properties making it easy for the game engine to control the details (lifetime, location, save/load etc etc). I knew I’d have several different types of animation, so my initial implementation chucked all that ‘management’ functionality into a TAnimation class, and left virtual methods for  things like Process and Draw for descendents to implement. After creating a few basic animations, my class hierarchy looked like this:

TAnimation
   TAnimText
      TAnimSpeech
      TAnimTexturedText
   TAnimTexture
      TAnimMissile
      TAnimExplosion
      TAnimMelee

Animations with text (i.e. picking up an item) were a subclass, and speech bubbles (or text with a textured background) were subclasses of that. Missiles (like fireballs) were a subclass where the animation moved from one place to another (and was rotated to face the right direction), and Explosions were in one place but had a series of animation frames over time. Melee animations showed a weapon and some motion-blur, sweeping out to attack a monster/player.

The problem with this system, which I discovered after adding TAnimTexturedText (specificially to show damage-dealt as a number on a bloodsplat-graphic background) was that most of the subtypes only varied in very small ways, and the overhead of naming, constructing and using each subtype took more effort than defining the subtype itself. Also, the ‘event’ system I was setting up for Icefall was supposed to allow for animations to be defined dynamically in response to any spell or event (and new events added in data files without recompiling the game) – but the code that supported this was going to be very complex and ugly if it had to choose between all of the different constructors each time and pass a specific set of parameters to make it happen.

So, I rewrote the animation subsystem to bring any functionality that I could possibly re-use into the parent class: now, all animations had a Texture property, a Rotate property, Frames, Movement, Sound… which could all be left at Nil or 0 if not needed. My new, composited animation hierarchy looked like this:

TAnimation
   TAnimText
      TAnimSpeech

As soon as I did this, I found that it was not only easier to manage the sources, but that features of the parent class ended up getting used more often than I anticipated: e.g. giving an explosion a random value for Rotate made each explosion look slightly different, and I could apply a small Movement value to Text to let it ‘float’ upwards from where it first appeared: new and useful functionality essentially for ‘free’.

Note that I kept AnimText separate from the parent, because there is some substantially different functionality: it has text (which directly contributes to the size and position of the anim), which is also dynamic, and there is some special logic to ensure two text animations don’t overlap each other. It made sense to move this code out into a specific class where it could be closely tweaked. Speech is different again, because there is a “speaker” creature that it it linked to: the speech bubble needs to move around with it’s speaker, disappear if they die, etc.

In summary, now that the TAnimation class is composited, it’s significantly ‘better’ code than before:

• Fewer types to worry about
• Much easier to follow the logic of the code in a single class
• Can trivially re-use functionality developed for one subtype in others
• Much easier for other code to utilise this class effectively

So, my conclusion in this small series is:

Use composition in your classes, unless there is substantially different behaviour, or external code needs to interact with a specific subtype in a special way (e.g. TAnimation itself is inherited from TWorldObject, because the world view needs to interact with animations in a specific way).

Next time, I’ll find something different to ramble on about.

Inheritance

When learning OOP, inheritance is what you learn! Create a common, generic ancestor-type class, and create new classes for specific game objects which inherit from, override and extend the functions of the ancestor. Repeat as desired. Let’s look at the consequences of following this model:

Pros:

1. It’s easy to locate all functionality belonging to each type: they’re together in the source for the child class.
2. It’s easy to write an appropriate constructor for the type; so you know the classes internal state will be consistent.
3. It’s easy to guard against the wrong type being passed to a function at compile time: If you have Function AttackMonster(WithWeapon: TWeapon); the compiler will prevent you passing a TItem that isn’t a TWeapon.
4. You can specify abstract methods in the parent where you know the divergent behaviour will be, and the language and compiler will help you get there and warn you if you’ve left something out.

Cons:

1. You end up with *lots* of different classes – which may be in lots of different files.
2. Some of the classes can be really, really small… e.g., a single method override.
3. When looking at the child class implementation with a call to the inherited parent, you don’t know exactly what the parent does.
4. If two different children of a common ancestor need the same functionality, you have to code it twice.
5. Code that constructs instances must take care to call the correct constructor.
6. You can’t “switch” a child to a different type; you need to destruct it and create a new instance of the other type.
7. Greater risk of circular-references if your child classes need to interact with each other.

You can see the pattern forming. The Pros of this model tend to be that things are easier to setup up-front, when you’re initially coding the classes. The Cons tend to hit you later: when you’re extending functionality, or just coming back to the code after time spent elsewhere.

It’s also possible with this model to really make life impossible for yourself. If you come up against Con #4 and are tempted to move some of that common functionality in the parent class, congratulations: you just blasted Pro #1 and debugging and maintaining this code just became a nightmare, and now the parent needs to duplicate some child state in order to know which of these “optional-children” operations it should perform. Ick!

Note that this inheritance style is still arguably a gigantic code-safety and readibility improvement from old-style procedual code. The question is, can we do better? In Part 3, we’ll look at the alternative model of Composited classes.

I tested Icefall on Windows 7 for the first time today (having developed & tested exclusively on Windows XP SP 3 up until now). It worked perfectly, in fact it ran a little more smoothly than it does on the same computer on XP.

It’s always reassuring when your application turns out to be forward-compatible, it’s a good sign my low-level code isn’t performing any horrendous unsupported operations, SimCity-style.

At any given time, the game will be operating dozens of different classes and hundreds of instances of those classes, with the majority of them representing either individual game objects (an item, a monster, the player) or a piece of the user interface (a button, an animation, etc). As you’d expect, many of these classes inherit from other classes (e.g. the button class is inherited from the generic UI class) but the question of exactly how much inheritance to use is something that confuses many people – and if you get it wrong, your code will suffer. So let’s take a closer look.

Inheritance vs Composition

Turning a program’s logic into a group of classes seems easy (hmm, my game has items, let’s make a TItem class!), but choosing the right combination of classes is harder than it looks. Like everything else, the more complex your application is, the harder and more important these choices will be.

One common choice is to do everything via inheritance. You make some ancestor classes which contain only the logic that will be common to all descendents, and you create inherited classes to cover all exceptions or additions to that logic. This style is called inheritance for obvious reasons, and lots of newcomers to OOP start like this. Let’s create an example that shows this in action:

Icefall needs to know an item’s worth (in gold) to a shopkeeper to allow the player to buy/sell it. As items in Icefall can have randomly generated properties, we can’t define the worth of everything at compile time (and even if we could, there will be hundreds of different items in Icefall. Don’t specify things you could calculate. I’ll talk about this another time). So we need a method in the TItem class to calculate the item’s worth for us.

Inheritance

The inheritance solution might look like like this:

TItem = class
   function Worth: Integer; virtual;
end;

function TItem.Worth: Integer;
begin
   result := ILevel * 20; // ILevel is another property.
end;

Nice and easy so far. The item’s worth is calculated as being 20 times it’s ILevel (item-level). But what happens when we want to make some items (let’s say weapons) more valuable than others? The inheritance solution is to build on the existing code and do this:

TWeapon = class (TItem)
   function Worth: Integer; override;
end;

function TWeapon.Worth: Integer;
begin
   result := 100 + ILevel * 50; // Weapons are worth more
end;

We have overridden TItem’s Worth function with a new one just for TWeapon. We just have to remember that when we’re creating items, if it’s a weapon we need to construct a TWeapon class instead of a TItem class to hold it, and the right Worth function will be called automatically.

Composition

Meanwhile, another style, often referred to as composition, says to group similar functionality together, and use members or properties to determine the appropriate behaviour for each instance:

TItemType = (ITEMTYPE_NORMAL,ITEMTYPE_WEAPON);

TItem = class
   function Worth: Integer;
   property ItemType: TItemType;
end;

function TItem.Worth: Integer;
begin
   case ItemType of
      ITEMTYPE_WEAPON :
         result := 100 + ILevel * 50;
   else
      result := ILevel * 20;
   end;
end;

Already, for our tiny example, the two implementations are looking considerably different. The composited version defines a class property called ItemType that stores what type of item this instance represents, and the Worth function contains all the functionality for both item types (I used a case statement instead of a simple if, because I suspect I will end up with more than two item types).

p.s. Icefall, of course, takes much more into account to determine an item’s worth: it’s rarity, any enchantments, whether the shopkeeper likes the player, etc etc. But that wasn’t relevant for this discussion

Conclusion

So which is better? What are the pros and cons of each style? Tune in next time to find out!

Initially, I looked at real-time. This is the only choice for multiplayer (turn-based multiplayer just doesn’t flow) and all of the ‘modern’ games follow this formula. So I developed a playable prototype along these lines. While still using a tile-based world, this would allow freeform movement (characters were not tied to specific ’tile’ locations), and could have supported multiplayer quite naturally. Using placeholder graphics borrowed from games, I developed a prototype game that ran in real-time:

Prototype of Icefall in real-time

The prototype accomplished it’s goal, which was to determine whether real-time was feasible, and what the challenges would be. After getting the prototype running with some simple monsters, I had figured out the challenges I would be facing:

* Pathfinding dozens of monsters around a complex environment, in real time, is very hard.

* Real-time locks you into a specific travel speed, and can make ‘huge worlds’ time consuming to explore.

* It was very hard to find the right ‘game speed’. Too slow and players get frustrated and bored. Too fast and the monsters can kill the player too quickly. I wanted players to dictate the pace: in Angband, you can play it very quickly or very slowly. I couldn’t find how to do that with real-time (a “game-speed” slider would not accomplish this).

* It just didn’t feel like the game I wanted to make. (I have played too much Angband).

* It didn’t quite ‘fit’ with other concepts I had already thought about, as well. e.g. I already knew that I would be implementing a ‘monster memory’, which tracked monster kills for players and stored any weaknesses/vulnerabilities/etc the player observed. With a real-time game, I couldn’t figure out how the player would access the monster memory without pausing the game (which would be ugly for multiplayer) or just looking it up academically after the battle was already over (not very useful).

Making the decision to go turn-based was a big ‘constraint’ in itself, but with the decision made, it makes many many other features much easier, and seems to make the player’s overall experience more relaxing.

This final key decision having been made, I was ready to start some actual coding. Next time, I think I’ll mix it up a bit by looking at an actual code sample…

Decision: Role Playing Game

Many of the very first games I got hooked on were RPGs: Moria, Ultima 5, Death Knights of Krynn) but each of them always had things I thought “if only it did…”, so creating my own game would be my opportunity to put that into practice. I’ve started to create many RPGs over the years, but I’ve never finished one or even got it largely playable. This was due to various different causes, either I’d hit a wall somewhere (pathfinding, AI, memory, and graphical speed have all defeated me over the years) or a new game (Halo, World of Warcraft) would come along and I’d abandon my development for long enough that I forgot the intricate workings of the code, and rather than dive back in I abandoned it.

So I’ve still never made a role playing game. Time to fix this!

Another good reason is that it’s within my ability. Making something like a first-person shooter (at least, a good one!) just wouldn’t be possible for me because having decent graphics is too large a part, and my graphical ability… well, let’s just call it “Programmer Art” and move on.

Decision: Free Pascal

Having decided on the type of game I’m making, the next step is to choose the programming language. These days there are more languages than ever, and some of the new ones are really good. C# + XNA would be my ‘high level’ choice, it makes it ridiculously easy to get graphics on the screen and a game up and running…

But…

I’m not just programming to make a game, I’m also doing this because I want to be challenged. I want to take fundamental, low-level control over everything my code does in every situation. Using a low-level language (C++, Pascal…) means there’s a lot more up-front effort involved (getting graphics on the screen isn’t one line of code anymore, it’s a couple of hundred) but, to me, also much more satisfaction when it works!

When I want to add a function, I can’t just copy a C# code snippet from the internet, I’ve had to go away and install the DirectX SDK, read the documentation for each instruction, look at the example code, re-interpret it to suit what I’m trying to do, and play with it until I get it to compile. The reward (and the knowledge that is acquired as a consequence of having to research every call) is worth it. (This is the same reason I’m not using an existing ‘game engine’, I’m creating my own with LX7).

Having decided to use a low-level language, my choices are C++ and Pascal (I don’t want to learn another language at the same time as creating a complex game, the game at the end would suffer too much as a result of my learning-while-doing). I chose Pascal because, I’m not really sure why, I just “like it”.It has all the language constructs I’m going to need (primarily Classes), and I like that it’s not quite as low-level as C++, which gives me a little bit more room to spend on game logic but without having to sacrifice anything.

Finally, choosing between my Pascal options, FreePascal and Delphi… I think FreePascal is superior! It definately compiles faster and makes smaller executables. It doesn’t support Windows GUI very well, but Icefall like 99% of games will have custom UI anyway. It’s also free. Finally, the platform is far less common than C++, and there aren’t many games in development using it (especially on Windows), so when the game is done and LX7 (the graphics/game engine I’m creating to support Icefall at the same time) is finished, I might have something to give back to the FreePascal community. So it’s settled!

Next time, I will talk about the third key decision for Icefall: whether to make it real-time, or turn-based?