Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411517 Posts in 69377 Topics- by 58431 Members - Latest Member: Bohdan_Zoshchenko

April 27, 2024, 11:29:17 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsMonstrum (Now released!)
Pages: 1 2 [3] 4 5
Print
Author Topic: Monstrum (Now released!)  (Read 13599 times)
Mr. Virus
Level 0
***


View Profile WWW
« Reply #40 on: July 31, 2014, 05:47:30 AM »

So the programmers are currently working on culling (among other things) just now, and one of them wrote a bit about how they're going about it Smiley. Might be of use to anyone using Unity! The original post is here: 1 

---

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.

Geometry Occlusion

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.

Lighting Occlusion


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.

 
Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #41 on: July 31, 2014, 06:54:52 AM »

Very interesting hearing how you are overcoming Unity's few limitations. It would be interesting to see a .gif of the player moving about as the different areas are rendered.
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #42 on: July 31, 2014, 07:47:12 AM »

I am forever bugging them to make .gifs so will say ha ha!
Logged



Tait
Level 0
*


View Profile
« Reply #43 on: July 31, 2014, 08:22:10 AM »

Hello, artist here  Cool I do a fair chunk of the textures on Monstrum.

Rust can be tricky but as long as you are constantly checking references and iterating on mistakes then you end up with acceptable results. There are tons of ways metal can decay too, so it can take a while to understand... I'm still learning tons!

Now that I'm here I'm happy to tackle any art questions y'all might have  Durr...?
Logged
jctwood
Level 10
*****



View Profile WWW
« Reply #44 on: July 31, 2014, 09:42:56 AM »

Thanks Tait! I was wondering if you are fans of Bioshock because I get a lot of those vibes from some of the images posted.
Logged

s-spooky g-g-ghosts
Level 2
**



View Profile
« Reply #45 on: July 31, 2014, 10:09:55 AM »

@Tait
Before even getting to your post I was just scrolling through the images and thinking to myself that those are some fine textures right there. I don't want to ask stupid questions, but I have no experience with texturing and I was wondering what do you start with when you're preparing textures? Do you assemble the textures out of multiple images?
Logged

Tait
Level 0
*


View Profile
« Reply #46 on: August 01, 2014, 04:25:12 AM »

@JctWood
Yeah I feel it's safe for me to assume that most of us here are fans of Bioshock, we get that question all the time Smiley

@spooky
I don't think there's many stupid questions when it comes to this and that's certainly not one of them! We typically build our textures from scratch in Photoshop. First, I tend to get my base colours (a simple diffuse) and combine it with basic normal and specular maps to get the object to look like the right material.. wood, metal, plastic etc. From there I slowly layer up weathering effects, rust, dirt etc using various brushes and masks to bring it to life a bit more. Sometimes i will use an image of the real life counterpart and overlay it with a low opacity to define it better. Though, I'll carefully mask parts out and make it fit in with the rest. But this isn't really done much.

I've made some dedicated material .PSDs of metal, wood etc with a bunch of different dif+norm+spec layers so rather than building a texture from scratch each time, I can open up these and have all the basic groundwork already covered.

Some objects can be very generic so I can get away with applying a re-usable texture simply to get the material read established. Like the containers seen above, they use a generic metal dif+norm+spec that gets applied to quite a lot of objects. Handy because I can change the colour too, inside of Unity.
Logged
s-spooky g-g-ghosts
Level 2
**



View Profile
« Reply #47 on: August 01, 2014, 07:45:38 AM »

This sounds like quite a bunch of work, but the effect is clearly worth it. It's so sad that I'm not a fan of survival horror games. They give me nightmares(literally Screamy). I'll only enjoy your work on pictures.
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #48 on: August 04, 2014, 06:19:55 AM »

Time for what is probably going to be the last catch up blog :O! We're matching timescales now! So here's the latest art blog, which you can also read here: http://teamjunkfish.com/blog/art-blog-17--lighting-revisited

---

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.


Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #49 on: August 05, 2014, 06:18:36 AM »

Not really a development update as such, but Eurogamer did an article on fear in games featuring Monstrum and Acid Wizard Studio's Darkwood which was pretty cool Smiley.

The Problem with Fear (Eurogamer)
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #50 on: August 20, 2014, 01:22:43 AM »

So, eh, been a little quiet on the whole blog posting side of things!

So a quick update:

We showed a new build of Monstrum at Dare Protoplay, part of the Dare to Be Digital event that takes place in Dundee every August. It went down pretty well! We used it to see how people took to new areas of the ship, and generally how the found it. A fair amount of people opted for the Oculus build, and had a few repeat visitors so can't complain really!

We're currently working on the last area of the ship we need to put in: the engine room. It's been through a few redesigns, but the current one looks like it'll do what we want Smiley. We're also working on the art and sound for the 2nd monster too, now that the design's been finalised. So busy times ahead! Should have some dev updates soon Smiley.

On another note, we'll be heading to EGX London in September. Any one else heading down?
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #51 on: August 22, 2014, 08:11:54 AM »

Outside of any touch ups and stingers, the musical themes for the 2nd monster in Monstrum are done :D!

Here's a sneaky peek: Soundcloud
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #52 on: August 29, 2014, 07:31:15 AM »

Been a while, so here's a fairly lengthy post on the ideas behind the music in Monstrum. It's sort of a follow up to this blog here, which talks about story building it games through audio. Specifically music! Anyway~

---

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.

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, here's 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

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?

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.
Logged



Quarry
Level 10
*****


View Profile
« Reply #53 on: August 30, 2014, 06:39:00 AM »

Original EPs? That reminds me of Wolfenstein, TNO
Logged
Mr. Virus
Level 0
***


View Profile WWW
« Reply #54 on: September 01, 2014, 01:01:26 AM »

Original EPs? That reminds me of Wolfenstein, TNO

Haven't played it! Will need to check that out though ha ha. Got them planned out, just a case of getting them done in between everything else. We're aiming to be at EGX London this month so hoping to have the 2nd one underway for it Smiley.
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #55 on: September 09, 2014, 02:33:13 AM »

Little mini blog on how we're doing our objective log from a coding perspective, including some of the issues we've come across and how we're dealing with them. The original post is here: 1

---

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!
Logged



8-Bit Ape
Guest
« Reply #56 on: September 09, 2014, 04:12:44 AM »

Love the visual aesthetics and the 70's theme. Really appreciate the in game journal too. I'm thinking of doing something similar for the inventory in my game. Keep up the awesome work!
Logged
Mr. Virus
Level 0
***


View Profile WWW
« Reply #57 on: September 10, 2014, 06:51:54 AM »

Love the visual aesthetics and the 70's theme. Really appreciate the in game journal too. I'm thinking of doing something similar for the inventory in my game. Keep up the awesome work!

Cheers very much :D! It's been a bit of a pain getting it to work with the Oculus but we got there! Will probably bug them to do a write up on it (and the UI in general) at some point Smiley.
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #58 on: October 02, 2014, 05:40:06 AM »

Been a bit too long since the last post, mainly due to everyone working on a build for EGX London at the weekend, and the press build we're planning to send out in a week or two. Should get back on target with blog posts soon though!

In the meantime here's another track from the game, the Hunter's Chase theme:

https://soundcloud.com/teamjunkfish/monstrum-hunter-chase-v1
Logged



Julien
Level 2
**


View Profile
« Reply #59 on: October 02, 2014, 06:26:56 AM »

I like that track. And the screenshots are appealing, good work !
Logged

Pages: 1 2 [3] 4 5
Print
Jump to:  

Theme orange-lt created by panic