This page is dedicated to answering technical questions people have had about the game and its development. If you have any questions not answered here send me an email.



Questions: contact Dan Windrem



How was Seasons of War developed in just 5 and a half weeks?

There are a bunch of things that made the development go quickly and let us make very polished game in such a short amount of time. I’ll go over the major points.

OpenGL
After getting past the naming conventions and programming structure, writing code that orients and renders objects takes no time at all. For example, as of 24 hours before the end of the competition none of the 10 projectile explosions had render functions. I wasn’t worried then because I knew how I wanted each to look and I knew implementing each would be trivial with OpenGL.

Linux
We decided early to develop on Red Hat Linux and port to any other operating system. This turned out to be a very good decision. Instead of the 12-20 reboots a day I had when porting to Win32, our primary development stations would only crash about once a week (albeit, when they crashed they crashed hard). This stability really helped in the crunch.

Division of Labor
When I realized my teammates weren’t as energetic about the project as I was, I made the best of it by dividing the labor in such a way that the other members could work almost independently of the engine. I could then outline the network and sound static objects and have Dan Coleman fill them in his own time. By having them work outside the engine, we saved a lot of time since every little tweak or fix did not have to be relayed to the rest of the team.

Thinking Portable
Making the game platform independent was something I forced myself to keep in mind. We choose GLUT 3.7.3 as our window manager and SL 1.3.1 for sound support. We lost a little on quality (no Quake style mouse turning and only 8 kHz, 8 bit sound) but we gained a whole lot of portability. The only part of the code that is platform dependent is the network code and according to Dan Coleman, he’s “still working on it.” With network disabled, any platform that supports GLUT and SL can run Seasons of War.

How is the terrain rendered? How is the terrain deformed in real time?

When the player selects the terrain in the setup screen, the terrain is loaded from the terrain file. The terrain is stored as just the height data in one of the color components of the *.jat image file. Each pixel in the file represents one point in the world. As the pixels are read in, they are converted to heights by multiplying by DTERRAIN_MAX_HEIGHT. So now we have a two dimensional grid of points, from which we can create triangle data, two for each square in the grid. At this point we can also calculate normals per vertex by sampling our two dimensional grid of vertices. We used 96x96 *.jat files so the terrain comes to 18,050 triangles (2*(n-1)^2)). Because our terrain grid is evenly spaced when we take a top down projection, we can do very fast view frustum culling on the terrain. We take the left and right edge of our view frustum, project them onto the plane and then render only triangles that fall in that region.

Instead of deleting the control points after we have the triangle data, we keep these vertices so we can do the terrain deformation. When a projectile hits the ground, it messages the terrain to deform at the current position based on certain parameters. The terrain takes the position information of the projectile and its type and for each point within the blast radius, the vertex is added to by halfVerticalDisplacement * (cos(distanceFromProjectile*scale)+1.0f), which gives a nice even mound or hole. After that the normals are recalculated, the “burnt” attributes are updated if necessary and the vertex data is replaced.