Archive for the ‘Code’ Category

The Theory of Game Tools

Wednesday, August 12th, 2009

The purpose of most game tools is to streamline process of content creation. They should enable the artists to easily get assets straight into the game, thereby reducing the work load of the programmer. That’s the theory anyway.

Right back when we were building Balls Unleashed and Throng, I started making the Character Editor 2D with this theory in mind. The idea was to have an animation tool that could handle a hierarchy of Quads that could move independantly  (eg head and arms attached to a body) and do sprite sheet style animation on each Quad at the same time. My vision was to be able to have a single “Anim” that incorporated both. It turned out to be quite ambitious but I think I got most of the way there.

Yellow guy in the character editor

Yellow guy in the character editor

Where the wonderful theory broke down was in the final 10%. I’m still not satisfied to offload it on the art guys. It always seemed like there was something much more important to do than iron out the niggling issues, and whilst those issues persist, it’s just more efficient for me to work around them and implement the character rigs and animations into the game.

Overall, the Character Editor 2D has been a success. Two weeks before DPB deadline, the character you see above was literally a square. I was able to take the sprite sheets and mock up images from Scott and build it into the Square Off character in a couple of evenings. Most of the dynamic movement (including gun, arm, body and eye rotations) are controlled in code because it’s smoother and more dynamic that way. However, the tool allowed me to visually set their relative positions, pivot points and sprite animations. I also use it to define the physics, which in this case is simply a box.

Level Editor

Thursday, May 28th, 2009
Throng Level Editor

Throng Level Editor

Well it’s actually the Character Animation editor, but it will soon be the Animation-and-Level editor. Lets just call it ThrongEdit for now. Oh yeah, welcome aboard Adam.

Throng tech info

Saturday, May 9th, 2009

Language

Throng is written in C# with XNA Game Studio. This was the only choice as we intend to release the game for XBox Live Community Games. Whilst this may seem limiting, C# and XNA truly enable rapid game development. Sometimes progress on the game seems to be rather slow, but it’s rapid considering the amount of time I can put into it as a hobby.

Physics

Currently, the only confirmed external library is the Farseer physics engine and I’m extremely happy with it. I initially tried writing my own 2D physics system which was used in Balls Unleashed. It worked reasonably well and I learned a lot, but eventually I realised that I was reinventing the wheel and wasting precious time that could be better spent on gameplay features. Farseer has opened up the possibilities of the game with support for polygons, joints and springs. I can’t say enough good things about the Farseer team.

Graphics

At the moment, I’m using the stock standard XNA BasicEffect to draw the 2.5D models and the 3D sprites. This may well change if we get time and deem it worth the effort. Thanks to Scott’s cool 2D and 3D art, I think we may be able to get away without a lot of special effects. They are always a Nice To Have, but I think I’ll concentrate my coding time on the essential gameplay features before worrying about the polish.

Pipeline – X2Model

One piece of in-house code I’m quite proud of is the way we load models. Some of you might be surprised to hear that XNA doesn’t include any API for directly loading models at runtime. If you have Game Studio installed, you can compile X and FBX files at runtime to be loaded and rendered with the Model class. If you don’t want to install Visual Studio and Game Studio, currently the only option is write your own model loading and drawing code. I managed to craftily avoid this problem by using SlimDX to parse and load the X files. That’s the simple bit. Wanting to reuse the built in XNA Model class, I used reflection to create and populate it with the vertex, index and material information. The benefit is that the artist(s) on the project won’t need to install VS and GS and even if they had installed them, they wouldn’t need to recompile the models each time they altered them. The drawback is that any custom content pipeline features are not available. I’m intending to release X2Model on codeplex once I get the time.

AI

This is my current task and the path finding is based on the A* algorithm. Once it’s closer to complete, I’ll post more info about it.

Before I sign off, here’s a quick screeny. The Necromancer on the top right is fleeing along an AI path.

watch out for the butcher

watch out for the butcher