I posted the following on the Card Kingdom development blog.

What I did

For this version of Card Kingdom, I worked on updating core engine components with some optimizations and cleaner code, refactored the serialization pipeline to be more robust with prefabricated objects, or prefabs as we called them, added an “editor mode” that supports in-engine particle editor and run-time resource reloading, and replaced the old forward rendering system with a new, more advanced deferred rendering pipeline that supports multiple post-process effects.

What Went Right

Team

Again, the team just works really well together. We all play off each other’s strengths and fill in each other’s weaknesses. We just have a great time making games and I believe it shows in this version of Card Kingdom.

Process

This time around, prototyping and iteration played even more essential roles in our process. Starting out, we refocused the design on what we wanted the game to be, iterating and refining the experience we actually wanted to present. Having multiple people work on the prototype helped immensely as new and, at first, farfetched ideas could be tested, refined, and tested again in a short amount of time. We also started using Trello, an online organization and collaboration tool, to assign tasks, list bugs, and track the progress of featured that needed to be tested in the prototype, implemented in engine, and finally reviewed for completion.

Testing

The one thing we did not do enough of for the last iteration of Card Kingdom was user testing. This time around, we did not want to fall into the trap of assuming the game was fun. We put a great deal of effort into a play testing session involving a large group of users with various backgrounds in games. We were also lucky enough to have some users in our target demographic play and give feedback. The results of the sessions really brought to light what was right with the build and what just didn’t work. One example of this is that there were actually two types of shields, one that was horizontally weak and one that was vertically weak. In testing, the horizontal shield was deemed useless as most people spammed the horizontal attack button and did not notice they were actually breaking the shields, thus added no reason to keep them. The play session was also a huge confidence boost to the team as many people really enjoyed playing and gave useful feedback.

What Went Wrong

Scope

Even though our team motto is “scope it down,” we fell into the rabbit whole that is over scoped features. This was mainly prevalent in the types of enemies we wanted to show in the build. We planned for and prototyped more enemies then our character animator could keep up with. I think this may have just been a lack of necessary personnel to produce assets at the rate the prototyping and engine teams were going, and not a lack of effort on the animator’s part. Going forward, we should take into account the amount of work that needs to be done on all fronts for a feature to be completed and make sure one group does not get too far ahead of another.

Schedule

We had a hard deadline to be done by, which is good, but we did not schedule our time leading up to the end effectively. A schedule of tasks was mode, but it was haphazardly put together late and not followed by the team. Even though Trello helped us organize our tasks, we started using it rather late in the process and did not use it to its full potential.

Conclusion

Overall, I am incredibly happy with this version of Card Kingdom. We took what we learned from the first version of the game and put it to good use, creating a fun, engaging, and polished game that I am proud to be a part of.