29th August '14 by Jaime Cross
This is one follow up to my previous blog which discussed storytelling in games. You can give it a read here. My original plan for the second part was to speak about the use of sound effects in story telling and world building, however I thought it'd be an idea to talk about how we're actually going about the music side of things ourselves!
In Monstrum we are aiming to use both diegetic and non-diegetic music for a few different purposes. The most obvious use of non-diegetic music are the monsters' themes, so let's start there. Simplifying some statements down a bit, these are used to provide information (i.e.: the monster is chasing you), context (which monster it actually is) and emotional content (trying to evoke a certain feeling). I've spoken about the “hows” of the Brute's theme before in detail here, including of the sound design that's used, so I'll give you a little summary of the decision making, the “whys”, that went behind it and what I was hoping to achieve.
First, let's talk about the Brute's musical flow:
Here we can point out how the musical themes provide information and context. There is the initial Wandering theme, which is used as players walk around the ship before being spotted by the monster.
The information players can learn from this is that they are "safe", but it is actually quite interesting due to the lack of context it provides. In a game that is going to be different every time you play, it doesn't make sense to give everything away from the beginning. It seems obvious, but it ties into how the Stalked theme is used and how it replaces the Wandering theme. You now know what else is on there with you, so the original gap in your knowledge has been filled, but you are also not actively being chased or hiding, which is when the Wandering theme usually plays. So while the information remains the same, the context is different, and this new emotional content is represented musically.
Brute Stalking theme
Each monster also has its own Stalked theme, which utilises some of the thematic and instrumental motives that are established in the Chasing music .
Brute Chasing theme
The Brute has an almost constant, unflinching rhythm during his Chasing theme, provided by the pounding drums, cymbals and background pulse. This is to reinforce his nature as a physical, charging force that has a singular focus and goal. On top of this are the metallic, almost mechanical screams and squeals that sound like metal buckling under strain. This was mainly an emotional content decision. I wanted the listener to feel uncomfortable slightly stressed while being chased because, well, it would be. I also wanted to somehow represent the ship in the music, so this was a decent compromise too as it also plays into some of the randomised creaks, thumps and squeaks that happen as you explore. These are the elements I bring back into the Stalked theme, because trying to sneak around while drums thunder in the background is somewhat jarring...
Anyway, time for something a little newer:
We're been working on the Hunter, so here's a little snippet from one of its themes. I'll do a more detailed break down of the hows and whys behind it later on though, because
Jonesy The Guardian watches for any and all leaks.
Now a little about our use of diegetic music, and how we're using it to build up the game world. Diegetic audio is something that has a source on screen or in the game (or film) environment. Basically the characters on screen would be able to hear it. I've briefly spoken about the radios in a previous blog post, and their implementation has evolved a bit further since then.
The 70's was an interesting time for music, with lots of genres and sub-genres coming into the mainstream. There are a few common musical tropes that hang over from that era, such as funk, disco and punk, so if we're going for general world building and theme setting it makes sense to focus on the easily recognisable ones. Canterbury Prog would probably be lost on a more than a few people. So how are we going about integrating these ideas into the game, and why do they have to be diegetic in the first place?
Also heard in our trailer...
From a gameplay perspective we are using them as part of the distraction mechanic. In Monstrum each monster will react to sounds that occur in the game world. For example, if you run around and throw things about a lot then the monster's more likely to hear you (and thus chase after you) compared to you walking around quietly.
Here's where the radios come in. Being a portable usable item they can be thrown into rooms, corridors, whatever you like, while active and will act as an audio source in the game world. As the music is coming from a specific object, we have also tweaked the song so that it sounds like it's coming from a fairly bad mono radio, like the character and monster would hear it, as opposed to the general themes that are “just there” in the background. This makes logical sense for how the item is used, and also proves a sense of place for the player and their interactions.
For an extra trick the “signal” deteriorates as you go further into the ship's underbelly. This has a few benefits, one being that it serves as a rudimentary compass, but it also helps keep the tone of the darker, grittier areas intact, as a funk track in the middle of the cargo hold maze might dull the atmosphere a tad. While these would be perfectly functional just emitting noise, the opportunity to do something a bit more interesting on the whole was too good to turn down.
And that's why these films will have soundtracks
We're hoping to have the record players with different (and possibly even swappable) LPs working at some point soon too, although these will be stationary sources.
Hopefully this'll give you a bit of insight as to how we're doing things and following our own advice :).
29th July '14 by Adam Dart
Time for another art blog. This week we are working on ship lighting!
With the new fuse system in place players are now able to power on/off different parts of the ship, which includes the lighting.
The player should find it difficult to navigate the unpowered sections without light but we do not want it to be entirely impossible so we've had to create two different lighting schemes; One for each section in a powered state, and one in an unpowered state which consists of the ships emergency backup lighting.
We wanted to contrast the two states as much as possible, building tension with a darker, colder colour sceme consisting of green and blue light whilst easing the player with a much warmer and brighter scheme as part of the reward for when the player powers up a section.
Currently we are still setting this up in the game, however I can show you some examples of these schemes in Unity....
Upper Deck Lighting scheme in the "Powered On" state.
Upper Deck Lighting scheme in the "Powered Off" state.
Upper Deck Room in the "Powered On" state.
Upper Deck Room in the "Powered Off" state.
Lower Deck Corridors in the "Powered On" state.
Lower Deck Corridors in the "Powered Off" state.
Container Room Walkways in the "Powered On" state.
Container Room Walkways in the "Powered Off" state.
That's all for today.
Adam and the Arts
24th July '14 by Jaime Cross
Today's blog is based on an event that happened as part of Abertay's Game Lab, loosely based on the topic of "story", and how people from different disciplines tackled it in games. I was asked to provide an audio perspective, and given that I'm usually better at explaining things in written form than verbally (shocking, I know!) I decided that I'd expand and clarify a few points I spoke about and why I think they're important. This will be the first of what will (hopefully only) be a two part blog post, and will have a few spoilers here and there, so heads up!
What is "Story" anyway?
The word "story" itself is a bit of a nebulous term. Most people would associate it with some form of narrative, such as the Hero's Journey, that follows one main protagonist or group of people through their various trials and quests to some sort of resolution. But is that it? Is that everything that's being told? Does the entire game world merely exist around the player character(s), with everything only being relevant them? What about everything else: the details, the history, even the context of the place and situations that you may be in. Going from A to B through C becomes much more engaging and involving if there are different forces, details and subtexts at play instead of "because that's where you need to go".
Basically, how do you "build the world"?
Worldbuilding is something I try to push a lot when it comes to audio, and there are a few different elements that I consider when doing so. There's the obvious, how things sound, to slightly more subtle stuff like communication and providing information, and not necessarily though speech and voice acting either. Sound is one of those things that people will immediately proclaim "This is super important we must have it" but not really have a solid explanation at to why it is, often jumping on the cheapest/closest/first thing they get after their game is finished as they needed some random noises to finish up.
A game must "sound right". This doesn't mean that it should be a one-for-one replication of real life sounds that are dropped into the game using real life simulations to make sure that the game sounds SuperReal™. Realism isn't always "right", appropriate or even possible, as any designer will tell you. From a sound perspective: real guns sound nothing like guns from films and especially games, and I have some bad news for you if you're into laser noises. But how do you determine what is right for your game? What sort of things do you need to consider when making those choices too?
Let's start with how music is used first. If, again, we were going for "realism" then your player would probably need a set of headphones to hear all the music that's going on. Alfred Hitchcock allegedly complained about the use of music for his film "Lifeboat" saying 'Where, then, did the orchestra come from?' The composer, Hugo Friedhofer, responded with 'The same place the camera came from, Mr. Hitchcock.'. This use of music that exists outside of the film/game world is called "non-diegetic", and is not heard by any in game character. In terms of story, you can use this to provide context to a situation, like a lot of "Final Fantasy" games do.
Would he have been even sadder if he could hear the orchestra in the background?
Similarly, it can also provide context to a place or person in the game world. Leitmotifs are nothing new, generally popularised by Wagner in the 19th Century, but chances are when you hear this theme (and variants) you know what sort of area you're in, what gameplay elements may be involved and what types enemies lie ahead. Similarly if you hear this one then you know who is about to appear too. Even main themes can say a lot about what is going on. "Papers, Please"'s stark, military style anthem plays on old Soviet/Eastern Bloc tropes to set the scene of the game rather effectively before any explanation is given.
But games have the advantage of being non-linear, meaning that music and sound can provide additional context and information without any additional visual cues in a manner that films and cinematic scenes can't. This can be a basic thing, like the music speeding up in Mario games once the timer hits a certain point. This allows the player to focus on what they are doing rather than a timer off in a corner away from the action. Here's a great breakdown on the music systems in Capcom's fighting games by Axel Speller that's worth reading. It details how the music changes depending on a player's health, the current stage, themes and even the effects of restarting the music for each round as opposed to letting it continue on.
Getting back on point, music is also key in building up the world. "NieR" is an excellent example of this, not just due to its sublime score, but the fact the use of vocals throughout is related to an in-game character who has been keeping watch over the player characters throughout the game. While still non-diegetic, there is an over arching unity with the score, the world and events in the story that bind them together. Similarly "Grim Fandango", with its Dia de Muertos theme combined with film-noir aspects, would just not be the same without the latin-jazz and big band score than runs through it, accenting and playing off of the visual and narrative themes. Appropriate genre choice is something that can bolster a game's feel and hold on a player. Imagine playing "Far Cry: Blood Dragon" or "Hotline Miami" without their 80's influenced, synth heavy soundtracks, instead replaced with the standard orchestral or modern electronic OSTs that ignore the source material and influences that these games are built upon?
But what if your character actually has headphones on or is listening to a radio? We can use “diegetic” music in these instances that give music a source within the game world. Instead of the background music being from nothing, the placement of an emitter like a radio gives it a reason to be there within the context of the game world.
This is an advantage in world building too, as it allows you to give a game space its own musical culture. In the aforementioned "NieR"'s first town you can enter a tavern with a musician, who will play songs about the world's history in their own language, as well as composites and variations on other, real life languages. This implies that this world doesn't exist around you, the player, but has a past and present that has and is happening all the same. On a side note, talking to her means that the singing stops as well, as it would in real life! "The Legend of Zelda: A Link Between Worlds" provides some fanservice in a similar manner, with the bards in the Milk Bar playing variations on classic themes from the series.
After being introduced to Professor K at the start of the game, "Jet Set Radio" takes the headphones comment and runs with it with its funk/hip hop/pop soundtrack seemingly coming from Prof. K's pirate radio station straight into the player character's headset. Given the game's focus on self expression and fight against authority, it's these little touches that further solidify the player character's place and ambitions in the city of Tokyo-to, and the culture surrounding the graffiti art and skating.
Beat from "Jet Set Radio". Note the headphones!
On the topic of radio stations there's also "Grand Theft Auto", which goes all out in its use of diegetic music in cars. On the world building standpoint, the multiple stations and personalities imply that it's not just your character in the city that is able to do anything, any other person in that world could be listening to one of the radio stations available.
But the beauty of GTA's system is how it's implemented. The radio stations are played in cars, but unlike the above examples they are played in a space, as opposed to merely being in the background. This means that the sound you hear changes depending on what environment you are in, with it being more muffled outside of cars as one example, but in GTAV the radio signals themselves can drop out depending on where you are in the world. There is also some character interaction with radio stations in the game too. Should you be driving with Trevor in the car he'll change stations if he doesn't like what he hears. There is a lot more on how the game's audio works in this GDC talk, including their music system, that is interesting viewing.
These are only a few examples of what to consider and how to use music beyond merely window dressing or “because it's needed”. I've stuck a few links below that cover various aspects of music in games as well as some of the topics I discussed above. So hopefully it'll be of some help! Next time I'll talk about how sound effects can be used in story telling and world building.
Karen Collins - Game Sound: A fairly detailed look at the history of game audio development
Michel Chion- Audio-Vision: One of the most important books on film audio theory, which is easily carried over to games.
Winifred Phillips - A Composer's Guide to Game Music: A great starting point for composers looking for info on game music and what's involved.
Dan Bruno - Dan Bruno is a developer over at Harmonix. He ran a blog called Cruise Elroy which went into great detail about the music theory aspects of a fair number of games. He only has his "Ocarina of Time" series on his new blog, but you can find some of the others that have been archived.
Alastair MacGregor - The Sound of Grand Theft Auto V (GDC Vault)
The Music of NieR (Wikipedia)
Alex Sheller - Fighting Game Interactive Music Study
The Hero's Journey/The Monomyth (Wikipedia)
21st July '14 by Team Junkfish
Hey Grant here again,
In my last blog I mentioned a concept that I refer to as 'Responsibility'. Now I'd like to talk some more about it and how it is used in a couple of my favourite games.
What do I mean by this?
Basically the player should be able to trace back a particular outcome to either their own skill or a decision they made.
'I didn't react quickly enough to that boss's attacks'
'Whew! I made the right call!'
'I jumped too early'
'I should have put that unit somewhere else'
It's the flip-side of player agency; by making sure the player is always in control of what their character does we aim to make them feel responsible for their ultimate success/failure.
Why is this a good thing?
If it's clear to a player what led to them getting killed – be it poor choice, action or even just inaction – they will make a note of it and try to do things differently next time. Hopefully the feeling of having learned something reduces the frustration caused by failure, as it means that even in defeat you are improving. The same is true for victory; if they can trace a success back to their own skill it shows their progression as a player and even if they ultimately lose it reinforces the feeling of 'Well I'm getting better, maybe the next run will be the one!'
Examples in other games:
Here are two examples of recent games that I think implement this concept really well. As usual I highly recommend them, especially to those interested in a challenge.
XCOM: Enemy Unknown
A tactical strategy game where the player must save the earth from alien attackers by adapting their technology and using it against them. XCOM offers a lot of meaningful choice in the form of decisions such as:
Which technologies you should research first, which affects what equipment you will have at each point in the game
How best to spend your scarce resources on this equipment
Which missions should be picked, with the ones you don't pick having small negative effects that build over time if left unchecked.
These are all part of the base management section of the game, and all are related to Responsibility, but the parts I want to talk about here are the combat missions.
The missions in XCOM involve you giving orders to a small squad of soldiers, moving them carefully about a grid trying to kill or stun any aliens they come across. It's basically the closest thing to 'Wizard's Chess' we're likely to get. Your tactics are very important here as your soldiers' armour has all the hardiness of wrapping paper and they will crumble into dust after a couple of hits. This means that if you make a poor strategic decision, such as ending your turn with a troop out of cover or spreading the squad too thinly it is almost guaranteed to result in someone getting killed.
While there are absolutely situations that feel like there was nothing you could have done, these are few and far between. Most of the time you are able to say 'Nope, I shouldn't have done that. That was a mistake' and the fact that you can name your soldiers only adds to this feeling. It's hard not to feel guilty and even a litte upset watching a soldier with your grandmother's name survive 19 missions, become a glorious world-destroying badass, then get suddenly blasted into mush because you were too hasty in trying to kill one enemy. Sorry Granny C, but without a proper strategy your jet pack and plasma shotgun were useless.
They might as well replace those stats with "Just 3 days from retirement"
A procedurally generated platformer that is absolutely ruthless. Spelunky is the purest form of this design philosophy; every single death is due to an oversight on the player's part. You didn't look down before leaping and land in a spike trap. DEATH. You throw a rock at a crate of explosives and find it launched back at your face. DEATH. You smash a pot to grab some treasure, only to find a spitting cobra inside. DEATH. All of these can happen in a split second and before you have time to register what happened you get the game over screen, complete with a replay of your demise and a little bit of text explaining just how you fucked up.
Now you're thinking 'A-ha! So if I just take my time and check everything I will be fine!' Nice try but WRONG. Even forgetting the unavoidable situations and enemies that require rapid-fire reaction times, if you spend too long in a level (say because you stop every few steps to check ahead), an unstoppable, insta-killing ghost will appear and begin chasing you. That's right, this game punishes both being too hasty and being too cautious.
Spelunky forces the player to strike a balance between moving as quickly as they can while also giving themselves as much time as possible to check the environment for hazards. This means that even if you are aware of every trap, enemy and dangerous situation that you can run into, there is still a chance you'll mess up your timing and get killed. And you will have only yourself to blame.
This explosion was caused by my own bomb. Yeah...
How are we going about it in Monstrum?
Well for starters we are trying to give everything dangerous some kind of signpost. Any sounds loud enough to alert the monster will be loud enough that the player should notice them. Every trap will be visible to a vigilant player and no room should have only one entrance and no hiding spot, there should always be a way out if players are skilled and clever enough. In addition we are working on some new systems to give the player more control of how their playthrough will go, increasing the impact of their decisions on their chances of success. More on that later
While all this may seem at first like we're making things too easy, remember that one of three deadly monsters could come round the corner at any moment. That stress and the pressure to keep moving make it harder to stop and carefully scan the environment for dangers. Being chased is even worse, in fact that is when a player is most likely to run into some kind of danger. Monstrum requires constant vigilance and quick reaction times if you are to survive and make it off the ship.
I hope this blog and the previous one on choice (assuming you read it) have given you an insight into the kind of game we are trying to make. The reason I have chosen now to discuss these design decisions is that several upcoming blogs will probably reference them. For example you might see something like:
So why are we putting this feature in Monstrum?
and those of you who have read these blogs will understand what I am talking about.
And as a thank you to those people, here's a gif of the (currently empty) cargo maze
I have to go now, my planet needs me,
16th July '14 by Andrew Bean
Today I'd like to talk about the occlusion culling process used in Monstrum. As good as Unity is, we couldn't use its culling support since it doesn't support dynamic occlusion. Additionally, our light culling system was overhauled as well using a completely different system to the one we had before.
We tried everything. Well, maybe not everything, but we did go through quite a few techniques before we got to this one. We tried cheaply rendering the scene and processing the image to look for renderers. An improvement, but it had an unavoidable expensive function call to get the texture off the GPU. We tried culling with raycasts from the camera every frame to get the renderers. Too many raycasts were necessary to see everything. We tried culling our culling raycasts. It worked in smaller rooms, but as soon as we entered a larger room it somehow ended up doing even more raycasts than before. Fantastic.
Well, we now have a solution. Or at least a better solution. It isn't perfect, but it breaks in places we should be able to avoid. I don't know if this method already has a name, or if there is something that was overlooked that can make it more generic or something. But here goes.
The culling starts by setting up a grid encapsulating the ship. Each node on the grid represents a cuboid the size of a corridor piece, and stores information about what nodes it can see, and what renderers are inside it. This is used for storing the occlusion data. Each time the camera changes what node it is in, the node at the camera tells all the nodes it can see to enable the renderers associated with them. Simple. The tricky part is working out what nodes can see each other, and this is the bit that is new.
Each node raycasts up, down, left, right, forward and backwards to figure out whether it can see the node immediately around it. This creates a graph of the level that we can traverse. You might notice that raycasts won't necessarily generate the most accurate graph. You would be right! It does have surprisingly few errors actually, but we will likely generate a much more accurate graph later to iron out the kinks.
Next, the core algorithm kicks in. To find out what nodes a given node can see, the graph is traversed using a flood-fill method, with a few modifications. Any node we expand in to is added to the list of nodes the camera node can see. The modifications are used to stop expansion in to nodes we won't be able to see. We are currently experimenting with both real time and baked versions of this process.
If the angle between the expand direction and the camera's forward is > 135° , disallow expansion. This forces the flood-fill to spread out vaguely in the direction of the camera's forward – the bit we really want to see. (Real time only)
A node is prevented from expanding when its centre is outside the camera's frustum by a small margin, since only stuff in the field of view will be rendered. (Real time only)
Nodes that are reached by going around a corner 'too much' are prevented from expanding. This check is not done in open areas, since corners won't necessarily occlude.
Once the path goes right, it can't go left (and vice-versa). This is because going left after a right would result in a U-bend that can't be seen around.
An advantage over the other systems we tried was that this is all CPU-based and didn't rely on expensive API functions like GetPixels() or raycasting to work, meaning we have greater control and flexibility over how it works.
Last time I talked about this there was a system to determine if a light should be on, using a render of the scene and use of special colours. We scrapped this in favour of a new simpler system. Lights aren't actually that expensive in Unity, but shadows are, meaning if we can reduce the number of lights with shadows, we are 90% of the way there.
Effectively, the new light system fades light shadows over distance. The only trouble with this (and this is something we wanted to avoid) is that far away lights can bleed between rooms. Our solution to this is just position lights well so that they don't. Additionally, there are some lights that end up casting large shadows, and these can be quite jarring when they fade. Fortunately, we can usually identify and workaround these on a case-by-case basis.
I hope you found something of this interesting! Until the next time!