dave news

Game programming

[NYI] Stuff


This document describes my intentions and plans for this web site and for the code that I'm going to write (maybe, someday, unless there's something good on TV).

First off, I want to talk about my target platform. Short-term, I'm going to be writing everything in C#, targeting the .NET Framework on Win32. There are a few reasons why I want to do this. First, like it or not, C# is something you're eventually going to have to think about if you're writing games to target future versions of Windows. It's starting already; DirectX 9 has C# bindings for most of the components, and the performance is surprisingly good. Microsoft has indicated publically that they intend to promote a .NET-based platform as the major platform for app development for future versions of Windows, so this may well be a case (like DirectX itself, once it got useful) where either you jump on the bandwagon or it rolls over you.

Second, there's a growing amount of interest in C# and the .NET platform (and its free reimplementations like Mono). Browse sites like SourceForge and you'll find a good number of people doing things like providing OpenGL bindings for C#. Despite this, I haven't seen a lot of people talking about C# with respect to the low-level game libraries that make up the core of any good gaming engine.

Finally, I like C#. These days, I'm lazy, and C# is just easier. I haven't written any C++ code for months, and the likelihood that I'm ever going to get far enough along where the performance difference is critical is really slim. If worse comes to worse I can always port to C++ from C# (which isn't as awful as it sounds), but I don't think it'll ever be a problem.

Okay, so what do I give up by using C#? There's two main things that are going to be difficult: time and space. No matter what, with the current .NET platform, C# code will run slower than real native C++ code. Most of the time that won't matter, but it will be something I'll have to keep in mind. As far as space goes, managing memory under C# is long as you don't care about it. Unfortunately, when you start to talk about large games which have a bunch of resources resident in RAM, you will care about your memory management. I'll try to show some ways of having better control over what's going on with your app's memory usage under C#.

So what games do I want to write? I mentioned on the front page that there are three that I'm thinking of. I probably won't write all three (or even one), but I think they're interesting usage cases to keep in mind while working on the core libraries.

The first, and simplest, game I want to write is an extensible (preferably by end-users) solitaire game. I've been playing this great game called Pretty Good Solitaire for years. It has something in the neighborhood of 3379085197 different solitaire games that you can play, and a wizard where you can create your own new games, to an extent. I think it would be fun to write a nice script-driven solitaire system that had a "construction set" mode. Although there's some complexity involved in designing a sufficiently rich scripting system, this is a pretty simple game. The resource requirements and performance requirements are minimal, which makes it a nice low-end test case. The real complexity is in UI and state management.

The second game, which in order of complexity is the porridge that's just right, is a puzzle game in the same vein as The Fool's Errand. Strucuturally it's potentially similar to a solitaire game, but everything's bigger and more complicated. For example, a puzzle game with varying types of puzzles and an overarching metapuzzle will have need for more different kinds of art resources than a solitaire game; its scripting system will have to be more complicated too.

The last game I'm thinking about, which continuing the metaphor is the porridge that's way too damn complicated (maybe it has currants or something), is a single-player CRPG along the lines of Morrowind. Morrowind is a fantastic game. There's a ton of content, a ton of things to do and see. I played for hours and hours. Every time I played I wanted to make a game just like it. It has huge memory, processor, and disk requirements. It's a pretty hardcore game.

Now that I know what I want to do, how am I going to do it? Well, I'm not really sure yet. My plan is to write up a small design document for each of the three games, and then go from there. Wish me luck.

Game links:


File Manager

Resource Manager


Solitaire spec