Capstone Game Post Mortem: Avalanche Adventures

Game Summary

Title

Avalanche Adventures

Genre

Action / Arcade

Platform(s)

Android

Revenue model

Free to Play

Development tools/Language

Unity

MonoDevelop – C#

Game audience

15-25

Team

David Laws – Project Manager and Production

Nick White – Sound Engineering

Jack Einhorn - Artwork

Copyright/Reference

Avalanche Adventure © 2015 David Laws

Backstory

Sound Bite

“Smash the falling icicles and feed the hungry penguins”

Executive Summary

Avalanche Adventures is an arcade style game that takes after old shoot ‘em up games in mechanics and playstyle. It follows a fixed movement build where the player-controlled character is locked to horizontal movement along the bottom of the screen while icicles fall down towards you. The player has to avoid or use their special ability to break the icicles. Breaking the icicles allows you to gather crystals, eventually powering up your hookshot weapon to take a shot at the boss character.

There are two playable characters, Edmund and Cinder, each with their own special ability. Edmund throws pickaxes in the air while Cinder is able to summon fireballs.

Inspiration

This game draws inspiration from classic shoot ‘em ups as well as a number of other games with similar mechanics. The goal was to capture that classic arcade feel of a simple game that was just fun to play.

The artwork was inspired by the artistic styles in games such as Alien Hominid and Castle Crashers.

Ideal

In an ideal world there is plenty that I would like to do with this game in the future. I think there is good potential for an adventure mode that reuses the same mechanics in a more story-oriented environment in the style of platforming games. I think there is also a lot more that could be done just in the arcade mode, improving gameplay and balance in particular.

Ideally I would also like to take all the lessons learned and the design improvements to this game and start from scratch with a vastly superior idea of where I wanted to go allowing me to improve the overall quality of the build from start to finish.

The Critique: What went right

Design & Aesthetics

Overall I was very happy with how the music and art assets turned out. I was able to get in touch with my team very early in the process and that helped greatly in getting the initial wave of assets done in a timely fashion. Everything was custom made for this project so I am glad it turned out well.

Project Management

During the initial development phase of the project I was able to keep to the schedule quite well. Sprints were completed in a timely fashion and doing weekly screencasts for the project helped to keep me on task as well. Additionally I think getting the team put together and working quickly was good.

Development

I think the game itself had a lot of good parts too it. The gameplay is fun and I think it was ultimately successful at reaching the goal I had for it. I think the tutorial was well executed beyond what my initial expectations were and I think the overall look to the UI went well.

Additionally I was quite happy working with Unity, the development environment and object based design was a blast to work with and made it much easier to visualize how the game and code would all piece together in an actual project.

The Critique: What went wrong

Design & Aesthetics

One of the problems with having everything custom made for this project was I could not really fall back on the Unity Asset store for help when needed. Since my team was on a volunteer basis so there was a limit to how hard I felt I could lean on them to get things done.

Looking back I would have liked to delegate the work better and I think I could have given them better direction to make their jobs more efficient. As it was I took on a lot of the responsibility myself and I think this added to an already heavy burden of work.

Project Management

I think the primary thing that went wrong with the project was the lack of good planning that went into the project. The initial ideas were good but scattered, and they lacked a lot of depth that left the game feeling incomplete after the initial development phase was over. This necessitated a secondary development phase to be completed. While I believe it was ultimately successful a loss of motivation and poor upkeep of documents made this overly difficult as well. All of this could have been avoided with better upfront work.

Further, as I mentioned before the sheer workload was something I found overwhelming. I think this was at least somewhat a side effect of the planning issues, but knowing when to delegate and not take on too much at once is important too.

I would attribute a lot of these management issues to my inexperience in performing this role, so my biggest lesson moving forward is the importance of planning ahead. Knowing what you need to accomplish, what you want to accomplish, and what you can accomplish are very important are very important to successful development. As well as keeping up documentation and iteration of said plans so you can be adaptable when they inevitably change.

Development

I think my development issues stemmed a lot from management issues, particularly the patchwork nature of the code. After the initial development, and even to some extent during that phase, things were done one at a time with not enough regard for what comes next or how the big picture fit together. This ended up creating intricate webs of processes that made maintaining and eventually updated the code difficult.

Looking back I think my inexperience with Unity also led to some of these difficulties. Instead of searching for a more elegant solution to a problem, I would often attempt to brute force my way through it, and probably creating unnecessary mess in the process even when successful. I think general experience with the environment can and will go a long way into fixing this issue.

Finally balance was always difficult with the game. I think the simplicity of the game as well as its reliance on RNGs contributed to this issue. Because the icicles always move in a straight line the balance between too easy and too difficult was very fine.

Testing

Testing was difficult in general because it all had to be done manually. Automated testing was nearly impossible due to the structure of the game, as much of the code and game objects were intricately woven so testing them individual pieces was next to impossible.

Manual testing also proved difficult due to the game playing differently, and eventually being unworkable, on the Unity editor as opposed to on an actual device.

This made testing later on a lot of trial and error guesswork.

Summary

Overall I was satisfied with how the game turned out. Certainly I would have liked to go more smoothly, but the final project was a pretty solid iteration of the initial design. Moving forward I think there is still a lot of work I can do, from adding the “adventure mode” to overhauling and/or improving the current mechanics featured in the “arcade mode” of the game. It has been an enjoyable experience and most importantly there are a multitude of lessons learned that I can take forward into future projects.

References

Easy Touch 4. (2015) Touchscreen & Virtual Controls. [Unity Plugin] https://www.assetstore.unity3d.com/en/#!/content/3322

Laws, D. (2015). Avalanche Adventures. [Android Application]