So clearly, I don’t post very often. Not much to write about really. However, I think I may have found a solution to that problem. Unfortunately for anyone reading, my solution is to use this as a place to write about what’s going on with the computer game I’m writing– Multiverse3D.
For anyone who doesn’t know, I should give a brief history. MV3D is a 3D MMORPG (Massively Multiplayer Online Roleplaying Game) that I’ve been writing on and off since 1997 or so. It was originally based on a text only MUD (multi user dungeon) game that I wrote/ran in the mid 90’s. The concept was to have a game engine that was capable of simulating worlds of all types and not something that was just stuck in one genre (i.e fantasy/sci-fi/etc). The worlds could be linked together so that you could have fun interactions between them. At the height, I managed a volunteer team of about 10 people– artists, programmers, designers, etc.
There were a lot of issues with the previous iteration of the game. One of the bigger ones was that you can’t really rely on free help. Granted, there were some people who I could most certainly rely on, the majority of people who joined the project ended up sucking up a lot of my time in training them before they went inactive or left. Most of the technical problems involved times when as the ‘head honcho’, I looked a daunting problem in the eye and said ‘let’s figure that out later’. Other ones were just from lack of experience. Creating a MMORPG is a lot different than creating a regular computer game. On the whole, I would have to say there was no way that the 110,000+ lines of code that make up that effort could go anywhere useful.
The state of affairs last time I worked on that code was that you could run a server, create a basic scene (say, a small landscape and a few objects), connect to it with a single client, walk around (though you would pass through walls), and that’s it. Even with just one client connected, it was horrendously slow. Lag times with the server running on the local machine were close to one second. Now that sounds like very little for 110K lines of code to be doing– especially if you consider that none of the physics (ODE) or graphics (Crystal Space) were handled by the 110KLoC. There was a lot of stuff going on in the background such as instance management, asset management (including autodownloading content during gameplay), and so on. The client and server would crash very frequently– a milestone goal was set to get the server to run for more than a day without crashing.
It wasn’t all bad though. There were some good parts, and I (and hopefully the rest of the team) all learned a lot in the process. Here’s a short list of what I think are the good aspects:
Resource tracking system. Resources (or assets) are what I call the media of the game. Things like images, 3d models, animations, and sounds are all resources. Resource tracking is complicated in MV3D because of the ability to a) update resources while the game is running, and b) download resources to the client also while the game is running. The resource system had to be robust, scalable, and easy to use. I don’t know that the MV3D system met all those needs, but it was pretty good. Resource groups held information on where to get the resources (lists of URLs) as well as the creator and other info. Resources were all a part of a single resource group and contained a unique id within the group as well as a revision number. They also contained information about low and hi detail versions of themselves.
Modular models concept. This was a concept I thought up when reading an article on how level designers could save time creating levels by breaking them down into small building blocks. Even if you have the most stable and scalable networking, simulation, and the best graphics in your MMORPG, it’s really not worth anything without gobs and gobs of content (things for players to do/go/kill/etc). The modular models concept would have allowed us to easily create non repetitive content to the point that everyone in the game could, for instance, have their own unique sword. Building a town would be as easy as setting the parameters, creating it, and then modifying it until it was what you wanted. Most of this didn’t get coded in MV3D, but it was used in a later project that I’ll get into in a minute.
Profiling infrastructure. This was pretty cool actually. I could get stats on how specific functions performed (how many times they were called, and how long they took) It was fast enough that I left it on all the time, too.
Division of worlds. Worlds were divided into regions which held a bunch of areas. Areas held objects.
There must be more, but I can’t think of it now.
The specific technical issues with MV3D were:
Extreme bugginess. The whole thing was just amazingly crashy.
Network Slowness. As mentioned before, the networking code may have been kind of nifty, but it was incredibly slow. There was no fixing it either.
Multiple Clients didn’t work. You’d think that an important factor in a MMORPG would be the MMO part, right? Well, I think I once got 2 clients connected to a server. Other than having a 5 second lag, moving the player attached to one client would sometimes move the other player. Not a good feature.
Non intuitive code. 110KLoC is pretty daunting, but if there is documentation and comments, it isn’t that bad. After all, I have no problem navagating the 400KLoC that makes up Crystal Space.
Bad use of scripting language. Python was used for scripting. It did mostly control the UI IIRC, but had pretty much nothing to do with anything else. You could attach scripts (as strings YUCK!) to objects, but that doesn’t really go too far.
Networking limitations. You could only run one server and one client on a given machine. That sucks for testing purposes, and your framerate dropped in half when running the server because 50% cpu went to the server.
Bad concepts of accounts. Player accounts were never integrated properly. Another important feature. 
An account should be what has the users password and list of PCs as well as their billing info. (maybe) Not so much.
Late integration of physics. Initially, I wrote my own physics engine. It was ok and could do basic collisions that were about 20% accurate. Then I migrated to ODE. Too little too late. It never worked very well– and through no fault of ODE’s.
Not very open ended. In the original design document of MV3D, you were supposed to be able get realistic results from doing obvious things. Pour some water over sand and you get mud. That sort of thing. Unfortunately, the design was way too rigid for that to ever be an option.
No advanced/enterprise class server features. Clearly, simulating multiple worlds on one server isn’t an option. The specs called for several types of servers that would be used and would talk with each other and load balance. None of this was ever coded or even thought about in any significant manner.
Spent way too much time on fun things. I spent way too much time on things I thought would be fun– graphics, AI, UI. All of those are nothing without a solid server back end.
In order to prove our game creating skillz, we decided last year to halt development on MV3D and go for something simpler. This is where Siegium came in. Siegium was meant to be a simple game that we could finish and release to prove that we had what it took to create a game. Well, it didn’t go so badly, and other than a severe lack of any real ‘missions’, it is currently a fun and moderately stable game. Though sadly, it was never completed. I’ll be releasing the source code on SourceForge sometime soon. All it needs is a bit more AI, some more models, units, and a whole bunch of missions.
Siegium was, from my point of view, a testbed for new concepts to be used in MV3D. I probably took this a little too far, and that’s most likely the reason it was never finished.
Siegium was meant to be mostly Python code. C++ code would pretty much serve as an interface between Crystal Space and the Python code. That worked amazingly well. In fact, in hind site, I didn’t push that direcive far enough. The C++ code kept a list of all the objects– I wouldn’t do that in the future. I tried out Twisted Matrix for networking and ended up writing the whole networking part of the game (which wasn’t supposed to even be included in V1) in about a week. Here’s a list of pros for Siegium:
Very easily mod-able. From the beginning, it was easy to add new Units and Scenarios. This was part of the plan, and it was executed fairly well.
Script driven. Python was pretty much in control of everything. I had thought with MV3D that running python code every frame on a client would slow it down. Not really that much.
Easy Development. Because of using python so much, development could happen at an amazing pace. I very rarely needed to recompile the C++ code after the first couple of weeks of working on it. This meant making changes and quickly seeing the results.
Awesome Physics. ODE kicks butt. Once physics was integrated into the game, it became fun. Granted, this took productivity down a bit because I’d sit there and knock down a castle wall instead of continuing to work on whatever I was working on. You know you are on to something though when the game is that fun.
Good networking. Twisted worked great. There were some odd bugs in the networking side of things, but they were in my code. (objects wouldn’t always get the right velocities on the remote client)
Modular Models. Just before I stopped working on Siegium, I more or less finished an implimentation of MV3D’s modular models concept. It was pretty cool. I could tell it I wanted a wall that was 50 feet wide and 20 feet high and I would have one. The implimentation was a lot different than what was planned in MV3D though. A factory (something that generates a modular model instance) was a Python module.
Python persistance. Persistance = saving game state to disk/database/etc. Using Python and Pickle made it simple. Pickle works similarly to Furk in the original MV3D, so picking it up was pretty easy.
3D A* Pathing. It was dog slow (because it was in unoptimized Python), but Siegium has very nice 3D pathfinding.
Steering. When you commit to using a physics engine for everything, you give your self some interesting problems. You can’t just tell an object to move forward at such and such a speed and expect it to do what you want. More likely, it’ll start to roll, or it won’t go anywhere because of friction. Siegium had a lot of steering code that could get an object to move from point a to point b, to track another object, follow another object, etc. Good stuff. It was cool to have a wheeled catapult behave as if it was on 4 wheels instead of just sliding around.
Siegium wasn’t perfect. There were some things that did go wrong:
Never finished. Kind of obvious, I know.
Should be even more control by Python.
Pathfinding was very slow. It really needed to be coded in C++.
Menuing system was annoying to make and modify menus for. Most likely the fault of AWS. I had to use a calculator and figure out what percent of the width of the screen I wanted to put the buttons at.
Now recently, I’ve started thinking more and more about MV3D. This was a bad thing for Siegium because it meant I spent more time playing with MV3D things in it than developing it. So now I feel I’m ready to start working on MV3D. More on that in the next post.