Category Archives: Games

The Ride / Vestige Similarities

So studio 2 is about creating games that aren’t mechanically heavy. And because that’s what I’m used to focusing on, I thought it was about time I found a game that tries to invoke a different experience.

I’m in the process of creating a small personal game called “The Ride”, where I’m trying to replicate and express (on a small scale) how it feels to ride a road bike. It’s not going to be to the quality of, for example: GTA V – but focus more on freedom, flow and beauty.

I played a few random games here and there where the title was the only clue as to what that game might have been trying to convey – some were great, but some were completely off the mark of what I wanted to convey. I wanted The Ride to a positive enlightening type of game – not focused on a negative/sad emotion or memory. What I ended up finding was practically on the exact same lines as what I wanted: An easy going, aesthetically beautiful soothing experience.

I found a little beauty called: Vestige. It’s a simple atmospheric walking simulator. And that description couldn’t fit it better. It’s literally about walking through a well crafted little landscape to view some ruins (and as I did: appreciate the environment).

Vestige Title.JPG

This slideshow requires JavaScript.

Without the description I think it would still have an easily decipherable design intent. The way that the landscape is constructed guides the player through the landscape and presents a series of ruins that gradually increase in size as you venture further to the main ruin.

As soon as I launched the game: what set the tone for me was the background music – or in this case the ambience. The gentle background sounds that makes it feel like this is a soothing, relaxed, free area.

Everything from there just solidified the experience – The walk speed, the camera look speed, the particle effects, sun rays, the light but tasteful colour palette, the simple but consistent art style. This is exactly what I want ‘The Ride’ to be. Although it’s not trying to convey some deep and meaningful experience like ‘End World Hunger’, neither is ‘The Ride’. It simply says “Here I am, walk on me, soak in the atmosphere, feel what I am”.

What stands out to me – and what I can take away from Vestige and put into practice with The Ride is:

BGM: The background music really sets the tone and pace for the game. Along the same lines as Vestige – but less environmentally accurate and more mood setting. Soothing, enlightening but power and motivational feeling.

The light colour palette makes the area feel so much more bubbly and enjoyable.

Also like what The Ride will be: replicating a feeling real life environment. But I’ll have to end up using post effects to really enhance the visual aesthetic to make it really pop and feel more beautiful. Give the player something to look at, and a reason to look.

There’s a few other little ideas that sprung to mind whilst wandering around Vestige – many audio and input feedback related.

Until next time –



Leave a comment

Posted by on October 2, 2016 in Games


The Ride – Let’s Get Some Audio

The Ride is a personal experience game about how it feels to ride. And being a personal experience game – what better audio than the sounds that my own motorbike actually makes?

This slideshow requires JavaScript.

Tonight I met up with the three audio students that agreed to work on the ride with me.


We discussed a few ideas of what positions the mic’s could be in to record the best audio with the least amount of wind, loaded me up with different mics and set me off to ride. The best mic ended up being the last one we tried which was taped to the inside of my jacket – completely protected from wind.

I never thought I’d be riding a motorbike while strapped up with mics – especially to record audio for a game I’m making. This blog is just – here’s a thing we did. It was something out of the ordinary, and it was a really worthwhile. The experience alone and getting to work some people who are in a different discipline, but share the same enthusiasm and passion for what we do. Unfortunately the project was so short for me, the audio guys said this would be a project they would love to have a few months on.

Edit: Chris did a vlog on some of the audio stuff we did for the ride.

Game dev makes me feel like spongebob:

Spongebob Dance.gif

Until next time –



Leave a comment

Posted by on September 27, 2016 in Audio, Game Dev, Games, Uncategorized


Post-Brass Razoo

This slideshow requires JavaScript.

Brass Razoo!

What a night. It was the first time that I’d had a game ready for play on display in public. It wasn’t nearly as nerve-racking as what I thought it’d be. I actually thoroughly enjoyed it. A room full of Games created by people trying to achieve the same thing – Enter the Games industry. Along with many people who are interested in Games or Game Development. Studio 2, 3 and Final Project were also there and the event was more-so to shine the limelight on them more-so than us. But that’s fine because our time will come.

Many people who played transmutation often didn’t finish the game, but had many giggles along the way. We didn’t receive any constructive criticism – but more opinions and thoughts towards our game. The general consensus was a thumbs up. People asked what the setting and premise was, so we gave them the run down and got the feedback that what we did was a pretty well done representation of what we were trying to achieve.

While the point of Brass Razoo wasn’t to show the world this new masterpiece ‘Transmutation’, but rather to dip our feet in pond of the game development community.

I Cannon-Balled In.

This is the moment I’ve been waiting for, an event that I knew some little and big game dev fish would be attending. I got to chat in person with a few of some of the people I’d been interacting with over social media where I’d been building a presence for myself.

I got to chat (but not in length) with, introduce myself or catch up with:

Anais Riley, Elliot Lewis, James Bowling, Sarah Smith, Scott Modra, Van Phadilok, Ray Morgan and Lee May from Zed Games  and some other general public. I already knew James, Scott and Van and we’d met in person before. I’d spoken to Anais a few times online. I Met Elliot and Sarah for the first time.

Morgan Jaffit was also there, And he was playing all of the games from studio 2 on wards and giving some really meaningful constructive feedback on their games. He was one of the people who I have had no prior contact with and was most excited to try to introduce myself. He was always having a conversation and I didn’t want to be rude and barge in and say “YO I’M NIC” (I would have done so in a more professional manner). I thought to myself don’t hover or try push the introduction, If he swings by transmutation or has a spare second it would be a perfect time. He eventually left without the opportunity for me to introduce myself, which was upsetting but I was also very sure that this wouldn’t be the single opportunity in a lifetime to meet or talk to Morgan.

The best part about the exhibition was getting to meet people and stand back and appreciate that I had the opportunity to meet these students, facilitators and industry professionals and soak in the experience. It was the best part because the exhibition wasn’t about showing off Transmutation, It was about being part of the community, the industry. It made me feel so content and like I was in the right place and on the right path. I really can’t stress that enough.

I’m so appreciative to even have the opportunity.

Until next time –



Leave a comment

Posted by on August 17, 2016 in Game Dev, Games


Pre-Brass Razoo Rush

So this evening was the night that our Studio 1 class had the opportunity to show our latest game prototype off at a place called ‘This Must Be The Place‘ in front of the real public and official people within the Brisbane game development industry/community. The preparation to get the game to the state we needed it to be was pretty full on. We had a list of things that needed to be completed, and by the time it was time to leave for the exhibition we had crossed of the most critical ones that would completely change the dynamic of the game.

Week 12 Schedule.JPG

The most important being:

  • Able to activate the game over screen through the elevator doors.
  • Make less mutants spawn with less characters alive.
  • Mutants stop targeting dead playable characters.
  • Add ‘some’ of the audio students sounds.
  • Making the hit’s instantaneous.

This list came from the thing’s that needed to be changed or fixed from the external play test that happened only two days earlier. Either some of these problems already existed or were revealed through play testing.

We wanted as many of these to be fixed to the best of our ability before taking our game to the public – and it was a rush. I don’t mean an adrenaline rush.

Adrenline rush

I mean this type of rush:


When it was time to leave for the exhibition we had our game in a really good state. There were four things that went wrong:

There still wasn’t a great deal of feedback throughout the game.

Not having enough feedback in the game (especially audio) is a two-part reason:

  1. We focused on making sure the game worked than giving players an idea of what’s going on.
  2. We were learning how to incorporate sounds through a unity plugin called FMOD.

But why did these go wrong?

  1. Well focusing on making sure the game worked than giving player’s feedback is a reasonable answer. There’s no point giving feedback for something that doesn’t exist. BUT, the reason we were still trying to make sure the game worked was because we didn’t properly design all of the systems that were going to be in use. It was a ‘Figure it out as you go’ kind of thing. The amount of time we spent ‘Figuring it out’ or ‘fixing the problems that entailed’ could have been saved if we planned out and designed the system properly. And part of that time saved would have definitely gone towards providing more feedback for players. Sure there’s no issue for time if you plan on never finishing a game. But we did, and we were strict for time. There’s a document that’s been introduced to us that is where we figure out and design all of the systems called a Technical Design Document (TDD). We started off working out a few systems and writing them in the TDD, and then implementing these into our game. The stuff we figured out first implemented really well. But once all of the things we’d already figured out in the TDD were finished and implemented, we continued to power on and continue making the game. We left the TDD behind because at the time it felt like we were making so much more progress actually making the stuff than figuring out how it works and what it’s intertwined with.
  2. We are forever expanding our knowledge on how to do something or make something work, which is fine, there is always going to be a learning curve. And FMOD really isn’t that difficult to wrangle – from watching our programmer set it up. BUT, the reason audio fell behind was because we knew the audio students were creating all the great sounds for our game and we didn’t implement as many placeholder sounds as we should have. Even if they were as blatantly obvious as making speech audio to tell the player’s whats supposed to happen. We had a lot of FMOD committing issues through source tree which was a time killer. But ultimately, we left learning and  incorporating FMOD into our game at the very last second. We left learning and incorporating FMOD at the last second for the same reasons mentioned in 1. We wasted time figuring out a sloppy systems over and over instead of having a properly prepared one and implementing it once. Even though FMOD was new, the only real reason we needed it was for the background music, to connect the intensity of the players radiation, the more they had the more intense the BGM got. But at this point this wasn’t completed either. They every sound could have been implemented normally through unity. Something that all three of our team is aware of how to do, and it wouldn’t have been left to the last second to do. On top of trying to make all of the sounds run through FMOD (which they didn’t need to) wasted quite a bit more time too. If we planned out and documented in our TDD when and how we were going to implement sounds earlier, it would have saved a truck tonne of time.

When the game restarted the mutant’s didn’t start doing what they were supposed to do.

One of the fixes for today was that mutants needed to target every player and target the closest one. Then if one was dead, stop targeting it. We fixed it. But this is a real head scratcher. Because we DID test every build throughout the day on the exact model of computer that was going to be at the exhibition. And everything worked fine. Restarting from any menu worked appropriately and the game continued as it should. But then it came to the exhibition and then when the game was restarted via loading the game scene again. The mutants spawned but never moved. I can’t for the life of my understand why. But it happened. The fix? Every time the game ended, just alt + F4 and restart the game. Because one of our team was always at the computer with our game we could always monitor when the game needed to be restarted. It was a real disappointment but not a deal breaker.

The goal still wasn’t obvious to people who didn’t know the game.

This goes back to the TDD and working out the systems. If we saved time and figured out how to implement our sounds earlier instead of wasting time figuring stuff as we went, we could have recorded ridiculous dialog to bluntly tell the player the objectives.

Players took damage from mutant’s when they were attacking, but also when they touched the mutants.

Analyzing why this happened – It was because the player AI was started. So when a mutant is in range and the character is not selected by a player they are able to attack mutants by themselves. It was set up to have a rather large sphere collider to detect when the mutants were close enough. And because it was a trigger – The mutant deals the damage to the player via OnTriggerEnter via the mutants arm. Because the sphere collider was so large. the mutants detected the players sphere collider which was part of the parent game object tagged as “Player Character” and dealt the damage. Then whilst the mutants were inside the sphere collider and close enough to hit the proper body collider – they could deal damage again. Ultimately this changed the dynamic and difficulty of our game by a great deal. And again, this happened because of the lack of system preparation.

How do we prevent this from happening again?

With the exception of the build and the mutants not working on restart.


I’m really learning this now. Figure out how everything in the game is going to what, and what it needs to work. Because ultimately this will save time and enable more time for all of the things that could have been done earlier.

Until next time –



1 Comment

Posted by on August 17, 2016 in Game Dev, Games


Scripting Time! Transmutation: Menus

Transmutation Main Menu.JPG

I’m no stranger when it comes to making menus. In my ‘Ball Ball Post Mortem‘ I noted that I made a huge mistake of constructing the game in the free aspect mode. I wasn’t going to let this cause me havoc again. So before I started creating any form of UI, I set the aspect mode to 16:9 and made sure that the UI Canvas scaler was set to scale with screen size.

Transmutation Main Menu Red.png

For the simple main menu of Transmutation all that we needed was a play button, instructions button, quit button and an exit instructions button and the code that would make the buttons do what they are supposed to do. The only difference with Transmutation and other menus that I’m used to creating is that Transmutation is going to be solely operated by a controller, not mouse and keyboard. One of the programmer’s had already set up the controller and mapped the inputs for using the left joystick.

Something new that I had to learn was how to get the buttons to be selected with the controller input. I’ve noticed that when I create a UI canvas, an EventSystem always gets created as well. I did some research and watched tutorials on how to make menus work with controllers and it turns out all I had to do (because the left joystick was already set up) was make the FirstSelected object in the EventSystem what I wanted. And I wanted the first selected button to be the Play Button.

First Selected.JPG

I hit the play button and waited for the magic to happen. But no magic was happening. I wondered why and fiddled with some of the buttons settings. Eventually I made the buttons highlight colour when they were selected a bright yellow.

Transmutaiton Yellow Highlight

Because the buttons navigation was set to automatic – they detect where they can go from their position – and the buttons were always directly above or beneath each other they could only ever navigate vertically. Which was the desired effect anyway.

Button Visualize.JPG

The Yellow Arrows Show Where They Can Navigate To

The instructions button brings up a separate panel for the controller. And now that writing that makes me realize shouldn’t the instructions be called Controls? Yes. ANYWHO.

Instructions Panel.JPG

Controller Input

It brings up this panel with a button that allows the player to close this panel and return to the main menu. But when this panel is activated the back button isn’t selected because the games already been started and the FirstSelected doesn’t apply. So there has to be a way to know what the event system is looking at right? There is. It’s called currentSelectedGameObject. So when pressing the instructions button we should make the panel activate and set the current selected to the back button?

Instructions Panel with back.JPG

Selected Back Button

But even within this menu, I could still use the controller to change the selected button to the other existing buttons in the main menu and play the game or quit even while this panel was activated. Like I mentioned before, if we select Visualize on the button it shows where they can navigate to.

Instructions Navigate.JPG

Back Navigation

The back button could still navigate to the other activated buttons. To fix it, I figured if they weren’t activated they couldn’t be navigated to. Turns out, I was right.

Transmutation Main Menu UIController.JPG

The only other thing that was different and new was using a newer version of Unity where Application.LoadLevel(value or string) had been made obsolete. It still works, but in the next version of unity (from my understanding) it won’t. So why not get into the habit of using the new version now. The new way requires the script to have access to using.UnityEngine.SceneManagement. Then instead use SceneManager.LoadScene(Value or String).

The exact same process was used when I was creating the game over menu that get’s activated by the elevator. Except if they win, it shows a happy face – If every player doesn’t survive, it shows an unhappy face.

Until next time –



Leave a comment

Posted by on August 3, 2016 in C#, Game Dev, Games


Tags: , , , , ,

Scripting Time! Transmutation: Character Switching

Character Switching 0

The latest game prototype ‘Transmutation’ requires the player to be able to control 3 playable characters – but not simultaneously. As it is, the player starts playing the character on the right, we’ll call him Mr. Broom. The other two playable characters Pots and Meat are currently sitting idle. There needs to be a way to switch playable characters – this blog will cover how I made it happen.

An appropriate place to handle the switching would be the GameController. It will end up having multiple scripts, one of which I will set up to only handle the character switching. This script is called ‘CharacterSwitcher’. In order for the character switcher to be able to switch characters it’s going to need to know:

  • What three playable characters we have in the game.
  • What camera or how many camera’s we are using.
  • The position of the camera’s or the positions of where an individual camera will move to.

There are only ever going to be three playable characters, but how many camera’s are we going to use and why? Three cameras and always have them be in the positions they need to be and just activate or deactivate them when needed? Or have a single camera and move it to desired locations?

I chose for the game to only operate on a single camera and move to the position it needs to. Purely because of wanting to always have a consistent view on the game world. Plus it would enable us to do something like an ‘XCOM’ game. Lerp the camera between the player’s its switching between except our camera is a fixed 3rd person perspective from behind the playable character.

So now that I’ve decided on a single camera I’ll set up the CharacterSwitcher script to know what it needs.

This slideshow requires JavaScript.

Character Switcher Camera Spots.JPG

The camera spots are empty game objects that are a child of each of the playable characters. They each have the exact same local position behind each character. Now that the GameController know’s what it needs and has them – I need to devise a way to switch between them. Speaking of switching, why not use a switch statement? The GameController will need to know which character is currently selected and which one it needs to go to.

This slideshow requires JavaScript.

In Start(), tell the GameController we are controlling character one. Everything is set up, now it just needs a way to actually switch. I made switching right E and switching left Q for the time being until we learn how to set up the game with a controller. I called these methods straight in update even though they didn’t exist. On many occasions I’ve created complex methods that never work because I create the system and never call it. This time though, I’m going to completely avoid that.

Character Switching Update

This slideshow requires JavaScript.

The switch statement checks which character is currently selected – and as of start, it’s playable character #1. When ‘E’ is pressed it switches to playable character #2. The <CharacterController> script is the script attached to the playable character that allows the player to control it (if the name wasn’t obvious enough). Each time a switch happens, it gets the current playable character – deactivates its control script so it can’t run around, moves the cameras position to the next playable characters camera position and changes the switch statement to the current character.

*video of Switching*

It’s not Lerping as of yet, but that’s a task for another day, it currently serves it’s soul purpose of switching.

Until next time –



Leave a comment

Posted by on July 29, 2016 in C#, Game Dev, Games