This semester, in conjunction with Smilegate, Project Crescendo created a classically themed music/rhythm game complete with five playable music pieces and the five hardware devices used to play the game.

The following is an evaluation of the process the team took to create that game.

What went right?
One of the biggest successes for project Crescendo was altering the means by which we read and created gameplay by using midi data. Prior to this conversion, our programmers read sheet music and by hand, entered events into an XML document that matched the pitch and timing of the music. This process was extremely tedious, very prone to error, and the document was not easily changeable. Luckily we were pointed to a tool that parsed midi data and converted it into XML. This gave us the exact timing and duration of note events within our music as well as information about the tempo and during play, our location within the piece. Having the XML in this format also allowed us to more easily edit the fingerings for note events through Excel. Using simple equations, we could determine how the pitch was changing from note to note. We used this to design our fingerings to match those pitch changes so that playing felt more natural and intuitive; more like playing real music.

The team cited our focus on user interface as another area that contributed to the success of the project. Throughout the semester, team Crescendo remained very focused on providing players with a specific experience. From the very beginning, as requested by our client, our intention was always to provide players with an experience that felt like playing music in an ensemble. With this in mind, we put a great amount of time and effort into finding the right user interface for our game. We designed many different interfaces, but in the end we kept coming back to a horizontal interface because it more resembled the act of reading music from a page. When we had push back from our client to try out different interfaces and types of gameplay, we put in the effort to try out their suggestions and prove that our designs were working. Having testing results that proved our horizontal user interface worked was very important to us.

Project Cresendo credits much of its success to having regular contact with its client, Smilegate. We met with them by video on a weekly basis. They were extremely supportive of our efforts. They encouraged us to do more and experiment with new ideas. Being able to bounce ideas off them and get feedback on our direction was valuable.

The lowest point in the semester for project Crescendo was our halves presentation. We’ll come back to that later, but what the team did right, was learn from this failure. We took a hard look at what behaviors had brought us to failure and what behaviors would help steer us toward success. This was a complete change in mindset. The entire team had a fire lit under them. We decided to work harder and recover.

It was at this point that we realized we needed to start pairing down own ideas, kill our babies, and really get down to what was the heart of the game. In the weeks after our half presentation, we turned away from many ideas that we had so ardently clung to at the beginning of the semester such as improvisation and a story. Making these tough decisions was a big step toward success.

One of the best changes we made during this time is that we began playtesting daily as a team. These tests allowed us to evaluate our progress on a daily basis. It gave us a chance to really look at the game and identify problems with design, gameplay, and art. It ensured that every day we were working to test something.

During this time we also did many external playtests as well. Just having another set of eyes on the project, a fresh perspective was very helpful in identifying features that just weren’t working as intended. We tested with many of our fellow ETC students. They were able to give us a very academic perspective on our game mechanics. And, we also tested with children within our demographic who gave us hard evidence of what worked and did not work with children.

What went wrong?
We did a ton of playtesting, but unfortunately it was almost entirely after our half presentation. Its reasonable to assume that the weaknesses of our demo at halves were a direct result of not regularly testing our game. After halves, this left us playing catch up. Our first playtest with our demographic wasn’t until after week 10! At that point time was so tight on the project, that we were only able to arrange one other playtest with children in our demographic. Our game, meant for children ages 5-12 years old, has only been played by a total of four people in that range! Just four. This definitely shows in our final product, as the game is still very difficult for very young children. Much of the hardware is unusable by very young children. It is definitely not easy to pick up and play, something that our client requested at the beginning of the semester.

To their credit, Smilegate gave us a ton of flexibility with the project. However, at the beginning of the semester this was definitely a problem for us. The team spent far too long brainstorming. In the first weeks we built a couple of working prototypes to get started. Unfortunately we became enamored with the simple, improvisational gameplay of our garden prototype. In the weeks leading up to quarters, our design meetings were largely spent discussing ways to incorporate elements of that prototype into a larger game. In fact, many elements of that prototype remained in our designs until our awakening after half presentations. The time we spent churning up ideas could have been much better spent actually developing something.

While making the move to parse midi data was one of our greatest successes, we ought to have made that change much sooner. We saw the writing on the wall. We knew that midi data would make our work easier, but we were unsure whether the time spent to make that change would be worth it. We were already so ingrained in our other method. However, we were wrong. Making that change sooner would have saved us countless days of work earlier in the project.

Ultimately many of the project’s early problems stemmed from lackluster leadership. When the time came to make decisions about design and scope, no one stepped up to make a decision. This left the team spinning its wheels for weeks. Additionally, this resulted in vague programming requirements and slowed down the entire process. As the semester went on, we had to change or else risk complete failure.

Conclusion
The team decided to rate our success based on two criteria. Is the game fun to play and is our client satisfied with what we created.

To the first point, the game is very fun to play. Players love competing against each other and themselves to get higher scores. And, even though children find the game challenging they still want to come back and play again and again even when their parents are asking them to stop. The game is definitely fun and engaging of our intended demographic so in that respect we were successful.

Our client is very pleased with us. They were highly impressed with everything we managed to accomplish this semester given the massive scope of the project. We’re very excited that they are pleased enough with us to invite us to their headquarters in Korea to give a presentation to the company about our project. And, as if that weren’t enough they’ve also decided to continue the project for another semester with the ETC, this time to take the prototype we created and bring it to the quality level of a commercial game.

The scope of this project was immense. Not many project need to develop across so many disciplines. That said, we are very proud of everything we’ve accomplished. We successfully had all five instruments and all five pieces of music working with the game, just as we planned.

Using the two measures for success mentioned before, we as a team feel that this project has been an outstanding success. Not only were we successful in a number of different areas, but our response to the failure we had at halves was incredible. We pulled through in the end and the success we had is a testament to our performance.

Elapsed Time: 15 weeks
Team members: 6
Platform: Windows
Engine: Unity3D