We are still currently at the development phase of the project. The team is made up of 3 volunteers: 2 programmers and 1 game artist.

I am responsible for both the server side architecture and the client-server messaging protocols. Lemuel is in charge of the client side engine. And Jeryl is responsible for the art assets. It would be great if we have another programmer take care of the messaging protocols so I can focus on the server.

As you can see from the game design, the uniqueness of the game calls for 3 technically challenging features. First, it has to be multiplayer, which means it has to be built on a server-client framework. Second, it has to simulate a growing organic being. Third, the game must have no “beginning” and “end”.

Standalone games are usually executed on a game loop (movePlayer->moveEnemies->checkAgainstGameRules->renderGraphics-> repeat until game ends). But in the case of a multiplayer game, the game loop is partly in the server and partly in the client. The server stores the game state and broadcasts it to the clients for rendering, while the clients get user inputs and sends it to the server to update the game state. In a turn based multiplayer game this change in structure wouldn’t really matter much, since the players are contained in a simple little queue and at any given time only one client is accessing the game state. This changes drastically on an arcade style multiplayer, since the game runs on real time and at one point multiple clients might be trying to access a single resource. This would eventually lead to deadlocks, memory leaks, and all kinds of nasty behavior. To resolve this issue, we implemented Sun Microsystem’s Project Darkstar Server. (Though still on its beta phase, this framework worked like a charm).

Traditional multiplayer game designs limit the amount of data transfers between client and server. Send packets too much too soon and you’ll clog the network. This leads the team to its current roadblock. The entire game state (plants, enemies, players and all) must be stored in the server. Everything, including the movement calculations, plant growth, collision detection, spell cool-downs, etc. must be calculated in the server. Why not put some of them in the client? Because the game has neither a definite beginning nor end. The game exists even without a client. Once a client enters the world the server has to send him the entire game state.

Putting all the stress in the server would be impractical. We are currently trying to resolve this issue by using timestamps. By storing a timestamp value corresponding to the time a game object was last updated, hopefully, any fresh client can calculate the game state based on the time elapsed without having the need to physically store the game objects. That way we are transferring the computational burden to the clients.

We are using Project Darkstar for server side and jGame for the client (the latter is actually pretty old/dead, but it’s easier for non-game programmers to understand than “real” java game frameworks like jMonkeyEngine).

With the deadline creeping in, the team would be more than happy if we can at least make the game playable. I for one, still think it’s the kewlest game ever.