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.

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.

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.