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!

The game that myself and Nick are developing has crept along at a slower-than-usual pace, due largely to the holidays, but nevertheless a SkyBox has been developed, integrated into our game solution as a content pipeline processor. This means that we have the ability to interpret game resources in a custom manner, meaning that it will be “wrapped” around our skybox. This will allow us to process things such as sky and other backdrops, visible and changing depending on the camera rotation etc. More on this when we have a suitable backdrop implemented.

The next month is a very exciting time for AllportGreenhillGames, with a set strategy being developed on how myself and Nick can take our pet project and turn it into something real.

When embarking on the creation of an RTS Game, such as the game being developed by myself and Nick, the first question asked is “do we use an existing RTS Game engine (either written in our preferred language or ported), or do we create our own from scratch?”

We decided that given my lack of prior XNA knowledge, it would be best for my game development skills to create an engine from scratch. Not only would this allow our coding skills to become better, but this would allow us to create the logic for our game from the ground up, giving us full control of what the engine does and possibly give us a seperate product we can use to create further games. The only downside is, this approach inevitably takes much more time. This has probably been the single biggest contributing factor to the slippage in the development timescale of our game.

I remember talking to Nick about this subject during my recent visit to Birmingham and we eventually settled on an answer of whilst it is always down to the preference of the developer/development team, generally speaking by going straight into game development using an existing engine, developers will not get an appreciation for how the engine works at a code level (i.e. there may be things that could be improved or perhaps certain operations perform badly on a PS3). New developers entering game development should at least make a simple prototype game engine that demonstrates a grasp of key concepts, such as loading terrain, unit loading and maipulation, pathfinding for AI, etc. This means that when they come to use an existing RTS engine solution as a base for their games, they know what it does and the concepts behind the things it can do.

Whilst I can see Nick getting increasingly good at Blender and me continuing to work on manipulation of units, we’ll have to have a think soon about the actual unit strengths/weaknesses and of course the storyline in our game.

Oh, and in case you didn’t know, our game is going to be Real-Time Strategy.

Expect to see it take shape on here soon. I’m now off to enjoy the rest of my weekend before heading into the office tomorrow.

For now, I get to play around with Word Press, choose some colours, decide on my layout, and generally make it all look pretty!