Map reading

I opened up our code last night after a 3 month break, and started working on the map engine. I’m very excited by making that into a configuration file-driven game component for controlling the maps, their layout and textures, resource points etc. This engine is being written in such a way that the resources are read in “on the fly” and processed using the XNA content pipeline. This will also mean custom map development will be made very easy by means of creating a new configuration file that defines the map and the resources to use.

Watch this space!

Game world code coming together

July has not only seen me move flat and Nick starting to cycle to work in an effort to reduce the beer belly, but we've also managed to get textures and backgrounds loaded, as well as the separate input handler and camera classes talking together, meaning that we can move the camera around the game world by using the arrow keys of the keyboard or left thumb stick of the Xbox 360 controller.

I'll be concentrating on getting zoom and rotation sorted within the game world, then thats pretty much all of the camera stuff done. The controls will be built as the game develops, so in terms of those aspects of the game we're doing OK. Nick has done some cracking work with the creation and rendering of the game world, so he'll be developing that as well as putting some focus on the heads up display or similar too (where status is reflected on screen as well as what you currently are able to do etc).

I will be working on (apart from fixing the camera class) some sketches for the 3d sprites and thinking about their realization in 3d Studio Max or similar.

All in all its going to be a busy month to mid-September, but one in which we will hopefully have something worth of showing at the end of it!

Aaron

XNA 3.1, moving and camera

So given that XNA3.1 is out and in full swing over on http://creators.xna.com, myself and Nick have downloaded and are working with it already. I've sorted out the input handler class and the game camera is almost sorted too, including zoom, rotation, etc.

The next item on the agenda is the creation of the world, and more importantly the maps and their implementation. This has been a cause of headache for us for a little while now. The creation of a pluggable, expandable, maintainable, and probably most importantly, useable tool for map editing will most certainly be a by-product of our project. Granted, the main effort in map development is the actual graphics, but with an underlying structure in code and pluggable properties, we can think about map packs and user-created maps after release of the game.

To top it off I've moved flat this past month, and have never felt so disconnected without internet! Still, the downtime has given me some time to continue grinding away on the game instead of procrastinating!

Cross platform controls

I've been working hard getting the controls sorted for both PC and the Xbox 360 game code base. Our project will be written firstly on a PC but with every bit of logic being the same regardless of platform, only the controls should change when the game is ported to the Xbox (to account for the Xbox 360 controller). XNA studio allows for the use of "#if XBOX" and "#if !XBOX" pre-processor directives which instruct the compiler to compile specific bits of code, leaving out code not related to the target platform. In theory, the use of pre-processor directives means that we can code for both the Xbox and PC platforms at the same time, and when the code is compiled, only the relevant code actually makes it into the executable for that platform.

Being a software engineer by trade, I like to enforce standards of cleanliness in code (in addition to comments, whitespace, naming conventions, etc). Given he fact that we're writing the game for two platforms at once, I've decided to move the input handling from the main game class to a separate class which will contain these pre-processor directives. Granted this means that this class will be messy, but at least it keeps any calling class cleaner in terms of the code it has to call, because there is only one method to call which handles the input from any outside class.

Another way we're going to keep all game engine implementation the same regardless of platform is by wrapping every operation of the engine in a separate method, no matter how small. This may cause more work initially, but if the game input class calls a method called "MoveCamaraLeft" regardless of the platform being use, we can be stringent about what the game engine will do. This will of course make our game debugging easier too.