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.