VectorStorm Blog

So I’ve been looking around at various input devices again, and pondering about how VectorStorm might support them.  Tablets and styluses and light guns are, of course, easy, as from software’s point of view, they’re basically just mice which have cursors which ought to vanish when their buttons aren’t being held down..  the VectorStorm engine can handle these quite easily right now.

Multitouch surfaces (such as many modern laptop trackpads, iPhones, and other devices) are a little more tricky;  one could argue that they’re just multiples of the tablet “vanishing mouse”;  instead of one cursor that behaves that way, you have three or four of them.  Unfortunately, none of them are actually implemented that way in the OS, and the current version of SDL which I use doesn’t support these types of devices.  Well.. my MacBook Pro’s trackpad has a “two-finger-scrollwheel” feature which works in VectorStorm games, but only because it’s being treated as a scrollwheel.

Speaking of scroll wheels, it’s worth mentioning that under Windows and Linux, scroll wheels act like buttons.  They have integer “clicks”, and send a “button down” event every time they’re spun a distance of one “click”, however that’s defined for the particular mouse.  You can’t scroll by a half-click;  if you had a mouse which didn’t have ‘stops’ on it, and you spun the wheel by half of a ‘click’ (however far that is on that mouse), you’d get no scrolling at all.  By contrast, under Mac OS X, scroll wheels typically have no ‘stops’, and report a floating point distance.  The VectorStorm engine treats a scroll wheel as a digital button — that is, the extra precision available under OS X is lost.  Or to be more specific, SDL swallows that extra precision, and never shows it to VectorStorm in the first place.  Similarly, the current version of SDL does not support horizontal scroll wheels at all, either on the rare Windows mice equipped with them, or Apple’s “scroll ball” on the Mighty Mouse or two-finger scrolling on trackpads or touch-scrolling on the Magic Mouse.  SDL does support tilt wheels, which while still somewhat unusual, are no longer considered exotic under Windows.  On tilt wheels, the left and right tilting of the wheel shows up as two extra mouse buttons, and so can easily be mapped to functions inside VectorStorm.  I imagine that proper support for horizontal scrolling is probably going to require a new version of SDL, and even then, it probably won’t support full-resolution scrolling  under OS X.  And even if full-resolution scrolling was supported for OS X, I couldn’t actually use it for anything important, as Windows and Linux users wouldn’t have access to it, as it’s not provided at an OS level for them.

Most popular custom controllers like Guitar Hero guitars and Dance Dance Revolution mats are easy to support;  they’re just joysticks without the sticks.  If you can get your OS to detect them as gamepads, VectorStorm should be able to make use of them.

Gesture controls are, of course, big business these days, and every platform does them slightly differently.  But when you come right down to it, gesture controls are the first big thing that really doesn’t fit well into the VectorStorm input model.  Oh, sure, I briefly ported VectorPhysics (from the testbed apps) over to the iPhone, and used the accelerometer to set the gravity for the simulation.  But I couldn’t use SDL to get at the data, and passing the data through the sysInput interface was a real kludge;  sysInput is designed to handle one-dimensional data.  Passing matrices and 3D vectors through it was just awkward and unpleasant.  I don’t expect to see SDL providing support for these any time soon.

And things like Microsoft’s Project Natal would be even more difficult to shoehorn into my current input model, which was relying on all input forms being, at a certain level, exactly the same, as they have been pretty much from the Atari 2600 up until the Wii, with only very minor evolutionary adjustments a few times per decade.

In discussions about video games, one often hears about the length of particular games.  About how in The Good Old Days, even action games were expected to be twenty to thirty hours long, whereas modern video games have now dropped to about six hours long (with some well-reviewed games such as Portal now as little as two hours long!)  Making longer games of a particular level of quality, of course, generally takes more time and more effort than making a shorter game of a similar quality level.

You also occasionally hear about a game’s depth.  A game which can be replayed in many different ways, with different strategies, and revealing different things about the way in which the game world works is commonly considered to be a “deep” game.  Just like with longer games, making a deeper game takes more development resources, and more design resources.  And it’s likely that many players will never see the game’s hidden depth;  they’ll stop playing before they reach the end of the game, or won’t be interested in playing it again.

So we already have length and depth.

Picture in your mind for a moment, visualise the full sweep of a game as a flat ribbon.  This ribbon extends from one position in space to another;  the “start” to the “end”.  The distance between those two positions is the game’s length;  it’s how much game a player has to play through to reach the end.  The first time a player plays through a game, by my definition, he is travelling along the top of that ribbon.  A game with depth has a thicker piece of ribbon, and may be played again on a different level within that thicker ribbon, and be enjoyed as a “fresh” experience, even though it’s the same game.  The more depth, the more levels the game may be replayed on, giving fresh insights or fresh experiences along the same length of the game.

I’d now like to add the concept of “breadth”, which describes how much latitude the player is given while playing the game and making progress toward the end of the game.  In Super Mario Brothers, the player travels exclusively to the right, and may move up and down only within the height of a single screen — there is not much latitude given to the player to deviate from the game’s prescribed path.  In later Mario Brothers games, the player was allowed to travel back to the left, and to jump (or fall) much further than the limits of a single screen’s height;  that gives a good deal more opportunity for the player to meander away from what the game intends for the player to do.  However, his progression through the game was still largely restricted to finishing a static list of levels, which all had to be completed in order.  And in practice, few of the levels actually allowed much deviation from the intended path.

I’ve been noticing recently that most modern games have been strongly focusing on depth (difficulty levels, achievements, customisable classes, various power-up strategies, etc), and are acutely aware of their length, but very few have paid much attention to their breadth.  Racing games typically constrain the player within a literal ribbon of track, RPGs maintain lists of where you must travel next and actively push you toward your next quests, platform games have you travelling through narrow canyons which usually are dressed up to not look like canyons, all of which give very little freedom to the player.  Many game genres have become quite adept at hiding how little breadth they have;  there are dozens of tricks of lighting and cameras which can be used to help funnel a player through the desired path, hopefully without noticing that he’s trapped in a tight little passageway.  And of course, if those fail, you can always lay out a trail of shiny things (rings, coins, stars, etc) for the player to follow.

It’s worth mentioning that some RPGs — particularly western RPGs — have a large number of optional “side-quests”, which certainly count as breadth.  But those often feel a bit like diversions;  not really a core part of the main game.  Certainly in Oblivion and Mass Effect and others, there are huge numbers of side quests (breadth), and relatively few mainline quests (length).  And some open-world games also let you wander freely through their world, when you’ve gotten tired of doing their linear story missions.  But in order to reach the end of these games, you have to pass through their narrow canyons, taking the actions they prescribe, usually with only minimal amounts of deviation allowed by the player.

Compare this against games like SimCity, or Dwarf Fortress, or The Sims, none of which really have any discernible “length”;  these games have no fixed end, and often don’t even have any explicitly stated goals.   This sort of undirected play has extreme breadth, but no defined length.  It’s to this latter class of games which MMORPG Tycoon belongs.  And this does scare me a bit;   these games are typically more difficult to build and often require more effort on the part of the player.  After all, the most prevalent types of games out there right now give a strong framework for the player to work inside;  they say “Press ‘A’ now!”, and when the player gets around to pressing ‘A’, the game plays a happy fanfare and then delivers its next instruction for the player to follow.  How does one build a game with breadth, which can deliver that same sort of positive reinforcement?  And how can you ensure that a broad game can automatically but unobtrusively suggest things for the player to do, when they’re not sure what to do next?

(One possible answer:  incorporate a variant of the Space Bar Game into the game design, to provide an artificial simulation of “length”.  Hey, it worked for World of Warcraft, right?)

I’m not saying that lack of breadth is bad — just that it’s interesting how little breadth there is in most modern games.  And how scary I find it to be designing a game which is almost entirely breadth.

I’ve apologised before about the recent lack of screenshots, and I’m afraid that I’m going to have to do it again.  All I can say is that I’ve been pulling together the secret third game mode, which requires learning to code a bunch of new things which I’ve never done before.  And every day, this side of the project is getting more exciting for me.

I mentioned about a week ago that I’ve been pulling apart some of the older code in the MMORPG Tycoon codebase;  things like class definitions and monster types, which previously stored their data together with their UI handling code.  Well, I’ve now mostly finished that process.  All the big difficult stuff has been thoroughly extricated from the UI code, which makes it much easier to reimplement the game’s UI without breaking the game simulation.  This means that as soon as I start posting screenshots again, you’ll stop seeing those ugly old black UI windows!

In other news, I’ve been experimenting with some new task tracking software, to help keep myself on track.  Folks might remember my brief usage of Mantis while developing Mantis version 1.1, but I was never really happy with it;  it was just too fiddly for my tastes.  The past two weeks, I’ve been using FogBugz, which is fantastic;  simple but powerful, and while it was clearly designed with people working regular 9-to-5 jobs in mind, it’ll happily cope with my currently somewhat eccentric work schedule.  And via FogCreek’s “Students and Startups” program, it’s freely available to students or organisations of just one or two people.  Anybody else out there working by themselves on a large project, it’s totally worth looking into!

Finally, I’ve been slowly working my way through another “Game Design” post which is secretly about some of my anxieties around MMORPG Tycoon’s game design.  Expect to see that soon.

I need to take this opportunity to give a quick shout out to Alex and Rudolf, who have just released Eufloria, the updated, commercial-quality successor to their game “Dyson”, which was created for (and took second place in) the same Procedural Generation Contest at TIGSource for which I created the first version of MMORPG Tycoon.  I always knew that they’d beat me to market!  ;)

Eufloria is basically a space RTS, in which colonies of spores fight against other colonies of spores for possession of asteroids within an asteroid belt.

Now, people who know me will tell you that I have a thing about RTS games.  I want to love them;  I eagerly await their release, purchase them, install them, and then play them up to about level four, at which point I remember that I don’t actually like RTS games, and then I never play them again.  This cycle repeats about every four months or so, whenever a new RTS is released.  But Eufloria is the most laid-back, casual-friendly, and atmospheric RTS game that you’re ever likely to see, and I’m still playing it.  It’s one of the few games released this year that I honestly wish I had created myself.

Anyhow, check it out.  There’s a demo and everything, so you have no excuses!  Eufloria can be purchased directly from the developers’ site, or via Steam.  Mac and Linux versions are in the pipe, but haven’t yet dropped.

In an effort to make the early game of MMORPG Tycoon 2 easier, I’ve recently been modifying a few of the older design elements.  For example, in versions 1 and 1.1, the player had five character classes and ten monster types which he could specify and balance.  In 2.0, since these now have far deeper configuration options and I don’t want to overwhelm new players, I am giving both more and less:  in a freshly begun MMO, you have only one class and two monster types available.  However, further classes and monster types can be purchased via the MMORPG Tech Tree, and there is no longer any maximum limit to the number you can create.  (Having more will make balancing more difficult, but will reap better rewards if you do manage to balance them all reasonably well)

So far, I’ve made this change for the character classes;  I’m expecting to make the same change for monster types tomorrow.  And once that’s finished, I’ll be moving on to the new version 2.0 MMORPG combat engine, which simulates combats using the player-specified class abilities, instead of only using the abstract “attack” and “defense” statistics from version 1.0/1.1.