When I joined the project, it was already in development with three to four developers. I recovered from a period of depression and wanted to start development on a PBBG. I contacted the person I worked with 6 months prior after the second iteration of Mecha Asylum was a failed attempt. I wanted to get to work on a project that was complete and had active players.

What Went Right

1. Group project.Well, there were multiple developers working on the project, but that was a WTF? in and of itself. There wasn’t any version control, so there were some interesting instances of overwriting another’s work.

   It was an accomplishment to go from one developer working on a project to four and I still do think that is what I liked most about the project. It would have been better if all of us were intermediate to advanced level developers and used version control. I’ve rectified the situation in the present to prevent the failures from occurring again.

2. Active player base.I enjoyed entering the development with an active player base. It helped with the motivation to add and fix features for them to play. I think it speaks a lot that people will play any game or give any game a try, just to waste a little time. It gives me hope that at least someone will play my game, if it at least functions.

What Went Wrong

In the case of Robot Warz, we were developing portions of the game live, so a player could, if they knew where to look play the parts that were being worked on. It also meant that some portions of the game could suddenly stop working, when a missing semi-colon or another bug was inevitability was introduced.

1. Administrators and developers played the game also.The game playability must protect the boundary of fairness, whether real or perceived. In the case of this instance, it is a gray area, because the administrators didn’t cheat. However, they could have and to the player it means nothing if the administrator could easily with a click of the button give themselves more money than any player in the game.

   After thinking about it a great deal, if you are going to develop the game, then the other players shouldn’t know that you are an administrator and if you are, then you shouldn’t have access to play the game. Administrators, if they want to play the game, should have another account to do so with the same access as the rest of the players.

   Ethically, an administrator probably shouldn’t play the game at all and should be completely separated from the playability to be as neutral as possible. If an administrator crosses that line, then feelings might be hurt when a decision was made against another player, because of an in-game alliance. Whether or not the administrator made the decision based on that is irrelevant to the player and would cause to destroy the fun factor of the game.

2. There wasn’t any version control.I remember implementing a feature and bug fix four times, because every time the file was overwritten by another developer who didn’t download the file from the server. It was only resolved, because I contacted the developer who was doing it and told him the situation. If version control was used, it wouldn’t have mattered, because his changes would have been merged with mine and resolved.
3. Security, what security?When I joined the project, register globals was used throughout the code base. I had to inform the other developers about super globals. I also spent a great deal of time going through code and updating the code to use the correct super global. I should also mention that in all fairness, the project was based off an open source browser based game engine that had these flaws inherent in the code. It might not have been the complete fault of the developers on the project.

   Validation and sanitization was only added when an security hole was already being exploited. Therefore, it was more of a cat and mouse game of patching holes after the hacker exploited it. There were also too many areas in the code that had to be patched to prevent future attacks. I wasn’t much of an security expert, but you don’t really need to be when all validation and sanitization is programming common sense.

   It is difficult to take much from the project, but when you have your name associated with a project that has a magnitude of attack vectors, then you pretty much have to take it personally.

4. Disjointed game features.The game features were developed separately from other developers and also separately from the original game purpose. I think I added a farming feature, because it “would be cool”, as opposed to matching the rest of the game playability. Yeah, I didn’t really get the whole game design concept and planning games at that time.

What I Learned

I learned the importance of version control and I’ve used it every since, even when I’m working by myself. It was the first time, I really seen an importance for it. Actually, I didn’t know about version control at that time, but I thought there had to better way to prevent events like when my file was replaced from happening without having to create a copy to ensure a backup was saved. I’ll learn the name Version Control and Subversion, 8 months later while working on Astrum Futura.

Security is important! The crackers that attacked the site, really expressed the importance of sanitization and validation. I’ve since practiced a great deal with making sure that I always code projects around a paradigm that includes those two. It is easier to sanitize and validate when first coding the project, then it is to react to attacks and fix security holes retroactively.

I’ve also learned that games tend to play better, when they’ve been planned and the game features flow together. When you add features, because they are cool and not to complement or extend the current game base, then you create a patchwork game that ends up confusing the player. For example, if you are going to add a pet, then make sure it isn’t for a robot game.

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 money

   The 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.

What Went Right

A few decisions that I made early on helped to get Rawrmy “on it’s feet”, for all that there were some setbacks during development. One of those decisions was to use Django, a popular Python web framework, to develop all of Rawrmy’s functionality. Django is geared towards rapid development in the same way that Rails is; both frameworks lend themselves very well to getting something out the door as quickly as possible – which was one of the goals for this contest due to the compressed time frame. Straight out of the box, Django gives you a pre-wired authentication system and admin backend – both of which were immensely valuable during initial development.

Another decision that helped ease the development process was a bit of a harder one to enforce: every feature implemented was droppable. What that means is, for any feature I was developing, I’d set a timer. If it took me longer than an hour or two, the feature got dropped – although I marked it as “come back to later”. Doing this allowed me to trim the fat out of Rawrmy, and focus only on the pieces that would get it to being a finished game the fastest.

What Went Wrong

Time was a massive factor that prevented me from completing Rawrmy. In hindsight, I probably should have taken some time off from my day job, or diverted time from some of my other projects – Rawrmy is unfinished because I was unable to devote as much time as I would have liked to to developing it.

Some things took too long. While I mentioned earlier that every feature was droppable, it was only after I had sunk a few precious hours into a specific(and still broken) feature that I realized I would need to enact this rule. If I had realized how much time I was sinking into non-valuable features at the time as opposed to afterwards, I probably would have had a lot more time to spend on getting the game working(and less time spent chasing down random bugs).

Lack of direction was a problem with Rawrmy. I have to admit that when I first decided I should enter the contest, I didn’t have any idea what I would build a game based on – and I believe this was one of my biggest problems. John Munsch had clearly been planning out his idea for ‘Big Villain’ for quite some time, and was therefore only waiting to do the development on his game. Multiple other entrants were also in the same position; the fact that they had already planned out most of their game gave them a massive advantage, because they could get started developing while I was still attempting to come up with a concept for Rawrmy.

When I initially entered the contest, I also had a team member who would be creating all of the written content for the game. However, after a week or so, my partner disappeared – and I still have yet to hear from him. This was another setback; the initial idea for Rawrmy was heavily text-based, and while I’m sure that I could have written the content myself, it would have distracted me from getting the game running and polished.

What I Learned

When you’re entering a contest with a short timeframe, you need to have a firm idea of what you’re going to build – it doesn’t neccessarily have to be large, but you need to have that idea and stick to it. Changing gears in the middle of a project will kill it – Rawrmy lost a good week or so’s worth of development time when my partner disappeared.

When you enter a contest like this, you need to be prepared to make the commitment. You need to be willing to commit development, monetary, and any other resources neccessary to get your game done – and while I was able to half-commit on most of those things, it’s not enough. The next time I enter a browsergame contest, I’ll make sure that I’ve got my other projects cleared out of the way for the duration, and can therefore focus only on the contest – instead of getting distracted by other things.

All told, I had a positive experience entering the contest – even if I had to drop out at the end. I learned a lot about my own development practices, and what I can do to improve in the future – which is enough of a win for me.

If you’re interested in seeing what Rawrmy was like, you can check it out at rawrmy.com.