Posted in portfolio

A Bitter Sweet taste of “Sommeliers”

Final project another project has reached a close and now it is time to reflect about the processes and things we did to make Sommeliers. Oh where to start.


The Rights

Game Audio achievements

From a very early stage we wanted to create game audio that would engage players and also complement our intent behind the type of game we wanted to make. Sommeliers is made up of audio created by our designer and programmers , which was both fun and unique and proved to be a much easier method of audio generation for our development time line, which plays into the reason how this help adjusting scope. This was a big learn experience for me, as has a lot on this project.

Doing this helped us all learn a new skill and a new area of developing a game. This also have us gain time by having to only communicate with a small set of collaborators, as I only need to keep tabs on a couple of people as the collaborator coordinator. This allowed me to focus on the other areas that I needed to work on and learn.

Not having to deal with extra collaborators and the back and forth communication that this would bring when a problem arose, we were able to fix the issue our self’s which gave as experience in the new area we were contributing to. This meant we could focus more on the work we were producing and working to make that of a higher quality.

Iteration on our scope

It’s key to point out the number of times we made iterations that our game core over the course of our five week of development window on this project. We went through a bunch of differing game concepts and I think it’s important to say that with each new concept that we come up with, we cut down on our games scope which have out team thankfully for the rework on our ideas.

Game Idea 1: Moonshined! (Wave-Defence production management game)

Game Idea 2: Gardelegan (Tactical Turn-based game based on a true event)

Game Idea 3: Motion_Exitus (Third person puzzle plat former)

Game Idea Final: Sommeliers (Third person wine drinking robots)


By going through constant iterations, we were able to cut out components and features that would be ultimately “un-achievable” in the time frame we had, and we could then focus on our core game play mechanic and game play loop to ensure we would create a working playable prototype by week 13 and create something that we would be happy with and proud of.

Role in the team

Our team was off to a great start by determining roles and responsibilities to each of the member of the team, we were started on the right foot and come at it with a creative attitude from the start. There was a moment of realisation “So this is what I was doing wrong before and this is what it feels like to have made the right choice this time. This project has several moment where I had felt that I was doing things better this time round.


When we were handed project 3 briefs, we determined roles for all of the different avenues of the project that we could think of at the time and most of all we talked amongst ourselves on “what” and “how” we were going to do in our assigned roles to ensure the greatest outcome for this project. Without tackling those housekeeping tasks during that initial stage of the project, we wouldn’t have had the experience that we did on the development of this game, and feel this gave us less issue then we had down the track.

Team communication and scheduling was key to the success we have had with this project and it was instrumental in our team completing work by set deadlines and working through difficult tasks that we faced during development. If it was talking and chasing up with collaborators, sorting our documentation hiccups, developing plans and schedules for when work was going to be complete. Whatever the task was, everybody had a role to play and the fact that everybody played that role to the best of their ability meant that we were able to have a playable prototype by the end of our time frame, and it’s something that the whole team should be proud of.

The Wrongs

Play testings constant rush.

We could never get things ready by our play tests and I don’t think it was caused by a lack of effort of our team, but that we just underestimated the amount of elements that we needed or where crucial to the game came time to play test. Learning from this, having a working build come play test should a paramount milestone from the beginning and should behave been the aim for all our tasks up to this point.

Having workable build on standby that you are happy with and maybe adding last minute elements is the plan, not have a bunch of elements your putting in a scene your building on the day. This way you receive useful feedback from it that you can immediately use to improve of fix something that come from play testing not that was broken beforehand. It means that if you are able to implement further functionality to your game before play testing you are just adding onto a working build that you are already happy with, so everything extra is just that… extra! Which is great news if that’s you, but unfortunately for us that wasn’t the case but it’s something that we will all work on improving in the future.

Our documentation Short falls

Documentation was our big letdown and it caused us the more issues and headaches in the long run than it should. It was good at the start and I think that our High Concept Document was the high point, we did a thorough job at determining our game concept early on after the first few iterations.


Our Technical Design Document is where we should’ve put more focus and effort. Fleshing out and getting to a workable state early so that it would actually be a useful document for us to reference out systems we had to create in order to have Sommeliers become what we had intended. Likewise with our art bible, if we had worked in more, that would’ve meant that our Animation collaborators would had a better understanding for the type of character models that we were hoping to have within our game by week 13 and could’ve spent more time designing them based of our specifications.

By not doing so we had received numerous iterations on our character model which had us constantly updating and importing a new asset in and set it up like the last and they were never quiet look like what we had intended. The same goes for the character animations, if we had broken down and written out the types of animations we needed and wanted and how they needed to work through a TDD and art bible would have meant we could receiving more workable animations and rigs that could have more iteration before final playtest.

These elements of documentation I know see are so paramount to a successful flow of a game process and having these experiences with these issues it is making me want to achieve these better out comes so as I’m able to work on a project in a fun and creative way instead of a rushed mess.


Click here to download our game.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s