Edge of Winter Postmortem

Edge of Winter Post Mortem

by Ed Dearien (Game Designer and Producer)

Edge of Winter is a 2D, procedurally generated, endless runner designed for Android tablet devices. Players take control of a fairy named Anora as she travels down bumpy slopes bringing the first day of spring to the snowy world. The player's main objective is to achieve the highest score possible by gathering energy orbs and surviving as long as possible on the slopes. Along the way, players must dodge a number of obstacles. These obstacles range from rocks and logs which line the slopes, to large chasms; quirky Yaks and some large imposing towers. As players travel along the slopes, they traverse through a simple, fairy tale-inspired world. Geometric mountains, trees, and clouds, along with cozy little homes give life to the world.

What Went Right

Quick and Swift Design Changes

Something that the team was proud of was our ability to adapt quickly to drastic changes to the design that we all deemed necessary. Our initial pitch (a side-scroller puzzle game with the focus on touch) was nothing like what we actually ended up with (an endless runner), and this was due largely to the team’s ability to recognize a change that would better the game, and quickly make necessary adjustments to accommodate that change. The changes definitely worked out better in the end, and allowed us to learn from our mistakes and see our new ideas come to fruition.

Different Specializations Helping Each Other

Having a small, four-person team was great in that everyone was able to offer assistance when needed. Our level designer was able to give valuable suggestions to our programmer and artist about different concepts to try out, and the low-risk nature of being in a school environment gave us the opportunity to try out different design methods that could not have been possible for us to do otherwise. I was able to do some art, programming and level design. It was a great experience for everyone to come together and be able to try out new ideas.

Scope

Because of the entire team’s inexperience, (this was the first game any of use worked on) we decided to take a slow approach to design, and assure a relatively polished product by its completion. Our meticulous approach ended up paying off in the end, as we had a polished product with very few bugs. We played to the team’s strengths and weaknesses. Cohesively, we designed a game that both was fun to play, but also was not out of the ream of our own personal abilities.

What Went Wrong

Personality Clashes

One of the biggest issues that plagued our team was personality clashes and the inability to deal with them in an efficient fashion. Each person on the team had a strong personality, some of which clashed. Luckily, we were able to identify some of the communication barriers we had and were able to resolve them. Unfortunately, this was not addressed until near the middle of the eight-week development cycle, which in-turn lost us valuable development man-hours. Catching and dealing with these issues early on could have saved many hours and allowed for more iteration in the design process in general.

Disagreements on Design

Near the middle of the Alpha milestone, a team member suggested a new feature to implement. This feature, while truly a great idea, had terribly unfortunate timing (being near the end of development). The team member was adamant that this idea be implemented, and they very much wanted to see this feature creep into the game. Unfortunately, this feature could not be worked into the schedule because of the current workload we all had. This is a specific example on how a disagreement on design can work itself into a team environment, and others occurred. Generally, disagreements on design cause development to stop completely in its tracks, and sometimes take an hour or two to resolve. Even though we (as a team) agreed to develop what was in the GDD, some team members did not completely understand they were ACTUALLY developing. This was due in part to unclear design descriptions in the GDD, and people not speaking up when they had a question. Our inexperience also played a huge role in us not even knowing which questions to ask early on. Many of our disagreements happened because of our general inexperience with making games in the first place.

Life / Work Balance

TIME MANAGEMENT BETTER. THE EXPERIENCE TAUGHT US

Regardless of profession, stress is something that always seems to creep into lives. We were no exception to this. Not only did we have to develop a game in eight-weeks, we also had three other class loads to balance on top of it. Because of this, there were certain times during production where team members were clearly not performing at their utmost potential because of stress from other classes. As this was something completely out of our control, the only thing we could do as a team was to keep pressing forward and tightening up the slack whenever a team member needed help.

What We Learned

Build In Tools to Assist Development

Something that all of us (especially the Level Designer and myself) wished we had invested time into during development was building tools to assist us in testing levels. Our process for creating the procedurally generated slopes was very time consuming, and it all might have been easier if we had a better system for testing in place.

Just Because Someone Likes/Dislikes Something, Doesn’t Mean Everyone Will

We learned very quickly as developers that there are many different types of gamers on this planet, with drastically different tastes in what makes a game fun. This did not change with our professors. While they offered excellent feedback to our design systems, it was very clear when one was not interested in endless runners to begin with. Considering this, we had to take in criticism and ask two simple questions- “Are they criticizing this because this is bad design?” or “Do they just not like this kind of game?” We came to the realization that at the end of the day, this was OUR game, and we had to make decisions that would help complement our vision, not obstruct it.

Playtesting is Key to Success

Our game could not have happened without the constant playtests we put into it. Some of the features sounded great on paper, but ended up hurting the overall vision, so we cut them. We could not have made these decisions without repetitive testing sessions with a diverse group of people. Playtesting helped make Edge of Winter into something special that all of us on the team are proud of.

Conclusion

Edge of Winter ended up being a successful project largely because of the team’s dedication and effort. While we had some solid blockers during production, they were nothing compared to our intense desire to create something special that people enjoy playing. Being in a school environment allowed us to take risks (and even sometimes fail). Overall, I believe that the team, through some of our differences, ended up coming out so much better on the other side. In retrospect, I enjoyed working on this project with this team, and I would not have traded this experience for anything. 

Here is the gameplay trailer for Edge of Winter: https://www.youtube.com/watch?v=odZoomS4k8U&feature=youtu.be