This semester I am taking a game programming and design class. While there have already been a few hiccups and overturned smiles in class there is something to be said for putting the material to use. I am in the process of building a game called Hades, a 2D game about digging that is of similar thread to Minecraft or Terraria, but with a bit more guidance, and of course built by me.
I submitted my proposal a week or so ago and it was chewed up and the following requirements were spit out:
- basic graphics
- keys to move and dig
- random terrain generator
- enemies can fill holes
- enemies can attack and chase
- population requests, pay
- money redeemable for tools
- fighting mode with weapons
- sound effects and background music
- keep score, game over, level complete
These are a small set of the features I had actually wanted to implement, but these are what I am being graded on, so I am trying to burn through it all this week and get to the more interesting stuff.
This game is being built on top of XNA, where I am trying to avoid libraries as best I can to build out the game above. There is a lot to be said for avoiding reinvention, but seeing as this is a school course I should be learning as much as I can.
I have decided, however, to use a port of the Box2D physics engine called Farseer and the rest of the elements I am looping in are all either wholly invented by me or inspired by the tutorials and articles on the MSDN.
I started work on the game as soon as I got the idea, and I’m forcing myself to keep a brisk pace of development. I hooked up the physics engine, game state management and started building out the game. Basic Graphics are always in place, keys to move and dig are completed and score and game over are already in place. Level complete doesn’t exist in this world.
Over the last week I have been working on the physics library and I managed to pull the following together:
One thing that is exceptionally difficult to do without help is debugging. In order to improve my abilities to debug I have taken to using test driven development and included a few DrawableGameComponents to help with it.
- The typical FPS counter, a proof of concept to figure out the drawing order for the scene manager to ensure it gets painted at the right time.
- An input component which outputs the keys, buttons and mouse state for each frame.
- A physics tracker which outputs the number of physics bodies in the world for statistical tracking and help understanding the load.
- An entity tracker which, given an entity, outputs a load of information to the screen, such as the position, rotation, score and health for that given element.
- A screenshot component which is drawn in between the debug components and the scene manager, to avoid having that stuck into the world.
Last night I added in splash screens, where all I have to do is add images on to an array that will automatically slide show through them. I have already used this to handle a Gneu.org logo and a second that I am using to provide attribution to the tools and libraries that I am using in developing the game.
Today I am working on tools, buying them and creating a few mock tools that I can use to attack enemies and probably the inventory. Taking care of this will knock out two further requirements and let me get into the enemies.
From this point forward I will be doing more frequent and detailed posts. If any questions come up, as always, don’t hesitate to forward it along.