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 explaination 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, miltary 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 devloper 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!
11th July '14 by Jaime Cross
We've got some pretty big news to announce that may disappoint a few of you: we have decided to officially push the release of Monstrum back by a few months to January 2015.
This isn't something that we've taken lightly, but truth be told we don't think Monstrum will be at a level that we as devs, or you as players, will be happy with by our original release date. We've had a lot of feedback from the people who we've shown it to, and are incredibly amazed and happy for the support people have given Monstrum so far in its early stage. As such it is on us to make sure that the game is as good as it can be, even if it is a little late.
Some of you may ask about making the game available through Early Access too, and while that is a possibility we still think that it is not the best fit for Monstrum just now. We're making a horror game, and we want to make sure that the horror factor can't be undermined by some of the silly/funny/game-breaking bugs that may happen in some Early Access games. That doesn't mean that we'll never do it, but we want it to be at the point where you get a decent experience even if the game is incomplete.
In the meantime you can keep up to date with Monstrum's progress on our dev blog, Facebook and Twitter feeds.
Thanks for your understanding and patience,
9th July '14 by Adam Dart
It's time again for another art blog post!
Now that we have the basis of our container section working in the game I can talk to you about a couple of small challenges that come with building art assets for procedural generation.
Within this new area the player needs to navigate through a series of broken containers which are all stacked up against each other. Due to the procedural systems in place, we need the containers to be built to allow the system to lay them out to form a coherent path through this section of the ship. Because of this we need to build a large amount of container variations to allow for every single type of corridor placement. This system works in a similar way to how our corridors are spawned.
Modelling and texturing all the different variations individually would take us far too much time, so we needed an efficient way of doing this. We split the faces of the standard container, leaving us with 5 main pieces: The sides/top, the back, the front doors, the floor, and the frame of the container in which the faces are placed into. Additionally, we needed broken variations of each face of the container, excluding the frame, for the player to move through.
Once these are made, all we had to do is swap out the faces of each container piece to form the appropriate path, combine them into one mesh, and then export them to go into the procedural generation system.
However, by having everything work within a grid system the scale of objects need to be very specific and when working on making assets to realistic proportions, it can generate some difficulties when they don't necessarily fit.
This led us back to the classic door problem...
To get into some of the containers, the player would have to open these doors to get into them. The problem was that containers in the hold (stacked to the brim) meant that there was no room for the player to open them. This proved fine for the doors on the inside as they were smashed open to create a path, but for the single containers on the edge of the hold we needed the occasional openable door for the player to get in.
The default container doors were far too large and the space between the ceiling and floor meant that the doors would clip through them as they were not paper thin. We could not scale the size of the container frame as it had to fit into the grid, and the container would look incredibly wrong with 2 doors of different sizes.
In the end, I decided to make an additional door variation :
A doors within a door! ( I am so happy this exists!)
The smaller door on top of the larger one meant that the door was small enough to fit into the walkway segments when open, and was large enough to fit into the frame of the container. This allowed us to have both variations of door which solved our problem!
Tait also came up with a creative solution to generate a large amount of colour variation on the cargo containers using only a few texture maps.
The idea was to use a base texture and change the saturation within unity to give us many colours using one map. Doing this however, meant that small details such as rust and any painted materials other than the one we wanted would also change colour. What he did was create a decal model slightly over the original which he put on an alpha texture, separating the paint layer that would change colour and the rust layer which does not change, giving us realisitc looking colour variations.
To finish off this blog, we'll show you some of the content we've created to fill up the insides of theses containers. We've got a couple of stranger things in there, but I'm not going to show you any of that to save them for the final game, so here are some of the more generic things we have made...
We're working on a pretty cool section of the ship next which is also pretty secret (Something you'd maybe see in a James Bond Movie!)
If I told you, I'd have to kill you.
.... so look forward to the next blog!
Adam and the Arts!