VectorStorm Blog

Since I’ve spent so much time on exciting new tech recently, I decided that it was time to buckle down and do some of the less fun work that’s been needed for a while, improving the code which I’ve inherited from MMORPG Tycoon 1.1, and which it in turn inherited from version 1.0.

It’s important to note that version 1.0 was written for a game writing competition, which had only a month to complete the game.  And while I had already created several games in far shorter periods of time than that, MMORPG Tycoon 1.0 was a massive game, and so I was taking any shortcuts I could make, in order to implement it as quickly as possible.  Often (or usually), this meant trading away clean, maintainable code, in favour of simple approaches that I could churn out in a short period of time.  Much of that old code is still in the project, only getting worse as time passes.

So from time to time, I go and try to rip out the bad code, and re-implement it in a nicer way.  Programmers call this process “refactoring”;  it’s not a fun process or an easy process, and when you’re working for a company, management usually doesn’t see the benefit of doing it at all.  It takes a lot of time and brainpower, and there’s no externally visible benefit from having done it.  But if you don’t do it, then the codebase slowly rots from the inside, becoming more and more unpredictable, fragile, and inconsistent over time.  As unpleasant a task as it is, it’s a big time saver over the long term.

The last few days, I’ve been refactoring how many of the player’s game design settings are stored.  In MMORPG Tycoon 1.0 (and later in 1.1), these settings were stored together with the code which drew their UI screens.  For example, when the game’s combat engine needed to figure out the chance that a particular character would be able to hit a particular monster, it had to talk to the UI screen for the character’s class, and the UI screen for the monster’s class, and also the “General Design” UI screen in order to retrieve the necessary values.  This was convenient for rapid development, but isn’t very flexible at all, so I’ve been working to decouple the data storage from the UI code.  It’s slow going, but worthwhile to have done.

The other nice thing about this type of “clean-up” task is that it gives me time to reflect about the next set of game design choices that I’m going to be confronting.  At this point, I have most of the design for MMORPG Tycoon 2.0 worked out;  there are only a few little niggling details that I’m still kicking around.  The one I’m thinking about at the moment is how (and whether) to allow the user to perform within-a-region terrain editing.  There are a few options.  I could let the player draw directly onto the terrain height map, which would give a lot of freedom to build terrain precisely how you like it, but would completely rule out the possibility of ever being able to share your maps with your friends over the internet (save files would be far too huge), or otherwise let others see what you’ve been doing.  I’m not planning either of these features to be in MMORPG Tycoon 2.0, but they’re at the very top of the list of features that I’d want to have present for a future version 3.0 release, and I really don’t want to have to remove a 2.0 feature in order to allow people to share levels in 3.0.

Alternate options include “no within-region terrain editing allowed” (which I don’t like).  Another option would be “placement-based terrain editing”, which would have the user placing “terrain” objects on the map in the same way that he places buildings, to create terrain features.  Imagine placing a “Mountain” object or a “Forest” object, and having a mountain range or a vast collection of trees spring up around it.  Another option would be to subdivide each region into many smaller districts, in the same way that the world map is currently subdivided into regions, and then allow the user to choose features for each of these regions, in the same way that he now selects a level range for each region.

I’m not really convinced yet;  I’m still weighing up the options.  But I’m currently leaning toward subdividing into districts.  Those districts would also be useful for improving AI pathfinding and a few other little tasks.  Anyone have other thoughts/preferences?

Sorry for having gone rather silent for the past week on the development front;  I’ve been hard at work on “the secret third game mode” that I’ve mentioned a few times before.  To be honest, this secret third mode is probably actually the fourth game mode;  there’s “on foot” (which is mostly about collecting and tuning game rules), “on graveship” (which is mostly about setting up the game world map), and the unnamed “high altitude” mode, which is a bit like the “on graveship” mode, but concerned with larger-scale features of the world, and overarching design decisions.  Of course, I don’t expect people to spend much time at all in that “high altitude” mode, so maybe I shouldn’t count it;  for the most part, you set it once and then forget about it.

Regardless, I’ve been spending a lot of time working on this other “fourth” mode.  And while I’ve been making games for an awfully long time, it’s an area that’s very new to me.  A bit like when I spent a week or two learning how to program collision and physics systems, back around the time that I made “Muncher’s Labyrinth”.  Only  more so.  In fact, this is a new enough idea that I wasn’t even sure that it’d actually be fun in a game until I finished prototyping it yesterday;  I’ve certainly never seen it done before.  Anyhow, I’m still keeping it under wraps for the moment, but I wanted to assure you all that I haven’t just vanished into a pit or taken a week’s vacation or anything;  progress is still being made!

I’m just not willing to spoil the surprise, yet, by describing what I’ve been up to or posting screenshots.  :)

In my days as an amateur magician, I noticed that as a magic-practitioner myself, I watched other magicians’ performances with a different eye than I had, when I was merely a normal spectator.  I stopped being surprised or amazed when cards were discovered in unlikely places or when the shapely lady who, just moments ago, had been handcuffed, bagged, and locked inside a trunk turned up somewhere entirely different.  This wasn’t particularly surprising — after all, I knew how these tricks and illusions worked.  What was surprising was that now that I knew all the secrets, watching these performances became even more interesting — watching how the magician managed to get his hand into his pocket without the audience noticing, how misdirection to something noisy or shiny allowed him to set up for the next illusion in plain sight, if only anyone had been looking at him during that critical moment, etc.

Now as a game programmer, I’m noticing much the same thing.  Today, I’d like to talk about levels and streaming, and the changing relationship between the two.  I’m going to be focusing on console games here, but the history of PC games has been very similar.  More beneath the fold.

Continue reading “Levels and Streaming: a Retrospective”

This UI is obviously placeholder and terrible, but the game mechanics are now going in.

Those who were following the development of MMORPG Tycoon 1.1 (before I cancelled work on it) will remember that the major new features in version 1.1 were going to be the new, more interesting player AI model, and the user-adjustable MMORPG game rules, particularly as they relate to combat.

Well, I’m now starting to get those game rules from version 1.1 back into place in 2.0.  In this screenshot, I’m editing an ability on the “Paladin” class, which I have entitled:  ”Mighty Smite”.  Mighty Smite, when used, causes 40 points of “Health” damage to an enemy, and uses 20 points of “Energy” from the player using the ability.  And I’ve set for it to take a few seconds before it becomes ready for use again.  As your subscribers play, they’ll be forming opinions about which classes are the most powerful, and if they’re not reasonably well-balanced, you’ll probably see the perceived-to-be-weaker classes becoming much less popular amongst your subscribers.  That is, until you buff or nerf classes back into balance.

I mentioned “Health” and “Energy”, earlier.  These are both user-editable character attributes;  the player can change their names, the colours in which their stat bars are drawn, how quickly (and in which direction) they recharge, and what happens if they should drop to zero.  When you start a new MMORPG, you get just the “Health” attribute.  Additional attributes can be purchased from the MMORPG Tech Tree (currently up to a total of five).  In this shot, I’ve bought one more attribute, named it “Energy”, set it to recharge slowly, and to do nothing if it should ever hit zero.  ”Health” also recharges slowly by default, but will kill a character or monster if it ever drops to zero.

With this system, you can already do regular attacks and healing of yourself or teammates.  (Or healing of monsters, if you had some reason to want to let your various classes do that).  Eventually, I intend to also allow these abilities to do area of effect and damage over time damage/heals to attributes, as well.  But that probably won’t be in the initial release.

That last screenshot, while delivering more colour as promised, didn’t really show anything that people hadn’t already seen many times before.  So to make amends, I’m adding one more screenshot tonight.  I’m now partway through adding region-terrain-styling support.  In this image, we’re peeking over the region boundary between a green, grassy region, into a more snowy, rocky region.

This is still very early, but I think it’s nice to start seeing some more variation in what the terrain looks like!