And Now for Something Completely Different

For the last week or so I've been working on getting weapons firing. This included a lot of architectural crap which I mentioned previously. Weapons are working quite nicely now, though bullets will keep flying off to infinity forever currently. The other issue are some obnoxious visual defects whose cause is a mystery currently.

Weapons have some basic rules which govern whether or not they're allowed to fire. First, the gun must have ammunition. Second, the gun must be ready to fire. Every weapon has to rest briefly between shots. In real life this is because it takes time for a new bullet to be loaded into the chamber and for the firing pin to be cocked. Finally, the gun must be cool enough to fire. I decided to take a page from the Mechwarrior games here. Every weapon produces some amount of heat. When this reaches a maximum the player must wait for the weapon to cool off again. Effectively the player's firerate is dramatically cut when the weapon overheats. Between heat, and limited ammo, the player should be encouraged to fire in controlled bursts for maximum damage.

Today I decided to switch gears. Since this phase is supposed to produce the first multiplayer implementation I started coding in Live support.

XNA provides network related code in two major chunks. First, GamerServices, which is where most of the Live service code lives. Second is Net, which handles all the grunt work of communication between players.

The first thing I figured I should tackle is allowing the player to sign in to the Live service. This is done through a program/widget built in to the X-Box 360 called the Guide. As it turns out this required about three lines of code. Two for some setup and the third, which does the real work.

Guide.ShowSignIn(1, false);

Seriously! That's all that's needed to fire up the Live signin screen. The 1 states that only one player can be signed in for this game. The second indicates whether only online Live profiles can be used.

Next task is to get hosting and matchmaking up and running. Thusfar it looks pretty simple. The hard part looks to be the actual work of communication between players.

This week was umm.... productive?

So anybody reading this might recall me saying I might have more information on how the project is going by this week. The good news is that I did get some stuff, namely, guns actually firing bullets, working. The bad news is that's all I got done this week and that was waay back on Sunday/Monday.

This week has been rather nasty due to other coursework supersceding the main project. Worst was the database course. The project is fairly striaghtforward. Everyone is/was to work in groups of 3-4 people and produce three or four programs that interact with a database tracking the hours of some hypothetical consultants. Very straigtforward... also very boring. The main twists were the intentionally vague specifications and the fact that part of the data, namely the client information (people buying consulting services, not the technobabble meaning of client), had to be on a MySQL database while everything else had to be on SQL Server. That meant a modest amount of extra work. Three/four client applications plus two databases. A nice little chunk of work to disrupt the momentum I had built up for the main project.

While I was definately productive on the database project (finishing my parts, the server and two of the clients, with about three days of work) I got barely anything done on the main project.

The work I did do was to fix/improve object composition. That is I can now make an object in-game out of many smaller objects. For example, a fighter can be made of a hull, two wings and two guns. This is all working well now. The underlying code isn't all that interesting to talk about so I'll refrain from doing so.

As I said before I also got firing bullets working. This really only required the addition of an extra phase in updating the game's state, known as the spawning phase. Any objects that are to be created are placed in a queue. At the end of the update they're created and added to the game. What I want to do now is add a few more rules governing when they're fired. I also need to add the capacity to remove expired objects from the game. Otherwise it will get quickly bogged down by thousands of bullets screaming off into the infinity of deep space.

Another Nasty Bites the Dust

As I mentioned in previous blog entries. This development cycle has been far more involved than the first. Mostly due to the fact that it involves a great deal of interdependent parts which all have to be developed at roughtly the same time. In this case I'm getting controls shared across multiple objects, object relationships and physics all working at once to support movement by simulating thrust.

I've figured out most of the math for the physics but it took several hours of effort to learn the basic math enough to even start. It was a few hours ago that I realized I'm starting to seriously diverge from what I want to be working on. What I'm trying to do is make the game look believable. I didn't originally intend to make the game accurate. *forehead slap* Out goes the physics, back to the drawing board.

My new method of simulating thrust is essentially a cheat. I'll just have thrusters appear to turn on and off in relation to the controls. Instead of simulating the behavior I'm simulating the appearance of the thrusters. This is far easier to build saving probably a day or more of work implementing it plus who know how long in getting it to be fun.

The Second Nastyish Problem

I now have the critical part of the batching portion working. Objects are decomposed to their smallest constituant parts which can then be rendered in groups. The actual grouping is still to be done but that's relatively straigtforward. I want to be able to measure how slow/fast I'm making my game's graphics before diving in to some hardcore algorithm hacking.

The next nasty problem for me to deal with is the issue of getting the game's controls working across multiple objects. For example, the player's fighter can be composed of a hull, a few guns and several thrusters. Input would need to be affect only relevant objects without causing weird side-effects in the others.

This problem is half solved currently. A single controller object, which is responsible for receiving and processing input from somewhere into actions. Any entity can attach itself to the controller and alter its state based on input from the controller.

A thruster, for example, can decide whether it should turn on based on whether the controller is saying "turn left" or not. This nicely addresses the issue of getting weapons firing in groups, thrusters firing appropriately and so on.

The second half of the problem isn't so easily resolved however. I also have to get state data from the enties that are attached to the controller back to the controller so that they can be sent to the network. My other option is to send complete object state data directly from each entity to/from the network, however that defeats the original purpose of the controller.

An additional problem I didn't quite want to solve this early, but have to, is getting the in-game physics working. This is due to my choice of controlling fighters via believable application of thrust and counter-thrust.

Plenty to mull over. I probably won't have a solution until the end of this week at earliest.

First Nastyish Problem Part 2

A nice bit of bone-headedness on my part. I spent around 40 minutes scratching my head trying to find how to get the VertexBuffer from ModelMeshPart so I could render it... only to find that it's in the ModelMesh that owns it. D'oh.

It really helps to look in the right place.

First Nastyish Problems

Now that the first phase of getting the basics up and running is done I'm starting to confront the nastier issues of getting this project to resemble a game that might, some day, be fun to play. Not to mention fleshing out the game's internals so they function as I originally intended them to.

The focus of the effort for the next couple days is on getting the graphics system batching objects to be rendered correctly.

The concept behind batching is to group together all similar objects to the video card in one big chunk. The hard part is that my graphics system is meant to contain very different types of objects (e.g. both 2D particles and 3D models) in a particular scene.

Technical crap below
My solution is to build two interfaces. The first, known as IRender, represents a complete drawable thing, for example a laser cannon on a fighter. This exposes objects which have the second interface, IRenderPart. These represent a piece of the whole object which has its own special appearance. For example an IRenderPart could be a glowing tip on the laser cannon and a second could be the actual body of the cannon.

The IRenderPart is the critical piece for batching. The IRenderPart exposes instructions on how it is to be drawn. The rendering enging groups all IRenderParts with similar instructions and draws them all at once. This, in theory, saves time used in sending different sets of instructions to the game console's video hardware since each set of instructions only needs to be sent once.

The big advantage of using interfaces is that they allow the graphics engine to see only the information it cares about to group the objects without having to worry about what, exactly, those objects are. This addresses the nasty issue of handling the variety of visible objects in the game that need to be drawn.
End of technical crap

Now it's down to implementing the changes. I'm approximately 25% done. In addition I need to implement a performance measuring harnass in the game so that I can perform adjustments to the game's code and know exactly what effects they have on the game's speed.

The Cockpit

Today I'm going to talk about the cockpit in the game as it is right now. When you're playing you see everything as if you're the pilot sitting in the cockpit of a starfighter. What I hope to do is display all information relating to the state of a player's fighter as part of the fighter's cockpit. This dictated that the cockpit be one of the first things to be coded since it will be critically important to the player's in-game experience. The fundamentals (code-wise) are there now but they're not much to look at currently since I don't have much of any artwork done.


I was motivated to do the cockpit this way by a pet peeve I have with space combat games like, for example, Freespace. The in-flight displays are just sprites, they're not part of the fighter! While this is primarily an aesthetic complaint it's something I feel is a major detriment to the immersion factor of games that often purport themselves as simulators.

There are a number of challenges with building the game's displays this way. Foremost is layout. The displays need to be placed such that they make sense and all of the information on them can be read easily. Also I need to decide how many displays there are, and what each should contain. Finally, I need to decide if there are to be any controls which change a display's appearance, for example switching between text and visual diagnostics. And, just for extra spice, the layout must fit completely within the "title safe" area which is the area visible on all TVs. If the displays don't fit then they'll be cut off for some players on the X-Box. Oops.

Currently I'm drawing inspiration from the F-16 fighter for a general layout of the cockpit. The F-16 features a HUD and three large displays for various tactical data.

In the game the cockpit will be somewhat similar. The HUD will display navagational and targeting data. The left screen will display sensory data and weapon status (e.g. ammo.) The right screen will display diagnostic data (i.e. what is, and what is not damaged.) The central screen will display tactical data. Additional information, such as score, is still displayed as text and graphics on the screen outside of game space.

Perhaps we have a muse

The first few builds of the project have been finished. Nothing too interesting to look at but you can fly around in space and the cockpit (but none of the information it should display) renders. After some initial testing with the demos I've downloaded I've decided that the Nuclex framework fits my needs better than Titanium XNA. It's a much more minimal product in that it's more of a toolbox than a game engine but the quality of those tools is excellent. Props to you Cygon!

For the past few days my girlfriend and I have started watching Batman: The Animated Series. One of several excellent cartoon series released by Warner Brothers in the mid ninties. I'm still impressed with how they managed to create such a surprisingly mature cartoon that was still accessable to children.

"But, what does this have to do with the game?" you might ask... One feature with Batman that stood out for me when I first watched it, and stands out even more now, are the amazing Art Deco images that pervade the entire series. I love the dichotomy of the style. With the right execution it can look both elegant and inviting in one moment then evil and terrifying the next. It looks both futuristic and anachronistic at the same time. Art Deco is an incredibly rich artistic style which I'd love to explore within the game. The future of the past if you will.

Just imagine something like this locomotive as a huge space-faring battleship... yeaaahhh :)