Seasons of War Dan Windrem (rona@stanford.edu) Dan Coleman George Gaxiola Platforms: Linux and Win32 How to Play ----------- Controls W w Accelerate Forward S s X x Accelerate Backward A a Turn Left D d Turn Right Space Fire Enter/Return Lay Mine Up Arrow Cannon Motion Down Arrow Cannon Motion Q q { [ _ - Previous Weapon E e } ] + = Next Weapon Escape Quit F1-F4 Camera Control Firepower The meter on the left side of the screen tells how much Firepower is currently available. If this meter is below the required amount of Firepower for the currently selected projectile, the player will not be able to fire until the meter fills up again. Different projectiles require different amounts of Firepower. Weapons The icon just below the Firepower meter represents the weapon which is currently selected. A mine can be laid at any time by pressing the Enter/Return key. The following is the list of available weapons: * Shell Cannon * Dirt Cannon * Dig Cannon * Rocket Cannon * Gopher Cannon * Napalm Cannon * Earthquake Cannon * Volcano Cannon * Akira Cannon Health The Health meter appears as a red cross on the back of the player's tank. As the player takes damage the meter will decrease and the player's tank will deform based on that damage. Targeting Crosshair The Targeting Crosshair appears as a spinning circle on the ground. The Crosshair hovers over the exact point that would be hit if the player fired a projectile at that instant. Pillboxes In addition to human opponents playing over the network, Pillboxes will be attacking the player from some of the terrain's hilltops. Try digging a hole for them. Download and Installation Notes ------------------------------- Seasons of War was developed on 733 MHz Pentium IIIs with NVIDIA Quadro based cards running Red Hat Linux and gets about 30 fps at 1600x1200 resolution. It was ported on a 400 MHz Pentium II with a NVIDIA TNT based card running Windows 98 getting about 18 fps at 1280x1024 resolution. It seems to run well on 32MB ATI Rage 128 Fury cards as well. I'd be interested to know how Seasons of War performs on other setups. Things of Note: * Setting the resolution to dimensions smaller than 1280x1024 may clip parts of the setup screen. * Pillboxes are currently invincible * Linux networking is only feasible over low-latency connections * Win32 networking has not been implemented Linux Binary Requirements * 3D graphics card that fully supports OpenGL 1.1 with at least 32MB RAM onboard * Latest drivers for your graphics card Installation * Download sw_lin.zip * Unzip the archive and run the binary * Everything should work if you have already setup your 3D card Notes * If you are running in full screen mode, try using kde as your window manager (x -w kde from the command line) and then kill kpanel * If it runs slowly, try changing the parameters in the sw_config.cfg Win32 Binary Requirements * 3D graphics card that fully supports OpenGL 1.1 with at least 32MB RAM onboard * Latest drivers for your graphics card * GLUT 3.7.3 (GLUT32.DLL) * OpenGL 1.1 (OPENGL32.DLL and GLU32.DLL) Installation * Download sw_win.zip * Unzip the archive * Obtain the latest drivers for you video card either from the card manufacturer's web page or if there is any confusion as to which drivers are the latest try GLSetup * Run the binary Notes * If you get the error message "GLUT32.DLL not found", try putting the GLUT32.DLL in the X:/WINDOWS/SYSTEM/ directory * If you get the error message "OPENGL32.DLL not found" or "GLU32.DLL not found", then you'll need to reinstall * If it runs slowly, try changing the parameters in the sw_config.cfg Technical --------- 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. Advanced Features: ------------------ control panel: we take an orthographic progection of any 'node' objects that are children of the screen base node. The coordinates are in pixels which preserves heights as the window is resized. scene graph: I implemented a node base class which lets you attach object to each other in the world for viewing and updating. There is a base node for the world and a base node for the screen. When we want to update or render the entire world we just call, VMUpdate(dt)/VMRender on the base node and traverese all the nodes children. view frustum culling: Since terrain points in the world are evenly spaced, its very easy to do view frustum culling on the terrain. essentailly its the same as drawing triangels (like assignment2). each square in the world is like a pixel on the screen. We take the left and right angle of the view frustum(in a top down projection) and consturct a triangle of grid squares to draw, that represent the visable portion of the terrain, the terrain drawing code in sw_node_terrain.cpp is almost the same as my triangle rendering code for assignment, execpt we dont need to check fro degenerate tris. collision detection: collision detection is done tank to tank, tank to turret, tank to terrain, and projectiles to tank. We do this by checking to see if the object is in the bounding sphere of another object. if it is it can not longer take any step in which the distance between the object it hit and itself becomes less. simulated dynamics: i dont know if these count, but the tank treads move independly base on there respective velocity, there is also a simple friction model. advanced rendering: all particles are billboared. sound: used plib's sl. Sound is attenuated based on distance, also used looping tank engine sound to hear if you are close to the enemy tank. ai: tank turrents look for the player closest to its range and try to hit them, not to intelligent. network: unix network support on fast networks, very small packets every tick about 32 bytes and another 32 if a projectile was spawned that frame. level editor: any paint program that can export 32 bit tgas (96x96) Models: All models are created in game, from openGL points. George Gaxiola did the tank model from scretch. Pillbox model imported through 3d explorer. Pillbox model made by a friend of mine, Andrew Dickson. Sounds: Quake3 sounds for the two menu blips. PowerUp from alterd beast, on the sega genisis Dan coleman, obtained other sounds from the web. Textures: Most taken from the web. Some taken from the game "Tread Marks", like the basic tank texture and some of the explosion textures. Leaf texture and spring dirt texture by Betty Cunningham, a friend. Sources: TGA loading code referenced from code found on the web, rewritten and striped of some of the useless features. the referenced code was about 2000 lines of code, I cut that to about 100 lines of code. see sw_tga. all the rest of the code is original and ours. all the models are ours, but some of the textures are not, but have been modified for the game. The sound library is a hacked version of PLIB's SL 1.3.1 by Steve Baker. we just incorperated that into the project so that we wouldnt have to worry about compling and linking problems... I was think about doing the same thing with glut but never got the time... Other sources of inspiration include Stuart Cheshire's Bolo and Wendell Hecket's Scorched Earth.