Monthly Archives: August 2016

The End Of Studio 1

This will be the final blog for studio.

Sad Egg.gif

Since starting studio 1, my knowledge has expanded of not only who works in the industry and what they do, but how hard making games of the magnitude I was aiming for actually is. Listening to Ben Droste’s public lecture gave me a great deal of insight on what it takes to make a game like ‘The Eyes Of Ara’ – Ben is a level designer and an environment artist. Listening to Van and Scott’s public lecture revealed to me the opportunities and the ever constant push required to make something of yourself while not in Uni. Making the three game prototypes reinforced the fact making games is really hard but it’s exactly what I want to do. Originally my career goal was to work for Blizzard Entertainment as a level designer. This hasn’t swayed at all – but I’ve taken on the understanding that it could potentially be a very long and hard road to travel. Not that anything else is inadequate, but the fact that I have a goal that aspires to be ‘part of the greatness’ I feel means that I aspire to that quality. I want to continue to absorb and apply as much information as possible which will ultimately lead me towards this goal.

Baby Steps

Only recently having a taste of creating some 3d objects and 2d images, I am genuinely keen on continuing to create all varieties of 3d and 2d assets that can be used to bolster my skills as a designer. Because like Ben, there’s so much more than sculpting a landscape for players to walk on. I will start to explore areas of asset creation then enable me to construct a level (be it 2D or 3D) with my own personal flair and consistency. Whilst what I’m creating now or in the near future might not be specifically applicable to my end journey, every lesson, experience or process will be. Instead of directly aiming to reach the end of the journey, I hope to venture of onto different paths which will require me to broaden the spectrum of level design but allow me expand my knowledge of the different elements that makes up level design.

It already seems that I’m constructing my own path to walk. But it needs a cave!

Until next time –



Leave a comment

Posted by on August 26, 2016 in Uncategorized


Transmutation: Post-Mortem

Transmutation Is Available For Download!

Programmers: Pritish Choudhary & Jordon Dodds

What Went Right:

Learning New Tools:

I got to learn quite a number of tools that allow me to make cooler things!

Adobe Illustrator, Gimp:

I learnt how to use some basic tools in gimp and adobe illustrator that allow me to make simple images and simple modifications to images. This is a big step because now I no longer need to rely on Google image to be able to form my UI elements.

3ds Max:

I learnt some basic tools of 3ds Max that allowed me to make my own Radioactive Goop Puddle, Picnic Table, Big Radioactive Goop Blob and Tiny Radioactive Goop Blob. I got to learn how to actually make things!


Picnic Tables

Image Effects:

I learnt how to utilize some of the assets available in Unity’s Image effects to create some interesting effects that allowed me to better portray and provide feedback that the player was radiated.

Camera Scripts



I learnt how to make Gifs!


In combination with the post effects and the levels lighting, I was able to simulate a pretty cool representation of a canteen 5 levels underground that is filled with radioactive mutants and goop puddles. The lights shut off and sirens alarm when something goes wrong.


  • I was able to put my scripting skills to the test to create a completely code simulated attack Slerp.
  • Created an elevator on a timer that has doors that open, lights turn on, close when an a Button is pressed and fades to a black screen to start the game over menu.
  • Set timers for lights to completely dim and create a desired darkly lit atmosphere with a random flashing light every 3-7 seconds.

Flickering Light.gif

  • I created the entire UI system that flashes when the players take damage, changes the highlight image to show which character is selected.
  • Main Menus, Game over Menus, Pause Menu, Made them operable via controller and learnt how to use event systems within buttons to play sounds, activate or deactivate highlight images.
  • I designed the Camera switching system (But Jordon assisted with the switching in the case of a dead player).
  • I scripted 60+% of the sounds.

What Went Wrong:


Like I mentioned in the Pre-Brass Razoo Rush our TDD was our downfall. We made stuff up as we went rather than implementing a solid system. Coming from Scripting 1, 2 & production that require us to focus on other things, studio presented us with our first knowledge of a TDD. It was hard to break the habit of just focus on making the thing than learn how to make a well designed thing. We have no Player AI. If more than one mutant surrounds a player they rotate to a point where they don’t deal damage to a player if they are standing still. The camera doesn’t rotate back to its original position if the player has moved it from its starting point and is no longer adjusting it and it clips and some of the objects it should be ignoring like weapons and mutants aren’t being ignored.

To prevent this from happening next time – Actionable Instructions:

Design and prepare each component before implementing it. ESPECIALLY if requires other systems to operate.


The project is over, and the audio is still partly a mess. Pots make a sound when mutants are touched by them, even if the player isn’t attacking. The playable characters don’t announce they’re almost dead or have started being buffed.

But most importantly – We let down the audio students. They went to the effort to create these amazing sounds for us and we weren’t able to reciprocate their efforts by using all of their material as intended.

The reason this happened 100% falls back onto us not figuring out how or when we were going to implement sounds not FMOD itself . It could have been solved by figuring this out in our TDD. We knew the assets we wanted but not how we were going to implement them. How we are going to implement them is so much more important that which sounds we need.

To prevent this from happening next time – Actionable Instructions:

Design and prepare each component before implementing it. ESPECIALLY if requires other systems to operate.

My newly learnt importance of a TDD will directly apply to future projects. This is a big part of taking a professional approach.

Until next time –



Leave a comment

Posted by on August 26, 2016 in Uncategorized


Transmutation: New Audio Feedback

In a previous blog post I mentioned that Transmutation needed more feedback, especially audio.

More Audio feedback.JPG

Since that blog post, I have in fact added:

  • A new 2 minute audio sound until the elevator arrives.
  • Make a player say “Two minutes until the elevator arrives, we can survive for that long can’t we?”
  • Every time the elevator moves down a floor, it dings.
  • Audio feedback for when players are taking damage. They use the proper audio students ugh sounds. Plus i also added a mutant bite sound, so when they deal the damage, it sounds like they’re taking a big chomp out of the player.
  • When the player hits a mutant, The mutant also plays the audio students ugh sounds. And when the weapon (be it Ham, pots, or broom) hits a mutant the correct weapon sound is played.
  • Some more radioactive audio feedback as well as some more UI visual feedback.

Some different audio feedback to let the players know what’s going on. Like when they have enough radiation to move faster or are almost dead it will play some audio to let them know “I can’t take much more” or “I feel different”. All of the sounds are now half way between a 2D sound and a 3D sound. It’s so they can hear it in the direction it’s coming from but loud enough at all times so they can hear it.

Quite a few of the tracks (apart from the female voice) I’ve altered to make the characters sound different. I used Audacity to record and edit these sounds. The elevator audio sounds have been edited to have no bass, full treble, changed the pitch from my own voice to about 15% higher, and then make the speed about 15% faster to make it sound the way it does. The static sounding speaker voice.

This slideshow requires JavaScript.

Some of the player voice pitch has been changed to more bass and less treble, a slower speed and a lower pitch to make it sound like they’re not my own voice, and then when they’re even more radiated, sound more like mutants or alter from their original voice.


White Skulls - Rad Handle.JPG

I also changed the UI slider bar to have the Radiation symbol as the handle that slides along with the value of the current radiation. Added three different skull images that get filled vertically with the value of the players radiation to provide more feedback that radiation will kill you. The UI slider bar also flashes yellow for a second when the player takes damage from being attacked or stands in radioactive goop.

Until next time –



Leave a comment

Posted by on August 26, 2016 in Audio


Tags: , ,

Transmutation: Camera Effects

Unity has some image effect standard assets that allow some pretty cool things to be able to happen to the camera.

Image Effects

Importing Image Effects

I started to fiddle with and check out all of the image effects on the camera, what they did, and which ones I thought would be appropriate to use.

I had Noise Grain: But chose not to continue trying to make it work.

Noise Grain.JPG

It didn’t add anything to the game play or make it feel more interesting. It was cool but didn’t change the atmosphere or experience that I was going for. Noise Grain is out.

I came across motion blur. It felt like if a person was to get radiation this is probably what they’re going to see.


0.92 Motion Blur.gif

Maximum Motion Blur

This was great, but I’d have to find a way to make sure that the player’s current radiation level on each character was affecting the amount of motion blur that the camera put out.

Motion Blur Script.JPG

Access the Proper Motion Blur Script

Because of the camera switching players and there only being 1 camera, it was easy to find the parent object constantly and get that parent object (player)’s radiation level. Then make the motion blur amount to 100th of the radiation level. Because the radiation level goes from a scale to 0-100, and the motion blur from 0-0.92. The divide amount is a set variable so there’s no magic numbers. But the / halfDivideAmount – I’ll get to that in a bit.

So the motion blur would increase with the players radiation and become more intense with the more radiation the current player had. Until it reached its maximum of 0.92. It looked pretty crazy but I knew I wasn’t going to leave it at that.

Next was bloom (makes colours brighter and more vibrant). Transmutation relies on the emphasis of lighting. Bloom just makes it more beautiful.

This slideshow requires JavaScript.

I fiddled with the Bloom Intensity for a while to try and find the right value. Bloom 3 was a really nice amount. 15 Was really cool, but obviously too much. So I decided to roll with three and give it a proper play test.

This slideshow requires JavaScript.

If a few mutants or radioactive goop puddles ended up close enough to each other it proved to still be a bit too ridiculous. I’d also recently discovered ToneMapping. This is a hard one to explain. “Monitors (along with others) all have a limited dynamic range (LDR) that is inadequate to reproduce the full range of light intensities present in natural scenes. Tone mapping addresses the problem of strong contrast reduction from the scene radiance to the displayable range while preserving the image details and color appearance important to appreciate the original scene content.” (WikiPedia). It evens out the amount of colour per pixel that’s close enough to each other to fit withing a 255 RGB (W & B) range? Or something? Anywho, It works!

This slideshow requires JavaScript.

I was still able to have the 3 intensity of Bloom and have the ToneMapping work its magic to make sure radioactive goop puddles didn’t become a pile of suns.

I thought about making the bloom scale with the players radiation level much like the motion blur. But after play testing with the tonemapping activated and the bloom set at 3, I was content. Although at the start while the level is much more empty and less bloomy, letting the game take it’s course and spawn mutants and radioactive goop puddles never became overwhelming but only more beautiful as time went on.

It came to a point where I found more image effects that seemed like they would be applicable if someone was suffering from radiation. Vortex!


Vortex allowed me to make vortex in the middle of the screen. I thought that along with the player getting motion blurring with radiation, why not have the vortex change between two values to give the effect of wobbling. I started with an angle of 25 to -25 (A range of 50).

This slideshow requires JavaScript.

Then I had to design the system to make it change between these two values. I wanted the angle to have a maximum and minimum value but change how fast it wobbles between the two based on the players current radiation level.

Vortex Script.JPG


Much like the motion blur, I needed to make the script I’m making access the ImageEffects.Vortex to get the angle of the vortex.

  • Start the current vortex angle on 0.01f (It’s not noticeable).
  • Have a countingUp bool = true (To make sure the vortex starts adding).
  • Make the camera get the parent player (because this changes)
  • Determine how fast the angle is going to change based on the current players radiation level.
  • Start the angle changing. If the current vortex angle is not maximum – Start making it ++ towards the maximum value by deltatime * vortexRate.
  • If the angle is at the desired maximum, start making it — down towards the negative value.
  • Set the vortex angle to the currentVortex.

When this came into play along with Bloom and Motion Blur – having maximum angles of 25 and -25 was a bit too much. It was completely mind boggling, It was really hard to comprehend what was happening and what you were supposed to be looking at or doing.

I changed the maximum and minimum values to be 10 and -10 (range of 20). The range of 20 made it still easily recognizable to understand whats going on and what you’re actually doing. Changing between the max and minimum at a rate of (makeFloat 5) was an ideal speed.
For Example: If the current player’s radiation was 50.
The vortex rate would be: (50 / 5) = 10.
Then the angle is changing by + or – by (Time.deltaTime (which is anywhere between 0.03 to 0.075 on my computer) * 10) which is anywhere from 0.3 or 0.75 per frame.
In a span of 5 frames at a rate of 0.75 the angle would change 3.75. And if there is a range of 20 it would be changing from max to min in 5.333(more) seconds.
At 90 radiation: The vortex rate would be 90 / 5 =18.
0.075 * 18. In 5 frames it would change 6.75. It would change from max to min range in 2.96296(more). That amount doesn’t make ME sick. And I hope it doesn’t make others sick. So as the radiation increases so does the speed of rate the angle of the vortex. If the rate needs to be smaller or higher all I have to do is adjust the makeFloat value.

At this point I also changed the maximum amount of motion blur. And as I mentioned earlier. The HalfDivideAmount. Read the big block of Green text.

Motion Blur Script

50% of motion blur at almost maximum radiation along with Bloom and Vortex was the perfect amount.

The one last image effect that I thought would add to the radiation would be something that resembles the player blacking out. Like A Vignette?


There was also an image effect for that too. And much like the motion blur.

Vignette Script.JPG

I’d need to access the Vignette script directly and apply the exact same principles. Because the vignette intensity goes from 0-1 (then anything over 1 makes the game white) and 1 intensity would make the entire screen black – the player wouldn’t be able to see what they’re doing from about 80 radiation and on wards. So 50% (0.5) intensity on TOP of all the other image effects would be more than enough to represent the player blacking out / dying.

Vignette Game.JPG

Are you ready? READY FOR THE MAGIC?

Until next time –



Leave a comment

Posted by on August 25, 2016 in C#, Game Dev, Post FX


Tags: , , , , ,

Transmutation: Mutant Particle Systems

Transmutation felt bare bones without anything other than audio feedback. So I decided to fiddle with the particle systems built into unity.

Particle Systems

Particle System

What I wanted, was to create a little explosion of little radioactive goop particles when the players hit the mutants. So firstly I ended up making a random little radioactive goop blob in 3ds Max.

Then imported it into unity, and made my particle system contain the new goop blob. The Render mode needs to be mesh, not billboard. I made my goop blob have the colour and size I wanted before making it a prefab and then making the particle system use the prefab as the object to spawn. From there it was a matter of exploring all of the options of particle systems to try to make it look like a little explosion of blobs.

Big Goop Burst.gif

They all start with a random rotation and randomly rotate through the air. They scale smaller and smaller as time goes on to make it look like they’re shrinking as they fall further. It also only happens in a small burst. It was close, but it was missing something. I came up with the idea to create a second particle system with a different shape to give it the extra feel of goop flying out, rather than having the same object every time.

Tiny Radioactive Goop Particle

Little Glop


A sphere that resembles a blob. Because it was going to be small in size, it wouldn’t need a distinct shape. But it needed some modifying from a perfectly round sphere to make it actually look like a little blob of liquid.

Tiny Blob Particle System.gif

Each Particle Effect

The only thing left to do was make it happen when the player hits the mutant. The mutant needed to have reference to the particle systems and the players weapon was already dealing the damage, so this is where it would tell the mutant to play the particle system burst.

Particle Systems

Particle Systems In Mutant

Play The Particle System

In Player’s Weapon

I knew the mutants were going to destroy themselves if their health got to zero, which would mean that if a particle system is playing while the mutant dies, the particle system would instantly disappear. That’s not what I wanted, so when the mutant is about to die, make the particle systems their own object to finish playing.

Particle System Make Parent Null

Make Parent Null

Tadaa! The desired effect has been achieved!

Combined Particle Effect.gif

Until next time –



Leave a comment

Posted by on August 24, 2016 in 3ds Max, Game Dev


Tags: , , , , , ,

Transmutation Art Bible Difficulty

Transmutation Art Bible.JPG

Every Single Page In Our Art Bible

This slideshow requires JavaScript.

This is the asset list of what we wanted – Best case scenario for transmutation. We had a list of the things that we wanted, and images that represented what we wanted. But it wasn’t in the art bible. Why? Well in this particular case the original art style that we wanted was completely out of scope.


Warhammer: End Times – Vermintide

We didn’t have the skills, or the collaborators with the skills to create anything close to what we wanted, nor did we have the time. The art bible became the asset list. ‘These are the thing’s we want if we have time to get the core gameplay finished’. And in this particular instance of making Transmutation I felt that I was more of a programmer than a designer. I didn’t focus on making the game look how we wanted it to be. I focused on making sure that people could play an unpretty version of the game we were trying to make. Hense constructing the entire game out of objects that can be made with primitve shapes in unity. We played as Yellow android logos fighting green android logos without legs.

This slideshow requires JavaScript.

We only gained animation collaborators when the project was already half way through production. And we knew that eventually we’d gain collaborators who would make our character models, so do we source ones in the mean time that have animations that we can use as placeholder that could potentially change the dynamic of the game? Or wait to see what they come up with. The animation collaborators had less than three weeks to two make two character models with any animations and a few clutter assets. And what they needed to know, and the reference images were in available to them but just not in a place called ‘Art Bible’. I sent them the picutures individually and described what we wanted out of each which took less that 5 minutes.

But what I’ve learnt from ‘Sea Of Mutiny’ and creating it’s art bible – is that the art bible is supposed to be/does:

  • A reference document / guide that contains the detail of what the complete desired finished look is.
  • Created before art production.
  • Made by the person who has a clear vision of the game visuals.
  • Maintains consistency of art style.
  • Helps the team understand the direction of the art.
  • Explains that this is what we want this to look like, why and what it’s supposed to be conveying.
  • Get new members up to speed.
  • (In a case where it’s going to be released properly) Help in marketing and communication of art syle.

It covers:

  • Character Art – Poses, expressions, height scale comparisons, color palette, costume/armor, etc.
  • Camera – Camera FX, field of view, gameplay angle and the position of the character relative to the camera.
  • Color Palette – Color Swatches, vibrance and values, environment colour palettes, etc.
  • Atmosphere/Environment – Scale, openness, weather conditions.
  • UI – Menus and HUD, UX, animations.
  • Many many more things.

It’s not:

  • A place where the art style is updated with progress changes and what to change (this is what I actually did in SOM).

So the difficulties I’ve found aren’t neccesarily in making an art bible. It’s actually knowing what we want and having the ability to make it look like this within a given time frame or create or find reference images that accurately get across what we want without writing a thousand page novel explaining the image. And like I said before, If I got to be a little less of a programmer and more of a designer, we might not be playing as the android logo in a white room with no textures.

Until next time –



Leave a comment

Posted by on August 20, 2016 in Uncategorized


The Difficulties of writing a TDD

It’s coming up to the end of Studio 1 and I thought it’d be a good time to express some of the difficulties and importance placed on a Technical Design Document. In the earlier weeks of Studio 1 we had only recently learnt about a TDD and what it’s supposed to do. My understanding of a TDD is that, it is a place where all of the scripts and systems are set out in place and how they will interact either separately or as a part of – or with something else.

Ultimately – it is an entity as a whole, as how the game will function.

The only difference being making a game and writing the TDD is that you are actually designing systems before trying to create them and make them work. I’m not going to say that Transmutation has failed catastrophically because the perfect TDD wasn’t written. I was about to say that our TDD was a good start, but after giving it a quick review I can safely say that it only started to scratch the surface of what Transmutation currently is.

In my head thinking about creating Transmutation it seems easy to say I could make it, or I could make it by myself if I had to. The core concept is to have mutants spawn – have switchable playable characters that can attack mutants. There’s a beginning state and end state. Survive for a duration or die and some bits and pieces in between. Easy enough right? Sure – If I had all the time in the world. But that’s the catch, I don’t. A TDD is supposed to be the building foundation for figuring out systems before trying to create them. It’s supposed to be time saver and a reference for the already designed system instead of figuring it out as you go.

So as an example – As you can see in the first play test there’s quite a number of issues. Instantly a big standout is the fact that mutants can float.


Floating Mutants

The NavMeshAgent was something that wasn’t documented in the TDD – I knew it was they way to go and I’m almost certain both programmers and I discussed using navmesh (and we all knew how to use it) as a way for the mutants to move. It was originally just “Find Player One” and translate the rigidbody towards the players location. But by the first play test navmesh had never made its way into the game?

A) If it was documented from the start – rather than designing a placeholder system for mutants to move – we could have had the correct movement from the start. And like I mentioned before it’s the time saver. Do the hard brain work before trying to implement the system.

B) Even if it wasn’t in the TDD – why did the navmesh fall off the priority list? Would have it made a difference in the task schedule? Even if we didn’t know exactly how we were going to implement it, having it in the task schedule would make it take priority over creating a dud placeholder. Or even forced us to take a step back and go “Right! Navmesh – Instead of just trying to implement as we go, let’s head back to the TDD and figure it out first”.

And that’s only to mention the Mutants floating. The same could be applied to the elevator doors not opening. Although I figured that out as I went and it worked before play testing, It could have been achieved faster and worked properly every time if it was designed before implemented. The same again – could also be applied to the mutants trying to find every player instead of a single one and only moving towards it.

I’ve only had a small fraction of practice with TDD’s, Ball Ball was my first go, Sea Of Mutiny didn’t require a TDD, Transmutation was my second go. So I’m slowly building up an understanding on the importance of actually writing a TDD. I know it’s important and I know it should be done. But not in little stints, like figure 5/100 things out, work on the 5, get them working perfectly and just continue on working blindly for the other 95 things. Either go back to the TDD or get more sorted from the start. Writing a TDD isn’t a one off “Right I’ve written one, it’s perfect – now every TDD I ever write will be a breeze”.


The important thing to take away is that I’ve made a mistake, I can learn from it and do better next time. Instead of doing all of the nitty-gritty documentation stuff that a person who really knows what they’re talking about Game Dev related says so. And try to be done with it as fast as possible so I can go make stuff, because having a physical representation of what the game needs on a screen rather than in a document doesn’t mean more progress has been made.

Until next time –



Leave a comment

Posted by on August 19, 2016 in Uncategorized