Jagdgeschwader was my entry for the „Pascal-Game-Developement“-Dogfight competition that was held between January 1st and March 15th. As the Name of the competition says, it was roughly (although many other entrants were not sticking as close to it as I did) about doing a game that circles around a Dogfight. For people that don't know what it is : The term „Dogfight“ was „invented“ by pilots in WWI/II and means a fierce fight to the death between two aircraft pilots. And that's exactly what my game is about. Since I'm very interested in especially WWII (which I still think is a very interesting topic, although most people prefer to ignore it) I was glad that this contest was about Dogfights, so without thinking about it too much I knew that I'd made a game that at least uses World War II – Aircrafts. This document will tell you about the project itself, what tools I used and also what went right and what went wrong. Since I enjoy reading the Post Mortems over at http://www.gamasutra.com, I'll write this one in the same style and I hope you enjoy it too.

Knowing your abilities. I'm coding (mainly games and 3D stuff) for over 15 years now, and in those years I learned what I can and what I can't. I'm good at coding 3D-Stuff but I'm not very good at 3D-Modelling and I'm very very bad at doing music. And when you're on a deadline it's very good to know what you can and what you can't achieve. So since I knew from the beginning that I'd never get some decent aircraft models done (the models itself yes, but doing the textures is the real magic) or would never be able to compose fitting music I directly started searching around the net for models and music. Finding models wasn't too hard and the guy that made them directly answered my request and allowed me to use his great models (Thanks go to Vincent) in my game. Finding music was a bit more tricky, but I finally found a public domain song that I then used. So with having the stuff I wasn't very experienced at being cleared out at the very beginning of my game I could concentrate on the stuff I'm good at : coding.

A clear vision. I already mentioned it in the introduction : From the very beginning (right after deciding to enter the contest) I knew that I would make a game about WW2-aircrafts fighting each other. Having a clear vision makes things much easier, since you don't really need to try out until you think „this is what I want the game to be about“. So when doing a game (especially under a time constraint) make shure you know what it'll be about from the very beginning. In my opionion this should be the first thing you should scratch your head about when doing a game.

Using well-known libraries. This one is also very important. If you have a project that needs to be finished in a certain timeframe, never ever try to use different libraries than you were already using for other projects. If you do so you'll much likely get into troubles which could cost you time and in the end could mean that you'll have to switch back to well-known libraries. I knew that I wanted good physics, so I used the Newton Game Dynamics Engine, I knew that I wanted the game to be in 3D, therefore I stayed with OpenGL. And as for the sound I had good experiences with FMOD (as opposite to OpenAL, which gave me some real troubles in another project) so I just used it again. To end this one with some smart sounding sentences : „Innovation is nice, but if that innovation would mean that your project would not be finished in time it is useless.“.

Setting timed goals. This one should be obvious and goes hand in hand with „A clear vision“. If you know what you want implement then you should say to yourself something like „today is monday and I want feature X implemented until wednesday“. Setting such timed goals, and moreover also keeping them, is (at least was for me) very important. If you have a limited amount of time to finish your project you should always put yourself under sime time constraints and you should also keep them. Just saying „I want feature X implemented someday“ will much likely end in a way that you're only two days away from the deadline and still haven't done a single line of code to implement that feature.

Having fun developing the game. Since this game was not developed as a commercial title, where it's all about money, the only thing that decided on how the final outcome would be was how much fun I had developing this game. This is a point I find very important when I develop especially games. Cause when you develop for "nothing" (at least nothing material) then the only motivation is often how much you enjoy working on your game.

Networking. Although I implemented networking (which is working) I was not very satisfied with it. The biggest mistake maybe was to use TCP/IP instead of something more suited for games like UPD. But since I already did one game using TCP/IP and did not really had the time to get my head into UDP (especially testing would have taken more time than testing something I already used) I stayed with it. But TCP/IP has some know drawbacks, like the fact that packages are always delivered, and if one package does not make it to it's destination, TCP/IP will do everything to get it there, which also means that all other packages have to wait. So if you play the game over network, you'll find it to be very laggy on the client-side. So my next title will much likely use UDP for newtork communication.

No clear vision of the scenario. As already stated, I had a clear vision what the game should mainly focus around. But what I initially did not thought about too much : Where should the aircrafts fight each other. My first intention was to just have them fly around in the clouds, but that soon turned out to be boring and looking too dull. So the second thought was to have some huge bombed city where you could fly around. But the drawback on that one was the fact that it then really had to be huge and that I would have to model it, which would have taken very much time (and in the end would have meant that the game would only have one scenario). So I also dropped that idea and then at some point thought „why not use a basic terrain“ and implemented it. It was easy to implement (using an octree and frustum culling for visibility testing) and moreover it was easy to add new scenarios by just creating a new heightmap and a new terrain texture.

Delphi's integrated debugger. Sounds weird, I know. And I also thought about not writing down this, but as this was the first project it really annyoed me I had to write this down. Delphi's integrated debugging features are great and make finding bugs *normally* very easy, but this time the integrated debugger exactly did the opposite. This may come from the fact that I used Newton, since especially when creating bigger collision trees (this is the type of collider used for the terrain and the trees) Newton allocates much memory (since it also tries to optimize collision data). And this is where Delphi's integrated debugger started to get me kind of angry. Not only did my scenarios need at least 2 or 3 fold the time to load, the integrated debugger also threw some exceptions that did not occur when I ran the game outside of the IDE. So this was the first game ever that I developed almost fully without using Delphi's debugging features (luckily I didn't need them very often either).

As you can already guess when you have seen the source code, I used Borland's Delphi (7) for coding my entry. I think it should be obvious, since there aren't too many alternatives when you want to do Pascal under Win32. Free Pascal/Virtual Pascal (and the others) are nice but are lacking an IDE as good as the Delphi one. And since I also did all my OpenGL/Win32-Projects before with Delphi too, the choice was obvious. But with Lazarus becoming more and more usefull, this could change in the future.
Coding itself went very smooth, but (in terms of amateur coder) I guess you can count me on the more advanced side. I already did several „bigger“ projects (see e.g. Napalm Bomber 3D, which made it around the whole world and already had over 70 thousand downloads), so I went straight on to start coding on my contest without thinking too much about how I would lay out the code. UML and other modelling tools are nice for bigger projects, but with a project of this rather small scale I find such things a pure waste of time. One thing I also should note is that I made almost everything from scratch for this contest entry, as I'd found it somehow unfair to use all my existing stuff to quickly put together a game. So almost every unit you find in the source package (except some basic stuff) was made just for this project. And if you take a look at my sources, you should see that I always stick to (there are exceptions, like some newton callbacks, but that couldn't be done otherwise) OOP and clean/well-documented source. Those both things are very important and everyone should stick to them, even if you do some small projects.
But back to how coding of the game went : Since I had a close vision of what I wanted (dogfight on the outside, two planes pitted against each other, using newton for physics), it took me roughly 2 hours to get the first prototype working, where you could fly two aircrafts around in a splitscreen-mode. Why did that went so fast you may ask now? Because I had a clear vision and knew what to do. If you lack one of those, your project will go nowhere. One example was the flight-model for the aircrafts : From the beginning on I wanted an arcade-like flight-model, so I searched around the net for some documents on aircraft physics, took what I needed and tweaked physics so that it would feel the way I wanted. So the most important thing, namely the movement/physics of the aircrafts was implemented at first and only did change marginally during the rest of the developement time. So my simple tip : If you have a project that has a deadline, implement the most complicated thing first (as long as it is an important feature). If it'll take you much longer than you thought you can still leave out some of the basic things. The rest of the developement time then went into additional graphics things, a rather nice looking GUI and mostly getting content into the game. Since I'm quite advanced in terms of OpenGL I had no real troubles getting all the graphics stuff to work (terrain, reflections, etc.) so that I even had some time to implement additional features like a lensflare and the vegetation (which made it into the game only a few days before the deadline).

At least for me, the most important part of a game is not the code (or engine, or whatever) behind it, but the content itself (I count „gameplay“ as a part of the game's content). A great engine with all the latest whistles and bells is worth nothing if the game that's made of it contains just boring maps, ugly enemies and uninspiring gameplay. So I've spent much more time on the content of my entry than on the code of it. What I personally find very important is the atmosphere of a game, which is mostly influenced by graphics. So a game should not only look good (or at least as good as the targeted hardware allows), but it's look should feel like it's made up from „one part“. So when creating the scenarios I first thought „how should the scenario roughly look like?“ and then started to create the terrain and terrain texture. After this I tried to create a skybox that would fit the feeling of that terrain and then also added trees that would fit into the scenario. If all those things, that made up a scenario, fit together, you get a great atmosphere and the player feels comfortable. So rather than trying to do graphically outstanding stuff I concentrated on getting a homogenous look for my scenarios.
The same goes for gameplay. Just look at what those things are called : Computer games. See that bold part? Yes, it's about games and the main purpose of a game is to make fun. So unless you want to make a simulation (which also are fun, since they let you do things you normally don't get to in real life) make shure that your game is fun. At least that's what I tried with my entry. At first I had a rather complicated flight-model (although it was still arcade) that featured some complex calculations that normally are used in realsitic simulations. But shortly after I implemented the terrain I knew that this flightmodel was too complicated and that the player had more problems keeping his plane not crashing into something than chasing the other player. So I started stripping down the flightmodel until I felt it was fun to play with.
This also can be applied to the properties of the aircrafts. Since those are real aircrafts that were used in WW2 I first started collecting information on them (like how fast they can go, how many weapons they have, etc.) and wanted to implement them into the game. But after comparing them I realized that, when I would use the real data, the planes would have been badly imbalanced. One plane in reality had 6 machine gunes where another only had 2, so the first one would have crushed the other one. In the end that would have meant that everyone would just use the better aircrafts. So instead of using the real data I only used two different properties for each plane (speed and firepower) and shared 8 stars on each of that property, so that all planes in the end would be balanced.
To make it short : If you want to make a small game (simulations tend to be bigger and take more time, small games are usually played for a short time), then try to make it as fun as possible and don't try to make it feel to real.

Every developer should have his set of tools that he uses to do at least the content of his game. Since there are so many good and mostly free tools available, finding what you need should not be too hard. Here is a more or less complete list of the tools I used for Jagdgeschwader.

Adobe Photoshop (commercial)
Although rather expensive this is THE choice for imagemanipulation/composition for windows. Although many see the free GIMP as an alternative, I don't (especially since GIMP's UI is not very windowslike). I used Photoshop mainly for doing the 2D graphics for the userinterface of the game, but also do to some maniplation of textures.

TerrTexGen (selfmade) and T2 (free)
Those were used to create the terrain textures. I used two tools, since on depending on what I wanted to achieve one of them gave better results than the other.

ScapeMaker (free)
I did some of the heightmaps with this rather neat tool. If I did not like the output I loaded the heightmap up in Photoshop and did some afterwork on the heightmap by hand.

TreeMAGIK (free)
Luckily this nice tool to create 3D-Trees became freeware just some weeks ago, so I didn't have to make the trees myself in some 3D-Modeller.

I already posted this some weeks ago on the web. This is the developement history of my project documented using screenshots. They're sorted by date so that you can directly see how my game advanced over the time.
06.01.2005 :

---

08.01.2005 :

---

25.01.2005 :

---

26.01.2005 :

---

02.02.2005 :

---

05.02.2005 :

---

08.02.2005 :

---

11.02.2005 :

---

19.02.2005 :

---

23.02.2005 :

---

26.02.2005 :

---

27.02.2005 :

---

03.03.2005 :

---

08.03.2005 (final!) :

---

And last but not least, a photo of my workplace where all coding happened :

---

So thanks for reading my first post mortem, hope you enjoyed it as much as playing my entry. This game was my first entry into a competition, mainly because this compo's theme was interesting and I had the time to enter it. My thanks go out to Dominique for organzing this, to the sponsors for supplying the prices and all other fellow pascal coders that also entered this compo!