VectorStorm Blog

One of the biggest nightmares for me in MMORPG Tycoon 1 and 1.1 was that of save game support.  In version 1, there was well over a megabyte of binary data that had to be saved and loaded successfully, to resume a game in progress.  In version 1.1, that size was growing drastically, as all sorts of new configurable settings and a new, much more complicated subscriber AI model were added.  But even worse than simply maintaining those save files, I needed to support loading in save games saved in earlier versions, and converting that data to a new format so that it could be used by the new game (as happened between versions 1.0.6 and 1.0.7, for example)

Those save files are going to be getting much, much larger again in version 2.0, and I imagine that the save file format will continue changing even after release, as I add further new features.  So I’m spending a little time investigating strategies which will hopefully ease the burden of managing those save files..  I was already using serialisation (which basically allows one to write a single piece of code which handles both saving and loading, instead of having to write two separate functions and manually keep the two in synch), but even that wasn’t helping enough.  Now I’m looking into moving to a property-based system, or possibly even to a full-blown reflection-type system, either of which would essentially be able to understand their own data well enough to write their own save/load routines automatically, at the expense of a slightly more complicated codebase, and perhaps some small amount of lost performance.

But I’m not sure.  I’m still thinking it over.  Designing and implementing something like a reflection system in C++ (which is not at all designed to support that type of language feature) can be rather brain-melting, I’m finding.  Especially since I’m so picky about what my code needs to look like.

I know I said I wasn’t going to write any code today, but..  what can I say, I’m weak.  :)

Today I started putting in the bare bones of procedural geometry generation.  In the bottom right of this screenshot, we’re looking at a starting area.  The game has requested a simple block of a rough shape and size, and the procedural geometry systems have filled in that space with actual renderable geometry.  It’s extremely simple in this case, but I didn’t have a lot of coding time today.  I’m just pleased that it’s coming together so easily!

There are a couple bugs to sort out;  in particular, there’s a bug with the generation of surface normals, which can lead to some really weird lighting, where you get hard creases in the surface where they should be smooth.  (This is visible where the cursor is pointing;  that edge should be soft, but instead there’s a hard border between light and shadow on the roof of the structure).  I’m not feeling up to figuring that bug out tonight;  I’ll leave it for tomorrow or the next day.

Also, right now, every starting area is generated at exactly this size and looking exactly like this.  I’ll need to add some variability into the system to keep things fresh, while still keeping enough constant elements so that the buildings remain recognisable to a casual glance.

Another boring screenshot today.  Ordinarily I would have made a video and posted it, but I have a big day tomorrow and am going to be getting to sleep early tonight.  Maybe I’ll do it tomorrow.

Today I implemented the Action Bar that I mentioned on Wednesday last week. The action bar has eight spaces for your primary commands, and up to six tabs along its top, which are used for secondary functions.  For example, in the shot above, the “Build” button opens the building toolbox, and the “Debark” tab causes you to stop piloting the Graveship.  (The Graveship hovers exactly where it is, and you can then walk around on top of it or jump off  or whatever).  There are two different action bars at the moment;  one for when you’re on foot, the other for when you’re piloting the Graveship.  The on-foot one has a Graveship call button, and other functions.  On the Graveship action bar, most of the primary slots will be taken up by various types of building;  ”Build” will become “Cities”, and the other buttons will provide individual buildings, roads, walls, landscaping, NPCs, etc.

The Action Bar, like the Context Matrix, is using the new “text-based commands” system, which makes it much faster and easier to create GUI interfaces to perform functions;   writing GUI code should now be much less of a slog!  Note that while the Action Bar and the Context Matrix are both using text-based commands, they’re not (yet) actually using the same system;  eventually, I’ll need to merge the two together into a single unified system which can handle everything.  But for now, I’m quite happy with the improvement over the old way I was creating GUI elements.

I also greatly improved the Graveship flight, just by adding a little polish to it.  It doesn’t actually fly any differently, but it feels different and better by having added a little visual lag to various elements.  You’ll see what I mean in the video that I’ll eventually do, when I have more time.

And on a technical note..  In the core VectorStorm library, I renamed the quaternion spherical linear interpolation routine from “Slerp()” to “vsQuaternionSlerp()”, to obey the standard VectorStorm naming practices.  A little embarrassed that I hadn’t noticed that before, but I hadn’t actually used it until now.

As I mentioned above, tomorrow’s a big day for me, so I’m unlikely to get anything new done.  But the next tasks on my plate are (in no particular order):

• Hook up time control and server online/offline control to be accessible again.
• Hook up design/business screens to be accessible again.
• Hook up a way to make region settings, so you can set level ranges again (right now, all monsters everywhere in the world are level 0).  Wherever this is done, the user should also be able to adjust sky, fog, and ground colours, and the type of ground surface detail.
• Landscape-modifying placements.
• New, non-Perlin-driven landscape generation (this might use the landscape-modifying placements).
• Take the next step in the procedural generation of building/city models;  ”block” subdivision.

This is a boring screenshot;  this really ought to have a video, instead, but there’s still a little more interface work that’s going to be required before I can really fill out a video.  The screenshot here is from my first GraveShip flight.

Right now, the GraveShip handles much like a FPS “noclip” camera (except that it has mass and inertia, and can’t pass through the world);  hold the right mouse button to look around, and use the WASD keys to move.  You can also use space and alt/option for up and down.  Eventually, I’ll provide other control methods, but I’ve become fond of this one, so I’m pretty sure it’ll end up being usable in the final game, even if I also provide simpler ones which will maintain a constant altitude.

To fly the GraveShip, first you click the “Call Graveship” button, which brings a graveship to your location.  You then select the graveship, and click “Pilot” from its context actions.  That automatically moves you onto the graveship, and transfers your control over to the graveship.  Right now, you stand on top of the graveship while piloting it;  that black bar at the bottom of the screenshot is the front edge of the graveship’s top surface.  I don’t really like using so much of the screen like this, so I’ve been thinking about fading the graveship out when you board it, or something of that sort.

Incidentally, just as a minor matter of polish..  if you’re in a region where there’s a graveyard, then summoning the graveship uses that graveyard as a spawn point;  the graveship rises up out of the graveyard, and then zips over to join you.  Similarly, when you dismiss the graveship, it zooms to the graveyard, and then gently lowers itself down into the ground.  If there is no graveyard available, then the graveship drops down from far overhead, and will lift back up into the sky when dismissed.

Right now, there’s no way to get back off of the GraveShip;  the GraveShip is going to need its own UI interface, with “disembark” (or something similar) being one of the options, to get the player back down onto the ground.  At least in the short term, I’ll probably just change the buttons in the button bar at the bottom of the screen to ones which are more appropriate while on board the GraveShip.  (For example, the “Build” button won’t be present when you’re on foot;  building placement is much easier from the GraveShip’s higher vantage point!)

I always felt bad that there was no way to wield the infamous Banhammer in my MMORPG Tycoon games.  Well, no more;  MMORPG Tycoon 2 will be the first one to proudly support people’s desires to wantonly ban subscribers with or without cause.  (It will also be the first to allow you to buff or nerf classes, but I’m not quite ready to talk about how that’ll work, yet… though those who tested version 1.1 might well be able to guess.)

Today I got the context matrix system set up and working, although only a few of the context actions have actually been implemented so far.  I’m actually quite pleased with how it’s working out;  I’m glad to finally get the “Remove building” and “Move building” options out of the Building toolbox;  they really didn’t ever belong in there.

Also today, I finally fixed the crash bug which would occur if you removed a building which hadn’t yet been activated, or if you still had a building selected at the time when a developer came by to demolish an activated building.  That bug’s been in the game for about four or five weeks, now; finally got annoyed enough to track it down and fix it today.  The only other annoying frequent crash still remaining (that I’m aware of) is if you bring the MMORPG online when there are no starting areas placed.

Also also today, inside the VectorStorm library, I’ve modified the vsHashTable class to not crash on construction if you tried to make a hash table of strings.  I also created a “vsHashTableStore” class, which is exactly like the vsHashTable, except that it stores pointers to objects, and will delete those objects when the hash table is destroyed.

Tomorrow, graveship control.  Honest and for reals this time!  :)