Introducing Mayflight

Mayflight is an infinite hardcore exploratory platformer I created.  Its terrain is generated upon entering each new room. You could explore it for hundreds of years and never come to its end.

It was implemented, in three-and-a-half months, using YoYoGame's Game Maker program, which I find, despite some distracting quirks, to be generally a good tool for rapid game development, and entered in their "Competition 06" game development contest. 

This post details its inspiration, gives an overview of the game, and goes into detail about features and concepts that it borrows from roguelike games.  It is substantially similar to my @Play column on the game posted on GameSetWatch, Gamasutra's sister site where I am a regular columnist.  Later posts may not be so similar.

Project link (contest version: v1.01) - Current (as of this writing) Dropbox download link (v1.02) - YouTube video demonstration of a rather good play - Large collection of screenshots

Some years ago I had an idea for a randomly-generated platformer game.  The concept was what we might call non-traditional: there were no enemies, there was no explicit goal, and there was no real purpose to the game. 

What was there was a few ideas as to how to create random terrain algorithmically, and the hope that this would be interesting enough by itself.  Really, I think it isn't.  (I actually think that it can be, but we aren't there yet.  I may say more on this later.)

Some time back I registered a copy of YoYoGames' beginners' game development kit Game Maker 8.  After poking around with it, I found that it was actually much more powerful than I had expected.  One can jettison the annoying "drag an drop" scripting system and use C-like code almost exclusively.  It maintains the DirectX commands for you, and generally lets you get on with the work of constructing your vision instead of wrestling so much with APIs.  I will not say that it is perfect.  If you probe the edges of the system you sometimes unexpected problem cases, such as if you try to generate random numbers within a very large range.

It also has real problems concerning keeping code to yourself; as it stands, anyone can take any published Game Maker game and fairly easily get the scripts and resources out of it.  However, "real" games have been made with it before, most notably to my mind two games we've mentioned here in the past, Spelunky and Desktop Dungeons.

Around the time I installed Game Maker on a new system, a news post opened up on its greeting screen about a game development contest YoYoGames was sponsoring, "Competition06." 

I gathered from the text that they were working on a Game Maker runtime that would be runnable on Playstation Network systems, most notably the PSP.  Because of that, the requirements for the contest were fairly restrictive, and geared towards producing games that could run on the PSP.  There was some prize money offered, and the theme of the contest was discovery....

Discovery.  That got me to thinking about my old random platformer idea, and wondering if it could be adapted.  I decided to give it a good, solid attempt.  That was the middle of May.  The deadline, as I write these words, was six hours ago.  After three-and-a-half months of near-obsessive work, the game that I submitted to the contest was Mayflight.

Postponing mortality two seconds at a time

Your character in Mayflight is a fairy named Aurora.  She exists in what is almost an infinite world: the game terrain is created algorithmically as you enter rooms.  It uses pseudorandom number generator seeding creatively to make its terrain consistent.

Although the structure and graphical look of each room is overwritten in memory the moment you leave it, if you were to return to it in backtracking it can recreate the area just as you had first seen it.  The game does store some data on which items you collected in a room and which enemies you killed, so the state of vacated rooms are preserved to a degree.

If it were just Aurora running and flying around a bunch of terrain, even if the graphics were fairly interesting (I think they are; judge for yourself from the screenshots on this article), it still wouldn't be a very interesting game.  This isn't a roguelike lesson; it is obvious.

Strong roguelike game designs have one essential element that drives the play, some danger or process that forces the player to keep exploring territory instead of staying in an easily-controllable area and grinding.  In many roguelikes this is provided by the food requirement.  In Mayflight, this is provided by a harsh time limit.  Aurora's species of fairy has a ludicrously short lifespan: she only can survive ten seconds on her own.

To overcome this dire predicament, Aurora can collect "sparks," spinning balls of light that are scattered everywhere in the world with the ubiquity of Mario's coins.  Each grants her from 0.5 to two seconds of continued existence.  (The amount varies according to time remaining; the more time you have, the less you get.) 

Although the collection mechanism is a lot more pressing than having to find a food ration every two or three levels, it is the same idea at heart: to force the player to explore ever more terrain to find time extenders, and in the process stay alive.

However, in Mayflight, the further you explore from the start the rarer sparks become, decreasing the player's time income.  Eventually equilibrium will be reached between time gained and time lost, and after that the player will go on a slow march towards oblivion.  The player's skill in maneuvering determines where exactly that equilibrium is reached.  Too, other dangers will often intercede before that, taking tolls of time both directly and in navigation hazards.

A factor that works in the player's favor is that some places naturally have more sparks than others.  In the center of each "area" there is a shrine that always has several sparks, rooms with only a single exit will tend to have more sparks than well-connected rooms as a compensation for hitting a dead-end in the maze, and the rare one-screen-size rooms that are rarely generated always contain lots of sparks, and other powerup items besides. 

Maps that may be randomly found in the game give the player an overview of a local area of the maze, and thus allow him to devise strategy about which rooms to visit.  The maze generator is purposely imperfect; there are biases in the area structures it creates, and a canny player may take advantage of those to find these special areas with slightly greater frequency.  This may be viewed as analogous to the usefully-predictable maze builder in Rogue.

Morbo says your quest is doomed.  DOOOOMED!

Randomly-placed goal rooms were originally planned for the game, but time drew short before I could implement them and the other game features that would make them useful to the design.  (Work may continue on the game into the future, at a reduced pace, and these things will probably be an early addition.)  So the focus of the game is another roguelike borrowing, one that they themselves borrowed from arcade games: the game is played for two types of score, and a high-score table is tracked for each. 

One is raw distance from the starting screen, measured in "meters," and the other is a general score that takes into account a few different kinds of accomplishments.  I am not actually sure if the score-based design is compelling enough for sustained play; when you're working full-tilt on an idiosyncratic personal project up against a strict deadline, things like this don't always get tested for.  It was interesting enough for me to continue play-testing it, at least, enough so that my best distance score is over 1,700 meters, which took about an hour to achieve.

There are not a large number of monster types in the game, although their behaviors vary depending on  the difficulty of the current area.  In truth, the real challenge of the game is in keeping Aurora alive by collecting sparks, but that isn't varied enough to make a generally-accessible game. 

Holding down the Z key allows Aurora to throw "darts" at the monsters, and pressing different arrow keys hurls them at different angles.  She can also stomp them, which does a bit more damage but carries with it the risk of getting hit.  Later on the monstrous opposition ramps up considerably; in the demo playthrough video given you'll notice times in the later levels where Aurora is swarmed with monsters.

There is a rudimentary physics simulation that both Aurora and the monsters follow.  It's not particularly detailed (this is one of the things that I had to wrestle with Game Maker in getting to work), but works for the game.  Unfortunately, this is the closest the game comes at the moment to providing a roguelike cause-and-effect system. 

The original idea was to provide physics-based traps and tools that could be used against the monsters if triggered creatively, but I couldn't get a more-complete physics system going than this without things getting stuck in walls, clipping weirdly and shooting off towards the stratosphere randomly on contact with each other, despite expending several development days on it.

Engineering an arms race that does something other than escalate

As it is, there is still some of it in place.  If Aurora's speed is over a certain level, she becomes invincible.  This is shown in the game as a fireball aura that surrounds her.  There are several ways to build up enough speed to reach this state.  At the start of a game falling from a height is the only thing that will even come close.  Once wing strength has been powered up a bit, there come brief flashes of fire from flapping that can immediately slaughter a monster only if timed and aimed exactly right. 

As wings continue to get stronger these flashes become longer, and eventually almost continual.  Once run speed and jump strength have been improved a bit, jumps made while running at a good clip will produce a streak of fire that will tear through monsters.  Eventually just running will provide enough speed to destroy monsters, but the game is balanced that this happens only when max run speed is near or at the top level.

To counter the player's increased avenues for invulnerability, monsters gain much more health towards their most powerful levels, so much that Aurora's stomp and dart attacks become much less useful.  The idea is not to provide a linear increase in power on the player and monster's parts so that they are evenly matched through the game.

This may seem to be sensible game design, and certainly a lot of MMORPGs subscribe to this school of design, but it's actually fairly uninteresting.  If the opposition is always matched to your level in power, then the game feels exactly the same as you progress, promoting boredom.

At its worst, this thinking has given us RPGs in which the monsters are artificially scaled to the player's level, which I consider to be a grave sign of design decadence.  The two approaches are the result of design philosophies that are different at the root: the idea that the game is a set challenge that the player must overcome, and the idea that the game is an interesting experience for the player to have. 

Neither is good or bad in itself, but currently the prevailing trend in experience gaming is towards trying to cook the game's challenges in order to always just be slightly beneath the player's ability to overcome, through techniques like level scaling and dynamic difficulty adjustment.  I hereby go on record: this is a bad trend.  It is treating the player like a pet, trying to induce him to feel powerful through largely artificial means.

To return to Mayflight, the game gives the player more frequent and longer moments of invincibility, but makes monsters much stronger in the elite levels of play so he has to rely on them.  This helps Mayflight to feel like its play changes in the later phases of a long game.  The roguelike this is most like is Rogue itself, where the monsters get stronger faster than the player so that ultimately he must rely on his accumulated consumable equipment, and sometimes just plain-out running away, to survive.