Technical overview

Implementation language

The White Orb project is being implemented in Java. The client is not, however, primarily intended to run as a Java applet. I will probably provide a few applet clients, but most people will want to use the application version. That way all graphics and other media-stuff can be stored locally.

Why Java?

Performance issues

The persistence problem

As it is now, White Orb does not use a database or any kind of persistance at all. Everything is in RAM, which means the whole world is lost whenever I have to stop the server. Needless to say, I have to solve the peristance problem some day... here are the alternatives I can see:
  1. Use a database
  2. Use object serialization
The main difference here is the (1) implies a constant persistence - ie all changes in the world are immediately reflected in the database. This feels awfully slow, considering that changes will happen VERY often. Another problem with this is that the design uses class hierarchies very intensively and, considering that object oriented database technology is a bit too young right now, I would have to use a relational database to reflect this. It would be very complex.

The second alternative means that the game is running in RAM and then once in a while I freeze time for a moment and save the whole world in a file using object serialization. I've done a few tests related to this and it seems quite OK so far.  My estimate is 10-15 minutes to save the whole world in a single file, even for a large world (and no "just in time" compiling or other optimization) - although I might turn out to be very wrong.

In the end I may have to compromize somehow. Perhaps use a database but only store the reasonably constant data there, or only do updates periodically. Or I might combine (1) and (2). We'll see. If you have any good ideas, send me an email...

Network communication

Right now network communication is done using Java RMI (remote method invocation). That means I don't have to worry about exactly how the sockets connecting the server and client are used. I can send objects as method parameters over the net, and not have to worry about how the object is serialized and deserialized at the other end, etc.

The good thing about this is that if I decide that the serialization is too ineffective, I can choose to implement it myself instead - without abandoning RMI. One reason to this might be that the default serialization is too "hard" - the objects become really small and compact but it takes too long to do it - for this project it is more important to quickly send things off. I think - but that's the kind of stuff I'll find out as the project progresses.

Remote administration and performance analysis

I will make (and have already made a few) client components for use in adminstration. My goal is that admins should log on to the server just as players do, but with a different client. The admin client will include performance analysis components (for example CPU usage and server RAM statistics) as well as information on which people have logged on when, etc.

This client will also allow the admin to "play god", ie look at the world and manipulate it.

Henrik Kniberg

Last updated: