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.
No comments:
Post a Comment