VectorStorm

So it’s been a busy month.  But not so much for MT2.

Most of my time has been going into paying work.  But I’ve been getting some things done in MT2 around the edges.  Most notably, I’ve hooked up a new system for generating roads and paths.  I’m pretty happy with it.  I’ll show some screenshots in the next few days.  Basic idea is that it now carves the roads into the terrain, basically overwriting the themed terrain type.  You can continue building terrain underneath the road;  the road just floats over the terrain surface (carved down into it).

I’ve been spending a lot of my time looking into AI bugs in the simulation.  I finally tracked down a problem which caused AI developers to occasionally slow down a lot when approaching a work site.  It was extreme enough that in my usual AI testbed level, the developer which was given the job of building the Inn would usually take so long to reach the building site that all the other AI developers would complete at least two queued jobs before the Inn-building developer even arrived to start constructing the building.  I fixed the bug (it was to do with the path variation code which causes entities to not precisely follow the “shortest possible path” to their destination.  The developer ended up in a version of Zeno’s Paradox, infinitely choosing to travel just 30% of the way to the target, and taking forever to actually reach the destination).  Fixing that bug also seems to have fixed another problem I’ve seen a few times;  AI players who eventually stop moving, while in the middle of questing.  If a monster comes up to them they’ll fight it, but otherwise they just stand still and don’t do anything.  Haven’t seen that again since fixing the bug, so I’m guessing that they were being affected by the same bug.

Regardless, I’m getting back into AI refactoring.  There’s still some awkward bits in the AI code, particularly around quest handling.  And things appear to go catastrophically wrong (ie: crashy) when someone completes all available quests in the game and wants to do another quest.  A little code cleanup should set that right, I hope.

A big concern I have right now is the terrain rendering.  The new infinite-zoom terrain system (which I love, and can’t imagine why I didn’t implement it in the first place) is fantastic, but the terrains don’t look so great from above — the visual style was kind of designed to be seen from a forward-view, not a down-view;  it was intended to consist of color-only, with textures used to add edge detail, while still maintaining the smooth color appearance.  And it just doesn’t read well from a top view.

I’m intending to build a MS3 demo in the near future.  My goal for it is to actually accomplish what I’d intended for the MS2 demo — a fully playable vertical slice of the game, similar to what would be in perhaps the second or third tutorial level of the full game.  I should really set a date for that.

In other news, I’m reducing my hours at paying-work, so I can dedicate a full day per week to MT2.  That starts in about a month.  We’ll see how much that boosts development speeds.

Mostly for myself, here’s a list of what remains to be done with MMORPG Tycoon 2.

DESIGN:

• Need to decide what to do RE: buildings.  Should buildings just be procedurally generated (or artist-created?), or should I be building a system which allows players to create their own structures within the game itself?  Need to make a call on this ASAP;  I’ve been procrastinating about starting either approach of this for far, far too long.
• Related to the above, what precisely is the visual functionality of raising/lowering the “level” of buildings/roads?  If they’re procedurally generated or artist-created, then this might just mean “make them taller” or “make them more ornate”, but if these structures are player-built, then I don’t really want to touch them, and maybe there should be no visible changes when a structure has “level-up” or “level-down” used on it.
• Also related to the above, how should the player be editing the world map?  Should he be using the “paint on” system which I’ve been playing with so far?  Or what about building oddly-sized “cells” inside each region, and changes to the map are made by assigning the changes to each “cell”?  (This isn’t far off from what most Tycoon games do).  This has the benefit of making things a little more regular and simple;  no grabbing a single vertex and extending it up into a 500 meter tall spike, for example.  On the other hand, the player couldn’t grab a single vertex and extend it up into a 500 meter tall spike if he wanted to.
• All three of these points are basically the same point:  Is this game a game in which the player places pre-built structures and assembles pre-built ground, or is this a game in which the player constructs the structures and designs the ground?  I very much want it to be the latter, but the UI for giving a player that sort of ability is not trivial at all.   Need to pick one option, and kill the other.  Stop wasting time by kicking this decision down the road.

Core simulation systems:

• Open passes which allow PCs to move from one region into another, through the impassable mountains.  (These probably get implemented as “buildings”, which appear on both sides of the mountains.  That is, treat them as tunnels through the mountains)
• Method for setting property values on a region.  Most critically, level range.
• MMORPG tech tree.
• Inventory, for limited-use collectable build actions (awards).
• Add “point of interest” building type.  No particular in-game function, but PCs — particularly exploration types — will occasionally travel to visit them.
• Consider spending some time tuning random generation of class/monster powers.  Right now, the randomly generated powers are the same, which means that a PC and a monster of equal level, both starting at full health, will each win a fight about 50% of the time.  This doesn’t seem right, compared against real MMOs, where the player should win most of the time.

AI:

• PCs store memories about recent events.
• PCs group into parties to go adventuring.
• Once a PC has gained too many levels for its current region, try to find a path to a new, correct-level region.
• CONSIDER:  PCs form guilds.  PCs form attachment to their guilds in a similar way to how they form attachment to the MMO now;  having guild support in your MMO and a strong guild presence will tend to keep guild-affiliated subscribers even if they’re not in love with the MMO.  Downside is that if you’re relying on guilds to keep subscribers present, then a guild collapse may result in many of its players leaving.  I like this idea, but is it interesting for a game?  Can players influence this in any meaningful way?  To be considered.
• If a PC wants to do a quest, but doesn’t know of a quest giver with an available quest for their experience level, generate a bad memory and cheat to find a new quest giver of an appropriate level.  (Imagine that the PC has access to something like Wowhead)
• PCs, as a group, evolve popular attack strategies over time.  (Imagine that they have access to something like Elitist Jerks)

Metagame:

• Scenarios: Series of pre-set game scenarios with objectives for the player to meet in order to progress.  Ref: Roller Coaster Tycoon.   These should be considered as “tutorials”, to teach the player how to play the game.  Each of these scenarios are confined within a single region of a larger MMO (although many of them may exist within different regions of a single MMO), and each should probably be focused on a different facet of the game.  (For example, Scenario 1 may be entirely based on terrain shaping, Scenario 2 be about building placement, etc)
• Free Play: The player gets full control of an MMO.  Probably want to give the player a set of starting MMOs to select from, here;  a WoW-style one, a sci-fi one, etc.  Which then can be modified to the player’s tastes.  Player should also be given an option about how large they want their MMO to be.  A full WoW-sized MMO takes up a LOT of memory/CPU!  Most players will be happier with a much smaller one, but I’d like to keep the option open for folks who want the whole thing.
• Add optional missions for the player, which give bonuses if completed.  Lots of the development time is going to go into creating these missions, and the system for when they’re presented to the player.  (See UI for the missions, see Core systems for the bonuses)

UI:

• Chat interface for PCs and system messages.
• Interface for presenting the player with their current missions, and available ones to accept (see “Metagame”, above)
• Inventory interface for MMO building awards (see “Core simulation systems”, above)

Graphics:

• Pick whether PCs, NPCs, and monsters should be representational or iconic, and set up proper graphics for them, one way or the other.
• Implement several more terrain types.
• Make the ground clutter system work for more than one terrain type.
• Need to replace current “umbrella” trees with nicer (and less polygon-expensive!) trees.
• Spruce up paths/roads.
• Nicer procedurally generated buildings.
• If rendering performance becomes a big issue, spend some time working on graphics batching some more;  there should be some big savings to be made here!

Always know when to say “maybe somebody else has already solved this problem”.

In today’s screenshot, you can see (some of) the individual building blocks of the MMORPG Tycoon 2 terrain.  I don’t know whether they will be visible in the final version of the game, but I thought you might like to see them now.

In essence, the MMORPG Tycoon 2 map is constructed from the cells of a Voronoi Diagram, with each game “region” composed of a single Voronoi cell.  Each of these regions is itself filled with more Voronoi cells, and these central cells become very important to the underlying structure of the game.

For me, the “maybe somebody else has already solved this problem” probably should have been two years ago, when I first set up this system.  I wrote all of this geometry code myself, and while most of it worked really well, there was one bit of which which didn’t;  clipping the embedded Voronoi cells inside each region, to maintain the region boundaries.  I struggled with that code for many days, trying to make it work reliably.

Don’t get me wrong;  the code mostly worked.  It worked about 99.9% of the time.  There were only a few really awkward situations which would cause it to fail.  But as you can see from the screenshot, there are actually a lot of Voronoi cells in a map — even a small one, like this.  My code would tend to fail about one time per five maps.  I’ve spent many, many days trying to make the system work consistently, over the years.

Then today, after spending almost another full day debugging the problem, I finally thought, “I bet someone else has already solved this problem”.  Fifteen minutes later, the problem is solved, simply by adding some source from The Clipper Library.  It’s much more powerful than what I actually need, but it handles my simple clipping problem without breaking a sweat.  Big kudos to its author!

So for future reference:  When stumped, particularly on something geometry or physics-based, go looking for a library.  They can save a huge amount of your time, and get you back to working on the things that you’re actually good at working on.

I’ve been working on MMORPG Tycoon 2′s procedural terrain generation, today.

Issues fixed today:

• Beaches are wider.
• Beaches are no longer jagged when not oriented precisely north/south or east/west.  (Related to this, lake borders are no longer blocky).  They also are no longer precise straight lines along the region boundary — the beach actually occurs about a hundred meters inside the region boundaries.
• When mountain borders extend out into the water, they no longer extend grass through the ‘beach’ zone bordering the water.
• When mountain borders extend out into the water, they no longer have a “wedge” cut into them (pictured in this screenshot).  The mountain border now ends more naturally.  Or at least, as natural as you can get when you’re talking about something which intended to appear as a blatantly artificial mountain border.  :)
• Beaches now smoothly rise from the water, instead of “stepping up” by a meter or so from the water level.
• Removed three ‘if’ statements from the edit-mode camera code, resulting in a much smoother camera motion while zooming in and out.

Useful tip for anyone writing camera code:  Removing ‘if’ statements (or other forms of conditionals where sometimes the camera will do one thing, and other times the camera will do something else) will almost always improve the overall camera behaviour, from a user’s perspective.

I very nearly titled this a “post-mortem”, before realising that that’d have implied that I wasn’t going to do more Game in a Weeks.

I’d like to talk for a bit about the Game in a Week process;  about what it was intended for, and about how it has worked out, and maybe about what I want to do with it in the future.

From the start, Game in a Week was supposed to be a game design exercise, not a game making exercise.  Yes, I was supposed to produce something playable by the end, but the real goal of the exercise was to get more practice at designing games — particularly unconventional, experimental games;  I already have heaps of experience implementing games, it’s breaking out of the box that I need practice at.  What’s more, it was supposed to be a low-stress activity and have low-impact on my other development;  the idea was that I’d do what I could do for a week, and then stop.  No matter what state the game was in at the end of the week, I would release it in that state and never spend time working on it or maintaining it again.

One of my unstated goals from the start was that each design for a Game in a Week should be interesting and unconventional in some way.  I didn’t want to just create a variation on somebody else’s game design.  I definitely didn’t want to make (for example) a fancier version of Asteroids.

With that said, let’s run down the list and talk about each game I’ve made as a “Game in a Week” project.

Ill-Timed Petition Damsel

In many ways, Ill-Timed Petition Damsel is my favourite of the Game in a Weeks.  It definitely had the best theme statement to select from, and it turned into a really interesting, unconventional game design.

The design here was that you were attempting to get signatures for your petition about road safety.  The trick was that each copy of your petition was somewhat cursed — after a certain period of time, an out-of-control car would smash through it and anyone nearby.  So your goal was to get the petition close to as many people as possible within the time limit (thus gaining lots of signatures), and then get rid of it again in such a way as to avoid any people being hurt by the out-of-control car.  If people did get hit by the car, police would appear and try to apprehend you, one police for each person hit by a car.  The game ran until the player was caught by a member of the police.

Stripped of the theme, the game was really a “push your luck” sort of game, where you want to get into a high concentration of pedestrians for as long as possible, and then get far, far away from them before the consequences hit.  As pedestrians (inevitably) get hit, you also have to evade chasers, which threaten to end the game.  It’s actually a very simple design, but not one that we see used often.  I can’t think of another game I’ve played which is structured this way.

I’m very proud of this one.

Continue reading “Retrospective on Game in a Week”