VectorStorm Blog

From a quick investigation of the current MMORPG Tycoon 2 codebase, I discovered:

• hilite : 189 instances
• hilight:  103 instances
• highlight (the correct spelling):  3 instances

One of which was this:  ”float m_hilightLength; // how long is my highlight?”

And to think that I thought I was a stickler for spelling in my codebases!  Fixing it now.  :)

I’ve spent a day working on VectorStorm engine improvements, today.  Those who aren’t interested in technical details should probably skip the rest of this post;  sorry, guys!

Here’s the list of improvements:

2D Display lists now correctly calculate their bounding boxes, even if there are transforms applied within the display list.  (previously, transforms within a display list were ignored for the purposes of calculating their visible size.  This probably wouldn’t have affected anyone;  it’s pretty unusual for a transform to be explicitly placed inside a display list that cares about its bounding box.

Bitmap font rendering now uses a vsBuffer to store each font glyph, so their data is stored on the GPU persistently, instead of needing to push explicit vertex positions and texture coordinates into the display list to draw text to the screen.  As a result, font rendering commands now only take up about a third as much system memory as they used to.  (My MMORPG Tycoon example was the string “Monster Type”, which dropped from requiring 1232 bytes of display list data to draw under the old system, to requiring only 352 bytes of display list data now that it’s using vsBuffers to store its vertex data.)

As a quick reminder, vsBuffer is my wrapper around OpenGL’s concept of VBOs (“Vertex Buffer Objects”), which are designed to store blobs of frequently-used data on the GPU.  The vsBuffer will also transparently fall-back to OpenGL’s older “array” functionality, for folks whose 3D cards or drivers don’t support VBOs.   Today, I have implemented interleaved VBOs within vsBuffer.

The old way of using vsBuffer was to give it an array of positions or colors or some other data type, and then put a command onto a display list telling the renderer what to do with the buffer.  (For example, you might tell it to use one buffer as a vertex position buffer, and another one as a normal buffer, and yet another as a texture coordinate buffer, each storing one type of data about each vertex to be drawn.)  That old code will all still work.  However, you can now use the explicit vertex formats exposed by the vsBuffer, such as “PNT”, for vertices which specify a position, a normal, and a texture coordinate.  The vsBuffer places all these bits of data together into a single OpenGL VBO, interleaved for fast access.  You bind these interleaved buffers by giving a “BindBuffer” command to the display list.  When finished, you can either give an “UnbindBuffer”, or “ClearAllArrays” command.

I’ve also converted the vsMesh utility class to automatically use its internal vsBuffers in interleaved mode, when it can.  So if you were already using the vsMesh or the vsMeshMaker (as I do in MMORPG Tycoon 2), you’ll automatically get this improvement.

With that said, I only see a moderate performance improvement on my laptop, but every little bit helps.  And I’m reliably informed that on embedded systems (such as mobile phones) that having interleaved VBOs gives substantially improved performance.  And someday I might want to look into things like that, I suppose.

Anyhow, as is often the case with these sorts of improvements, I’ve done this in my MMORPG Tycoon 2 development branch;  these changes haven’t yet been migrated back into the main publicly accessible VectorStorm trunk.  But I’ll get to that eventually.  :)

Further UI improvements, working on improving general usability.  I’m trying to expand on the existing features, making them more powerful and easier to use.  This has required a fair amount of “under the hood” work.  Right now, the UI is using both the old and new systems, with the old systems taking priority (that is, the new systems are only in operation when you’re not using the old systems).  Hopefully, over the next few days the old system will be phased out entirely.

Most notable new visible change is that you can now move any object around the MMO world just by clicking on and dragging it.  This includes buildings, PCs, NPCs, and monsters.  (Previously, you could only move buildings, and you had to activate a specific tool button to do it;  now it happens by default when you try to drag an object in the world).

This means that you can (for example) grab any PC and drop him into a field of monsters, or into the middle of a wide lake, or etc.  It also means that you’re no longer completely reliant on the your AI devs to place monsters for you;  you can now manually move monsters around to wherever you want, whenever you want.  If you don’t want to, though, the AI devs will still do it for you automatically.  (TODO:  devs don’t currently like it if you grab a monster out of their grip;  they’ll fight you for control of it.  Need to make the devs gracefully release a monster if you grab it from them)

So the thing I’m most excited about today is that I finally cracked the nut of how to get the developers up above the ground (and, for that matter, how to handle flight in general).  I was really annoyed to always have those developer cursors crawling along the ground, half-hidden under the ground!  Here you can see a group of developers that are in the process of placing some monsters (currently displayed as red boxes)

I’m also thrilled to have the mountainous region boundaries back.  I lost them for a bit after converting to the “paint-on” terrain interface, but I’ve got them back again now!  The player can use the brush tools to make the mountainous areas at the borders of each region wider, but cannot actually remove the mountain borders;  they’re permanent fixtures of the world.  Eventually, there’ll be a type of building you can place to make a small pass through the mountains, to allow subscribers to travel from one region to another.

But neither of those were really important fixes;  just little visual touches that I was glad to get in.  I also got a good start on some more game mechanics.

In the screenshot here, the big pillar in the background marks what I’m currently calling a “Grinding Zone” (suggestions for better names are welcome!)  Basically, you place one of these to tell your developers that you want there to be monsters to fight in that general area.  You will be able to (but cannot yet) specify how big the area is, what type of monsters should be there, what levels they should be, and how many you want.  Once you have “Grinding Zones” placed, subscribers will go to them when they want to fight monsters.  Alternately, you can use them as destinations for hunting quests, to force your poor subscribers to defeat twenty spiders and then return.

Starting on an interface for editing quests today.  As you can see, it’s still really early;  not very much there yet.

Also today, massive changes and bugfixes to lots of things under the hood.  Notably, fixes to rendering of text-edit-buttons, fixes to text entry (you can enter punctuation, now!  And more than 32 characters!), added functionality to the vsBox2D and vsFont, and a couple other minor bits and bobs that will eventually find their way back into the trunk VectorStorm library.

But the fun stuff is that I made it so that the action bars can be placed either vertically or horizontally;  I’m thinking about using them instead of the old-style build toolbars that you’ll remember from earlier screenshots and versions of MMORPG Tycoon.  In this screenshot, I’ve selected a quest giver, which has opened up a quest editing action bar on the left, where I can select any of his five current quests.  Right now, I’m looking at the one labelled “Q4″, which is a fetch quest.  So far, the player can edit the quest name and description, and add quests to the QuestGiver’s list (by clicking the little ‘+’ button).  All of these new functions are being performed via the (relatively) new scripting system;  each button in the actionbars just sends a text command into the scripting system, which takes whatever action is required.  This approach really is an awful lot nicer to to write and maintain than the “every button is a different class which holds its own game logic” approach which I was using in previous versions!

But I’ve derailed myself;  I was talking about quest editing.  Right now, the actual tasks which must be performed to complete each quest are still being procedurally generated, rather than actually being settable by the player.  But I’ll get to that tomorrow.  :)

Also on the radar: I’ve been thinking about getting rid of the “context matrix” in the top right corner of the screen, which shows actions you can take on a selected object.  It just uses up too much screen space, and I think it would work every bit as well (and without intruding into the screen nearly as much!) as a simple action bar.