A new update

Things have been happening recently so I haven't been keeping up with the blog updates. This does not mean however that I've been stopping with development, quite to the contrary development of Phystank has been coming along quite well. Where am I? Well currently I have the player almost entirely implemented, this includes rotating barrel that following the mouse as well as the ability to shoot bullets. Next step is to maybe add some enemies, I have several ideas of what enemies could be implemented:

• Bomber/Fighter: This type of enemy fly's overhead and drops bombs on the player character, the bombs can be shot/destroyed.
• Soldier: This type of enemy is a foot soldier who runs at the player tank and either explodes himself or fires a weapon (not sure which yet), if the player kills one of these guys his body will ragdoll.
• Tank: The enemy tank is another tank like the player tank but slightly smaller. The enemy tanks are pretty tough.

Once I've got these 3 enemies in place I'll think about implementing puzzles, after that it'll mostly be polish to the final gameplay mechanics. I've also been working on the UI adding a stage indicator, timer & player score. The idea is that the player gets points for killing enemies, completing puzzles and doing it in a quick time (the quicker the time the more points the player gets in addition at the end of the stage).

Another thing i'll need to consider is the level editor, which will be important for creating further stages quickly.

The player, component or controller?

One thing I'm having a hard time deciding on is whether I should allow the player to interact directly with the entity as a component or use a controller-controllable pattern. The benefit of the component system is that it effectively shows player actions to be simply a function of the game entity, as if the player itself was sitting inside. The benefit of the controllable method is that it provides a very clean and clear way in which new types of input can be read and output to the players entity. I'm not entirely sure which route I'm going to take yet...

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.

Audio System coming along

Some changes were made to the resource cache as based on Mike McShaffry's "Game Coding Complete 3rd Ed.", an excellent games programming book may I add. The resource cache is now much more flexible and allows it to maintain things like D3D Textures for sprites. These changes were done to facilitate the introduction of the sound component which seems to be coming along nicely.

I am currently planning to support 3 audio types, uncompressed WAV, OGG and MP3. My plan is to stream music and large audio files straight from the harddrive. How this will work in the context of the resource cache remains to be seen. One option is to leave music files seperate from the resource cache, although I'm not too keen on this. The only other option is to somehow stream the music from the compressed zip that makes up the resource files. This seems like a difficult job however, since I'll essentially have to decompress the audio twice, one from the zip and secondly from Mp3 or whatever format into raw PCM data that can then be used by the underlying audio API.

The sound will be done on windows using XAudio2. DirectSound seems to be one the way out now and XAudio2 is also cross-compatible with the X-Box 360 which is a bonus If I want to port it (meaning I can leave most of the audio code intact). I haven't decided on the API's for other platforms yet, but I'll cross that bridge when I come to it.

Basic Main Menu in place

I've implemented a pretty simple main menu with some buttons on it. None of the buttons are hooked up yet so that'll probably be the next task. The main menu is accessed after the user passes the splash screen. Text/Graphics should be added to these screens. I'll probably add some sort of disclaimer/GNU notice on the splash and the title on the main menu. For the background I want to play a video, this will probably be a video of me playing the game when I get the game/video components implemented.

User interface coming along

Development recently has been focused on the user interface. This effected several changes in other systems like the renderer and platform also. I really want to get on with the fun part (developing the actual game) but as I've mentioned my approach is to have as many other components in place as possible first. It shouldn't really matter what order you write your code in though, if your design is modular and clean.

Developing a user interface is easy whilst developing a good user interface is very hard. With the user interface for PhysTank (as with most games) easy is taken over functional. A fully fledged UI API would contain a richly featured widget system, incorporating buttons, sliders, dialog boxes etc no dissimilar to the java swing libraries, developed entirely in a blackbox fashion and probably farmed out to a seperate library. There are C++ API's that exist which contain this and deciding whether to use one of these or roll your own is often a tough choice. For PhysTank the UI doesn't have to be particularly complex, I probably won't be using that many floating dialog boxes or slider controls, so where appropriate will fashion my own thrown together widgets. In a game that does require a more complex UI I would definitely recommend using an API like GTK. Using common API's like this rather than rolling your own will not only save you lots of time but since most UI API's are designed around making sure users have a certain degree of familiarity you won't be confusing your players with weird and wonderful designs. I will probably be using one of these API's when it comes to writing the level editor.

The User Interface still has a long way to come, and I probably won't polish it off until (very) late in development, but as long as there's something in place that gives the player reasonable feedback about what's going on in the game it'll do. Next up on my check list is to implement a basic main menu for the game, also further down the line colour schemes. One problem I'm having is deciding how screen elements (pictures, text etc.) should be placed and scaled on screen. If the user ups the resolution from 800x600 to 1024x768 for example, or higher, then icons and text will appear too small on the screen. In order to fix this these things have to be scaled dynamically based on some "ideal" resolution (i.e if the ideal resolution was 800x600 then on a 1024x768 display that would be a scale factor of 1.28 for the on screen elements). Doing this in an elegant manner isn't easy, and I may just have to resort to having the renderer scale things automatically and all positions given in the range 0-1 and maybe implement scaling functions for text (GetFontSizeScaled() for example).

Changes to the physics system.

I've changed the Physics component to expose more the underlying Box2D implementation. The reason for doing this is that I didn't see much point in building a complete wrapper only to act as a relay to Box2D function calls and restrict functionality available to the game. Due to this the Physics class has become more of a helper class, defining functions which will make future code look cleaner and easy to understand, such as functions to create physics bodies and shapes rather than having shape and body definitions all over the place.

The other changes include adding an AbstractCollideable and AbstractCollisionHandler to the Physics component. Game entities will be able to inherit from AbstractCollideable and be notified of when a collision occurs between them and another body/shape. The other type of collision handler, AbstractCollisionHandler, can be registered in order to receive global collision notifications. This would be useful for the sound system for example, which could implement this class to play sounds when a collision occurs.

As is often the case when using third-party code, finding the right implementation in your code can be somewhat of a nightmare. Your natural instinct is to encapsulate the third party code in your own set of classes which masks its use to the rest of your application logic. The problem with this is that the used code can often be quite large and have a fairly complex interface, so unless you want to spend a great deal of time encapsulating every small function call you're probably going to end up masking some of the used library's functionality.

The alternative to is present the third-party code directly to your application. The problem with this is that it very much ties it to your game, so if you find a better solution to the problem down the line, then replacing the system can be quite a long drawn out and loborious task. It's extremely difficult to create a "one-size-fits-all" interface class for systems with complex interfaces. It's very rarely you'll find a perfect solution to this problem. In PhysTank you can see both approaches, with the Renderer I've very much gone down the route of masking functionality in favour of portability and modularity, where with the Physics component I'm tieing the Physics API being used to my game. The difference is that the Physics API should be portable between various platforms since it itself has been written platform-independent, where as there a good chance the rendering code can't be (especially in the case of Direct3D).

I am not entirely happy with the approach but as is often the case with Game Development, trade-offs are part and parcel.

Help

I should mention that I'm always looking for help, coding, asset creation etc. If you're interested in working on a fun project either e-mail me or leave a comment and we'll work out giving your repository access.

I really should work on the design documentation so everyone has a better idea of what the game actually involves.

PhysTank with Physics!

A basic physics component has been semi-implemented using Box2D. I still need to complete the interface and make sure everything is working as it should. Next I will probably move onto sound, I want to complete the tertiary components so I know what I'm working with when developing the game itself. The next step after that will probably be to allow users/developers to manipulate INI/XML files in order to change application settings. This will include things like choosing which renderer to use (only Direct3D at present), display resolution, setting AF(Anisotropic Filtering) on the loaded textures and MSAA (Multi-Sampling Anti-Aliasing) to make the line drawing seem smoother as well as run speed etc.

A good tip: Use the interface design pattern and use lots of them, I can't stress how useful a good interface class can be. By interface I mean an abstract class which contains nothing but pure virtual functions that you inherit from. The reason for doing this, for the renderer for example, is that it provides a common interface that lets you switch out various components. For example at some point I'll be writing an OpenGL renderer for PhysTank that I should just be able to plug-in without having to change any interactions between the UI and the Renderer. Even if you don't think you're going to need one, for example if your game is only ever going to have one renderer, I'd still recommend doing it because it makes you think about the interface to components you're creating.

All too often there's a temptation to use the D3DX extension classes for example in areas of code outside of the platform or renderer, i.e. in your main game code. D3DX provides perfectly good Matrix and Vector classes right? Along with an entire set of easy to use functions. Resist using these things in your game code at all cost. If you don't feel like writing your own vector or matrix class (although you probably should), at least use what are called wrappers which hide the underlying implementation as a D3DX class (or if you're really lazy use typedefs, i.e. typedef D3DXMatrix Matrix4x4). Then if at some point down the road someone offers to port your game to a UNIX OS they won't have to tare their hair out looking through file after file attempting to replace every D3DX call and instantiation, they can simply re-write the vector and matrix classes.

Keeping platform dependent code out of your main game code keeps things looking cleaner and easier to understand too, it also makes you more diligent against lazy programming.

Phystank Update

PhysTank is coming along nicely, resource cache, renderer and the game engine are in place, also work has began on the user-interface and game components. Next up physics (which I will use a 3rd party library for, like Box2D) and a bit further down the road sound. Since the game will be rendered entirely using lines I won't have to mess around for hours in photoshop, although some nice user-interface graphics would be nice.

New Project Started - Phystank

Phystank is a two-dimensional puzzle game involving physics. The player will be forced to confront, as well as puzzles, a whole host of different enemy types. The game will also come with a pre-packaged editor.