Design decisions

I said I'd talk about why I'd decided to use C# and OpenTK, so I'll do that here. Along with why I'm developing reusable code, which is something of a two-edged sword if you're not careful.

Why C#?

To be blunt, because I can get from clicking "start project" to a working OpenGL window in under 2 minutes. With OpenTK installed on the system there's minimal messing around with dependencies etc, etc.

On top of that, .NET has a very, very rich network of libraries. VB also has access, but it's not as flexible a language. There are other options for adding useful libraries to C/C++ but you have to take time to set things up, which can take a long time and there's also issues with linking things so they'll "just work" on other people's machines. C# with always "just work" on a Windows box and with mono installed will most likely "just work" on both Linux and OS X as well without requiring me to release 3 copies of the game.

Why OpenTK?

Once C# was decided on, there were several things I could use for games programming. The most obvious is XNA, which is Microsoft's release and is easily portable to the X-Box 360. However, it's Windows only and is based on DirectX, which I've never particularly liked.

SDL.NET was another possiblity, but this works in 2D and seems to be abandoned in recent years. It was more active around .NET 1.1 than any other time and much of the coding harks back to that era, C# and .NET have moved on since then.

Tao is another possibility and would be a solid choice, but again it looks abandoned.

So that brings me to OpenTK, which has almost direct calls to OpenGL, contains a very quick and easy class called "GameWindow" (which allows that 2 minute setup I spoke about), contains maths classes that are almost (but not quite) directly portable with XNA, has support for sound playback and has extensive input support for keyboards, mice and joysticks. It also supports these features across both Windows and Linux, with most supported on OS X (I think sound playback and joysticks are a bit iffy, but I have no Mac to test them on).

Also note, I'm discounting anything that isn't free here.

Reusable code

Working out how much of a game to make reusable is more complex than it first appears.

For example: You could build an entire game engine that could be used for multiple games, but it should be pointed out that this is a large project in and of itself and if you just want to write a game then it's advisable to write a game-specific engine which will be much less flexible, but you're more likely to complete.

For my Game-A-Month project I've hit somewhere in the middle ground. Certain parts of my games will be reusable, but the game itself will be built largely from scratch each time.

The main part that is reusable is are the user interface components. Specifically this is a lump of code that contains the decision making for what is happening in the game at the moment, making sure things that are supposed to be rendered are so and those that aren't, aren't, making sure when a key is pushed the game takes the right action, etc, etc.

In Whirligig it deals with where and what the mouse has clicked on, who's turn it is and what to display on the screen at any moment. It will also deal with the main menu and shop when those are implemented.

In Hoshi it just deals with the basic rendering right now and not a lot else, although it also knows when the player dies and deals with ending the game; this bit of user interface is particularly clever as internally user interfaces lie on a stack, the first on the stack is the 'main menu' then you stack whatever else the user visits as you need it. When the user finishes with the user interface it just pops the stack and the user is automatically returned to the previous interface. If the stack is empty the game ends.

This allows me to very quickly knock together a group of components I want rendering into a user interface, chuck it on the stack and have a game prototype. This is the stage both Hoshi and Whirligig are currently at. When I want to add a main menu, I just create the menu as a separate interface and when the user selects "play game" just push my 'prototype' interface onto the stack. When the game ends, the stack is popped and control drops back through to the main menu.

Other components are designed to work with this interface and mostly consist of fairly mundane things like windows, labels, buttons and progress bars (all showcased in Whirligig) which inherit an interface called IUIElement. This interface allows me to create and add a new element to a user interface very quickly. For example, the radars took ~30 minutes to knock up in the end and the energy bar not a lot longer, then I just use an AddControl() call on the interface and they're rendered the same as anything else.

This is all very useful, but I take some performance hits for it. Interfaces suffer some nasty performance problems and once I start developing more complex objects I will certainly start using less of them (right now every render object uses one for it's main render cycle, this is VERY BAD as it generates unnecessary allocation and therefore garbage collection calls for every object in every render cycle -- 60+ times a second -- which severely impacts performance and may be the reason I'm having issues recording a video). Hopefully project #3 (which I'm looking at a plaformer idea I have for) will have less of these.

There are other small elements that I'm making reusable, small things like the OpenGL texture upload code, which I'm just doing quick'n'dirty right now, text drawing is done through the .NET image subsystem to a texture then uploaded with a transparent mask, this isn't perfect (rapidly changing text would be bad for this method) but works for what I have right now.

When I write a simple audio subsystem (which I'll be doing in the next couple of weeks for Hoshi), that will be reusable as well.

Game A Month Project #1 and #2

So, I've only decided in the past couple of days to go for this game-a-month thing and I already have 2 projects currently on the go.

These consist of the earlier spoken about Whirligig and also a re-re-make of Hoshi.

Whirligig I've not worked on since the tech demo, except to do some testing. I can confirm it works with more than 2 players, but it is the bigger of these two projects so, despite starting it first it will take longer. Also I used it as the test bed for a lot of the framework I'm developing for use in my game-a-month project and I spent over a week getting this working to a satisfactory and easily reusable standard. However, when I started work on Hoshi, this meant I could just drop in a lot of this framework with very little change and now I have two games where I just had one two days ago. Perhaps I'll release some of this framework afterwards, we'll see.

A little more on Hoshi here: when I first found OpenTK one of the first things I wrote for it was a re-write of my uni game Hoshi. Again I got around 75% of the development and then discovered I'd made a huge (and I mean huge) error with how I was translating all the objects around the screen. Untangling this mess would have taken as long again as a total rewrite, so I essentially left it there. There are some videos of the engine on youtube. So, I'm once again re-making the game I put so many hours into as a kid. Right now I have a starry sky (just a quick note, the word hoshi in Japanese -- kanji 星 -- means 'star') and a ship that can fly around it. I have ship designs for the enemy ships in place and I haven't mucked up the positioning system yet. I'd say I'm around 70% of the way to a tech demo with it and around 50% of the way to a full game.

So, those are my current two dates. Hoshi I estimate will be ready sometime in May, I'm going to say provisionally the 16th, since it's my birthday and this was one of my favourite games. ;o)

Whirligig will take longer as I've more plans for it, mid to late June is probably a fair estimate.

New game plan

Ok, so things didn't go quite as planned with my AudioGame. I'll explain the specifics in another post, but this one is more about what I'm planning to do for the rest of this year.

One thing that a lot of indie developers seem to do that allows them to enjoy the scene is to publish a "game a week" or something similar. So, I'm planning on doing the same. This will be hard for me because I'm not someone who easily works to deadlines. I code because I enjoy it and I want it to remain that way, so if I find I'm trying to do more work than I'm enjoying I tend to back off.

This has resulted in a rather large accumulation of half-finished projects however as I also enjoy exploring new ideas, but rarely see them through to completion.

One such example of this is a game I originally wrote for university called Hoshi which is a re-make of an old RISC OS game called Foray that in itself took a lot of inspiration from a BBC/Acorn Electron game called Starship Command. I spent many hours playing this game and it's one of my fondest gaming memories. Single-player, you fly around shooting enemies in waves. One hit kills on them, you have a shield bar, however the enemies shoot so quickly that if you remain still in a shot of their bullets you tend to die in around a second. Unfortunately I long ago lost the original, which is where my wish to remake it originally came from. And I succeeded, sort of. Things were going great, I had ~75% of the game in place and then the deadline approached and I rushed the next 15% and introduced a LOT of bugs that effectively stalled development. I handed in a game that was near enough completion to get high marks, but it was also bugridden as a result of that rush at the end.

What does this have to do with now? Well, I want to make it clear that I won't make that sort of mistake with these games. If I start introducing bugs like that I'll slow down. My plan is to make stable, fun games on a semi-regular basis, not unstable, broken games on a strict timetable.

What this leaves me with is that I won't set an exact time for each game. I also want to put more time into some of the ideas than has been done by some developers (that's not to say their games aren't good, but you can see where corners were cut to fit deadlines). I'll also be using OpenTK and C# instead of some of the more rapid development tools available. The reason for this is simply that I like the additional "wiggle room" that using a base language gives you over something like QuestViewer. Audiosurf is a good example of this. Fantastic game, but all it's bad points ultimately point to it being developed in Quest3D.

So my timetable is this: Average a game once a month. Sometimes it might be two months between releases, sometimes it might be 2 weeks. Updates will primarily be from here, hosted on DropBox, because it's easy and free. ;o)

Whirligig

Whirligig is a small artillery game I'm currently working on.
The basic idea takes from an old, old game called Gravity Wars which involves two stationary ships arranged between several planets where the idea is to shoot your opponent and the planets have gravitational effect on your projectiles.

I've taken other ideas, mainly from an old RISC OS game called TANKS, although the concepts are similar to those used in Worms, that is different types of weapons.

Currently I have the game running as a short tech demo (~2.4MB) between two players with infinite "split" weapons and a video on youtube from earlier in development.

Small technical notes on the game: it uses OpenTK and is written in C#.

I'm also building as much of the internals of the game in a re-usable fashion so I can use them in other projects as well, as I'll explain in my next post.