VectorStorm Blog

Warning:  long, meandering musing about some basic UI design follows.  Feel free to ignore this;  I’m just trying to work some things out in my head.

When designing a user interface, one of the critical choices that must be made is how the user is going to give commands to the program.  Traditionally, there are two different ways to do this.  You can either specify the verb first and then the object, or you can specify the object and then the verb.

Let’s use a simple calculator as an example.  Your calculator has an current value, and you first specify an operation (the “verb”), and then a number (the “object” that the verb will operate on), and this results in a new current value on the calculator, and you can repeat.  So if the current value is 20, and you wish to add 2, you press ‘+’, and then press ’2′, and then press ‘=’ or ‘enter’, or whatever other button tells the calculator that you’re finished pushing buttons, and the calculator’s current value becomes 22.

But there’s a second style of calculator which works the other way around, often referred to as reverse polish notation.  On one of these calculators, you still have a current value as your starting point, but when performing an operation you specify the object before the verb.  So if the current value is 20, and you wish to add 2, you press ’2′, and then press ‘+’, and the calculator’s current value becomes 22.  It’s the same operation, but expressed differently.

Which is better?  Well, you could argue that the reverse polish notation version is more efficient;  you have to push fewer buttons to perform a calculation, as the “verb” button also serves as the “I’m finished typing in the object” button.  On the other hand, you’d have trouble finding a calculator like this these days, because it’s not the way that most people think about doing math, so it’s kind of inconvenient.

In most Tycoon games, the User Interface is set up to be verb-object, like common modern calculators.  And certainly that’s how it worked in MMORPG Tycoon 1.  You have a toolbox with a bunch of tools in it;  you first click on the tool you wish to use (the “verb”), and then click on what you want the tool to operate on (the “object”).  This is how you build and remove buildings, create roads, etc.  The plus side of this approach is that it makes all the verbs visible right from the start;  there are no “hidden features” that users might accidentally overlook.  The down side is that in a UI with a lot of features, it can be overwhelming to provide the user with all these options all at once, and it can easily appear quite cluttered.

In most other types of game, the User Interface is set up to be object-verb.  For example, in World of Warcraft, you must first select the enemy you wish to attack (object) before the attack that you wish to use (verb).  In The Sims, you must select a sim before you can choose what action that sim should take.  Often, the available verbs don’t even appear on screen until you’ve selected an object, so that the game can only display the applicable verbs.  (That is, The Sims will present “Call a friend” as an option when you click on a phone, but not when you click on a fish.  If its input model had gone verb-object instead of object-verb, you would have had to choose “Call a friend” before clicking on the phone, and the game would have had to provide error messages if the user had tried to use the “Call a friend” verb and then clicked on a fish.  Whereas by only providing the legal verbs for the object clicked on, lots of that type of error simply can’t occur)

RTS games are particularly interesting, as their base-building orders are typically verb-object (“pick the building type to construct”, then “click where you want it to be built”), whereas their unit orders is typically object-verb (“click the unit, then click a button to tell it what to do”).

Word processors, image editors, and most other applications are all object-verb as well;  make a selection, then choose a verb to operate on that selection.  (Select some text, make it italic.  Put the cursor somewhere, then type some text to add it there.  Etc.)

At the moment, I’m wrestling a bit with the interface on MMORPG Tycoon 2.  There are certain functions which feel to me like they ought to be expressed as object-verb (for example, removing buildings), and the UI would become much less cluttered and imposing if I could somehow wedge more functionality into context-sensitive menus using that type of approach, instead of having everything be expressed as verb-object, the way it is right now.

Still thinking about it.

So that problem I mentioned yesterday — having roads end up being selected as though they were in front of objects which they were actually behind — eventually turned out to be a nasty little leak of temporary collision result data which was being generated as part of an optimisation.

Basically, when I’m trying to figure out what you’re pointing your cursor at, here’s what I do:  I create an imaginary line which starts at the camera, and travels out in a direction through the world which is determined by the 2D position of your cursor within the game window.  I then test that line against all the polygons in the terrain, all the polygons in the roads, all the polygons in the buildings, all the polygons in the toons, etc.  For each polygon that the line hits, I keep track of where it hit, and how far from the camera the polygon was.  Whichever polygon got hit closest to the camera, that’s the one that I consider you to be pointing at.

Now, doing this sort of test-every-polygon collision test takes a lot of CPU power, and so I’ve made a lot of optimisations to avoid testing polygons which I don’t absolutely need to test.  One of these optimisations (which is being used on everything but the terrain) is to create an invisible “bounding box” around each object in the world, and before testing any of the polygons in those objects, I test whether the line hits the bounding box at all, and if not, then I know that I don’t have to test any of the polygons inside the box;  the line didn’t hit the box, so it couldn’t possibly hit any of the polygons inside the box.

The bug that I fixed today was that anything which used this “bounding box” optimisation (which is almost everything) wasn’t calculating “point where I hit the polygon” and “distance from that point to the camera” as they were supposed to;  they were calculating “point where I hit the polygon” and “distance from where I hit the bounding box to the camera”.  Most of the current placeholder graphics in the game are cubes which exactly match their bounding boxes, and so this bug wasn’t noticeable on them;  the only exceptions were the roads, which undulate and have bounding boxes which are much larger than the roads themselves, often entirely surrounding the objects which travel on the roads.  Since the collision system was accidentally using the distance-to-bounding-box instead of distance-to-polygon, the roads were taking priority over those objects which looked like they were closer, but were actually encompassed within the roads’ bounding box.

This bug would have affected buildings and all sorts of other things as well, once full procedural building generation is implemented.  But it’s fixed now.

Also, my head hurts.  Too much debugging of collision code will do that.

So as I was implementing the mechanics of selecting objects and getting information about them, I was reminded about just how hilariously awful my character name generation code from MMORPG Tycoon 1 was.  Generating such unpronounceable character names as “Iqkeb”, “Adqiy”, and “Ojkage”, it really is going to need a big overhaul for MMORPG Tycoon 2.

Subscriber names, on the other hand, are mostly okay, if sometimes a little bit old-fashioned and US-centric, as they’re being generated via statistical data from a 1908 US census.  I probably won’t have to modify those immediately (but in a later version of MMORPG Tycoon, it might be nice to start thinking about the home countries of subscribers, and generate appropriate names and play schedules based upon that).

New today:  I’ve modified toons, monsters, buildings, roads, and the graveship to all derive from a common base class, which handles the mechanics of being selected by the cursor, and implements the selection mechanics.  Now when you click on something, information about that object appears in a box in the top middle of the screen.  Still to do is adding a button which will bring up a detailed information/settings window to show further information.  This has also brought to my attention that there’s something going slightly wrong about selecting roads;  roads seem to be acting as though they’re closer to the camera than they should be, and so it can be very difficult to select a player who’s moving along the road, rather than selecting the road itself.  I’m kind of dreading jumping into that collision code and trying to debug what’s going wrong..  but that’s what I’m going to have to do.  I’ll look at it tomorrow.

Also today, I drastically improved the look of the region boundaries.  You might recall the region boundaries from earlier screenshots;  they were huge sharp plateaus, and often had giant artifacty diagonal shadows running in patterns along their sides.  These new region boundaries are much softer and the lighting on them is heaps better.  I’m still expecting to modify them to look more like mountain ranges, but at least I’m not embarrassed to include them in screenshots any more!

So my web server apparently decided to die in a rather spectacular way about two hours ago;  I only just realised it now, as I came to post this update.  Apologies to those who may not have been able to connect during that time!  I’ll be watching closely to make sure it remains okay.

On the topic of offline, the screenshot here is a composite of an offline and an online view of an MMORPG, in my current development codebase.  The new things in this screenshot are the fog (mentioned yesterday), and the new offline terrain rendering, which is slowly moving in a more blocky, almost Darwinia-inspired direction.  I’m not sure whether I’ll really use that look;  it’s difficult to tune the appearance of your game when it looks different when offline than when online, so maybe I oughtn’t.  More thought will be required.

There’s also the in-progress top-left information box.  Right now it’s still using a lot of old UI tech, but I’ve got a number of key indicators on it and functional, now.  Though obviously, it needs to be prettied up an awful lot.  And right now, it’s crowding the left toolbar.  But that’s okay;  that left toolbar is going to be moving to the bottom of the screen, shortly, so it won’t look so cluttered up there for much longer.

I also fixed a pretty major performance problem in the VectorStorm engine, today.  While flying around in “noclip” mode, I noticed that despite my having code in place to keep the game from trying to draw terrain that’s under water, it seemed to be doing so in many places.  In fact, as I flew around the world, more and more often I’d find large blocks of sea floor being drawn.  It took me an hour or two, but I eventually tracked down the culprit;  VectorStorm’s OpenGL code had a minor bug in it which caused it to submit more data to the video card than was requested by the game.  The biggest place where this was causing problems was in the streaming of terrain data, where I re-used several buffers which could drastically change size from one piece of terrain to another.  Net result from fixing this bug is that on my (rather fast) computer, my average FPS rose from about 100fps to about 160fps.  I haven’t yet tested it on my slower test computers where the game was struggling to hold 60fps, but the way I see it, telling the GPU to draw fewer illegal triangles can only help performance!

Today, I actually got very little work done;  was doing the rounds and looking at various new MMORPGs.  Took a peek at Champions Online and the new free-to-play DnD Online, neither of which really thrilled me.  Each had some interesting minor variations on the standard MMORPG formula, but neither seemed to do anything that was genre-redefining.

The one thing that I did get implemented code-wise today was implementing fog properly inside the core VectorStorm engine.  That is, game code can now specify what type of fog to use, what colour it should be, and how thick it should be;  previously, it was hard-coded inside VectorStorm that everything which was marked as being affected by lights would also be affected by a greyish fog.  This change has made it so I can now have a thin black fog while the MMORPG is offline, and fade that black fog into the thicker, greyer fog as the game servers are brought online and the colourful sky is moved into place.  The grey fog always looked really weird against that flat black offline sky, I felt.  It’s much better now.

This fog support will be migrated back into the public “VectorStorm” source code repository not too far in the future, at the same time as the rest of the big MMORPG Tycoon 2-driven engine changes get merged back into the public trunk.