Devastro updates, part I

I decided to do some extra work on Devastro. I need to make localization easy because there are some distribution deals coming and I want to keep all the different builds in sync. Second, there will be more variety to the missions and some enticing mid- and long-term goals. Third, the controls, handling and graphics get some fine-tuning to give the game a better “feel”. Yes, even the aliens get a proper walk animation. I’m so generous.

Part I, fine-tuning

Starting easy with various little tweaks here and there.

Added dynamic alpha blending to the renderer. All smoke, decals and debris can now fade in/out smoothly. Took quite a time to add the alpha component to the rendering “pipeline” but once it’s done it can be used for many things.

Added keyboard controls. Ctrl for shooting (same as left mouse button), arrows for walking. As expected, these two don’t work together very well. The soldiers still aim where the mouse cursor is, so it’s impossible to play using just keyboard. However playing using the arrows for walking and mouse for aiming is alright.

Improved pathfinding. The a* algorithm now uses 8 directions (connections) for each node instead of 4. Soldiers that get behind and have to get around obstacles to join you again don’t look so stupid now.

Barrels! Just like in Doom. Shoot them, they explode. Not used in any levels yet.

More graphics. Finally got a pretty good looking water with nice banks and isles. Still needs some work. Made pictures of walls, rocks and concrete floor for extra textures. I’m planning to add some larger terrain obstacles. Added muzzle flash effect to soldiers’ machine guns, looks pretty cool. Also replaced the shooting sound, it has more ‘kick’ now, pretty addictive.

Improved level editor. Adding ‘links’ between various objects is now done by drag & drop instead of typing the ID numbers of the objects. Should’ve done that earlier.

Added support for “zooming” in and out. Not used yet but the plan is to add some levels or cutscenes that will be played in a different scale. Also very useful for the editor.

Many other fixes and tweaks; upgraded bundled JRE, NSIS, Retroweaver; done a lot of refactoring in many places, removed Linux build scripts (maybe next year will be the year of the Linux desktop? No?).

Devastro project postmortem

What’s a postmortem? Did somebody die? Not really… it’s actually about a game being born. It is an after-the-fact analysis of a completed project, in this case, the computer game “Devastro”.

Yes, let’s start
Yes, let’s start

Introduction

Devastro is a fast-paced 2d action game. With a team of up to 4 soldiers your mission is to stop an alien invasion by destroying all flying saucers and killing all enemy. Some missions have different objectives, such as herding sheep to save them from the aliens.
The theme of the game draws inspiration from 50s sci-fi B-movies such as „Earth vs. the Flying Saucers“ and „Forbidden Planet“.
It took 9 months to create Devastro from start to finish. Everything except music was done by a single person – me. I designed it, programmed it, created all the graphics, sounds, and levels myself.

They came, they saw and they got their green butts kicked.
They came, they saw and they got their green butts kicked.

What went right

The right scope. The size of the game was just right for me as the sole developer. If I had chosen anything more complex it would’ve taken much longer or more likely I would not finish it at all. On the other hand, doing a simple puzzle gem swapping game would have felt like cheating. And I don’t play games like that myself, so it would be boring.

If you run out of grenades, make something else go boom.
If you run out of grenades, make something else go boom.

The platform. Java was a blessing for this project. I was able to refactor things right away and keep everything under control. The source code is over 38000 lines of code and I cannot imagine dealing with the same amount of C++ code so quickly. At the start I knew C++ and STL and Boost pretty well and knew little about Java, but it was very easy to pick up. Debugging and profiling the Java application was so easy and quick I could hardly believe it; Eclipse is a wonderful IDE.
Apache Ant is a great build tool. With one click I can make a new build for three platforms, create the installation packages, upload them to FTP and update the Help page to show the new version number.
And to people who’ve never used one themselves, a version control system may seem overkill for a single person but in fact it is absolutely essential.

The “team”. Having other people do some parts of the game would have definitely slowed it down a lot. Since I was doing everything myself, I never had to wait for anybody to finish their part and all the tasks were in my head.
I always had many different things to do, which meant that I was free to choose what I felt like doing at the moment. Bored with AI code? OK, let’s work on the website for a while. Stuck on graphics? No problem, go record some sounds with a microphone or set up the credit card processing system. The variety of the work was immense and I enjoyed doing it this way. The only thing I didn’t do myself was music. A friend of mine did it at the last moment and it turned out very well. Thanks, Bourek!

It is empty. That means I’m done. Hooray!
It is empty. That means I’m done. Hooray!

Custom development tools. Luckily I realised the importance of having good level and sprite editors early on. I put quite a lot of effort into them and made sure it was possible to create an entire level from scratch without having to edit anything by hand. It is even possible to record the soldiers’ movement and play it back as a part of a cutscene.
The editors are built into the game so the turnaround time between editing and testing the gameplay is really short. I even considered including the editor in the shipped game but decided against it, as it would have required some additional polish I didn’t have time for. Also, probably only a few people would have used it.

Don’t let them kill more than one sheep within the next 4 minutes. Isn’t that clear?
Don’t let them kill more than one sheep within the next 4 minutes. Isn’t that clear?

What went wrong (not much, really)

Financing. Towards the end I was really broke and had to borrow money. Having some savings before starting the project would have helped a lot. This is a double edged sword though. Being broke forced me to work harder. It was the best motivation I could ever get.

Flying saucers that don’t fly… Not all the features I wanted to put in are included. All the saucers that you encounter have already landed, you see none of them actually flying. Helicopters and other types of vehicles such as tanks have also been left out. There wasn’t enough time to do it properly, so I didn’t do it at all. I don’t consider this “cutting corners” because the game doesn’t really suffer without these features but on the other hand… tanks are cool, right? Maybe next time.
A few people complained about the lack of proper animation for the aliens. I kind of expected that but kept them in anyway. They do stand out but that can be a good thing considering they are your primary target. So this will either be an improvement I keep for a future update or you will just have to get over it. If you don’t like the way they move, shoot ‘em, not me.

Short play-time It is possible to get through Devastro from start to finish within an hour. On average it will take about 90 to 120 minutes. That’s not much.
Almost each level in Devastro has some unique feature or trick that sets it apart. I didn’t want to water it down just to be able to say it has 300 levels worth 45 hours of gameplay and charge more money.
Also, 90 minutes is not much when compared to other games but it is the length of a feature movie. You can have great fun playing it and then still have time to go out.

OpenAL issues. There are different implementations of OpenAL and some of them behave differently than others. The Mac version of the game often crashed because of OpenAL. This is a very hard thing to debug and in this case even harder due to the fact that I don’t own a Mac myself, so I have to rely on other people’s crash reports. I should have used the more proven FMOD library for audio playback.

Conclusion

The project turned out very well and I’m curious whether it’s going to sell any copies. I had a great time working on it and learned an incredible amount of things. I definitely plan to make more games in the future. It is a great feeling to see the credits roll by.

Devastro home page:
www.catnapgames.com/games/devastro.html

Go home, we’re done with shooting.
Go home, we’re done with shooting.

Number of developers 1 full-time, 1 contractor (musician)
Budget $0
Length of development 9 months
Release date 2007/1/22
Platforms Windows, Mac OS X
Used hardware Low-end office machines running Windows, one Mac Mini for testing the Mac version.
Used software Java, Eclipse, Apache Ant, NSIS
Size 3 GB of source assets, 38000 lines of code, 15 MB resulting installation packages for each platform.

Development tools

Here is a list of development tools I’m using at the moment.

Hardware

  • Athlon XP 2GHz
  • 1GB RAM
  • 21inch monitor (important!)
  • Low-end NVIDIA graphics card
  • Nikon Coolpix 4500

Software

  • Java 1.5 and some 1.6 betas
  • Eclipse
  • Subversion
  • BMFont
  • Adobe Photoshop
  • Apache
  • Ant
  • Nullsoft Scriptable Install System (NSIS)
  • Retroweaver
  • Pngcrush and Jpgcln

Libraries

  • LWJGL
  • Commons Http Client
  • Log4j
  • Jorbis
  • XMLtp
  • Args4j

Built-in level editor

When I started working on Devastro I thought I could create most of the data in external editors and by hand. I can draw the sprites in Photoshop, export to PNG, add some hand-written meta data. I can draw the levels on paper, then hand code them in some human readable text format. Easy.

Forget about it. It gets messy very quickly. Not that there’s so much metadata for the sprites, but there are many sprites. Not that there’s much stuff in a level, but there are many levels.

Now what? Can I use existing tools to solve that? Photoshop has a feature called Slices, I can use that to add collision boxes to the sprites. Save the HTML output, parse it, extract collision box info. Easy!

No? No. It didn’t really work that well. I ended up writing a custom sprite editor and a custom level editor. Is it worth it? Definitely! Level editing is a joy now, which is what it’s supposed to be. Editing sprites is now, well, bearable.