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?
-
Concurrent thread handling - the Java
language has really nice, simple constructs for dealing with multithreading,
which can otherwise a very dirty, complex matter.
-
Internet communication - I hardly know
anything about the TCP/IP protocol, etc, and I'm not really that interested
in spending time learning the low level, gory details about it either.
I simply want to use the internet as a medium of communication, which is
possible using Java. RMI allows me to raise the abstraction level to that
of virtual method calls over the net. Very nice.
-
Object Orientation - A Mud is a typical
candidate for object oriented design and class hierarchies - C++ provides
the same possibilites, but is a terrible mess (in my personal, subjective
opinion, of course...). Java is clean, at least comparitively. Thus development
is much faster - mainly because the language takes care of all garbage
collection and memory pointer allocation automatically, which means less
details to worry about. Also, a lot of twisty syntax that C++ has inherited
from C has been cleaned out in Java.
-
Platform independence - what more can
I say :-)
Performance issues
Java programs are pretty sluggish in performance. Even though it will
speed up, it will probably always be slower than other more low-level languages.
I still chose to implement this in Java because of the powerful nature
of the language - it is simply the best OO language around right now. I
could have chosen another language, say C++, but then I would have to simplify
the design since C++ development is more complex and error-prone.
So I decided to implement it in Java. If this turns out to be too slow,
I will try to speed things up using JIT (just in time compiling) technology,
or maybe even full compiling (if it becomes possible). Or just use a fast
host :o)
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:
-
Use a database
-
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: