More on One Game A Month 2013

Listing out some ideas I have for what I'm thinking of making. These are in no particular order right now.

1. Arena / Twin-stick shooter: Going with a typical player in the middle (either a man or a ship, ship is easier to animate) who can shoot in a full 360 degrees using either mouse aiming or the classic 2 sticks on a joypad. Enemies would attack in various patterns. I've prototyped this playstyle in C++ with OpenGL in the past (image of prototype)so using that as a reference along with using my existing C#/OpenTK library means this should be easy to get up and running and so would make a good first month project.

2. Single room platformer: This would consist of a simple platforming engine in which each level is a single room on the screen (no scrolling). The original point of this idea was to allow me to experiment and learn about level design. Exact specifics about each level are unclear right now, whether there are collectibles/puzzles/enemies/all of these and the number of levels depends on time constraints.

3. Scrolling jumping platformer: The two more well known examples of this genre are Canabalt and Robot Unicorn Attack. Adding multiple levels you drop down to with the higher ones being quicker might be an interesting twist to this. Building the levels randomly (and consistently) will be an interesting challenge.

4. Ship management: Something similar to FTL, but much simpler. This would be more a prototype and I think it's one of those genres that a lot of devs would like to experiment with.

5. Side-scrolling shooter: This is a genre I've made a couple of simple Flash games of and I experimented with it using music to generate enemies, but I've never put a lot of thought into a comprehensive game in this genre. Several levels with various weapon/ship upgrades and limited lives. Not bullet-hell, more casual.

6. Survival: Something similar but simpler than Don't Starve. Mouse controlled movement, simple crafting. Again more a prototype but something to experiment with.

7. Hoshi 2: I love this game but I feel it's missing something and I'm only sure of parts of that. I would like to update the UI and sound effects especially. Some sort of online score system would be nice. At a stretch I'd like to add multi-player but I'm unsure how easy that would be to do in a month. I want to add more game elements as well and update the AI. It's extremely simplistic atm and overwhelms in a horde-style instead of actively hunting you. I'll write more about what I want to add/change if I decide to pick this up as a game.

8. Fixing Whirligig: A lot of Whirligig's problems are a result of some questionable design decisions when I first started it. Sometimes player rotation goes out of whack and there are pauses as the new planet bitmaps are produced after every impact. Additionally the physics (especially in bouncing) are a little odd at times. The amount of refactoring and fixing required would mean this would take as much time as a new project.

9. RTS/TD hybrid: This would consist of a small group of 'units' that you move around a map, gathering resources, defending yourself and building more units whilst being attacked constantly. I'm unsure how well this will work and may require a lot of tweaking.

10. Procedurally generated exploration: Not exactly a game, but it would create a landscape you could explore procedurally (that is, on the fly, computationally and consistently). The reasoning is that the Survival and RTS/TD hybrid ideas above would require such code before implementing the gameplay specifics for those games. Whilst I doubt this would be a huge amount of fun, with enough thought behind the landscape generation it should create some interesting scenery. Separating it out like this means I'm more likely to spend time fixing issues with the generation before moving on to gameplay elements which should produce a more robust system I can then use for more games.

11. 3D puzzle style game: Something akin to Marble Madness although I'm thinking closer to Arcturus (an old RISC OS game) with varying obstacles, different surface types, slopes and enemies to navigate.

12. Fixing/finishing Five Point Five: Five Point Five was a game I started for a TIG competition regarding multi-player only. Technically it works, although there's no input set up for all 5 ships and it's local only (looks something like this as I left it). The base gameplay is to destroy the other players, however you can't damage them until all the asteroids are destroyed. You can however push them around with your bullets. The asteroids drop power-ups like rapid-fire, power-shots, faster shield recharge. Once the asteroids are destroyed you can damage each other and whoever is left at the end wins. Has plenty of particle effects and you can see the heavy influence from Spheres of Chaos. Fixing and finishing it would require adding net play (which would be the biggest challenge) and a proper menu with rebindable controls. If you plug in enough joysticks it will work fine locally but having a couple of computers for it would make more sense. The levels are set up internally in such a way to reduce lag issues - they're based on a single number and procedurally generated from that, with all the sub-asteroids based from that original number, meaning that clients only need a location and time for a split and not all the individual asteroid information. Moving the game on from the original spec to include AI players would also make things interesting.

So those are 12 ideas. I don't know whether I'll use all of these as doubtless I'll have more and some aren't hugely interesting. There's also various puzzle games like Tetris or Puzzle Bobble that I'd like to clone and would be pretty easy to do.

A return

Resurrecting this blog as I'm taking part in 2013's One Game A Month project (http://http://www.onegameamonth.com/) and my original game-a-month project back in 2010 was one of the reasons I started this blog.

I'm on the site as 'phillmwebster' as that's my Twitter handle (http://www.twitter.com/phillmwebster/)

Not really sure which game ideas I'll be using for the projects. I may start off small with the 2 ideas I had for my old game-a-month project (simple arena-style and single-room platformer) and see where I go from there.

I will be re-using my C#/OpenTK library that I used for Hoshi and Whirligig in the past. At least for the first two projects. This is mostly because it's tried and tested and very easy to throw sprites around with.
I may drop into Flash and/or Unity for some of the later ones. Using Python is another possibility, but I'd be learning the language from scratch so would have to see.

Talking of Whirligig I have done some small additional work on it, but it still lacks the viability of a release as there's no real UI outside of a game so all the player names, amounts, etc are still hardcoded. I'll poke around with it some more during December to re-acquaint myself, probably film a video of it and perhaps release a hard-coded version with working random levels and the ability to re-start the level without quitting/restarting the game.

A note on sound

Since I've revamped the sound engine for the toolkit I've created and have interfaced it with Whirligig, I thought I'd talk a bit about the design decisions behind the sound.

Firstly, all sound is played from plain old WAV files. This is purely for practical purposes. I don't want to start mucking about with OGG and other things in C# as there isn't much in the way of good libraries for doing so and all the sound effects are small enough that keeping them uncompressed isn't an issue.

All the sounds for both Hoshi and Whirligig (and probably projects 3 and 4) has been done in sfxr, which is a very useful project that just outputs simple waves with a few parameters to play with, allowing easy retro sound effects to be created with minimal effort.

So in actual code I use OpenAL where-ever possible. This is mostly because it's a fairly comprehensive library that takes raw WAV data and works on any system with the OpenAL library installed (Windows, Linux and OS X are all supported, for instance).
However OpenAL isn't available on all systems, but .NET and Mono provide a very basic sound player in the form of System.Media.SoundPlayer. This works well for single sound effects, but is useless for playing multiple sounds together. This will be less obvious with some games over others. It's very obvious on Hoshi, but does give an idea of what is being missed. It's also somewhat buggy under Mono it seems, playing sounds unexpectedly or not at all in some cases. As this is purely a back up system I'm not too worried about it and won't be making any effort to fix the problem(s) introduced through this method.

So, when started the sound system checks the options file. If the options file says to not bother with sound, it just loads the dummy sound driver, which just says "ok" to everything, so the game thinks the sound system is all working, but the driver does nothing with any data passed to it.
If the options file says to use OpenAL, it checks that OpenAL is installed on the system then attempts to use it. If either of the checks for OpenAL or if a valid OpenAL context can be created fail then it drops back to the dummy driver.
If the options file says to use the SoundPlayer then the sound system will attempt to create a SoundPlayer class, if that works then it will assume that SoundPlayer works and so use that. If it fails it will default to the dummy sound driver.

The last two options are 'Auto' and 'ForceOpenAL' and are a bit more complicated.
'Auto' is the default and will attempt to use OpenAL followed by SoundPlayer then will drop to the dummy if both fail.
'ForceOpenAL' will skip all checks when initialising OpenAL, which will cause a crash if OpenAL isn't installed. This shouldn't ever be needed by a user and was intended by debug purposes.

So that's the new sound system. As I stated, after modifying it to this in Hoshi, I inserted it into Whirligig this morning and now Whirligig has a multitude of retro sounds that bring some extra life to the game.

Hoshi bug fixes

I'm making an effort to get Whirligig released (hopefully this week, maybe even today, I'm not sure how long it will take to do what I want with it).
In doing so, one of the things that needs implementing is sound. I have all the sounds I need ready and I had Hoshi's sound engine. So, no problem, yes?

Well, Hoshi's sound engine isn't perfect. It actually causes the game to crash randomly when OpenAL isn't installed. This is a fairly major issue, so I decided to go back and fix this on Hoshi before moving the engine across to Whirligig.
Whilst I was working on the engine I quickly added a simple substitute for the sound when OpenAL isn't installed. This uses .NET's or Mono's System.Media.SoundPlayer. This isn't ideal because it will only play one sound at a time with no mixing and Hoshi requires many sounds to be playing at once to sound correct. But it's a good substitute for those who don't want to go searching for OpenAL.

So, now Hoshi will work out of the box with sound, although you'll get a much better experience with OpenAL installed. There's also an additional option in the hoshioptions.xml file in AppData that allows changing the sound engine. So you can set it off, set it to the Media.SoundPlayer option or set it to OpenAL. There's also a ForceOpenAL option which skips any checks for OpenAL and is not really recommended as it will cause the same crashing issues as before if used on a system without OpenAL.

Anyway, new release is here.
These are purely bugfixes, if the version of Hoshi you have already doesn't have issues you won't gain anything from this new version.

And now I can do some work on Whirligig.

General update

I've been lazy this week and not done any work on Whirligig. Hence the lack of updates here.

What I have been doing is playing Merentha again. Which is a MUD (an early multiplayer RPG, generally with far more involved systems than more modern MMORPGs).
Used to play it all the time, but it gets a bit of a grind so I play on and off since it's free.
No pretty graphics, it's all text-based, but the base gameplay is unrivalled by MMORPGs imo.

Err, that's pretty much it. I won't get any work done this weekend since I'm in Scotland for a stag do (not mine!)

The only real bit of news on Whirligig I guess I've for is that I started the shop on Monday then thought I had a serious UI problem, so I played Merentha whilst I thought it over and realised I didn't have a problem. :oP
Just need to put UI components together, but as I've stated before I don't enjoy that aspect of coding at all.

Quick UI taster

This is how far Whirligig has moved along:



As you can see, everything is labelled, the 'projectile', 'shell' and 'shot' types all have icons (although pretty crappy ones ;o)) Clicking on them opens a window like the shell type one shown, which is showing 'normal', 'bounce', 'double bounce', 'double split', 'triple split' and 'clusterbomb'.
A 'split time' counter has been added so you can see how that works.
Oh, and there's 3 players, which (as I think I stated) was possible back as far as the tech demo, I just used 2 players back then.

The window is busier than I'd like. I need to fit the number of shots/shells/projectiles on there yet, which will require some reshuffling. Also I've not implemented that part to the weapon-choice windows either. And still not started on the shop. Still, getting there slowly.

Minor update

Not a lot to report really, all current work is pulling together UI parts. It's pretty boring stuff.

Have I mentioned I hate UI work? ;o)
Unfortunately most of the rest of this project is UI work now. The only bit that isn't really is the AI and level generator.

The level generator will just create 3 (or half the number of players, whichever is lower) planets and make sure they're spaced far enough apart then randomly locate the players making sure they're never closer than 90 degrees on a planet.
There may be some occasions on small planets where players get placed close together, but these should be rare(ish).

The AI I'm unsure how to do... I think I'll just have the projectile report back how close to an enemy the shot was and have the AI adjust from there. I could probably write in a load of simulation code that would make the AI dead smart, but I think a simple "how near am I?" setup will work well enough for the level of game I'm aiming at this. Were it a commercial product I'd bung in several AI levels, including a genius one that never missed. ;o)

Whirligig Update

Well I did write a fairly long post about this yesterday, but lost it, somehow.

Anyway, I took a small break over the weekend since I finished Hoshi early and yesterday I resumed Whirligig.

First thing I implemented was a shell type window to go along with the shot type window.
I should probably explain the shell/shot/projectile types at this point.

Projectile types determine the size of destruction (there's 4 sizes).
Shot types determine whether the projectile will split after it's fired and into how many subsequent projectiles (1-5). The length of time before splitting can also be set.
Shell types determine what the projectile does on impact. This is the most complex and consists of bouncing (once or twice) or splitting (2 or 3 times) or a clusterbomb which explodes at the impact point and fires 4 other shots off.

I now need to finish building the GUI for these (timing for split shots and projectile type need implementing) then put together a shop.

The shop is needed because you will start with a limited number of each projectile. The only thing you'll have inifinite of is normal/normal/normal. Although this can all be changed in the options.

Basic gameplay will consist of a series of rounds (1-20). The shop can be set to be available mid-round or only at the end of each round.
After the rounds various stats will be shown with a 'score' winner, a 'kills' winner and a 'rounds' winner.

I don't think that's as clear as my original post about all this, unfortunately. If you've any questions, leave them in the comments and I'll try and clarify. Or you can wait a few days and I'll post some screenshots hopefully. ;o)

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.

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.