I figured I might as well do a post mortem, or a development review/critique , of the process of making Super Monster Dance Party. I'll go over several different aspects of the development cycle, namely Team Forming/Brainstorming, Development, and finally Quality Assurance/Publishing. I'll give an overview of what happened in each stage, then give some suggestions on how to possibly improve the step for the next time.
**Warning- This is will be a long post. You have been warned!**
Here is a two sentence summary if you don't want to read it all: We set out to make a pseudo-rhythm game featuring various monsters destroying towns around the world. The development phase went smoothly, but we needed to allow more time for concepting and testing.
Team Forming/BrainStorming:
Overview: This stage went pretty smoothly.
Dave Troyer came up to
David Fuson and me and said he had a concept for a game involving a monster destroying city to music. It started out as a very simple, one button game where notes, or rings, would come in from the sides and you tap the button when the notes go through it. Over the course of around 30-70 minutes we had a more fleshed out version that had the possibility of multiple buttons, several monsters, and several different modes. After we had a stronger concept we recruited Corey Farmer to work on the songs for the game. The rest of the team were kind of picked up along the way, I'll go over that more in the development stage.
Suggestions: I don't really have any suggestions for this stage, it went really smoothly. If I really had to pick one thing it would be to establish an art style before work starts on the art assets. I think spending more time doing concepts to lock down a style will help reduce the amount of assets that need to be redone when the art style changes.This would also include concepting out menus, page backgrounds, buttons, and other aspects of a game that often get overlooked.
Development:
Overview: We started off pretty strong on this game. After Dave proposed the idea and we elaborated it a bit, I started prototyping the engine that would spawn the notes and had a working version within a couple hours. By that time, David Fuson had concepted out 5-6 different monsters and presented the art style he had in mind for the game. We spent the next couple weeks refining the art and engine. Due to certain limitations we ended up cutting the infinite mode, due to how
Construct2 handles loops. We also decided to reduce the amount of monsters from the 10 we originally had down to five, as well as the amount of songs.
This was where we changed up the team quite a bit. Corey decided he had enough on his plate working on our school project, and withdrew from the group. To fill the sound void, Dan Langford stepped forward and took on the task of making sound effects and music for the game. Since he was still learning some of the digital music software, he only had time to complete one song, as well as some voice acting. Since we were approaching our target release date and were lacking the amount of songs we needed, we resorted to bringing in a third party composer,
DJ SynthR, to supplement the missing songs. We also added Ben Mjelde as a backup artist to work on the buildings for the city.
Onto the art style and art assets. As mentioned before, partway through the development cycle we cut back on the amount of monsters the game would feature. We had to go through and pick the monsters we liked the best, and that had the most diversity stylistically, so they wouldn't all look the same. Once we got those decided on David started putting together the sprite sheets for the animations for Dave to set up in Construct2. Dave ended up redoing the monsters since the previous ones had some issues once they were actually put into Construct2. The only problem with that is that Dave and David's art styles are substantially different, where David was leaning towards the pixel art style with rough edges and shading and Dave had made crisp and shiny new ones. To alleviate some of the differences Dave worked some magic in Photoshop and got his pixelated. They still looked different, but not nearly as much.
Since a lot of effort was being put into the monsters to get them squared away, other aspects of the game were being ignored. We were still lacking a cohesive menu/button scheme, and till right up at the end we were running with the placeholder images I had made so I could set the pages up. These took till the day of release to get finalized, which is not the time to be deciding on layout styles for a game. As we got towards the deadline it seemed like trying to get art assets became increasingly difficult. What I mean by this is when an art asset needed to be updated with new information, or just a tweak to make it look better, there was some resistance to actually update them. I realize that they had already been made, but it should be expected that art assets need to be tweaked/updated. It is frustrating as a developer to be met with an exasperated sigh when we need an art asset before a major deadline, and then receive something that is vaguely what you had asked for.We did manage to get everything updated though, so that was good.
Suggestions: The major thing I think of is to diversify what a group is focusing on. For instance, instead of focusing the entire art team on getting monsters animated, have someone start working on the menus, page backgrounds, text, and stuff of that nature. That way we have more time to refine/redo those assets if we're not satisfied with them on the first go around. When it comes to redoing assets/code/sounds we need to remember that things will need to be adjusted, and just do them. This is especially true if the change would take minutes at most. Sure, you already did the work once, but the assets aren't finalized until the game has been released(And sometimes not even then!)
Another thing that would help the team is to don't take on more than you are willing/able to work on. This was a major issue when it came to our songs, we had the game very close to being done, yet we had no music(which is a major part of the game). It wasn't until several weeks into it that we found out Corey wouldn't be able to do the songs. If the team is relying on another team member to get them something, the team member should let the rest of the team know as soon as they can that a different person will have to work on it. This would avoid a lot of frustration for the remaining team. By all means, if it turns out you have less time than you thought you would have or something comes up and you can no longer work on it, then let the team know. We understand that things come up, but it should be brought up as soon as you know you can no longer work on it.
Quality Assurance and Publishing:
Overview: This portion of the cycle was entirely too short. Since it took so long to get the songs and remaining art assets we had very little time to test the game with all of that stuff in it. During this process we learned that each browser handles HTML5 different, especially when it comes to audio. Audio support for HTML5 is sporadic at best it seems. Part of the time sound would work great on Chrome, then others it would only work on Firefox. We ended up doing a lot of last minute testing right before we started the publishing process. We also should have tested the game on more types of phones, since apparently every Android device handles HTML5 differently just like a browser. We had the best results on the latest version of Android, and very mixed success on older phones. We also found out that there really isn't anything we could/can do to fix a lot of those issues, since the browsers haven't decided on web standards for HTML5 yet. If we knew Javascript we might be able to smooth some things over, but that is beyond our team's capability at the moment.
Publishing was quite a new experience for Dave Troyer and myself. We ended up spending around 4 hours going from exporting the game to actually publishing it to Google Play. We had crash courses on how to sign an .apk which is needed to upload to the marketplace. Now that we have the process down it should be really easy for future games, but it took a little bit to find a tutorial/explanation that was detailed enough for us newbies to figure it out. Thank you to whomever made this
tutorial over on Scirra.com, it was easy to follow!
Suggestions: Main thing would be to allow way more time for testing and to have a wider testing base for mobile. I think that would solve many of the problems that arose during this stage.
Project Overview:
Overall I think this project went pretty smoothly. There were a few hiccups here and there, but we did finish it. Main suggestions would be to: Know your limitations, be prepared to redo stuff, and allow a bunch more time for testing. I would also recommend a longer concepting phase, or at least not just focusing on the main aspects of the game. I feel that would help the game as a whole be more cohesive, and provide a clearer goal for the different teams to work towards.
P.S.: On a side note, after the release of the game we have had reports of features(mostly sound) that are not working correctly. These issues appear to be with how Android processes HTML5 and varies between different versions of Android. I apologize for the inconvenience. We recommend trying to get the latest version of Android. If we receive enough sales we might port it to Apple devices, which are supposed to handle HTML5 better, but that is farther down the road. Thank you for all of your support!
