Pathfinding is hard in the sense that it takes a lot of computing power to accomplish. And it doesn’t get easier with newer hardware either – as computers get faster, games generally incorporate more complex terrain and more inhabitants, so pathfinding stays complex. For example, the average RTS devotes 30% of CPU time to video (prepping stuff for the GPU, plus UI etc), 30% on AI & scripts, and 30% on pathfinding (the remaining 10% on everything else).

Icefall uses two different pathfinding algorithms to improve efficiency. Being turn-based, I don’t have to worry about time-critical calculations, so paths should always be optimal path (it’s acceptable for realtime games to take a ‘best guess’ or suboptimal path – you can see this in games like Dragon Age or Diablo: if you click somewhere far away or obscured by obstacles, your character will try to walk there but they get stuck). Let’s talk about how Icefall’s pathfinding works specifically.

A* Pathfinding Algorithm

A* (Wikipedia entry) is the method Icefall uses to calculate the player’s path. If you click on a distant doorway or shop, your character will move towards it using the fewest steps possible, regardless of how convoluted the actual path is.It works by starting at the player’s current location, and looking at all of the neighbouring squares (all the squares that the player could reach in a single move). For each of those squares, it looks at the *absolute* distance between this position and the goal position (that the player is trying to reach). The absolute distance is just ‘the distance in a straight line, assuming there were no obstacles’.

This (simplified) example shows a very simple dungeon with a start and goal square. The three initial candidate squares have been marked with red circles (this is called ‘the open list’ of squares), and the number within represents the absolute distance between each square and the goal.

Initial step of A* evaluation

The algorithm selects one of the squares from the open list that has the lowest absolute cost. So in this case, it could select either of the “6″ squares. Let’s say it picks the bottom one (to try and go in a straight line). The process is then repeated, with all of the neighboring squares from our new square evaluated for their absolute distance to goal – but with a new step. We add to that distance the number of squares that we have already taken to get there (in this case, 1, since we’ve only moved once so far). Note that we also briefly consider the start square, and the other two red circles, but we discard them because they’re already in our ‘open’ list.

After evaluating the bottom '6' square

We’ve found two new candidate squares to add to the ‘open list’ – both are of absolute distance to goal 5 and have a distance travelled of 1 (+1 in the diagram). Because we’ve now fully evaluated that bottom ’6′ square, it’s moved from the open list to what we call the “closed list” (which just makes sure we don’t end up re-evaluating squares that we’ve already done).

Now, the process continues by picking one of the squares in the open list with the lowest absolute distance + distance already travelled. If multiple squares have the same total, we pick a square with the highest distance already travelled first – this ensures that if there is a direct path to the goal, we find it immediately. If we continue this for a few move evaluations, we’ll end up with something like this.

After evaluating 4 more squares

We evaluated the next two squares in the dead end, as they both had a combined total of 6, and they had the highest distance already travelled values. But then we reached a dead-end there (there were no valid moves from that 3/+3 square), so we next evaluate the remaining 5/+1 square. on the open list. It finds two new squares to add, a 6/+2 and a 5/+2. After this picture, the lowest total value that’s still open is actually the original red circle (it has a cost of 6. Our other open squares have values 7/0, 6/+2, and 5/+2). When evaluating it’s neighbors, we find that it has a shorter route to the square directly above it. Instead of 6/+2, it can be replaced with 6/+1 – this is fewer squares travelled to reach the same goal. So this square value is replaced in the open list. Evaluation then continues. Eventually, we’ll end up with the following table, and the optimal path.

Final path determined

In this contrived example, we end up evaluating almost every square, but the important part of this algorithm is that it will ALWAYS find the MOST EFFICIENT path possible. Apply these steps to any path (assuming the path can actually be reached), and you will get the best possible result in the end (note that this path has effectively “skipped the corners” in the tunnel, without us having to do any special coding to take this into account).

Summary

So, that’s how Icefall calculates paths for the player. Seems easy enough, but you can see a lot of squares may end up being evaluated (especially in a big dungeon that has dead ends). So, how do we calculate the pathfinding for monsters? Since there may be dozens or hundreds of these in an Icefall dungeon…? Stay tuned for next time!

The audio engine is the latest of these. It has been redesigned and now supports multiple channels of audio, with their own volume/mute controls, and a master control that lets you mute everything in one fell swoop. The game also ploughs on if it tries to initialise the audio library and fails – now it just skips loading any audio resources, disables and greys out all the audio UI settings, and carries on. Much better than popping an “Audio engine failed to initialise. Icefall will now exit” error message

Here’s a screenshot of the new Audio page in the Options dialog (game music and sounds respond to any of these being changed, in real time):

Audio Options

Also, I’ve been using C# for a couple of projects, and I wanted to step back from the managed, garbage collected goodness for a while. So I decided to forego all UI toolkits and just write direct Win32 API calls to create all my UI elements. Painful, yes! But fun too  Here’s the application:

WinNetStatus Application

It also includes full FreePascal source code. I managed to remove all external dependencies on other code, so it will compile solely from the FPC Win32 RTL. I’ve also commented almost every line, so on the off chance someone is as crazy as me and wants to see how to program the raw Win32 API from FPC, this is probably a good example!

You can download the application (and source code) from this link.

That happened to me with Icefall’s UI bar. Originally, my layout placed the player character’s health and mana bars in the bottom left corner, with the player’s current target displayed next to them. The action buttons and experience bar were in the bottom centre, and the status window was on the right:

Original UI Layout, with player/target health bars at the bottom left.

This made sense to me, and was based on Angband displaying the player/monster health stats in that corner. However, when I got a couple of friends to play it, both of them struggled to track the player’s health without me explicitly pointing it out, and one got the health bar confused with the experience bar in the centre.

So, as a result of this, I did some tweaking of the layout and the UI graphics. I’ve put the player and target information in the centre, and shuffled the action bars to the left hand side. I have to admit, after playing for a while, this configuration makes more sense:

New UI Layout, with player/target health bars in the centre

I also took the opportunity to update the UI backdrop to make the player/target area jump out a little more with a “leather canvas”-type frame.

The lesson? Always test the UI on people who have never seen the game before, and be resigned to the fact that you might have to change it.

Although I haven’t posted anything for a long time, I have still been (occasionally) developing Icefall. There are three new concepts which I have introduced since my last Icefall post – two enhancements to the visual engine, and one to the game core. Today I’ll talk about one of the visual enhancements – seamless textured walls.

If you look carefully at some earlier Icefall screenshots, you’ll see the white and teal-coloured wall graphics. I actually thought these were pretty cool at the time (certainly an improvement over most Angband clones’ “single tile for every wall”, as they had a slight 3D aspect, and wall tiles “linked up” with those next to them. The only thing I wasn’t happy about was when there was a wall that was exactly two tiles thick, and the player could see both sides (e.g. they were two separate rooms), these ‘wall texture’ bubbles would appear in the centre of the wall – this was because the tiles didn’t check their diagonal neighbours, so they had to assume there wasn’t wall there (checking in the old engine would have meant I would need 256 different wall tiles for every combination of neighbours, instead of 16 when they only link up horizontally and vertically).

Old-style Icefall wall tiles

But, this was fixable! I have recreated the whole wall-drawing algorithm so that it now takes three passes instead of one. The first pass draws a nice ‘wall texture’ (the actual texture can vary depending on the level, so the deeper you go into the dungeon, the walls themselves will start to look more sinister).

Secondly, an “outward-facing” wall texture is applied. This fixes up all the edges between wall tiles and ground tiles, similar to what happened before except that this tileset has no diagonal corners. Finally, another pass is made over all wall-edges, looking solely for diagonals and filling those in as needed.

Although this takes more GPU power than the old method, GPU power is not something I’m really worried about for Icefall, as the visual engine overall draws the game world very efficiently. (I must talk about this sometime if I haven’t already). And the results, hopefully you will agree, look a lot nicer!

New wall-drawing algorithm.

Next time (which I promise will not be as far away as this update was from the last!), I will talk about displaying the player character themselves – as they’re now displayed in the gameworld with the equipment/weapons they have equipped!

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

Coincidentally, this is the same reason I don’t use managed languages like C#. I quite like knowing about things that managed code wants to hide! The increase in development time is not that important to me, I have no external deadlines to meet.

However, there are points beyond which it’s not practical for me to write the code myself, because it’s either A) incredibly complex, B) boring, C) proprietary, or D) so ubiquitous that it really doesn’t need reinventing. e.g.: writing code to decode an MP3 file into raw audio. I could *potentially* do this, but as it belongs to all four categories, I’m really comfortable with not doing it myself!

Currently in my Freepascal development I am using three 3rd Party Code libraries every day. And they are all excellent, both in terms of features and being easy enough that I can ‘plug them in’ to my own lx7 game engine with very little work. Here they are:

DirectX – by Clootie

No, not DirectX itself (that deserves a whole separate subject!), but a port of all the headers/structures/glue code necessary to use DirectX in Freepascal. This gives me low level access to every function and interface used by DirectX itself, and the port is so perfect I was able to build my own graphics engine on top of Direct3D just by studying the (C++) DirectX SDK. Nothing is missing! Everything works! You probably won’t appreciate how rare this is if you normally use C++.
http://www.clootie.ru/

BASSfpc

BASS is an Audio Library that makes it *dead easy* to play sound and music files of many different types. BASSfpc is the FPC port of this. BASS handles MP3s, WAVs, OGGs, and about a million other sound types, and it does it efficiently and with the bare minimum of code needed (literally about 4 lines of code to init the library and start playing an MP3!).
http://www.un4seen.com/

LNet

The newest addition to my Libs folder. LNet provides a set of classes to implement networking, at the very lowest level, without adding any additional features or complexity. That’s exactly what I needed, because I want to add my own features and complexity! There are many many network libraries out there, but (for Freepascal at least) LNet definately gets my vote, for being simple, class-based, and extremely elegant.
http://lnet.wordpress.com/

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.

The rule is:

Provide gamma and volume controls, and separate music from sound.

Pretty simple. But essential! The good news is, the AAA titles pretty much universally support this now. And it’s a good thing, as I use these settings all the time.

I have an Xbox 360 but, unlike most Xbox 360s, mine isn’t connected to a TV – it plugs into a second DVI port on one of my 22” widescreen PC monitors. This is awesome because I can run it at 1680×1050 and games look beautiful! (handy bonus: I can web-surf on my other screen while waiting for Matchmaking in Halo 3)

BUT my monitor has a very different colour profile than your average TV, and games with a lot of contrasting light/dark elements can look really bad by default. Gamma controls in your game are pretty essential for me to see the graphics the way the designer intended. I’m sure there are other people in similar situations or even wildly different situations who also need gamma settings. Your game needs to support them too!! And since there’s nothing on the “con” side of the ledger that could make it a bad idea, you have no excuse!

Providing separate controls for sound/music: Music is awesome but people like to be able to hear the game sounds sometimes! Particularly in a ‘competitive’ environment, or simply when your game is providing an audio narrative (GTA4 is an excellent example – the “in-car radio” music is huge and contributes to the GTA atmosphere, but you need to turn the music volume down to be able to hear what mission you’re being given via the cellphone). If I’m playing an FPS single-player, I might turn the music up, but in multiplayer I want to use every audio cue the game gives me for competitive advantage, so I need to kill the music or at least turn it down.

Just like with the gamma controls, the good news is this is pretty universal now. But there are still Flash games that don’t separate them (and, even worse: there are plenty that have no Volume settings at all – sound is either On or Off). Sound might *add* to the game experience, but I’d like to set it so that it doesn’t completely drown out my background music, thanks! Vista and Windows 7 allow you to set the volume controls at the “application” level, which solves the problem for me specifically, but it doesn’t help anyone using XP (or anyone who doesn’t know about that feature). Support them too!

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.

After working on Icefall for so long, I was amazed at how quickly I was developing the code for the new program! When writing Icefall, I might create a single new source file in a night’s work, or maybe make 4 or 5 moderate improvements to existing code. On the media app, I was churning out half a dozen new source files at a time, and I had the entire application virtually finished in about three days.

Thinking about my observations of the difference, I eventually came up with the following formula:

Development Speed = Effort / (Complexity * Quality)

For a given amount of effort, I can get a lot more done on the media app, because A: it’s far less complex, and B: I care much less about the quality of the code. Multiply those factors together and you can see why Icefall development is approximately an order of magnitude slower: it’s a complex system, all the code has to be correct, robust, speedy, and extensible.

I’m convinced this is part of the reason why so many “we’re going to create the perfect application, that does everything and is open source” projects never reach version 1.0. With all the effort in the world, they’re just throwing huge numbers on the wrong side of the divisor.

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.

To me, that is not only a frighteningly ignorant and dangerous way to develop software (you’re not going to discover caveats & usage notes by browsing RegEdit!) but of course this is not the supported way to do it (how could any sane developer think otherwise?), and of course that app would have broken immediately on any new of Windows had MS not added a compatibility shim to watch for that program checking that buggy key, and substituting in a quick call to obtain the real value…

This isn’t backyard programmers writing in VBA in Excel to accomplish some one-off business task, either.. it’s commercial software that did this, written by professional developers and sold to unsuspecting customers for big cash. Scary stuff.

The only question worth pondering here is: was this ‘grab something promising out of the Registry’ technique better or worse than just hard-coding “C:\Windows\Fonts\” into the application? (I’m not 100% sure but it seems very likely there’s a shim out there for programs that did that, too.)

Why Allow Windowed-mode:

It’s more convenient for your users. Some users multitask (gasp!), even while playing games. This is much harder to do when your game is Fullscreen. I suspect this is a part of why games like Minesweeper and Solitaire get so much play-time. They’re built into the OS, sure, but you can also fire them up and play while you’re waiting for something to download/compile/whatever. Very handy!

It’s more convenient for you. Debugging is hard, and debugging fullscreen is harder! My own game engine (in debug builds) has a feature to throw a debugging/log window up so I can watch internal game messages etc: you can’t do this if your game is always fullscreen. Not only that, but if your game crashes at some Direct3D stuff (which can happen in early builds, before you lock down your video interface code), it’s very tricky to find a cause when you’re staring at a blank screen. A blank window on the desktop gives you more context and options.

It makes paying certain Windows taxes more obvious. If you’re running in Windowed mode while developing, you’re going to be hitting the titlebar close button, you’ll be minimising/maximising your game Window, or maybe just clicking other apps, stealing your game’s focus. Because you’re doing these things, you’re much more likely to take the time to ensure your game handles them correctly. Fullscreen games are required to handle these situations too, you know: but some of them never get around to it! (Civilization 3, which is always “fullscreen”, can experience a rather ugly crash if I dare to click something on my second monitor while I’m playing).

It’s future proof. You might think your fullscreen game is pretty cool, what with it supporting resolutions right up to 1920×1080, but who knows what the future holds? How well will your fullscreen game look on some giant desktop running 12,000×12,000 pixels? Or do you just expect no one will be playing it then? (if you don’t, then code this way: you’re sure to be correct). Windowed mode doesn’t solve this completely, but it gives your users more options.

Ok, hopefully you can that there are always scenarios where that option would be valuable, but you might not be convinced to allow it in your game. Let’s take a look at some reasons why not:

Why NOT allow Windowed-mode:

It’s hard to code. Oh no, now all of your video code has two scenarios to account for! Well, actually, no it doesn’t. Once you’ve initialised Direct3D correctly, none of your other code even needs to *know* it’s drawing to a windowed area of the desktop. And initialising Direct3D to support either Windowed or Fullscreen mode is easy! I’ll bet you $5 that the sum total of video code required to support this option is LESS than the amount of code required to present the option to the user and store the result.

Fullscreen is more atmospheric. Atmosphere is important in my game! By all means then, make fullscreen the default. Plenty of games do. I’m just asking for the option!

But I want to retain control. Fuck off! The user is in control: it’s their computer. Besides, if the user really wants to window you, they can do it: they can fire up a virtual machine and lock you inside it: good luck getting into fullscreen mode then. Of course, if it’s that important to them, they’re more likely to just uninstall you and go play something with a windowed option.

And there you have it. Why I believe every game should support Windowed-mode!

• Respond to Windows messages correctly
• Respect user action (don’t silently cancel a Sleep request)
• Non-standard installs (don’t assume C:\Windows!)
• Run fine as a Standard User
• Respect the user’s settings

Raymond talks about more complex taxes too (internationalisation, heirarchical file systems), but I’m sticking to what I’m comfortable with!

Unfortunately, amongst all applications, games appear to be the worst at being good Windows citizens, there are far too many games out there (not just freeware ones either) that don’t pay any of the above taxes, and (to sustain the metaphor) some start trying ‘tax-fraud’ schemes like:

• Trying to disable Alt-Tab
• Refusing to be minimised (automatically restoring themselves after 1 sec)
• Preventing the system from shutting down

I might make this another series because there’s plenty to talk about, and most of it’s not even that difficult these days: you just have to be aware of the situation, and what the correct behaviour is. (I must admit I never gave thought to multi-monitor situations before I got my second monitor).

For now though, I will limit myself to a list of ten ‘golden rules’ which I believe all games should obey, at a minimum (not all of them are Windows taxes – some of them are just treating your users properly). In fact I will expand on some of these in later posts too, because they’re worth talking about.

Top ten Golden rules for Games: being a good Windows application

1. 1. Fullscreen games: always allow an option to run in a Window.
2. 2. Provide gamma and volume controls, and separate music from sound.
3. 3. Always allow your game to be paused, saved and quit. At any time.
4. 4. Provide a way to skip anything non-interactive: from cutscenes to credits.
5. 5. Respect multi-monitor: If you were dragged to monitor 2, next time open on monitor 2.
6. 6. Respect the filesystem: don’t open files in Read/Write mode if you only want to read from them.
7. 7. Respect security: A game does not need an Administrator account to play!
8. 8. Respect UI settings: if the user has selected ‘Use Large Fonts’ in Windows, use larger fonts in your game!
9. 9. Respect sessions: if the user logs off/hibernates/shuts down, handle it gracefully. Don’t try to block the action, and don’t lose their progress.
10. 10. Adapt to a changing system: if you last opened on 1680×1050, but the system now says the monitor can’t support that, open in a res it can support.

I’ll talk about how to implement some of these (and why they’re so important) in future posts.