Three Projects... Four Projects... Five Projects!?!

Yes, well (conservatively) counting what I'm up to at RIM. The project I'm wrapping up is a particularly fun and rewarding one, creating a tool for providing detailed code coverage tracking for the various testing efforts within the OS Group. Sadly, the details aren't all that exciting. Mostly it's just processing gobs of similar data into an easily queried form. The majority of the work is in the logistics of collecting the data in a way that doesn't interfere with testing and manages to collect as much information is possible given the limitations of the testing environment. My other project(s) relate to some internal OS Group initiatives. I could tell you about them, but then I'd have to kill you ;)

So that's two...ish. Where's the other three? Well...

1. Space Combat Sim
   Yup, that thing is still going. Adding bots, improving the graphics, cleaning the code up and generally learning as much about 3D networked games as possible.
2. A shmup game developed from scratch for XNA on X-Box 360 and PC.
   Something simple for building a strong C# codebase that I can port to other projects. Goals here are making a programmable effects system and some decent GUI widgets.
3. Another shmup, using FlatRedBall
   Why? Because screw you! That's why... Actually I figured I'd just start messing around with plugging tools together just since that's normally not the way I make games.

Actually, to go on a boring long monologue...

I have finished only a few game projects, mainly for school. That tends to be because I approach the subject by first building tools and such, then building the game using them. I end up having so much fun making the tools that the project devolves into adding new features and refining code that I lose focus on making the game. Then I get bored and start a new project.

Now, I'm a tools developer professionally I can finally spend all hours of the working day making all sorts of exciting tools for a moderately hardcore development environment. This means that I'm not getting quite the same buzz from making yet more tools at home. So... time to make some fugging games!

Later d00dz! I'll try to keep the interval to next post to less than a month this time.

Some Inspiration

Lately I've been getting most of my coding jollies from my job as a tools developer at RIM. Mostly Python with a nice dose of C, SQL, and other stuff. Mainly fixing some reporting systems that go to external reports seen by management. Plus a dash of code janatorial work since nobody else seemed to be available/willing. After eight months doing solo work it's very nice to be working with a team again.

Anyway, that's not actually what I wanted to talk about. Today's just a shorty (I have a longer rant about myself coming later.) TIGSource recently posted a couple montages of a huge collection of free, indie games. I've played a few of them (Fraxy, Cave Story, Cho Ren Sha 68k, Prototype 2, Warning Forever, Clean Asia and one or two I can't recall... yea I'm a SHMUP fan) Holy hell there's some awesomeness.

Check it out!

So, What Now?

Well, today I spent a TON of time writing up blogs that I've been meaning to finish for a long time now. Three of them in fact! The first on exporting from Blender to XNA, the second on how the demos for Space Combat Sim went, and the third is a postmortem. But, I haven't talked about what I'm doing now, have I?

The short answer is that I have a job. In fact, I started my job before my "good demo" which was on May 4th. I'm working as a testing tools developer for Research in Motion. Unless you've been living under a rock for the past few years you've probably heard of their flagship product. Before I started this blog I worked as an intern for RIM over a period of 16 months. I work for the Operating Systems group which is responsible for all of the hardware drivers etc. that make the BlackBerry phone work. The culture of the OS Group, relaxed, friendly and fairly close knit, is what motivated me to return to RIM after finishing school. I'm quite happy working somewhere that I can spend the day working on hard technical problems with minimal political friction then finish the day by hanging around the pub.

My job now is to maintain and improve tools for automatically testing the Blackberry OS. Obviously I can't go into specific but I will be able to come out with articles on scripting, automation, testing and testing tools in a general sense. On top of the occasional post about work I'll still continue my game development work which means, of coure, more posts on Space Combat Sim and other projects as well.

Cheers.

Space Combat Sim Postmortem

In the spirit of continually learning I'm going to do a postmortem of Space Combat Sim as a school project. Don't worry though, this doesn't mean the project is dead. But the priority now is on having fun with it again, instead of busting my ass getting it demo-ready.

I'm basing my postmortem on those typically found on Gamasutra. If you haven't read one do so, they're quite eye-opening.

What Went Right
1. Tight, focused scope
Game projects can be massively complex. Particularly when they're 3d action-oriented online ones :). Most of my early projects started out relatively simply but grew into complex behemoths due to "wouldn't it be cool if" syndrome. For example a simple game where you killed enemies before they could leave the screen evolved into a vertical shmup with procedurally generated levels.

For Space Combat Sim the scope was set in stone from the beginning. The project would be a multiplayer game combining elements of X-Wing, Quake 3 and Counterstrike. Tools were only to be developed for the game if they were absolutely necessary (ignoring content pipeline extensions only two tools were made, one for creating hit boxes and one for creating effects.)

With the scope in hand I was able to set out a series of broad goals which defined how the game was to be built from the ground up. These broad goals were converted into a 24 page document describing all of the required features of the game (required for the course.) That was then turned into the detailed list of tasks that needed to be done to produce the game. Making the game was then simply a matter of finishing all of the tasks on the list. Since all time was spent exclusively on those broad goals the amount of wasted effort was minimized.

2. Continuous integration
Continuous integration means always having a working version of a project while it's being built. There may be missing features, and if it's a game it may look and play like crap, but it at least exists. One thing that always happens with software projects is scheduling issues. Feature creep, scope creep, unanticipated challenges or whatever, eventually something will cause a project to go off course. Having a working version means that even if the deadling is looming at least something is there for everyone to see.

In the case of Space Combat Sim, a lot could go wrong. I was challenging myself technically since I hadn't produced a 3D game before, nor had I produced a multiplayer game before. Except for a few occasions I succeeded in this goal. This was very helpful in keeping me from being too ambitious in coding features and forced me to break down overly lofty goals into more doable tasks.

3. Scrum-like scheduling
Space Combat Sim used a barebones version of Scrum, albeit with each cycle of development being much longer than specified. By dividing the project into sprints and assigning a set of real deliverables to be completed in each I was able to keep on task. The faculty's imposed limit of about 8 hours per deliverable also helped keep tasks from meandering and getting out of control.

What Went Wrong
1. Not enough time spent getting tools
The first four or five months of development time were spent building up the back-end code needed to support the first network session. A huge amount of that could have been saved if I spent that first month just looking at rendering engines and playing with them. No more shader development, effect tool development, etc. etc. in all about two months of work there. Sure, I'd still have to spend time on managing game objects and networking but that was kinda the point of the game. Instead I gave up after about two weeks of looking at tools, honestly, because it was boring.

2. Working solo
Especially in combination with making my own tools working solo made the game take a painfully long time to get done. It would have been quite nice if I could have focused more on object management, networking and gameplay while someone else took care of UI, loading, and other backend stuff. With only myself I generally had to focus on every task of game development which tended to result in polish getting short shrift.

The game's code is poorly documented in places, hacks abound and not all of the visuals that I wanted are in the game.

3. Continuous integration
Continuous integration has proven to be a double-edged sword. On one hand, having a working copy of Space Combat Sim all the time was motivating and helped reduce the impact of schedule slippage. On the other hand it made me midjudge whether a particular piece of the game's architecture was actually done or not. The area where this resulted in the most wasted time was in the game's startup sequence. The issue was that, while the game did indeed have space for its menus and loading sequence it wasn't really set up with its final usage in mind.

Having something that works, and having something that works correctly are different things. Continuous integration overall has been very useful, but at the same time it can cause one to do something that is expedient and fast rather than the correct solution suitable for the remainder of the project.

Conclusion
Overall I'd consider Space Combat Sim a modest success. I met my basic goal, which was to produce a multi-player combat game in space. My more lofty goals of having mission-oriented combat, style etc. weren't met due to time pressures though. The experience has definately been worth while and I learned a lot about actual project development through it.

Bad Demo, Good Demo

So, here's the final update about Space Combat Sim as a school project. I'll follow up with a postmortem and a bit about what I'm doing in the future.

Bad Demo
The first presentation was to faculty and some industry representatives (fortunately their thing seemed to be anything but games.) It was originally going to be in a classroom setting but moved to the lounge in the student life center due to the number of people attending. The lounge, which happened to have one, maybe two, network ports. Both which were in use by other equipment... sigh. Without being able to play with someone all I could do was crash into scenery. Not much of a demo.

I was able to re-show the project in a lab, with a proper network, but the damage was done. My kingdom for Fraps... and the time (and people) to use it effectively. The fact I didn't have a fallback in case of network failure was a pretty major oversight on my part. Still that last minute venue change was really frustrating.

The most frustrating issue though was the fact the most vocal representative was most interested in how a project was supposed to make money. The fact he seemed more impressed about a group wearing suits than their actual project (which was quite slick) was particularly rankling. Why in the fuck are superficial details such as what the presenter is wearing even considered relevant? Caring more about clothing than the product demonstrated is not something to be proud of!

The impression he left me is that I could have run a pre-rendered video (not a recording of the game) and made up some bullshit about online gaming being worth billions and not been called on the fact I didn't even present a product. That would have saved a couple months of effort... At least the other members of the panel were willing to ask some technical questions during all the presentations.

Good Demo
The second demonstration was at the technology program showcase for the college. This was a 3 hour affair where a large number of people in the various technology programs at the school got to show off their projects. This time a lot more time was given to setup, last time there was a token effort in setting up a router which didn't work at all when used for wired networking. The project was set up on two PCs and running with proper Live accounts. There was some pain as some old bugs managed to magically un-fix themselves, and I didn't actually have the passwords for the Live accounts that were set up for the demo, but that got worked out early on.

The big lifesaver was having Heather (from Slime Cat Blog) and her sister to demo playing the game while I could talk about what it was and how it worked. They would fly around, shoot at each other, be silly, laugh and generally have fun. This attracted a lot of attention from the various people attending the showcase. It also nicely showed what the project was without me having to go into crazy amounts of detail describing how it worked. I'm glad they were there because a lot of the people coming to see the project weren't gamers.

By the way, if you're wondering how those photo****d textures turned out; here's a rendering of the three fighter types.


Not great but still decent for about 2-3 hours per ship I think.

Imporing blender models to XNA as FBX

This post was meant for release on April 28th. I've been very busy in May and hadn't had much chance to update until now. Sorry.

For Space Combat Sim I've been making game models using Blender. It's powerful, it's free and it's got an active development community churning out new versions regularly. Check it out.

Like most modelling programs Blender uses its own file format for model data. XNA projects can't read these files. You normally can only add .X and .FBX files to games using XNA (though there are ways of adding your own model file importers via content pipeline extensions.) Fortunately Blender provides exporters for both X and FBX. I chose FBX due to the readability of the format and the fact the exporter worked more consistently for me.

Exporting from Blender to XNA created two major issues for me. One was ensuring the right material shaders were used. That was handled by writing a simple custom content processor. I simply named materials using "shader-name" which worked nicely. The second issue was more annoying. Blender uses a different co-ordinate system from XNA.

Huh? All modelling programs express positions using three numbers representing the object's position on three axes called X, Y and Z. Each axis represents one direction an object can move. In XNA, the X axis goes left to right, the Y axis goes from upward and the Z axis goes out from the screen (backward in the game.) In Blender the Z axis goes upward and the Y axis goes into the screen.

The result is that if I export a model and use it in XNA as is, it faces downward. Obviously that's a problem. Fortunately XNA provides a nice simple solution.

Just rotate it!

As you can see here the content processor lets you specify a rotation to be applied to the model before it's used by the game. This takes care of things nicely.

To finish, here's a list of things to watch out for.

• Scale. If you don't make your models size consistent with each other you'll need to deal with this in the content processor.
• Shaders. By default the model processor in XNA will assign the model a basic shader to render it. Not much good for fancy lighting effects and such.
• Orientation. I tended to model my ships facing along the negative Y axis keeping rotation simple. If your models aren't facing straight along an axis importing can be more painful

More Spit and Polish

The project demo is in just a few days now. So I'm going crazy with minor bug fixes and polishing to ensure the demo goes well. For example:

• The game join menu doesn't crash when no games are available


• The game join menu will poll for new games if none are available


• Beam weapons now do damage when swept through other ships


• All incomplete scenarios are have been disabled


• Fighters have photo****ed textures instead of default test patterns


• Minor damge model bugs fixed


• Thrusters flicker slowly enough to be noticable


• Sound effects fade correctly

Regarding the photo****: One thing I really wanted to do in this game was give the fighters a nice metallic look. Metal is shiny! But, if I add shininess to the game it gets choppy. Ugh. But I might have a solution. Rust! Patina! etc.

I want to avoid making the game a rusty-brown shitefest so I'm hoping to go for more of a tarnished silver/brass/bronze/copper look. If, later, I manage to get some decent shininess at decent speed I'll bring back the metal look I wanted originally.