On to the next one

So with Tetris wrapped up, mostly, it’s time to move onto the next project. Siva and I had decided a while back that we would start small, very small. We decided to forgo the entire creative aspect of game development. At this point, we are here primarily to improve ourselves as coders, not developers. As such, we would be cloning classics. Our job only gets as difficult as imitating features proven to be successfully implemented. The next item on the to-do list is, Raiden.

At one point or another, I’m sure many of you have encountered games of the type, top down air plane shooters where you move vertically through the level. The biggest changes from Tetris to this game would be a far more advanced Game Logic design. In Tetris, the entire world, from a game logic point of view, was just a 25x10 grid that contained my block objects. All objects in this world had set moves and were always in existence. Furthermore, the world was designed in such a way that it makes sense to display it in its entirety.

From a design perspective, here’s what I think will make coding Raiden stand out from Tetris:

· Enemy will have AI

· World will be more dynamic, with objects coming in and out of existence

· The concept of a viewport must be applied, seeing as levels in Raiden can get pretty huge and the player only needs a small window of it

· Collision Detection, this game is an arcade style shooter after, bullets will fly

· Begin applying use of resource caching perhaps? To load levels as they are needed. In Tetris everything was needed seeing as the gameplay was very contained. But resources for Raiden will only come up as you progress through the game

· Having a more robust communication system between the game’s actors

· Perhaps even creating a level editor complete with GUI at the end of this project, for the time being though, maps will be hard coded.

Architecture of the Game

The way I will be implementing the architecture of this game is through a system I recently read about in Game Coding Complete by Mike McShaffry. It consists of building three distinct systems that act independently but are in constant communication with each other.

Game Logic

The purpose of this system is the most obvious; this is where the game lives. This is where the various states and data fields of all actors in the game and the game world are stored as well as the engine needed to drive all the interactions within the game world

Game View

What I liken this class to is sort of like sitting in a camera that observes the Game Logic system. Many instances of this system can be instantiated and each of them can have independent views of the game world. This is the basis for a robust multiplayer system. None of these Cameras can make any direct changes to the game state, but based on the information it is allowed to view, it has the capability to make change requests to the game logic system. It would then be up to the game logic system to go through the logistics of applying the request.

Game Application

This system is the one tasked with doing all the grunt work needed to make the other two systems run smooth. The role of this system is sort of akin to a referee in sports. The referee never participates in the game itself, but without the referee, the game would dissolve into chaos and crash. The Applications system handles things like loading resources, communicating with the operating system, controlling game start up and shut down, etc.

Considering the emphasis I put on programming tasks rather than creative tasks at the beginning of this post, it’s safe to say that we will be using shapes and solid colors for graphics in this game. The image and audio files required for this game will be represented with basic placeholders. Only after I feel all coding within the game is complete, will I go to the trouble of making proper sprites for all the animations to make this into a solid title I can release. Only do this for 2-D projects kids, I imagine pulling this kind of laziness in a 3-D project will cause you to run into an abhorrent number of problems.

The documentation of Raiden will be far more detailed than Tetris. The posts related to Tetris were written when I had already hit around the last week of production. For Raiden, I will be doing periodic recaps of all the work I did, along with uploads of the source code as it develops. I promise to actually comment the code this time, so that you guys don’t get the urge to hunt me down and manhandle me for giving u unexplained spaghetti code.