From the doc: Post-mortem: What went right, what we learned

What went right

Using Flash

Flash / ActionScript is a very high-level language, which saved us a lot of work in developing the low-level minutiae of how the graphics, events, file management, etc. in our game would work. Thus, we could devote much more time and effort to the design and development of the gameplay systems.

ActionScript3 is also a very flexible language. It is mostly an object-oriented language but also has some interesting functional language features. We could pass callback functions and even use classes as objects. AS3 allowed us to design lots of flexible systems, like the Quest system and the Interaction system. These systems look much more elegant and were much easier to develop than they would be if we had to simulate these features using a more restrictive language.

Using Flash also made it very easy to show off and test the game. We could get people to playtest the game over the internet, without having to gather large groups of people physically or to bribe them with food in exchange for playtesting (although we did do some of that, as well).

Connected Mini-game Concept

The concept of connecting mini-games into stories proved to be fun and interesting. Players enjoy exploring the world and seeing how the mini-games connect into silly, abstract stories. The fact that the stories don’t always make complete sense does not deter players. They enjoy the nonsensical aspects of the game.

The connected mini-game structure allowed us to build a game with no fail states, a game where players get a sense of progression and exploration without having any explicit levels, progress bars or character statistics. Players at an RIT event spent an average of around 24 minutes playing Micro Missions, because they were interested in exploring what comes next and what other new things they can acquire or experience.

Architecture Design and Focus on Architecture

The game architecture implemented for this game, specifically the Interactions and Interaction chains architecture, is simple yet powerful. It creates boundaries that can be easily machine-readable in the future, whether for Level Editor or AI purpose. Yet, it also allows us to create very flexible and interesting gameplay sequences.

Focusing on architecture first and content design second proved to be a good choice: although it took us longer than usual to start getting a playable experience, the resulting architecture allowed us to create that content very quickly, and integrate lots of different content from different authors into one cohesive whole.

Undergraduate Team Members

At the beginning of the project, Yana was the only graduate team member. All of the other team members in Winter Quarter were undergrads who wanted to participate in the development process just because they thought the concept was “cool.” Although all of these undergrads were getting at most two hours of credit per quarter for this project, and they were all busy with their classwork, they came together and worked hard to make this game happen.

Geoff Landskov was particularly instrumental in designing and helping develop an architecture that fit the design of the game, not allowing the scope of the architecture to creep up, and giving expert advice on Flash and ActionScript.

Dynamic Quest System

The Dynamic Quest system is successful in generating quests that fit into the game’s flow and fit the game’s tone. Generating quests from archetypes is definitely a viable idea that warrants further exploration.

Mini-games and Separation of Labor

The structure of the game–modular mini-games connected into stories–allows for much greater separation of labor than most game structures. This design enabled Farhan to jump in during Spring Quarter and make significant contributions to the project, even though it was already well under way.

This separate, yet cohesive, structure also allowed Farhan, as well as anyone else who’s ever worked on a mini-game or even discussed the game with the team members, to contribute to the eclectic design of the game. Everyone’s silly and crazy ideas fed off of each other and came together into one strange but cohesive whole.

Mini-game Jam

The mini-game jam was fun, generated lots of mini-games, and allowed us to test and polish our architecture and APIs! More here.

What we learned 

Connecting mini-games into stories is an interesting and viable design technique, which should be explored further. However, this technique is very prone to confusion. Although some of this confusion is desirable and is part of the fun, a lot of the confusion can and should be mitigated by careful design of feedback structures.

The parts of the game that really need to make sense to the player are why certain things are happening, what effect they are having on the game world, and how the player can affect them. The storyline of the game does not need to make sense, but the gameplay does.

From the doc: Post-mortem: What went wrong

Using Flash

Although ActionScript is a convenient, flexible high-level language, it also has its share of quirks that trip up the rapid development process.

Flash’s handling of variable scope in anonymous functions created some very interesting bugs that took a while to diagnose and fix. Random quests and interactions seemed to use completely wrong characters for no good reason whatsoever.

Although we used Flash Develop to make and compile all of our code, we had to use the Flash IDE to create all of the graphics for the game. The IDE crashed much more frequently than it should have. For a series of files, the IDE consistently crashed when the user was done editing the files and tried to save them. Aside from the stability issues, Flash is a very odd tool to use for graphic creation. It tries to be both vector-based and pixel-based at the same time, and does not fully succeed in either.

The Flash documentation proved to be inaccurate or vague several times. Tracking down assumptions made on the basis of this documentation and realizing they were wrong was a time-consuming and frustrating process.

Time Constraints

There is never enough time to complete all of the features and polish that are on the ever-growing to-do list. We did not have time to replace the stick figure art with more detailed character art. We also did not actually use many of the sound effects or music created for the game, simply because we ran out of time.

For a game made out of mini-games, the amount of content–mini-games, items, characters, missions–is very important. Although we created enough content for about 1-2 hours of gameplay, even more content would have been even better.

We also ran out of time for polishing the game and finding and eliminating points of confusion, or lack of direction.

Game is still confusing

Micro Missions is a hectic and confusing game. A large part of this is by design, but certain elements of confusion subtract from the experience and make people less willing to explore the game.

Interaction Flow

Players were often confused by the flow of events and interactions of the game, the consequences of certain events and actions, and the next steps the players were meant to take in order to progress the game. The game still needs a lot of feedback on what just happened, and why.

Quest System

The quest system also proved to be somewhat confusing, especially in the context of an already confusing game. More feedback about what quests are active, where to go to complete them, and when quest-related events are happening is needed. The current implementation of the Quest System, which uses character relationships to generate quests, is also not clear enough. Players were confused about why they had to perform certain tasks for certain NPCs, and not many people seemed to get the idea that the quests actually stem from dynamic relationships.

Architecture is sometimes too simple, restricting

The architecture worked really well as designed for most purposes, but it did not fit all of the situations that we wanted to develop for the game, so sometimes we had to cheat or bend the rules of the architecture. The Interaction structure does not allow for optional inputs that can sometimes be omitted, so we had to pass dummy inputs in some cases. It also does not allow for arbitrary numbers of inputs, such as passing in an arbitrary number of goals to the Quest Generation Interaction, so sometimes we had to bypass the input system altogether.

Perhaps the most noticeable example of “cheating” the architecture is the sewer-traversing Pac-Man-like game. In it, encountering a slime starts a new fighting mini-game. Beating the slime brings you back to the same spot in the sewer mini-game. The Mini-game architecture does not allow for the pausing or interruption of mini-games and being able to come back to them later. In order to make the sewers work, we actually had to embed a copy of the fighting mini-game inside the sewers min-game and pass all of the fighter data to it manually, and manually process the output.

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)