 |
Submitted by , posted on 20 June 2002
|
 |
Image Description, by
Trash: Harvest it, make war machines with it, then turn your enemies into it.
Trash is a Real Time Strategy Game set in a Post-Nuclear War Desert Wasteland. The game features three races: the Humans, Mutants, and Machines. The Humans offer easy-to-learn gameplay to those who have played other RTS games. The other races introduce unique and interesting gameplay.
The game focuses on multiplayer action and supports games up to 24 players. The game design encourages coordination with teammates. We created a separate lobby server app for the in-game matchmaking.
Beta Test. We hope to begin our beta test sometime soon. We are
looking for beta testers. We are going to need a lot of them. If you
are interested in helping us out, please sign up at our website. http://inhumangames.com
Technical Features
Custom Built 3D Engine. Simple yet effective for an RTS game with many players. Features a flexible particle and explosion system, random terrain and texture generator, simple animation, and dynamic lighting. The engine uses DirectX 8.
Client / Server Network Model. Most older RTS games use a peer-to-peer network model. This model is simpler to implement and has the potential for better latency, but it has several drawbacks. Games are usually limited to about eight players because network traffic increases exponentially with each added player. Also games typically lag for everyone if one player has a bad connection to another. With the Client / Server setup, a player's game will only lag if his own connection to the server is slow. Additionally the Client / Server model permits the server to process a super set of the game state and send results down to the clients. This can lower the system requirements for client machines. The key feature of the Client / Server model is that it lets the game scale to a larger number of players.
Lockstep Sync Model. Lockstep refers to the way each computer stays in sync with each other. Computers cannot progress game time without the multiplayer game data associated with that time. With lockstep, you only need to send players' input over the network so there is no limitation to the number of dynamic objects in the game. Lockstep usually requires each computer to have the exact same game state through out the game. Each client usually must run the full game simulation or it will go out-of-sync. This can cause slower machines to have trouble keeping up with faster ones when the game has too many objects. We wanted Trash to support very large games which require a lot of CPU power. We designed a system where the client machines have a subset of the game state--only the server has all the game state. This was tricky to implement with Lockstep. Trash supports very large games and only the server needs to have a powerful processor.
Join in progress. We thought it would be cool to be able to join a game in progress. The more players a game has, the more likely that players will drop. We wanted to have the ability for players to join a game in progress or resume playing if they were involuntarily dropped. We wanted the process to be seamless without causing the game to stop. This feature is not easy to implement if using the lockstep model. As a client connects to a running game, the server streams all necessary game state. When the client enters the game, its game state is identical to all other clients in the game.
Minimal Off-Screen Processing. Trash uses an event system so dormant objects take no processing time. Objects off-screen follow very simple rules for minimal processing. Objects on-screen use substantially more CPU so that they are realistic and interesting
|
|