Months of tedious research into how best to realise this game are… - On this day in 2017
Jun. 15th, 2005
Months of tedious research into how best to realise this game are finally starting to pay off. Taking the decision to baseline on Java with JDK 1.5 seems to have helped as it narrows the range of applicable technologies considerably and I’m finally able to look at code.
There’s a dearth of good Java game engines, at least compared to those available in the C/C++, which is hardly surprising when you consider the traditional poor performance of the JVM. However the Hotspot technology employed in recent versions of the runtime has made a big difference and Java is now within 30% or so of the runtime performance of C++ for many real world problems. Add to that the excellent Java OpenGL and OpenAL bindings and writing a high-performance game engine for modern hardware with native acceleration shouldn’t be a problem.
A couple of interesting C/C++ 3D graphics engines have caught my eye as open to a Java port: Cube takes an interesting approach to engine design, and Sauerbraten extends it further. Both engines are fast under C++ and looking at the code I think there’s potential for using the same basic approach under Java with the aid of JOGL.
Graphics alone aren’t enough for 3D though, you also need a good physics engine. Whilst building one of these from scratch is superficially appealing (that could just be my having a physics degree I suppose) there are already a couple of pretty good freely-available options: Tokamak is one option for collision detection and rigid body dynamics which could be ported to Java, alternately there’s the Newton Physics Engine but due to being a closed-source library that would require use of a JNI wrapper which is something I’d prefer to avoid if possible.
The JVM is also a good host environment for a number of scripting languages, including perennial favourites like Python and Ruby. There are also some excellent implementations of Prolog and Production Systems so implementing both heuristic and predicate logic for game entities should be a lot simpler than might be the case with a C++ environment. I always intended to adopt a language-neutral approach to scripting support regardless of how the system would eventually be implemented so this is a very positive set of features.
One of the things I find surprising about current game design is the way that data is handled - storing it all in zip files seems a pretty clunky approach in an era of efficient relational database management. I’ve found a couple of interesting Pure Java database engines that have me very excited about the possibilities. One is Hibernate, a full-blown Object/Relational DBMS with SQL query caching and various optimisations that promise excellent performance. Another interesting system (though not one I intend to use) is MaVerick, a MultiValue DBMS with Linear Hashing and several third-party drivers.
I suppose networking is a must for modern games, whether for Death Match modes, or for some level of MORPG experience. Java does a pretty good job of providing networking out of the box, and there are some distributed agent ideas lying around in my old-projects files that would add a nice higher-level abstraction to the process. I’m also interested in the various Java P2P projects but will leave an investigation of them until later in the year - networking support can wait until the graphic side of the game engine is up and running.
Well that’s the technology glossed over, where next? Let me introduce you to The Identity Engine, a game engine designed specifically for 3D interactive fiction. I chose the name because a key gameplay ingredient needed for silicon_beach is the association of multiple (possibly unlimited) identities with a given game character, and that computer-controlled characters responses are dependent upon the identity of the character they’re interacting with. It is possible that the name will change in the future, but every project needs a name if it’s going to get anywhere.
Because development of the game engine is separate from the development of silicon_beach I’ve set up a separate wiki to discuss its requirements and document progress. A website will follow when I’m certain that the project is off to a solid start.
It’s my hope in the longer term to turn the ideas behind The Identity Engine into a marketable product, probably adopting a similar dual licensing model to other commercially successful open source projects.
xposted to silicon_beach