The last six weeks I’ve been working on a game titled Snofyr. (which you can download and play here). It was the longest project of Studio 1 at six weeks, meaning it is the most developed of the other two projects made over the trimester.

Snofyr is a game where you play as three kids rolling a snowball down a hill to destroy a lighthouse. Because reasons. You pick up objects along the way to increase your mass and destroying capability.

What went right

Scope

The project was scoped quite well for the length of time we had to develop. We didn’t quite end up getting as much done as we wanted to, but this is more a failing of time management. The games core mechanics were quite simple, leaving us plenty of room to expand the player experience. I feel the approach of “starting small” will work through most of the Studio classes as I go through the degree.

Second to Second Gameplay

The core gameloop ended up being quite entertaining and enjoyable  to play. The act of rolling around, picking stuff up, then running into the lighthouse was quite enjoyable. This was because players could have a goal that had an immediate effect, and they would go about that goal on a per second  basis.

Code Quality

Working with Marv, the code quality of the components running in the background was quite solid. The state machine we used (found here) was very useful in coding the states of our game (I’ll be going into detail about that in a future post). Snofyr can be played from start to finish without exiting the game or taking your hands of the controller.

Aesthetic

The aesthetic quality and the art direction worked quite well for the silly kind of game we were going for. The limited colour palette and stark contrast of the snow and sky made the game look bright and vibrant. This also gave clear indicators as to what the players were supposed to be aiming for (the lighthouse), which assisted in game design.

In addition, the music (suggested by Tony), fantastically fit the feel we were going for.

Clutter and Environment

The tool I’ve been developing allowed the designer on our team, Josh, to easily implement random objects into the world such as trees. This meant that time spent on manually placing objects was used for other things. In addition, this meant that we didn’t have to create code for the random generation of obstacles that the player could pick up.

What Could Have Been Better

Minute to Minute Gameplay

While our second to second gameplay was pretty solid, there was no minute to minute gameplay. The original design of the game was to be played between three different players, which would have the MTM gameplay of trying to beat the other players but we abandoned that concept due to enhance game flow. However, we didn’t replace the  minute to minute design, meaning that once players had played the game once, they would have little incentive to continue playing it. We can avoid this in the future by updating our design documentation when core mechanics change.

Task Deadlines

There were multiple times throughout the project where we were allocated deadlines from the team leader, which did not get met. Sometimes there were multiple different reasons for it, such as game breaking bugs or the work simply not being done by allocated persons, however it was mostly to do with the fact that individual tasks weren’t scoped correctly. The deadlines were often a massive list of “things we should have done” without expectations of how long a task would take.

In addition, some tasks wouldn’t be updated following the next backlog, leaving a trail of various tasks that would never be done.

While a good portion of this could be attributed to the project manager, there was a lot more that I could have done to maintain and update these tasks. The solution for this is ensuring that all people using a system such as hacknplan actually use the system, and update it and others regularly.

Polish

While Snofyr was the most polished game out of the three projects I’ve worked on this trimester, there were still some problems with content polish. Primarily in audio and player feedback. For example, hitting the lighthouse only responds with a light thud, instead of a momentous crash. The way in which we spawned the objects to be picked up could have been finer tuned also, as we could have given the terrain more coherence in terms of where objects were placed and why.

I feel this is a result of audio not being put into the game until the very late stages of the game. Audio is an essential part of player feedback, and should be in the game as a part of the base mechanics.