The main ingredients for making a great tank game are "guns, lots of guns," as Cameron Smith puts it. Smith, a 23-year-old from Brandon, Manitoba, Canada, helped create the player tank models in Scorched 3D. Future versions of this free software game, he says, will have "biological weapons, aiming systems. We recently added one favorite: napalm."
Adding to the armory is a natural evolution considering that Scorched 3D itself is an expansion of an old DOS game: Scorched Earth. In this classic, players lob artillery fire across great distances, aiming to blow up their opponents' tanks. Scorched Earth's graphics are in 2D.
Gavin Camp, a 26-year-old software engineer in Scotland, UK, took this simple duel game as the model for Scorched 3D, which is, as its title suggests, a remake of Scorched Earth punched up with 3D graphics. He also included the ability for up to two dozen people to play at once across a LAN or the Internet. Scorched 3D was originally developed under Windows, but the source code has since been modified so it runs on Linux and other platforms.
Camp recently talked to the O'Reilly Network about the requirements of translating the 2D gameplay of Scorched Earth into the 3D realm.
O'Reilly Network: What inspired you to create a 3D version of the classic game Scorched Earth?
Gavin Camp: Scorched Earth was an institution for me and my friends at university. On many nights we used to play the game while drinking -- although it is pretty good even without the drink. Recently on a boring flight I played it with friends for eight hours straight; we hardly noticed the time passing. I thought that Scorched in 3D would allow many more game concepts, and [it] also combined my love of 3D graphics with the classic game.
|Linux/Unix System Administration Certification -- Would you like to polish your system administration skills online and receive credit from the University of Illinois? Learn how to administer Linux/Unix systems and gain real experience with a root access account. The four-course series covers the Unix file system, networking, Unix services, and scripting. It's all at the O'Reilly Learning Lab.|
Scorched 3D started as a 3D landscape generator. We gradually converted it into a game, which is why the first few versions have more graphics than gameplay. Originally, I toyed with making [the game setting] a small planet in space, eventually choosing instead to make it an island. The water element provides many gaming possibilities and restricts the graphical detail that needs to be drawn.
ORN: Does Scorched 3D incorporate code that your team did not originally develop?
Camp: Scorched 3D started off as a Windows game. It did not use any other code or libraries, but instead made heavy use of the DirectX libraries. As time progressed, more and more third-party libraries were used to save development and testing time. Many of these libraries are used to make the game cross-platform and to take the place of DirectX when it was removed. These libraries provide a hardware abstraction layer, so we didn't have to write platform-specific code for each supported platform.
The portability libraries we use are SDL (Simple DirectMedia Layer) and wxWindows. All calls to DirectX -- DirectPlay, DirectInput, and DirectSound -- were removed and replaced by calls to SDL. Any native OS GUIs were replaced by wxWindows GUIs. Scorched 3D now supports Windows, Linux, Solaris, and Mac.
The other libraries used are purely to give us more time to concentrate on the actual game logic. These libraries are ODE (Open Dynamics Engine), a free physics engine we use to model particles, tanks, and missiles; and zlib, a compression library. We use zlib for coms compression.
ORN: What major technical challenges did you have to deal with in making Scorched 3D?
Camp: Most of the problems are caused by differences in graphics cards and their drivers. I use a GeForce card, and many Radeon owners say that the OpenGL effects look different on their cards. Scorched 3D uses quite a few OpenGL extensions; since these extensions are not supported directly by the static OpenGL API, the game tries to detect the extensions and enable or disable features dynamically. Sometimes this does not work, as some graphics cards wrongly say they support features when they do not, or support the feature but not to the required specification. Without hard-coding checks for certain cards, this can [require] a certain amount of fiddling with the display options to get it all working.
Making the game cross-platform has introduced its own set of problems. Not only must you write portable code, but it also prohibits the use of some libraries that can be used to help implement the game. Originally, the game was written using the DirectX API for the network, sound, and input features. All the DirectX code needed to be removed and replaced by cross-platform libraries. DirectX has a very full and nicely abstracted API; during the conversion, new code needed to be written to wrap the portable libraries and abstract them to the same level as provided by DirectX.
ORN: What are the unique challenges in designing a network game that uses 3D graphics?
Camp: One of the aims of Scorched 3D was to allow players with low-bandwidth connections to play and not have a disadvantage [from] someone on a faster connection. To facilitate this, Scorched 3D does not communicate with the server during most of the game cycle. During the time to decide what move to make, no communication is sent to the server. Once a move has been made, it is sent to the server. Once all moves have been sent to the server, the server simulates the outcome and then sends the result back to the client. Each client then independently re-simulates the result, using the data from the server to ensure the same outcome. Once the result is received by the client, no communication is received again until another move is made. As each client uses the simulation data from the server to check its calculations, this ensures that all of the client simulations have the same outcome.
In earlier versions of Scorched 3D, the clients simulated the outcome on their own and did not check their simulation against the server -- similar to how some RTS games work. This led to clients gradually getting out of sync due to the large number of floating-point calculations required during the simulation, and the floating-point differences across systems. Eventually, these differences could get bad enough to cause inconsistencies -- for example, causing a [player] to die on one machine but not on another.
When the first version of the game was released, many people commented about how easy the game was to hack, even though at this point the source code was not available. People were hacking the binary executable. The move to the client-server architecture made more sense. Although there are always hacks that can be made, at least with this model simple hacks, such as changing the values of health in memory, are discouraged.
ORN: Did you guys have to develop unique networking or graphics technologies?
Camp: One of the first and most difficult problems when creating the game was how to generate a realistic-looking landscape mesh. The technique we finally hit upon was very simple: Adding a random number of differently proportioned hemispheres to the landscape surface, smooth them, and then scale them. Depending on the number and size of the hemispheres, this can generate very different landscapes.
The landscape uses an optimization technique based on ROAM. ROAM allows landscape meshes to be optimized in real-time, depending on their proximity to the viewer. At the time of coding, there were not many ROAM implementations, and Scorched 3D uses one written from scratch. ROAM was an ideal choice, as it not only performs the optimizations in real-time but also allows the landscape to be deformed in real-time.
When moving the network engine from DirectPlay to SDL_net, a network layer was written. This network layer abstracts the game from the network, allowing different protocols to be added to Scorched 3D and the game code to communicate to clients via the notion of players instead of sockets. This notion of players hides the actual player location from the game. Currently using this network framework, there are TCP, UDP, and HTTP handlers for different parts of the game.
ORN: Any plans for a P2P version of Scorched 3D? At first glance, it appears this game could work well on a P2P network -- or not?
Camp: To change Scorched 3D into a dedicated P2P application would require a complete rewrite of the coms subsystem. Although Scorched 3D does not explicitly support P2P, it can run on a LAN with a dedicated server running on one machine with others connecting to it as clients. The server does not use many resources, so it should not be a problem to run it on the same machine as a client. Actually, that is how a lot of the testing is performed.
ORN: Could the Scorched 3D engine work well as the foundation for another game?
Camp: The Scorched 3D engine is designed to be very modular. Different services are provided via components. Each component plugs into a state machine-driven framework. The state machine determines which components are active (receive network, input, game events, etc.) in each state. The graphics and physics components are just two of the many components that can be plugged into the state machine. For example, the server uses some of the components from the client, but in a different state-machine configuration. The game logic is then slotted into the state machine to drive the state changes.
The Scorched 3D framework could be used as a whole or components could be removed and used to form another game. To my knowledge, there are no other projects based on the framework. Although the architecture developed seems to work well for Scorched 3D, it's a little bit of a special case with the scale of the landscape and the fact it can be deformed. For most cases, you are probably better writing on top of a commercial engine like Quake or Unreal.
ORN: What's planned to be added to future versions of Scorched 3D?
Camp: The next stage is to add more elements to the gameplay. High on the list are team play, tanks having different capabilities, making the water an integral part of the gameplay, and making more use of the 3D environment (smoke cover, limited viewpoints, fog, clouds, etc.).
ORN: What contributions could the Scorched 3D project use from volunteers who are interested in lending their talents?
Camp: We are missing cool graphics stuff: Things like trees and buildings, better landscape textures, better water features. We are also missing graphics features that use the capabilities of the new graphics cards, like vertex or pixel shaders for reflections in the water, grass, etc..
ORN: What's the foremost lesson you've learned from your experience while making Scorched 3D?
Camp: Try to keep the project varied and get it out to the public quickly; both things help to keep your interest up. After all, you will probably be doing the project in your free time. Try to make your project cross-platform from the beginning. Adding it afterwards can be very costly.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to LinuxDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.