Destination Alpha

Now that stages (levels) are being loaded from XML I can focus down on getting an alpha test sorted out. This will consist of one level (using very basic graphics since I'm rubbish in photoshop) from the game in order to get a feel for the direction the final game will take. I'll need a basic graphical interface for the player (health, armor, ammo etc), the ability for the player to move and fire an avatar and perhaps a basic puzzle and an enemy (just the one). I've set a deadline for myself of two weeks to get to this stage, if I can it'll land me in good stead for the rest of the project.

A level or stage for the moment consists of nothing but game entities, i.e. everything is classed as an entity, from physics props, the player to the actual geometry. I might put static geometry into a separate subsystem for the purposes of optimization (static world geometry doesn't need to be updated every tick). The benefit of doing it this way is that it makes the structure of the game very understandable to other programmers : everything is classed as an entity. Using the component system even things that are just for show, such as background tiles can be classed as an entity, simply don't assign it a physical component.

I need two more components designing next, MultiVisualComponent, this is used when an entity can be represented by more than one visual (Sprite, Model, Line etc) and MVCPAComponent (MultiVisualComplexPhysicsAdapterComponent if you want the full name, ain't it a mouthful?) despite the name this component has a relatively simple job. All it does is map bodypart positions in the ComplexPhysicsComponent onto visuals in the MultiVisualComponent. So for example if your entity has wheels represented as different bodyparts in ComplexPhysics you could assign them they're own wheel visuals using the MVCPAComponent and then applying torque to the wheels to rotate them and move your vehicle would also make the visual rotate.

Progress Update

I recently submitted some rather large updates to the sourceforge project. I've been going to town creating some "macro magic" that will assist greatly in creating and using factories (for any type of object type). I have also been playing around with the physics component, working out exactly what it shouldn't and should do. I have also added "CollisionHulls", which is basically encapsulates the physical presence of an object in the world.

Currently I'm focused more on how I'm going to structure things rather than steaming ahead with the game, I'm focosuing on structure probably more than any other project I've worked on for the simple fact that I realise down the road I'm going to need it!

Updated the sound system, "How To Compile" Added.

The updates to the sound system are complete, although I'm not really sure if they were needed since I'm getting similar performance with the updated version. Still, this way is probably better for the simple fact I haven't got audio resources everywhere that I know nothing about, now all of the source voices are maintained by the audio system.

I also added a short "How to compile" text, the process is relatively straight forward and just requires DirectX and the Boost libraries installed on your system. I probably should have added that earlier.

Component system is in place, couple of components added.

If you want an idea for what the component system I'm implementing looks like then head on over to the sourceforge page and download the latest release, since it's there! Only two components presently, one that stores a box2d body (for physics) and another that draws entities as polygons. When the user presses "New Game" on the main menu I've set up a little box falling test to make sure everything is working like expected, so far so good.

These components will probably need expanding, since one entity does not necessarily have only one body. The player vehicle for example will be made up of several moving parts (including wheels, chassis and a gun turret) as such I'll need to create a new component to handle multiple bodies. This will require a new drawing component also. The problem is getting the drawing component to interact with physics component, i.e. assuming these two components don't (and shouldn't) know anything about one-another how do you make it so the physics updates the positions/orientations of the bodies so that the drawing component knows and does the same? The solution? An intermediate component, which acts as a sort of adapter. It basically maps bodies onto shapes in the visual component. The other possible solution to this problem would be to use a messaging system, where when a physical object movies it fires off an event saying "body with this ID has moved", then in the visual component each shape could maintain the same ID and receive the message, updating the visual position/orientatition. This is why component orientated design really is the future, it gives you so many options of how to do things, rather than being tied down with long inheritence heirarchies.

Next thing I'll do is probably update the sound system like I said I would a few posts back. It's definitely not working optimally (create a new source voice for every sound effect really will destroy performance) after that maybe work on loading 2D "models" from memory to be used by the visual component to draw, rather than inputting them by hand (which for complex models would be laborious). This will facilitate two models, one a complex one for the renderer to use and the other the collision hull for the physics engine, using one for both systems wouldn't be recommended.

The Game Component : An entity is the sum of it's parts

During the next stage of development I am going to focus down on designing the meat and potatoes of any game; the game logic. I think I've reached a point now with the other components that I have a fairly stable base from which to work from. The Renderer is about 90% complete, the UI component still needs some additional work, particularly the GameScreen, and the sound interface is complete although I'll probably change some of the underlying code.

The game logic in most games contains some common components:

• The game class:- The interface to the game logic, keeps track of objects within the world, player score, level etc. Usually is responsible for updating and rendering these objects and handling game events.
• Game entities:- Objects in your world,, i.e. the player, enemies, sceneary etc.
• Physics:- The physical representation of your world, handles collision detection between game entities, determines what to do when objects collide, updates entities positions and orientations.
  
• Level:- It's sometimes desirable to have a class representing your level. These classes would handle level saving/loading, maintain checkpoints, render backgrounds, maybe contain a tile-system that can be used to colour your environment.

This is by no means an exhaustive list, but you get the idea. The game shouldn't know anything about the Renderer, UI or Sound components except for their interfaces.

True object-orientated design approaches for representing objects within the game world all-to-often fall flat. I've done it in the past with projects, you start out with a nice class hierarchy all worked out then as you proceed with your design you begin to realise you're duplicating a lot of the functionality between cousin entities. So what do you do? Well, the traditional solution would be to propagate that functionality upwards until you reach the first common ancestor. I won't go into much detail but needless to say what you end up with is "one-for-all" classes (the "blob") which do a little bit of everything; particularly OO friendly. In these designs usually the entity base class become vast and debugging a nightmare.

I'm somewhat of a proponent for component driven design. In composite designs containment is chosen over inheritance. For example, rather than an object inheriting the ability to explode on touch, it contains the ability to explode on touch. The benefit of this design is that common code can easily be transported to various different entity types easily, without any need to propagating functionality up the hierarchy or duplicate code. Basically each entity becomes a simple container for components and contain no functional code themselves, for a more detailed description I suggest you head here. This is the approach I'm hoping to use on PhysTank. It's clean, easy to understand, easy to debug and allows additional functionality to be easily implemented. It is also receptive to a data-driven approach.

I'll probably start by creating the container class and the component interface.

MP3 support added

I've added MP3 support to the audio system (more specifically the SoundResourceHandle) using the MAD library. I'd like to implement streaming MP3's from memory, this should be possible using MAD although for now I probably won't bother. The only problem is that a 4mb MP3 could expand to a 50mb sound file in memory, although with the obscene amounts of memory people have these days it shouldn't be a problem (it will become a problem if I port the game to any other systems).

Audio System in place

I've uploaded the audio system for the game. Currently it only supports XAudio2 which is the new API designed to replace DirectSound. The way the audio system is structured is to allow new audio API's to be easily plugged in, it is based around the design presented by Mike McShaffry in Game Coding Complete (3rd edition). The reason I chose this design was because it presents a very clean interface and easy to understand relationships between the various components. The game code requests that the Audio System create it a new sound effect object which it does based on a loaded resource. The game code can then use that sound effect object (AbstractSoundEffect) to play/stop/pause sounds. The use of the interface AbstractSoundEffect by the game code obviously hides any underlying implementations. The AbstractSoundEffect then passes any buffered audio data onto the AudioSystem in order for it to be mixed with other active sounds and the final sound produced through the players speakers.

There are some tweaks that need to be done to my XAudio2 implmentation for performance reasons. I'm finding that having every sound effect maintain it's own "SourceVoice" is killing performance, only a few active sound effects can drop the frame rate quite substantially. In order to solve this I'll probably keep a set of pre-made source voices in the XAudio2AudioSystem class which active SoundEffects can then request and release when they're finished. If a system attempts to play a sound effect but no active source voices are available then the effect will either be queued or not played at all (in the case of extremely timing senstive effects where playing it late would just seem odd).

Although changes do need to be made to the Audio System the interfaces won't change. This means I can use them in other systems without the problem of having to alter that code at a later point.