November 22, 2005
World War 2: The Game
Christian Decker wrote this late at night:

Also interesting posts:

For some weeks now, some Friends of mine and I are working on a next generation browser game. Why next generation? Well it’s completely Web 2.0 
Basically we have 4 Components:
- The AJAX Frontend, which will be the part the user spends his time on. Its Task is to visually display all the data to the user in a nice way. Currently we’re thinking about using the community edition of BackBase which looks really nice and is easy to use. And now a thing the AJAX-Community has been waiting for: we’ll use the Google Maps API as a the base framework for our maps. That means you move your troops on the real map. We’ll discuss the map later on.
- The Web-Server, which doesn’t do really much being relieved of the task of handling layout and such stuff it will serve the static pages that are used to bootstrap the game itself, and then it is used to generate the XML-Files containing the game data. We’re currently using Tomcat since it allows us to use the Java objects that are then used in the WorkHorse/Simulator directly (more or less as you’ll see later).
- The persister, which has the task of managing the whole lot of data that we generate and make sure we don’t loose anything. The persister is based upon Prevayler which allows us to keep a "cloud of object" without the need to save and reload to a flat structure like an SQL-Database everytime we do something, all the references are kept in place and no extra loading is done for queries, while for commands we have a slight overhead to create and serialize Transactions.
- And last but not least the WorkHorse/Simulator! This is the part where the magic happens
. The WorkHorse is a Program that accesses directly the data in the persister (in fact until we find a better way to communicate persister and workhorse are part of the same Process…) that accesses a Priority Queue containing Events. The Events have a scheduled execution time and are processed one after another. Events may be simple tasks light change the password of a user, or really complex stuff like simulation of whole battles, in which case a separate Thread is launched to do the actual execution of the Event.

We played around with different technologies for the communication, which is absolutely non-trivial. The Persister has to be accessible by both the WorkHorse and the Web-Server, we therefore had to split the whole in 3 parts which communicate with each other:
- The Web-Server mainly executes queries to the persister, asking for new information which is then passed to the AJAX-Frontend. All user interactions, such as sending a troup from one place to another, is then created as Transactions and passed back to the Persister for this a JMS-Server would be good enough.
- The WorkHorse has to access in an efficient way the data in the persister, this means we have to be able to access the Object structure directly without serializing stuff to be send over a Connection. We thought about using RMI but let the thought drop soon since it restricts the way we can interact with objects. For now we have put the persister and the WorkHorse together, but we are brainstorming to find a better solution.

- JavaScript Persisten Object Notation (JSPON)
- Persistence
- Why Ajax is conceptually better
- Site design using Prototype
- Ajax, CSS, DOM and JS-related resources