Latest News


Programming Blog 12 - The Journal

9th September '14 by Andrew Bean

Hi guys!

Today I thought I'd explain how the journal system in Monstrum is implemented. The journal is our equivalent of a quest/mission log in many other games, and has a few noteworthy features:

  • It is diegetic, which means it exists in the game world itself, instead of, for example, being rendered on a 2D plane in front of everything else. We chose a diegetic interface as it is generally more immersive, and also works better for the Oculus Rift.

  • The information in the journal is rendered on the page itself, following the curve of the paper. This makes the journal feel more natural than, say, having text float above the page.

In order to create the effect of having the UI rendered on to the page, the journal model is first split in to two - the cover and the page. This is so the two meshes can be UV mapped separately. The cover is just a standard model, but the page is UV mapped with (0,0) in one corner to (1,1) in the opposite. A separate camera is pointed at a custom UI system and draws to a RenderTexture that is displayed on the page. At this point, we can see the journal info on the page. The trouble is, we can't interact with it!

To solve this second problem, we have to start with the player.  The player starts an interaction with any given object by looking at it.  Therefore, we raycast along the camera forward, looking for the collision mesh of the journal page. If we miss, the player isn't looking at it. If we hit, how do we know where on the page they are looking? Well, Unity provides the texture coordinates of a hit from a raycast. These will be mapped between (0,0) and (1,1), as defined earlier by the UV map. All we need to do now is use the Camera.ViewportPointToRay function, and cast the returned ray, masking for our journal UI elements. At this point we can do whatever we like with the returned hit data (button clicks, mouseovers, positioning the journal cursor). Hooray!

I hope this technique may be of use to someone!

- Andrew


Art Blog 18 - Life in the Deep

5th September '14 by Adam Dart

 Hey All.

Once again, we've been working on some super cool stuff that we would rather keep secret for now. However, I thought I would share some interesting videos that may, or may not be related in some way or form. (Maybe even set the mood by watching the first 3 whilst listening to this playlist of the Alien soundtrack... )

1 – Macropinna Microstoma. A cool semi-transparent fish.

2 – Squid versus Fish

3 – Life in the Deep Sea

And one last one...

Take from this what you will.....

 

Adam and the Arts.  


Design Blog 10 - RTFM. On Procedural Tutorials

3rd September '14 by Team Junkfish

Hey, Grant here, making another ham-fisted attempt at arranging words to form coherent sentences.

Procedural games are a tricky business. As I've mentioned before, when you aren't in strict control of things like the level layout and scripted events it adds a whole host of design considerations. One of the most important of these is how you actually teach the player to play the game, and this blog will discuss some approaches to this problem. But first, a little history.

In days of yore

In the early days, back when the market was young and game design wasn't well understood, many games took the standard software approach to informing users which was just to supply a manual with the product. The player was expected to read this to learn the controls, systems, and sometimes backstory of the game.

With the rise of consoles and the growing complexity of games, tutorials have become standard. Manuals still exist but they're really just tokens now, little books that add weight to the box likely included because many gamers (myself included) have a sentimental attachment to them. In fact with the popularity of digital distribution the idea of a modern game without a tutorial is unthinkable.

The problem with procedural games

Most games implement tutorials mainly as an early part of the game, usually an easy section with no threat of failure and often worked in to the story (e.g. boot camp/training for military games, escaping jail for stealth games, etc). Tutorials are usually as long as a game needs them to be ranging anywhere from a few minutes to several hours. Sometimes they are spread out through the entire game, explaining new mechanics as they are introduced.

This formula doesn't really work with procedural games, which are made to be played multiple times. Having to play through the tutorial section over and over again would quickly get tedious, especially if it takes a long time to complete. The general idea is that players should be able to jump in and play once they know what to do.

How do other games solve this?

Different games get around the tutorial problem in different ways. Games like Daylight, Binding of Isaac and Eldritch give the player all the controls right at the start then turn them loose, gradually introducing item and enemy mechanics through gameplay. This means that new players can read the instructions and take their time getting used to the controls, whereas experienced players can just get on with it.

 

The first room of the game, plenty of time to memorise and play about without any threats

 

Other procedural games, such as FTL and Spelunky, take a different approach. Since they have more complex controls/mechanics they run with a more conventional system and have a short tutorial section. How they avoid repetition problem is by separating the tutorial section from the main game and making it optional. Interestingly enough this approach isn't actually unique to procedural games, for example Deus Ex had this system back in 2000 which shows the developers expected people would play it more than once. (And by god they were right, the game even spawned a meme to that effect).

How are we doing the Monstrum tutorial?

Honestly? Right now we're not 100% sure, but we do have some plans and ideas. We are in an unfortunate situation where neither of the aforementioned solutions alone will really work for us. The things we want to teach the player to start off with are a little too complex for the first, but not really extensive enough to require the second. Our first approach was a combination of the two: a small section contained entirely within the first room that new players would play through to learn controls and a few necessary mechanics while experienced players could breeze through in around 10 seconds and then get on with the game. However we found that even at such a short length, this became frustrating to play through each and every time the game was run. In response we then stripped this section down to a much more basic form, but this resulted in us not being able to teach the player as much as we wanted to, so currently we are revising our approach.

What we're aiming for now is a more spread out tutorial system, teaching the player as they go through the game. Ideally how this should work is that when the player encounters a new mechanic, they should already have the prerequisite knowledge on how to interact with it, with just a little help from us to guide them. To do this we plan on using:

  • On-Screen Prompts

    • Ideally we'd only like to text prompts for initially teaching the player the controls, because we feel that constantly seeing text onscreen (e.g. “Press F to pick up” every time you look at an item) would break the immersion that we're trying to create.

  • UI effects

    • E.g. Highlighting items that can be picked up, changing the reticle icon when looking at an intractable environment piece, etc.

  • Journal System

    • The player has a journal that tracks their current objective and gives them hints about what to do next, which combined with what they already know will allow them to complete it. E.g. They find a fuse box and gain the objective of finding a fuse and restoring the power. By the time they have found the fuse and returned to the box they should already have learned how to pick up and use items (Prompts) and that they can interact with the fusebox (UI effects)

  • Strategic Item placement

    • A difficult one to explain so I'll just give an example. At a later stage in the game the player will be required to grab and move a large environment object, however before they can do this they will need to reach a switch somewhere else in the room. What we could do is block the path to the switch with the movable item, so that by the time they actually need to move it they should already know how to do so.

 

We are also considering the idea of providing a setting to toggle parts of the tutorial (Such as prompts) on or off in the options menu. That's all I really have to say for now, but if you're at EGX at the end of September you can see these systems for yourself! Because we will be there! With the game! Subtle hints!

 

Avg Coherency Rating: 46%,

Gra-WAIT. HOLD UP A SECOND.

 

Wait a minute right here. I wrote a blog without sharing stuff I think is cool! This will not stand, I must post something, but what should I choose? My favourite tutorial sections? Sure here you go:

Call of Duty 4: Modern Warfare 

What I like about this is that it records the time taken on the course at the end and recommends a difficulty based on your performance. That's neat! That's a neat thing!

Star Wars: The Force Unleashed

Holy shit! Did you see that bit with the gate? In addition to making you feel like an absolute badass while you learn the controls, the game is also teasing the kind of world-destroying power that you will have by the end of the game.

Also check out Egoraptor's Sequelitis episode on Megaman X for an example of a fantastic tutorial. (Language warning though. Language. Warning.)

There we go. Now I can sign off properly.

 

Avg comma to word ratio: 7:1.

Grant.

 


Audio Blog 07 - Story in Games Pt. 1.5: The Music in Monstrum

29th August '14 by Jaime Cross

Ahoy!


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:


Sorry artists...


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.

Wandering Theme

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 :).

Cheers,
Jaime


Art Blog 17 - Lighting Re-Visited

29th July '14 by Adam Dart

Hey everyone!

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