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.
Posted in portfolio

Dirty Particles Effects.

Our rolling drinking sommelier robot in Sommelier for a while were robots just sliding around a barn. This work for our game play and functionality but was lacking the is visual and polish department.


Unity particle system where I parented an empty game object so that I could set the particle effect to emit  as the player a direction to the movement thumb stick. This was designed to be short trail and I set up this effect so that it ran or 2 seconds and that the particles shrink over the life time.

Due to the fact of our characters have one large wheel i made the particles start their life a larger size the normal, this gave the look that the dust was coming from the hole wheel. There was a gravity add to this trail so that it felt it had a weight to it and not a solid straight line from the wheel.

The top image is only a default texture and a colour that pair with our ground texture.


This image above has a changed shader that has as tinted secondary colour this is so that the effect would smooth in to the surrounding environment. With the original texture you notice the difference between the effect and the ground or surrounding object.

The tweaking and little changes that can be made to this effect within the inspector are simple and after you are able to understand and combine these different tweaks the result can make you game or elements in you game feel a lot more coherent and believable.

Posted in portfolio

“Sommeliers” and “Prosthetic and me”.


Prosthetic and me.

These two titles are the things that have had my attentions focus for a far few week now but what i want to focus on is the background work on these game and how the work a scripting level.

Sommeliers had a lot of areas where myself and team members all tackles the scripting challenges at the some time to have a few head working out a problem but toward the end when broke up and focused on different areas of scripting.


Screen shake: this is something that can be done easy but also done badly. Some screen shake can be repetitive and the same every time it happen and this can hurt a game experience. What i sort about doing was making a executable so as i could use this not only for a camera shake but also anything that i want to shake.


Have the set up i could make something shake randomly over all possible axis or i could allow for the option to pick specific axis to shake. I called this on our camera and it work for a abrupt shake however later in the project i felt it could be better. I did look into springs like feel to camera shake but lost time to impairment. But this would lurp a camera position between two points in a floating motion, apply this to all axis would allow for a more realistic steady cam feel with i hope to look at in the future.



There where time were code that we were working on had myself and team member working together as is was something that effect both of us. The camera axis was a element that had implantation both in game and in menu to allow for player switching this during game. This was a task that was easier then first thought and i think got blown out of proportion though communication.


Prosthetic and me.

This was another project i worked on with a programmer friend. As i worked on most of the story and critical academic tie ins, I work on a part of the code or this text based experience. I did learn a bit a bout have to code this and interact and setup through unity.

See it here

Although i did not work on this code heavily i did find a few different coding functionality and worked a lot closer with a programmer then i had in the past to find out what information they need and it has shown the importance of a good Technical design document, ans working together on this from both a programming mind set and a designer mind set.




Posted in portfolio

Early Sommeliers Lighting effects.

In the early stages of the project, i made concepts level layouts during my trip to the Ekka (blog here). Once i have made this layout and through them off to my team members i look at how to light the area so a the players will want to pay attention to an area then other of the add a feel to the environment.

To start i made my wall assets with the idea in mind of light shining thought slates in the wall of the barn, this had me making easy variation in the wall design that is over on this blog.

This slideshow requires JavaScript.

Above was my first attempt at the is, having the deep blue was a way to give the idea of a night environment and then i added area lights to this as a way to highlight the main floor area and to illuminate the two side rooms the the barn. As this looked effect i didn’t have the pop of the shadow from light shining through the walls.

This slideshow requires JavaScript.

There it is. Well hmm. As it was the effect i was looking for i was split between the two. In the first i felt the the warm lighting was better to highlight areas and have player be paying attention to the level and what we will have in it. Where as with the images above i like the look of it but i felt the areas of importance where distracted by these hard lines across the floor. After a run around the level i also found that when you span the camera there was a hash flicker of the lines of blue light.

Based on these negatives we went with the first idea of a soft blue light that high lights everything and allows for the interior lights to draw the players attention.

Moving forward i hope to be able to use light in projects to greater effect, this project and a lack of text as had me thinking heavily on other way to portray things to player during a game.