Pre-Brass Razoo Rush

17 Aug

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


One response to “Pre-Brass Razoo Rush

Leave a Reply

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

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

Google+ photo

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

Twitter picture

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

Facebook photo

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


Connecting to %s

%d bloggers like this: