From the doc: the Metronome system

The Metronome system was probably the most confusing idea to my fellow developers and the least noticed part for our players. Below is a brief description of the design, and an excerpt from the post-mortem on the technical difficulties we had with integrating the system with the music (and therefore making it actually noticeable).

Micro Missions uses a light version of a metronome system. The metronome system was developed by GL33k, a collective of independent game audio developers, and first used in the game Mushroom Men. Bobby Arlauskas made a poster presentation about the idea at GDC 2012 (http://gl33k.com).

The idea of a metronome system is to provide beat-based timing cues for the whole game to use in place of traditional time measurements, like seconds and milliseconds. This process makes the timing of events and transitions synchronized with the music and simultaneously dependent on the music speed. If all events synchronize to the same beat, the player can predict the timing of events better. There is also more opportunity for serendipitous synchronization between various happenings on the stage at any given moment. This system is meant to be quite subtle and is not necessarily intended to be consciously noticed by the player.

In Micro Missions, the metronome is used primarily to measure how long mini-games, cutscene frames, and instructional overlays should last. Micro Missions has four different musical themes, each with its own speed. So, changing the theme can affect gameplay by changing the speed of the game.

From the post-mortem

One of the biggest issues arose when we were trying to tie the Metronome system to the Sound Engine. The Sound Engine was meant to trigger the next loop of the music exactly in time with the Metronome beat, so that the music and the gameplay match up. However, this design caused a small but very noticeable piece of the music to be skipped, as if the music player ran out of time and could not finish playing the previous loop iteration before the next one started.

The cause turned out to be caused by Flash taking a non-negligible amount of time to actually start playing the music. Moreover, this amount of time was very inconsistent, which made it impossible to compensate for.

We ended up scrapping the synchronization system and simply starting a new playthrough of the loop when the old one finished. This did not get rid of sound artifacts completely, since the sound froze a little while Flash thought about how to start playing it again.

From the doc: Motivations and Goals (more on "a qualitative sense of progression")

The primary motivation behind the design of Micro Missions was to create a game that emphasizes moment-to-moment fun and variety rather than a constant grind to progress and go just one step further. At the same time, the connected nature of the games and the idea of acquiring and exploring a variety of content provide the sense of progress and improvement.

However, this progress and improvement are qualitative rather than quantitative. Instead of filling a level-up or progress bar or gaining points, the player acquires and sees a variety of content, some of which is more suitable for his current goals and is thus an improvement over the old stuff. This qualitative variety and difference should be more interesting for a player to explore than simply adding more numbers to his stats as time goes on.

The connected mini-games structure is thematically cohesive, yet very disparate in terms of gameplay. This design allowed us to create an RPG-like game world that requires a lot less gameplay balancing than an actual RPG, since gameplay rules are not nearly as strictly defined.

The “anything goes” feeling of the game also allows for a game that is more like a crazy, barely controllable bumper car ride than the intentional, directed drive of a typical progression-oriented game that is punctuated by the start-and stop of dying or failure states. Instead of having failure or lose states where the player has to revert to a previous state and try again, this game is more suitable for having diversion  or deflection states, where the action goes on, but goes in a direction that was not necessarily anticipated by the player.

From the doc: Executive Summary

I want to post some bits and pieces from the big Capstone Design Doc(recall that this game was a capstone project for a Master's program in Game Design and Development).

The first bit I want to post is the executive summary of the game, written after the game was made. It's interesting to compare and contrast it with two versions of the game description that I had posted before we started making it:
http://micromissions.blogspot.com/2011/12/whats-micro-missions.html
http://micromissions.blogspot.com/2012/01/what-is-micro-missions-again.html

Micro Missions is both a mini-games collection and an action-adventure game. Everything you do in the game is a mini-game, but these mini-games are connected through the world and its characters and locations. Each mini-game’s outcome also affects the world and the story. For example, to enter a city whose gate is closed, the player may have to traverse the city’s sewers by playing a Pac-Man style mini-game. If the player runs into an enemy while inside the sewer maze, he will have to defeat him by playing a fighting mini-game. While in the sewers mini-game, the player may also happen to find a special weapon. This weapon will help the player in future fighting mini-games.

The player’s actions are directed through a series of quests that are automatically generated based on the implied story goals as well as the goals of the Non-Player Characters. The quest generator chooses and populates quest archetypes, such as “The Fetch Quest”, based on the current goals and the requirements and potential outcomes of the archetypes. The goals and the quest generator are dynamically affected by the world state, so the generator seeks to make quests that are appropriate for the current situation.

The goal is to create a game that is fun and varied moment-to-moment, but that also offers a qualitative sense of progression, both in terms of getting better in the game and in terms of progressing in the story.

Potential future work includes developing a multiplayer version of the game, adding more missions, and developing a more robust quest generation system.

Games are back up!

Yay! I finally got around to hosting the game (and the prototype) on Dropbox so they are now playable again through the original posts.

TODO:

• Actually fix up the game so the player can choose between the "experimental" and "really experimental" story modes (currently a random choice indicated by 1 or 0 at the beginning of the game. don't remember which is which. good luck.)
  Meanwhile, you can play the "experimental" version here and the "really experimental" version here. The only difference is the quests you'll get: they are dynamically generated in the "really experimental" version.
• Publish posts I finished or almost finished but forgot to publish, like this one. Oops! (Turns out all the other drafts were either completely blank save for the title, or stubs with just a few words in them.)
• Dig up my capstone document and post relevant and interesting anecdotes from development and playtesting.
• Write a retrospective based on the original intended scope/feel of the game and the final capstone game
• Make game more better!

Broken?! :(

I just realized (well, ok, someone told me) that the game embedding has stopped working. I was hosting the game on my RIT home page, but since I graduated from RIT, the home page must have gotten removed. I will fix it shortly, after I find a good way of hosting a flash game distributed into multiple .swfs.
(And I'll also make a new clean final build of the game)

The almost kind of close to final game

Our capstone presentation is on Wednesday, and our game is pretty much done(except for bug fixes, minor changes, etc.) For my research hypothesis, I am once again looking for people to play the game and fill out a survey. There are actually two versions that I am comparing, so please remember what your "Test Number" is! It pops up after you start Story Mode. Oh yeah, the mode I'm testing is Story Mode.

After you play the game, please fill out this survey to let me know what you thought:

Theory: controlled nonsense is viral

Just a little more insight into my motivation for making a "connected mini-games game."

I think this phenomenon of viral nonsensical content is most prominent in video memes. Badger badger is one of the earlier examples of this; Narwhals is a newer, somewhat more nuanced song from the same author. In general, Weebl's Stuff is full of weird, surreal songs and videos that frequently go viral.
On YouTube, we find things like the Baman Piderman series, Don't Hug me I'm Scared, and almost anything by Don Hertzfeld (especially "Rejected").

In games, there are fewer examples, and almost all of them employ mini- or micro-games. Raving Rabbids raises a lot of unanswerable questions: Why are there crazy bunnies invading the world? And why are they obsessed with plungers?
Warrioware is a prime example of having a complete disconnect between the games and the events of the story, and both the story and the games are quite nonsensical. But I think that disconnecting the two completely takes away from the "controlled" part of "controlled nonsense," which seems important to me.
Perhaps the closest thing to what I'm trying to do in terms of nonsense/story balance is a free game called Keyboard Drumset Fucking Werewolf (gameplay video), which connects the crazy, weird mini-games into a crazy, weird story (that also matches the song the game is set to).

My theory about these "controlled nonsense" experiences is that they lure the brain into asking unanswerable questions. And since the questions have no real answer, your brain can't stop asking them, even if you do theoretically know that asking them is futile. Kind of like an earworm for the brain. The key, I think, is in the balance between the amount of nonsense to prompt questions like "but why?" and "but how?" and the feeling of underlying connectedness that keeps the player from dismissing the entire thing as, well, nonsense.

My goal is to make a game that keeps the player wondering not only "what the hell just happened?" but also "what caused this to happen?" and "what would happen if I did something different?" by providing many underlying systematic connections in a world that's on the surface divided into separate experiences. Hopefully, this will encourage them to keep re-playing the sequences in different ways to try to get a better feel for the systems that connect the mini-games.