Looking back on the release of Spring It as the producer I can see a lot of things we could improve upon. I want to talk about those things here.
Pipeline Lessons Learned
Awhile ago I look a look at the time we spent on each aspect of the project to look for inefficiencies and to improve our overall decision making process. The biggest two inefficiencies was a lot of wasted time on art assets and programming features that were created but never used. Both of these problems stemmed in part from a poor design direction regarding everything besides the core gameplay loop, and the other part due to not play testing enough.
First, the art issues. We had Bongi model up objects whenever we decided to start working on a new feature. There was not approval process, and very little direction to how the object looked. This lead to tons of models being completed just for us to say we don't like they way they look. This was not an acceptable use of our limited development time. To solve this, we first started requiring all art to have concept art first, to then be approved by the team. This saved us a ton of time and from that point forward we had only minor adjustments to our models.
Secondly, I implemented a few features, like the Level Select screen or the trap conveyor that we never actually ended up using the code from. We also learned that a lot of the features were not as fun to use as they could be. We were not running playtests as often as we should have been and we were not planning around playtests with our development. Once we started focusing on playtests, and what we could learn from the playtests, we were able to have clear goals for each development cycle. This meant, as a programmer, I was only focusing on the most important thing as each step of the project. For all future projects, I will be much more playtest/milestone focused in my sprints and planning. Additionally, art will only be added after a function has be internally playtested and approved and concept art has been approved.
The project started out as a very scrum like tracking system with the meetings as well. This was too cumbersome for us so it evolved significantly over the time we were working on the project. I still kept track of hours, and we as a team estimated the hours but the meetings we had changed dramatically. Instead of being scrum meetings, we just had a team meeting to discuss all aspect of the project once a week. This proved to be more useful to us than scrum meetings twice a week. We really did not have enough time during the week to make measurable progress to constitute more than one full team meeting a week.
Google sheets was the tool I choose to use for the first scrum tracking, but I am thinking using something closer to Trello.com would be easier for all future projects. I recently started using favro.com based on a talk at GDC, and I plan to implement our next games tracking using this. The main reason is because we really lacked a way to tell each other when to test each feature, and a lot or the time our internal testing was sub par. I plan to use the not started, doing, testing, done categories that trello and favro type systems strive in.
Post Completion and Release
One of the things I knew the least about going into this project was the marketing and release aspects of the game. The game finished over a month ago, and due to some procrastination and self rewarded relaxation we are only just releasing the iOS version now. The approval process and the materials required for marketing take a lot more time than I originally expected. The good news is that I now more about how to plan for this time, and the approval processes for the various distributors. I know now that there is still a large amount of work that needs to be done once a game has been completed.