Posted in Uncategorized

Critical Reflection of my Prosthetic and Me.

I have learnt about the way i work and a lot more on topics that know but didn’t know as much as i do know. Before this assessment, I had never attempted any sort of story creation, let alone game story creation, and was therefore a little bit anxious as to how the quality of the product would be at the end of the project’s timeline. but I believe the quality achieved was of a very high standard, if not overall, as there are many things that i cut to meet the time frame we had and to schedule with all the other projects we had on the go.

The project idea was first conceptualized as an interactive website, much like a game, but would require a lot more work than one could possibly do in just a few weeks. This concept would have probably been feasible in the time given if the both of us were able to code at the level in which I could achieve it at, but that wasn’t the case.


I did a lot of research into a way to achieve such a project,  I have previously experimented with UI components and button-driven menus and dialogue before with manual creation of such menus, great for title screens and introduction monologue.  We came across a potential solution in the form of a Unity add on called Fungus. Fungus had simplistic programming concepts. Luckily once you know the ins and outs of what makes a programming language, you can pretty much pick up another language within a day or so as many concepts are translated transferable.

Overall, I have learnt so much whilst doing this project. I have learnt how to handle and fix the few issues I encountered along the way, and have taught myself very thoroughly, the ins and outs of Fungus, so that they are able to use such a powerful narrative solution in other games from here on.


I’ve had lots of fun across this project, as I love problem solving, hence why I think I do so well in the design discipline. In the process of creating this project, I have also learnt a ton of facts in field of current and future technologies in prosthesis and the processes that are carried out in the process of receiving a prosthetic, but also more generally in the subject of trans-humanism. Prosthesis may be given as standard stock or may be custom-made cosmetic looking silicone versions, with the latter obviously costing more. I did not realise how well customized prosthesis could get for an individual, down to the exact skin colour most of the time, and how similar the prosthesis dimensions are to their counterpart. I’ve learn that once you begin to look into a topic or a situation of human lives  and interaction you start to find all of these greater connections to other topic that can help you explain or rationalise or better inform you about what you want to know or give a bigger question then the one you were looking to answer.


The overall product of the submitted project, I believe, is an immersive experience, with a good story line, above the expectations anyone could have asked of me. I have many plans to improve on the game in the future, by adding more materials such as background music and audio effects, as well as polishing the visual effect to game experience for players.

Making this project and this trimester was a great creative experience for me and has changed the way i approach my creative works in the future, thinking more on a premise and how it relates to this premise , to how people will interact with a work instead the nut and bolts of the work it self. Making something work on different level first and then making it work physically.



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.


Posted in Uncategorized

Brass Razoo!

About two weeks into development on Sommelier we were invited by facilitators to exhibit our games at the Brass Razoo! SAE showcase event on the 17th of August. With some what of a daunting exciting as this meant we would have to get our games to playable state to present a public audience in test of a test group. As this was a first for a studio 1 cohort we could prove that even in studio 1 you can make something great.

The showcase’s location was ‘This Must Be The Place’ in Fortitude valley, a small venue but was nice and packed with student games from Studio’s 1, 2, 3 and Final Project + a new title from Handsome Dragon Games. The night insensitive was going to be the visit from many prominent industry professionals based in Brisbane, including my old facilitator James Bowling which was awesome.

“The designers and programmers of Game Studio 1 had been tasked with making a prototype that showcases a clear core game play loop. Some of their creative limitations include using a third-person camera, an in-game location set after-hours, and no form of text after the main menu”.

– Sommeliers by Adam Crompton, Philip Oterdahl, and Nicholas Staracek
– Transmutation by Pritish Choudhary, Jordon Dodds, and Nicholas Lyness
– Snöfyr by Caleb Barton, Marivan Ebrahimi, and Joshua Textor


As studio 1 i know our games would not be the main draw card of the exhibition, I did have some interesting iteration with the public and devs that played Sommeliers. I got asked questions about my game design, my degree and SAE.

Showing off our game to the public was an experience that I’m glad i participated in this event, have all a lot of people circulating through this small environment and made for a lot of opportunities to get chatting to people about the games on show. I was able to gather some useful feedback on player motivation and player response within your game, as well as visually witnessing this as they are playing your game. It’s a play test experience on a hole different level.


It was great to chat with other uni member from studio class above mine, getting there thought and experiences and advise had me coming away from the night with a few new ideas and outlooks on my work and interaction in the future.

Before any of this at the start of studio 1 my out look to a career was something that i didn’t know to well or were i really saw my self in the future. After experiences  the projects i work on this trimester and the advice of Brisbane professionals. I’m not looking at AAA title as I’m looking at working in Brisbane or Australia on smaller games. After the Brass Razoo and the attention that iPad game where receiving and the fact that the professorial that attended were attached to iPad games that have don well in recent months.

Based on my work in class i have found that i am understanding and fine turning my working with collaborates and groups. I think that i would work will in a small team environment to help work other with the tasks that need completing. I enjoy have a few things on my plate at once and be involved with many areas of a game all together as a posed to work on a element and then dust my hands of it. see have all elements are interconnected and planning and design that at a high level sets me challenges and problems to solve. This is something that excites me and drives me to make new and creative things.


Posted in Uncategorized

Exhibition Cram.

Working in a rushed state of mind , and from recent experience is something that should be  avoided. Last Wednesday before our Brass Razoo! exhibition we were pushed for time and had a lot outstanding implementation on Sommeliers.

We needed Sommeliers to be in a playable state, so not only a core mechanic that was playable but a game loop also. We needed to show our core game play loop and demonstrate our design of this core loop and how it would be experienced within the game, however for this to be effective our mechanics needed to be polished and implemented fully  Now let look at where it fell down slightly.


What Went Wrong

Repository conflicts: the great repository issues of 2016. These have been present several past projects and feature here in “what went wrong” round ups i have, but this issues cost us a lot of time work that was on polish to the menu scenes visually and functionality. While work on the scene was happen a members deleted a button within the same scene as it was linked to other functionally that they were working on. This caused all sorts of push and pull issues within our repository and resulted in loss of work that was made on the project.

Player movement: a key thing in most game however it wasn’t as function as we would have liked. During production on Sommeliers we had character movement implemented but it was consistently buggy,  the player would get stuck in the game space on virtually Nothing that we could see  and in other insistence it  would just float away out of the play space. One of the predominate errors that we faced with our player movement was the uncontrolled force that would push the player back once they had turned around within the game, this was game breaking and was top of the list to fix.

Drinking effects: this was a aspect our game loop the need to work for the intended experience. We had it implemented somewhat and they looked like they worked correctly but once our test build was made it would consistently fail to execute correctly. We wanted these implemented for exhibition as it is a major interaction and win state of our game. There are vital indicator in game as they would trigger when a bottle of wine had been drunk by the player, with these not working, our players would be lost and not know when they had done something.

fire exercise

What We Did About It

At the time there wasn’t much that we could do to save the changes that had been made to the updated scenes, so we had to roll with that punch at the time. Lucky although not great they were only cosmetic changes and easy controller commands that could be fixed easily as apposed to large amounts of game play or key areas. We pulled what we could from the changes and move on with more important issues. The polished elements would have been great to draw people to our game during our exhibition, you can learn from all out come and situation.

We intended to have our horizontal and vertical axis movement working also we desperately needed our horizontal movement implemented so that players could strafe, as this was something that from play tests play wanted because that is what they felt was natural. Fixing this issue was relatively simple, as we figured that the majority of problems were in the setting for the x and y movement and then calling them one after the other, meaning that they were being overridden.

We had one of our drinking effects working ,speed boost on the white bottles however the jumping effect was not in to add variety, and then if we were able to implement mixing the wines together and drinking them, then we wanted to have a different effect for that which would logically be the combination of the two original effects. We worked on implementing  hopping to the character if they drank red wine, we had some issues with setting an appropriate jump force and had this “working” but was not consistent across different test play troughs.

This rush time before the exhibition has in-bedded a greater importance of planing scheduling for these element early on in the process of a project. Greater iteration and breaking down of the structure of a project. Would mean the lose of aesthetic after functionality wouldn’t happen if the planning of these elements was flipped and realized early. A stronger TDD would have found this early and an art bible would have had this atheistic definite before it implementation. Which i explain here.


Posted in Uncategorized

The Art Bible and TDD.

During the last 13 weeks, there has been areas that I have identified as room for improvement. Not to say that they are areas that I don’t have a good understanding about it’s that they could have been forfeited better. Which I would like to break down.

An Art bible is a reference document/ guide that contains the details of what your game is going to look like. This is something that you can figure out with the help of a few question like:

  • What is your games purpose?
  • What do you want to achieve from your game?

With these question in mind your able to start looking at the artistic style you want to depict in your game and how this will specifically compliment you purpose.

The road block for our project was that of writing our games art bible and harnessing a reasoning or purpose of our game.

  • What were we trying to tell players during play?
  • What should players feel when they playing?
  • What do player take away from this game?  

After many different feel, we lead to comedic feel and in some ways we hit these markers with our game, but we were lacking to a degree and I fell that this was down to not honing down on this purpose impacted those issues.

Your game needs to have purpose behind it… or otherwise you are working a little lost

Having decided on a art style you can start to answer:

Why this style and how will it do what you want it to?

Answering this question there are different things to consider, and this isn’t something you can rush , you may have just chosen your art style because it was something you want to portray or  that seemed achievable , which in itself is something you want to be looking for but with the assurance that its going to compliment the purpose you’ve set out for your game.

Choosing to with a specific art style will directly impact the purpose of your game and the things that you’re trying to achieve. We went with a low poly with our art style to keep to a simple colour scheme for our game, our reasoning was that its would more achievable with the style and to fit with the length of project, but with a longer projects we would have like to elaborated on this and more thought and consideration into other art styles. This would have given us time to look at the benefits and downsides of using one over the other.

Technical Design Document

The TDD is something that didn’t receive the attention that it should have early on in our project. My understanding and realization  of its impact when done bad.

In planing stages we knew of sommeliers it was a while for us to pin down a core mechanics to our game and what the player experience would be. This didn’t help the iteration and proper break down of what we needed to plan out and what would connect to each other. As we did work out what “each other” was until we were making these elements, we didn’t see the possible problems this would impact until they happened.

Make a TDD in the beginning of a project help cement the plan and important that element have over each other and the best order the should be connected and structured so that fixes and changes later in the project are easier. Also so that you don’t have to pull apart half you project to fix a simple problem.

Having a TDD structure from prefab that the start would help for a few different iteration down the track.

  • It would make testing and changing of the scene or setting up of a scene easy so that changes are easy fixes not large reworks of assets .
  • structuring what a prefab needs would mean that additive of simple box colliders would need to be consider late project.
  • these above make different scene work easier and apparent to a team
  • would give all members a better understanding of scripts content and functionality

The take away is that mistake have been made, but I can learn from these and take this forward so that you can make new mistakes on the next project. Before this point i felt documentation as the part the you do to support the game. But its this documentation that should the law you adhere to for you game, if this is precise and heavily details so as the making of a game is more of a creative fun time instead of a frantic catch up of mistake making.

Posted in Uncategorized

Saying Thing. In French. Badly.

Recently i recorded my own lovely voice in a bad way for a good use. On your game Sommeliers, we have french robots casing and drinking  wine to say it for mankind. As our game is limited to allow for not text or work on screen during game play, the use of record voice is how we are looking to info players.

Check out our teams effects

So this as seen our three members of our team recording our bad french accents. Say funny phrases and statements was the first set that i completes. However these are french robots so i went about mixing the audio of my voice.


I used Audacity to record my voice assets, i had used Garage Band in the past but i sort out this program as a different learning experience to better my understanding of different programs and maybe come out the other side with a program i might use in the future.

To add a robotic feel to my audio I add a couple effects to my tracks, First i changed the pitch of my voice down. Which turns out not by much as i have a voice that is of a lower pitch to begin with. Then on top of this i added an echo to give a metallic ring to the track and to distort the sound enough from a normal human voice.

These elements although simple were effective in giving our vocal for our game the sound and aesthetic we wanted. Our Sommeliers now have a voice of their own.

Posted in Uncategorized

Making Music

A little while ago i set about making some backing music for my games and just to have a a little library of assets i can pull on in the future. As it is only a small one at this point in time, it will be something i add to when thew occasion arise.

These two music track were made in Garage Band, This is a program that i have had experience use a long time ago during my short iteration with music in few different as i was part of a three year long program that mentored performer and teachers in music with  student to collaborate on sound to make an album as the final goal.


Using the program was both a new learning venture and a dust off of some old skills that i for got that i had. As is was over 8 years ago this was

Both of these tracks i layers different elements to add a depth the what you hear instead of a start, finish, feel as this is a boring progression. Having different elements overlap or have elements louder then others allows for a interesting mix what you hear.

In the images below is my two tacks,

  • one image showing the the breaking down and sequencing of the elements with in the track showing how the elements have the moments where this is one sound having its moment over the backing.
  • The second (Game Music 2) shows how i was able to add drop out and increase of intensity so as elements would be about to accompany each other in the same sound space and not over power or drain out the parts i wanted to stand out over the others.

This slideshow requires JavaScript.

This doesn’t mean that you throw 20 different thing in all at one as it will become a mess of sound. So balancing and have element have their monument to transition into an other element of the song or clip means that things are there for a reason and a purpose. As is many thing in the realm of making a game it self and music is one of these elements that adds a layer to a game but if this isn’t add in a way that adds to other elements it can feel like a big mess.

Track: Game Music.

The process of my design with this track started from the drum backing. I look at different ways to start this process with things like types of music of fro a certain game genre. but i felt that that is was getting stuck at impasses. the simple fact of the matter is i made these songs base a  backing beat that i felt i could add to. Following this i broke this take down to a intro, chorus, and bridge, will as much as one as i could in a track this short.

At the start i found three instruments or sound t set a collective of sounds. The progression of the song strips back these sound all the while keep the backing as a way for all the sound to stay connected. Despite the changes in the song the they are conjoined by the backing. This lets the rhythm sections to have there moment to move the song forward. By the end of this track i found the sound leaning toward something that of a space shooter. I tweaked the pitch and intensity of individual element and make some element start when one finishes as as key beats in the progress of the track.

Track: Game Music 2.

As above i started with a backing beat that i felt i could add to, after the first i decided to make something less intense. So i look for a jazz feel to the track i switch up the synthesizer to “abstract atmosphere” which is the high pitch moments in this song a couple this with 70’s piano to give the song a collective consistency. I add more layers to is track and i experimented with the drop of and fade in more then the first. I fell that this rising and falling in pitch of element helped the song flow from on element to the next. If there was solid stop start you would help the feel i was intending. I also keep a intro, chorus, and bridge so as the song had progression.

In the future i hope the iterate over this and improve them when i learn more interesting techniques.