Postmortem: Mecha Asylum

The time span of Mecha Asylum was three months, from development to completion, and not including planning. The planning stage consisted of several posts hashing out the ideas that would be implemented in the game. There wasn’t much of a debug stage, I lumped that in with the development.

The cycle was prototype-develop-test, which allowed for a somewhat rapid prototype to finished product. The issues with this style will be addressed later. When you are one person, developing a complex game, any sort of direction helps.

This iteration was the third of the Mecha Asylum rewrites. Well, that isn’t completely accurate, the first two iterations were unusable and early PBBG research projects. The first two working and completed iterations of Mecha Asylum did allow for specifying the direction of the current one.

What Went Right

1. Separation of presentation from business logic.Well, the earlier incarnations also separated the presentation from the business logic, but this was the first time I used an actual template technique. While it worked, it allowed for better focus on the view, and followed more of the MVC pattern. Not strictly, but MVC tends to be cleaner, because the majority of the logic is outside of the template.

   It allowed for focusing on the code, where it should be and added needed organization for easier debugging later.

2. Game was completed on time and well was actually completed.The other versions weren’t so lucky. With the other permutations, it felt as if the flow of the game was disjointed midway through development. Even though the final product in this iteration ended with the same result, it wasn’t apparent until development was over.
3. Basic attempt at achieving intelligent moneyThe concept, I believe, was noble in that the player would be based on a more random calculation. So instead of being able to easily predict what they had to do to quickly advance in the game, it would require more time and effort.

   Well, in theory, and if it had worked. Players like a bit of unpredictability, but it is hard to say whether players would have enjoyed this feature. When it comes to cash pay out, unpredictability makes sense in the case of a stock market like feature, but it might have been very annoying in retrospect.

   It is easy to take the theory of unpredictability = fun to the extremes, but players know what is fun and what isn’t, so it is better to let them decide. It is also better to also remember that while new ways of doing old tasks can be better, it isn’t always the case.

   I thought the concept was a success and the game never had any active players to find out if it actually was a success or failure.

4. Left out the kitchen sink.The very early iterations tried to include the kitchen sink and shifted the direction of the game to where none of the features were completed. I tried to focus on the features that were planned and left out the features that would be nice for future versions.

   It is too easy to put down this feature or that feature and when you try to include team features, it can become time consuming. Although, in all of the iterations I’ve never reached the stage when team features could even be considered.

What Went Wrong

1. Template technique failed to work on later versions of PHP.The template system worked well with version of PHP that I tested the site at the time. When I visited the site 6 months after development was completed, I found the site no longer was functioning. It appears that either a bug was introduced to break the site or a bug was fixed that the template system was dependent on and I didn’t notice it.
2. Early attempt at primitive artificial intelligence for calculating money was flawed.I thought it was call that the system in place for calculating how much money the player made was based off of a generic sequence. If it had worked, it would of made the game somewhat more unpredictable and I would have hoped more fun because of it. In which case, the only reason the player still had anything was, because there were checks to ensure that the player never passed the minimum threshold.

   In hindsight, it probably would have been easier and better to just not rely on such a complex system for calculating something as important as the payouts for players. At least, not with an incomplete AI system.

3. Game was far too complex.The game was so complex, that playing the game after it was completed left even me confused on what to do. The game lacked focus, and that is partially what makes a game fun. It lacked the fun factor, because it made the player think and do too much.

   Some people like complexity, but to better define it, it would be to say, they like to micro-manage their game details. There wasn’t any micro-managing, there was barely anything except forms for doing things without any apparent purpose.

4. The game lacked a seamless flow.Along with #3, the game lacked an inherent seamless flow from task A to task B. In games that I’ve enjoyed, you knew or didn’t have to go far to figure out how to perform the needed tasks to advance in the game. That is difficult to achieve in game design and development, but it would have been worth investing another month or two of polish to pound it into the game.

What I Learned

I learned that playability and fun factors aren’t decided by me. When you develop a game for yourself, then only you are going to be playing it. A game must combine elements that will be fun for other people. In that you must design and develop for the entertainment of others.

Whether a player will find the game entertaining or a flop is ultimately to be decided, but thinking about them is the first step. The next step, would be to allow a select group of players to test the game and give feedback on what they honestly think of the game. If you have your friends do it, then they might tell you what you want to hear, instead of what you need to hear.

It is important to have a group test the site for playability as well as beta test the site. When you beta test, your concern is whether or not the site functions as you intended. When you test for playability, you are testing whether or not the game is fun. If those playing the game don’t think so, then it is not.

Simple is better, in the early stages of the game and early versions. When the game advances and players start demanding certain features, then go in that direction. Too much time was spent on features that I liked, but not necessarily what the players would like. When I do it over, I’m going to develop a subset, do those features very well and then go where the players take me.

While this iteration of the game worked out better than all of the previous permutations before, it was still a failure. The next iteration will build off the failures and successes of this one. If all goes well, I’ll have another postmortem before the end of 2009.