VectorStorm Blog

More UI mockup happening.  Here’s kind of what I’ve been thinking;  please feel free to comment!

• Persistant bottom toolbar.  This bottom toolbar will have about eight buttons in it, which will be square-ish (more square than the ones you see here), most of which will open other windows (such as the ‘Build’ button seen here, which currently opens the old Build toolbar from MMORPG Tycoon 1.1).  The Online/Offline control will be moved to a separate screen.  Not quite sure what to do with the time controls yet, but they don’t belong on the main button bar.  The items on this button bar will all have keyboard shortcuts (probably simply numbered from 1-8).  Goal is to have this button bar visually remind people of the bottom button bar in most MMORPGs.
• Persistant top left info bar.  This top left information bar shows you information about your current MMORPG.  Not sure exactly what information needs to constantly be displayed, but there’s space for about four or five tidbits of information.
• In the top right is a similar info bar about whatever your current selection is, and (if appropriate), a “Context Button Matrix”, which gives functionality specific to that object.  For example, on a building, you’ll have “Upgrade” and “Downgrade” buttons, and also “Remove”, and possibly “Move”.  And possibly more functions, as required.  One button (probably in the bottom right position) will always be present in this matrix;  that’s the “More information” button, which will open a pane that shows even more exhaustive data and configurable settings about whatever you have selected.  This second info bar and the context button matrix vanish, when the player has no selection.

Other stuff..  in this screenshot, you can sort of make out the brightly-outlined view of the distant land masses, out at the horizon.  The dark blue areas are seas which are far enough out that they aren’t being drawn by the regular rendering.  That’s the same stuff you saw in the last screenshot, just viewed from down near ground level.  That’s all temporary, and won’t be visible in the final game from this perspective, but I thought I’d mention what that is in case you guys were curious.  :)

Other stuff.  I’ve been having a bunch of trouble making the detailed generated terrain match up nicely with the large-scale region map (seen in the previous screenshot);  those huge black areas look like they should be land when viewed from up high, but precisely where the shoreline begins is very unpredictable, and many of those black areas are currently generating as almost entirely underwater;  the shore appears just before the next region in from the sea.  (In fact, this screenshot is taken from inside one of those black shoreline “landmass” areas, and you can see just how little land is actually generating above sea level!)  Since the current Perlin-noise-based terrain generation system is proving so uncontrollable, I’m reconsidering how to generate region terrain, and have come up with a few ideas that ought to give some nice and more predictable results;  I’ll start prototyping those later this week.

Lately I’ve been thinking a lot about adding a text interface, so that most game commands are actually implemented via text commands.  This would simplify a lot of my UI code, as I could then have just one or two types of button, which would simply send a text command when clicked, whereas right now I have dozens of different (but mostly similar) types of button in the codebase.  Users would also get a benefit from this; it would allow power-users to type text commands into a console rather than search out a button in the UI, and it would make it possible to implement MMORPG-style keybinding and macros, sometime down the line.  I’m not sure whether I’ll actually go this direction;  it’d be a lot of work to modify the existing UI to work via this type of system.  But I’m going to use this type of system for the “Context Button Matrix” pictured in today’s screenshot, and if that works out brilliantly, I might consider revamping the rest of the UI system to use it as well.

Finally, I’ve fixed a bunch of region issues.  Fixed a lot of cases where particular spots in one region were mistakenly being considered part of a different region, fixed a float imprecision bug which would occasionally determine that a particular spot that was right on a region border wasn’t part of any region, and set things up so that region borders don’t appear bordering sea regions.. so that we can have nice beaches.  That is, once beaches are generating in the right places.  Oh, and I fixed a maths mistake which caused there to be strips of land a little over 200 meters wide bordering the north and east edges, just beyond the northernmost and easternmost regions in the region map.

Oh.  And in the VectorStorm library, big performance optimisations to creating VBOs (via vsBuffer, when using the ‘set values in the built-in array, then baking them into a VBO’ method, as almost everything does), and a small performance optimisation to calculating Perlin noise., by eliminating some double-precision maths.

Tomorrow, I should have the context button matrix functioning properly, and will get rid of the “Remove Building” and “Move Building” buttons from the “Build” pane.  And then I’ll start filling out the button bar.  And maybe I’ll finally get around to writing that Graveship movement control I’ve been distracted from for so long.  So much still to do!  :)

Here’s a slightly updated version of the hacky “full MMORPG view” map, where I’ve begun setting many regions as “ocean” regions.  In this case, I’ve told the MMORPG region generation routine that I want two main continents, much like WoW has.  It’s pretty trivial to adjust this to have one huge landmass, or lots of tiny ones, or anything in between.  I think that having the water there really does help a lot.

This still has about twice as many regions as the basic initial WoW release did (WoW has more regions than almost any other MMORPG out there, which is why I keep using it as a benchmark for playable game area), but it’s a lot less intimidating like this than it was in the previous screenshot I took.  And it’ll be easy enough to remove more regions if it really becomes a problem.

I’ve mentioned before (and some may have guessed purely from the infrequent postings on my only-half-joking game review site) that I’m a nut for highly polished games;  games which show a strong attention to the craft of making games, with love and attention lavished upon even their most inconsequential nooks.

So yesterday, I took advantage of TellTale’s “Play Like a Pirate” offer, and downloaded the first episode of their  Tales of Monkey Island episodic adventure, “The Launch of the Screaming Narwhal”, and spent some time playing it under Crossover, on my Mac (it plays beautifully, except for the launcher, which is mildly broken.  But TellTale’s launchers have always been mildly broken for me, even when running under Windows, so I can’t really blame Crossover for that).

Anyhow, I just had to mention that the first time I paused the game and saw the seamless transition to and from the pause screen, I almost fell out of my chair, and had to go preorder the rest of the season right that very moment.  This is a game which has had some serious care and attention in its construction, only marred by a single awkward transition between the end-of-prologue cutscene and the start-of-main-game cutscene.

The transition between these two cutscenes was clearly intended to be beautiful and completely seamless, but has a several-second-long black load screen smack in between the two, which totally breaks the flow of the narrative.  And this is the only rough spot in Screaming Narwhal‘s presentation;  otherwise, it positively sparkles.

All of TellTale’s games seem to have some sort of “unpack on demand” feature, where the first time you enter any area after downloading the game, it takes much, much longer to load that area than any later time that you enter that area, even when starting a new games.  It’s possible that this “unpack on demand” functionality may be responsible for that bizarre black load screen in between the two cutscenes which were clearly supposed to blend into each other seamlessly.  Maybe (I haven’t checked this) that load screen wouldn’t be there, if I was to play the game again, now that the first “slow” load has already been done.  TellTale guys, if you read this, I would happily accept an extra “unpacking” process during the game install, if it had given me that seamless cutscene transition!  :)

In terms of the game itself, it’s pretty much standard TellTale episodic adventure game fare;  if you liked the Sam & Max games, you’ll like this.  If you didn’t like them, this won’t change your mind.  To me, Screaming Narwhal felt shorter than most of the Sam & Max episodes, and it had a couple of (in my opinion) unfair puzzles.  As an example, at one point you’re following a map from a landmark to an unknown destination.  However, in order to actually wind up at the right destination, you must first “use” the map on the landmark, and then follow the directions on the map.  If you merely go to the landmark and then follow the directions on the map, you will not end up in the right place.  And if you’re like me, you’ll likely not even realise that there was a different place you should have ended up, or realise that you’ve done anything wrong, and just assume that you’d been misinterpreting the map.

But putting that aside, I still had a lot of fun with it, and I’m quite looking forward to the rest of the season.  And TellTale guys;  whoever created that pause screen transition deserves a raise.  Seriously.

So today I did something which I’ve been meaning to do for months;  I put in some quick full-MMORPG visualisation code.

What you’re looking at in this screenshot is almost the entire MMORPG map (there’s a little bit that’s behind the camera or off to one side or the other), viewed from four kilometers up.  Each of the outlined areas is a “Region”, and is (on average) about three square kilometers of terrain (though some are as large as five or as small as one).  In relative terms, an average-sized region here is about the size of World of Warcraft’s Goldshire, and this whole map is approximately the same amount of ground terrain that you’d find in all of World of Warcraft’s original “Azeroth” (including the sea between the two main continents), and far more than you’d find in most other MMORPGs.

This is the first time that I’ve actually seen the large-scale structure of the procedural MMORPG world;  previously, I had always been working with a camera that was primarily concerned with small-scale details, never going much above a few hundred meters, and never venturing more than one or two regions away from where I’d started.  I knew that the rest of the world was there, and had flown over it from time to time, but never really paid it close attention.  However, when viewed from this perspective I have a couple of thoughts:

1. I had forgotten how important it was to have this “massive” zoomed out view of the world, even though I’ve mostly been focusing on the smaller-scale details for MMORPG Tycoon 2.  Without this massive view, you can’t put your creations into perspective.  So I must keep something like this in the game.
2. If you go back in the archive to the “roads UI” video, at one point you’ll see me fly around in a debug camera, watching AI developers placing quest monsters.  In that video, even with how far I traveled, I don’t think you ever saw the edge of a region;  that whole video took place inside just one small section of just one of the regions outlined above.  Yowza!
3. There are a huge number of regions, here.  Far too many.  There are around 40 regions total on World of Warcraft’s two main continents, and there are 225 regions in a max-size MMORPG Tycoon world, like this one.  Now, the MMORPG Tycoon regions do include “impassable water regions” which aren’t counted in WoW’s number, but even with that taken into account, it’s far too many.  40-ish usable regions sounds like a much better (and much less intimidating for the player) number.
4. At four kilometers up, all the terrain appears to flatten out;  the roughly inverted-bowl-shape of the terrain is completely lost from up here, and even hundred-meter-tall cliffs look completely flat from this altitude.  I had initially hoped that the player would be able to see the basic shape of the terrain from up here, and then move in closer to see details, but now I don’t think that’s going to work;  there simply won’t be enough verticalness to be visible when you’re zoomed out far enough to see the arrangement of regions.
5. Even with the regions flattening out when viewed from up here, I don’t like the basic shape of the regions;  they look random and haphazard;  not like they’d been designed by someone.  I’m not sure exactly what’s wrong with them, but I’m going to need to find a way to make their layout look more human-designed.  Maybe it’s just an optical illusion, and setting up visible “water regions” to act as boundaries will  help give structure to groups of regions.  Or maybe I should switch from the “stretched grid” approach of defining regions that’s I’m using here, to something more organic, like a Voronoi diagram.  Adding visible water from here will be easier, so I’ll try that first.
6. I really like having the view from up here be a high-tech vector-style display;  I’ll probably keep it looking a lot like the views seen in MMORPG Tycoon 1 and 1.1, and only switch into the solid, fully-detailed view when you zoom in, rather than try to maintain that sort of look when the player’s way up here.

On an entirely different topic, today I modified the VectorStorm library to automatically drop the frame rate cap from 60fps to 10fps when the program is put into the background or minimised.  Makes it much better behaved with your CPU/GPU resources now, if you want to alt-tab out to check mail or write a blog post or something.  :)

So I was grumbling to myself today about how tricky it is to be dealing with such a large world in MMORPG Tycoon 2;  since the world terrain is generated procedurally as you move around in the world, it means that data such as the height of the terrain simply isn’t stored anywhere for locations which aren’t currently near the camera.

This can be a problem in many situations.  One example is when you have AI developers putting monsters into a quest zone.  The AI developers know approximately where the quest zone is, but if the camera isn’t actually near the quest zone, they have no way of knowing what the slope of the ground is, or precisely how high the ground might be.  Often, I’ve found that these quest areas end up having all their monsters placed down at sea level, with the terrain being twenty or thirty meters above there, so the monsters can never actually be reached by the players.

As I was thinking about the problem, I worked out the maths and calculated that for the size world I’m talking about (20km x 20km), it would take nearly 100 megabytes of memory to store the terrain height, if I kept the whole world in memory at once.  My old-school programmer brain immediately told me that this was complete madness, and threw away the possibility of doing this, and I went back to designing complicated queued fetch-and-correct systems for placing objects when not all the required data was actually present in memory, and it wasn’t until almost ten minutes later that something in the back of my mind clicked, and realised that no, 100 megabytes isn’t very much any more.  So I did it.

As a result, I’ve increased MMORPG Tycoon 2′s memory footprint from 256 megabytes of RAM to 384 megabytes of RAM to store this terrain data.  (To a programmer, those are nice round numbers;  256 is 2^8, and 384 is 2^8 + 2^7.  Aren’t those nice and round?)

Anyhow.  I set the game up to procedurally generate the whole world’s terrain when it starts.  And on my (rather fast) computer, it takes between 70 and 90 seconds to do so.  Which is completely unacceptable to me, so I changed the system to generate-and-cache-upon-demand, which means that the first time you visit an area, it runs at about the same speed as it did before, but is substantially faster each time you revisit an area you’ve been to before.  This also solves the “no terrain data for areas which are far away from the camera” problem, solves lots and lots of different of bugs, and actually makes the terrain generation code much simpler overall.  I’m quite pleased with how it’s turned out.  And I could quite probably create a background thread to generate terrain data for areas you haven’t visited yet, while you’re working on other things.

But it does now use an extra 128 megabytes of RAM.  This thing certainly won’t ever be running on the iPhone!