Thursday, 10 December 2009

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.

Monday, 9 November 2009

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...

Tuesday, 27 October 2009

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.

Friday, 16 October 2009

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!

Monday, 12 October 2009

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.

Monday, 5 October 2009

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.