next »

[Mr. Virus]

We started concepting stuff around later March last year, then put together a quick proof of concept that April. May was focused on everyone graduating, and half the team was out for the Summer due to Dare to be Digital, so the rest of us fixed up a little puzzle game we made. Started properly in September, so around 6 months .

[Mr. Virus]

Some more catchup stuff, again on level generation. I was going to include the blog we had on the lighting system, but it's now out of date! Anyway, this one is about going from a single floor to multiple floors. You can find the programmers' original posts here: 1, 2

---

Before, our ship was over a single level; flat and dull, kinda like those maze things where you roll the ball around. Peter used a primitive stair model to identify where changes in the floor of the ship occur and joined the corresponding connections back to the main bulk of the ship. It took some tweaking to eliminate all the bugs, but the result was a wonderful mess of corridors and rooms spanning multiple levels. It has turned what was a reasonably straightforward gather-items-run-to-victory-point game into a labyrinth of confusion and tension.

That isn't to say this feature didn't introduce its fair share of problems. The key items that spawn throughout the game were suddenly sparse and it could take player an unreasonable length of time to find all of them. Gary suffered from the introduction of these levels as the monster could suddenly attempt to climb stairs and had to find the player across different floors.

The first bout of fixing this was to allow the pathfinding of the monster to travel vertically, instead of just horizontally. This was sound in theory, and worked to a certain extent for the stairs (he was able to travel down them), but it also meant he could run outside the ship. We had the monster falling away to infinity, running across rooftops, and just generally avoiding the player instead of homing in on the player.

After much adjustment by Gary and Bean of where the monster is allowed to walk, how his vertical navigation worked, and how fast his path was calculated, the monster was finally capable of moving up and down the ramp-like stairs we had added. Just as they managed to get this working, our resident artists provided a fully-fledged stair model to replace the grey ramp nonsense we had before.

… And there wasn't actually a problem. The monster is still capable of climbing stairs, although he can be a bit jerky. The new model also provides extra connections to lead off to corridors, allowing for a more varied ship and extra choices for the player when trying to escape the monster. The addition of extra stairs per level, instead of the initial amount of one on each level, further aided the monster's pathfinding by providing extra options for it to get between levels.

Also, at this point the game would pause for a few seconds whilst the ship was generated - fine for development, but for release we need a loading screen that keeps the game responsive.  One solution is to run the ship generation over multiple frames, by pausing the generation at reasonable points to let the loading screen update+render, then resuming the algorithm again.  The transition to this technique went pretty smoothly (well, hello there coroutines), but, more interestingly, a by-product of achieving this means we can watch the ship generate itself! That means GIFS!

[jctwood]

This is easily my favourite devlog at the moment. Look forward to the next post.

[Quarry]

Very Fallouty, I like

[Mr. Virus]

Very Fallouty, I like

Cheers! Love the look of Starshock, kinda grew up on early/mid 90's FPS games among other things so keen to see how it is in the end :D!

This is easily my favourite devlog at the moment. Look forward to the next post.

Much obliged! Hopefully we'll be up to date soon, which is kind of scary!

[Mr. Virus]

Quick catchup blog this time, on audio stuff which means I know what's going on for a change! You can read the original here: 4

We've spoken about the use of distractions in the game and I want to talk quickly about one in particular: the radio. Instead of having the bog standard static and white noise coming from them I wanted to do something a little different, so we're planning to have them play some bursts of music from what would basically be a "radio station" just to break up the white noise a little. If you've watched the trailer you might remember a bit of this, which has now been expanded upon:

Soundcloud

I've been doing a bit of research into a few different genres that were floating around when the ship was built (perk of the job), so the plan is to get a few songs from maybe four or five select styles and run with it. With regards to the "radio" part I'm planning to remaster the tracks to make them all nasty and... like they're coming from a radio. There's also the issue of the distortion and signal dropping out, so it's not going to be a clean passage from a song playing all nice and clear. This is a horror game after all.

[DeadAlienCult]

Very impressive work. Nice job guys! 

[Mr. Virus]

Another catch up blog, more of an art dump this time! You can read the original posts here: 1, 2

---

Firstly, some early shots of the bridge:

And windows, before the outside environment was added.

The bunk rooms' tile set also got an update to the wood paneling.

Other areas of the ship were being concepted out around then too. First, the lower deck:

The artists said: "The lower deck houses the general working and maintenance sections of the ship and contains the main engine room. The plan for this area of the ship was a very cold, industrial feel, reinforced by cold green lighting. Metallic in appearance, this metal mess of shiny gauges, wires, dials and pipes make it the rusting metal jungle of the ship."

Next up was the Hold, which you can see some more up to date shots of a few posts back.

Again, the idea behind this one: "The cargo hold of the ship is a maze like formation of shipping containers, making it possibly the hardest area to navigate. With little light in this area, the narrow paths will be hidden in walls of shadow; dark enough for something to lurk around safely unseen. The tall, colourful variations of containers will hold a variety of curious, and sometimes secret objects. With fewer hiding spots, dark paths and a labyrinthine layout, the hold will be a complicated area of the ship you won't want to stay in long (unless you like being scared)."

---

Next art one will probably be about constructing some of the outer shell of the ship .

[Mr. Virus]

As always, another art catch-up blog . Not too many more of these left, so should be posting up to date stuff soon :D! As always these might be a wee bit out of date as we've been doing more stuff, but you'll hopefully see/read about that in due course. You can read the originals here: 1, 2

---
With a procedural game the size and shape of the ship will be changing with each playthrough, and modelling many different ships is both inefficient and does not give us much variation. Instead, we've been modelling it piece by piece. By creating repeatable tiles, we can expand the size and change the shape of the ship to fit with the level accordingly.

So far, the outer deck sections only spawned at the edge of the ship as a small exterior section that did not connect to any other places. They were pretty useless, having a similar behaviour to the rooms but with fewer spawn locations. Ultimately players would find themselves running out to these sections when chased and with nowhere to go or hide, they would have no chance to escape.

The exterior sections have been redesigned, now with walkways acting more like corridor pieces, linking up the exterior walkways and giving the player a lot more freedom.

Below is an example of the modular tiles put together in  Maya to imitate a section of a ship that has been put together procedurally. So far, this is only limited to the top superstructure of the ship, but the rest of the ship will work in a similar way once implemented.

Here is an exploded version showing each tilable section. Overall, 18 tile variations are used to construct the current superstructure of the ship.

We can add additional floors, windows and walkways accordingly.

On the inside, we've been playing with shaders to get the kitchen looking shiny. We are using static cubemaps to make the metal in there look very reflective. These are all still early shots and have been tidied up since they were originally posted, but are all in-game. Here's a kitchen:

A mess room.

A shower room.

...and a toilet...

The next few posts will be moving outside more, so keep checking back for more info. Cheers :D!

[Mr. Virus]

Ninja update, but we have the procedural generation working in the cargo hole, complete with GIF!

[Mr. Virus]

Ooo, a combo catch up blog! This one involves the outer deck, and more specifically, the first escape route in the game. This area has a lot more room compared to the corridors, and its generation is slightly different too. You can read the original posts here: 1, 2

---

So first things first, the deck itself:

The deck is covered in both rooms and small sections that are 1 cuboid in size. The general idea behind creating it is: spawn as many rooms as possible, then fill the remaining holes with the appropriate 1x1 segments. Take a moment, and see if you can identify where the rooms are from the picture. A hint is that there are 4 main rooms shown on the immediate deck. If you guessed that the mast is in one of the rooms, you are correct! The room it is in is 7x6 in size, and spawns all of the junk and such that surrounds the mast. Room #2 is the area with a deflated life raft, the large crane machination, and enclosing railings. So well done if you clocked that! The last 2 may be a bit trickier to locate, but they surround the edges of the deck area, and spawn items than line along the railings.

Currently, the number of rooms that can spawn on the deck is limited, which results in a similar looking deck each playthrough. However, extra rooms would not be hard to add, and varying up the deck through the use of these is definitely the intention.

Now, if we just left these rooms as the base deck, we would end up with holes across the area, as shown above. Hence the 1x1 segments. These are spawned in by detecting what kind of room is attached to each side of the node in which the segment is looking to spawn. If a deck or walkway is detected, a connection is permitted. The appropriate model is chosen based on connections, rotated and moved into place, then voilà! A fully kitted-out deck.

You may be wondering “Why not just generate the whole deck out of 1x1 pieces?”. Sure, it would probably have made life a lot easier, and that was the intended approach at the beginning, however it lead to a rather serious issue: spawning of deck objects. Some deck objects where larger than 1x1 cuboids, making it difficult to detect where they would be allowed to spawn in the context of the deck. Also, if every single piece had a chance of spawning a barrel, it would quickly lead to a deck covered completely in barrels. The larger, pre-made tile sections allow greater freedom, flexibility, and creativity with regards to the placement of both preset and random items. For example, the mast is intended to always be at the centre of this piece of deck. It would be hard to guarantee that when only spawning single segment pieces.

Here's a closer look at some of the things on deck, although they are all older, WIP shots:

And here's an in game shot too:

Cheers !

[Mr. Virus]

This catch up blog is about some of the traps that we're putting into the game. You can read the original here: 1

And away we go~

---

As we've said before monsters won't be the only threats to the player aboard the ship, so in the meantime here's a look at a couple of the traps and hazards we've been working on.

Currently In Game:

Cameras

First up we have the Cameras, which if you are familiar with stealth games should be fairly self explanatory. When the player is spotted by a camera they have a few seconds to move out of its view or the camera will sound an alarm, giving away the player's location and attracting any monsters to the origin of the sound.

If the player manages to avoid being seen by any more cameras, then after a short while the alarm will time out and stop. However, if the alarm is still playing and they are spotted by another camera then the alarm will immediately begin emanating from that camera's position and the alarm timer will be reset.

Cameras appear commonly throughout the whole ship.

Pit Trap

The pit trap is a heavily rusted and damaged area of floor on the verge of collapse. The player may walk over it safely but should they run over it or jump on it the rusted section of floor will collapse into a small pit. This makes a loud noise and trips the player, knocking them prone. This can be a minor inconvenience while exploring the ship, but becomes far more dangerous during a chase sequence, where the loss of a few seconds can be fatal. It can be leaped over, which is a preferable tactic while being chased as slowing to a walk can be as dangerous as triggering the trap.

Pit traps are also common throughout the whole ship.

Steam Pipes

The ship also has some more lethal hazards in store for players. For example in the lower decks there are broken pipes which intermittently blast out pressurised jets of hot steam. If the player touches the edge of the steam they will be damaged, warning them of the danger. Should they ignore this and attempt to run through the steam they will find themselves in an unfortunate situation (e.g. a game over.) The steam may be avoided either by crouching under it or waiting for the intermittent period where nothing comes out the pipe. For each broken pipe there will also be a corresponding nearby valve that can be used to turn off the flow of steam to it.

Steam pipes appear uncommonly in the lower decks.

In Development:

Tripwire trap

Tripwire traps are man made obstacles set up by prior inhabitants of the ship in an attempt to take out the monster. Unfortunately they can take out the player much more easily. The traps take the form of a heavy object suspended from the ceiling, which will drop upon the tripwire beneath it being broken. The heavy object itself will be procedurally generated, e.g. an engine part, a TV, etc. Like the steam pipes, this trap is deadly, but its lethality is offset by its visibility. It's hard not to notice a TV hanging from the roof, so the likelihood of accidentally triggering it is lower. The player can either activate the wire themselves by crouching next to it and breaking it, or they can attempt to throw something at the tripwire from afar (the latter more useful in case of chases).
Tripwire traps appear rarely throughout the ship

Drop Trap

The drop trap is similar to the pit trap but instead of knocking the player prone the floor collapses completely, dropping the player to the floor below or - if they're really unfortunate - onto another drop trap, with possibly hilarious but most definitely fatal results.

Drop traps appear exclusively in [REDACTED]

[Mr. Virus]

Ahoy! Some art stuff again. This is getting pretty close to where we are just now too! You can check the original blogs here: 1, 2

---

Upper Deck

We've been adding more variation into the upper deck rooms. Right now we have been testing the addition of different light sources in the rooms to give more variation to the colour in the environment. Below is an example of this in our Unity test scene, in which we added some additional light sources such as floor lamps and spotlights.

The monitors in the security room have now also been switched on, giving the room it is in a strong green glow. So far the monitors are static but we may do something a lot more interesting with them in the future.

Additionally, we have modelled plenty of assets to be placed onto the walls and ceilings of the rooms so that they are not so bare. The removal of some of the ceiling panels also give the room a little more space so that they aren't all so cramped, and a corridor set sporting wooden trim and carpeted flooring has also been made. Below is some pipes, vents, sockets, cupboards and general geometry on the walls.

Currently, these have not been brought across into the game yet but we'll hopefully get them in with in the next few updates.

Lower Deck

We have now begun working on the leaky lower bowels of the ship, with the engine room as our centrepiece. Expect to see lots of pipes, steam, moisture and rust. Here is the current corridor set for the lower deck section along with the initial concept for the lower deck hallways.

Here is a little sneak peak of a section of the engine room; a huge room multiple floors high housing a labyrinth of machinery and walkways. This huge area spawns in a completely different way from the upper decks, even housing smaller rooms within it. Trying to wrap our heads around the intricate functions of the equipment in this room is not an easy task, and on top of that, making it so that it can be procedurally generated is a big challenge that we are excited to see pay off. Here are some test models that we put together while shaping up the room.

And here are some textured assets.

There's also a fuse box for the power mechanic we're working into the game too.

---

I'm hoping that some of the team will jump over soon so that they can post their own, up to date stuff now that I'm running out of old things to post!

[Mr. Virus]

More catching up, more art! This one is about the engine room again, complete with a break down on one of the areas. You can read the original here: 1

---

Last time we showed you sections of the engine room that we had been working on. Since then we have been finishing up the basic components that make up this area of the ship.
Below are some images of the control room that Tait, one of the artists, has been working on, as well as some tricks he has been using to efficiently texture these sections. In his own words...

*wavy transition*

Here are some work in progress shots of the engine control room. Turns out ship's this size is quite complex, so we wanted to make the control units look busy and detailed. I reused parts of the assets from the bridge and updated them for use in this room. Some new additions were also added to give these control panels a unique feel.

Among these new things are general buttons, dials and readings. These were made entirely in Photoshop and assigned to flat planes inside of Maya. Then its simply a case of dragging the UVs around to the part you want! The normal map used on these give the impression that there is geometry there, even though they are just 2 triangles. There is still plenty of room in this 'button' texture map so we can add more variation when the time comes.

I have also added a whole bunch of new floors and mats to be used around the ship. Using a small texture that tiles 4 ways we can create a variety of mats of different sizes, using a small texture and very little geometry whilst retaining detail.

COOL HUH!? Bye!

*wavy transition

If you've seen any footage of the game so far you may have noticed the rather unappealing player hands. You'll be happy to know that the placeholder player model has now been removed and replaced with a newer, better looking one. No more sausage fingers! With this model comes a whole set of new player animations that Judy has worked on which encompasses more nervous characteristics.





And here are some work in progress shots of the container room that you saw earlier. In this section, the player will have to navigate through a huge maze of broken cargo containers with (in time) some interesting bits and bobs within them. Here are some untextured model pieces that will be used to construct this section of the ship.

This area won't have many lights, so better bring some glowsticks!

[Mr. Virus]

Running out of catch up blogs :D! This one is on some issues we had with doors of all things, and how we got round them. As always, the original is here: 1

Doors. You may have heard of them. You may have even walked through one yourself. Well, it turns out this seemingly simple piece of modern technology becomes fraught with problems and design issues when it comes to including them in a video game. A recent article entitled “The Door Problem” highlighted this as a common design challenge that many games need to solve. For example, how will the doors in your game work? Can doors be locked? If so, how can they be unlocked? How big are they? Can every door be opened? In this blog we are going to explore some of the door challenges we had, and what solutions we came up with.

Why doors?

In Monstrum, the player will be exploring a vast ship in order to find a means of escape. It would be weird if the ship didn't have doors, so unfortunately we couldn't just skip the whole door problem. Blast! So we added some simple doors and following that, everything was sunshine and roses and we retired early to the countryside and drank a cold beer. Well, that last part might be a lie.

Door == Doom

While at first glance things seemed OK, we later noticed that when it came to running away from the big bad monster using doors would always end in death. Why? We couldn't get through the door fast enough. In a rush, we often misjudged the movements required to back away from the opening door and the moment to run forward, causing us to be on the wrong side of the door. By the time we corrected our mistake, the monster had already caught us.

We figured that if we pushed the player backwards automatically whilst the door opened, it would streamline the actions required to move through it. But what direction is backwards? Well, we tried a few different likely candidates: along the player's normal, along the door's normal and along the door frame's normal.



The player's normal and door's normal were quickly rejected, since they end up with the player on the wrong side of the door, sometimes trapping the player in geometry at the side of the door.



However, the frame's normal turned out to be the most consistent and felt the most 'right', so we stuck with that. These weren't our only options, but we were happy with the results.
Now all the player had to do was hold forward, and the game would let them run through the door as soon as it was possible. Hooray! With the help of a couple of triggers, suddenly figuring out how to meander around the door was a thing of the past. But then we had another problem.

Let me go!

The problem with our simple method is that it would often grab the player and move them when it wasn't appropriate, such as when the door was opened from the other side.
So we needed a better method to detect when the player would want help from our push-back system. Firstly, we assumed that the player would only want to be pushed if they were in the way of the door. This could be detected by figuring out which side of the door they are.



For this we took the angle between the door's normal and the direction from the door to the player. If the angle was < 90°, push the player back. Turned out this worked pretty well! If the angle was > 90° we knew the player was on the other side of the door, which was useful for a similar push-back system for when the player closed the door. We also only applied the pushback effect if the player was close enough to the door (using a raycast to get the distance). When closing the door, we used triggers instead of a raycast, since we wanted more precise control at the edge of the door.

A wizard is never late...

This system got us most of the way to what we wanted. The player would be pushed back until the door was open, and then allowed to go forwards. Great! But we wanted better. Our system was pessimistic, and by that we mean the door would wait until it was fully open before the player could run through. But we knew there was definitely an earlier point they could run through the door without problems – we just had to figure out where that point was. In the end we settled for a raycast from the player to the middle of the door frame; as soon as the door was out of the way the ray wouldn't hit the door and marked the path as clear. This particularly improved slower-opening doors.

A Conflict of Interest

Another chain of problems we had involved whether or not to lock the player's normal movement when being pushed back. At the start it was not locked; a result of this was that if the player decided to run in to the door whilst being pushed back, it caused an erratic jerky motion as the two movements conflicted. We tried increasing the push-back speed, which helped somewhat, but then the opposite happened: when the player stopped moving, the push-back amount caused a clear jump/small teleport in movement away from the door.

Next, we tried locking the player's standard movement. The jerkiness was effectively gone! However, this felt far too restrictive, as it prevented the player from moving sidewards and backwards (manually). The solution we devised for this was only locking the player's movement when they were moving towards the door. We worked out when this was the case by finding the angle between the player's movement direction to the door frame's normal. This seemed to work!

A final word

It is worth noting that the doors in Monstrum are continuously being refined and improved, so it is likely that in future these methods and solutions may be replaced with something more appropriate. None-the-less, we hope someone might find the information in this blog useful when implementing their own doors!

[jctwood]

Every time I see these wonderful new models I wonder how you get the rust to look so natural?

[Mr. Virus]

One of the artists is waiting on his account being approved, so hopefully he'll be able to jump on and answer himself . Also saves this from being a constant stream from me ha ha!

[Mr. Virus]

Dunno where he's gotten to with his account . I'll chase him up though!

Anyway, new catch up post, this time on the cargo hold that was kinda shown earlier and how we're working that into the procedural generation system too . As always, the original is here: 1

---

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, we decided to make an additional door variation: A door within a door!

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 realistic looking colour variations.

Winding up, here is some of the content we've created to fill up the insides of these containers. We've got a couple of strange things in there, but SPOILERS, so here are some of the more generic things.

[jctwood]

I have to say the insight into the pipeline you guys are giving is brilliant. I wish more devlogs would spend time on the issues faced rather than just the things they have added!

[Mr. Virus]

I have to say the insight into the pipeline you guys are giving is brilliant. I wish more devlogs would spend time on the issues faced rather than just the things they have added!

It's one of those things I (and a few other folks on the team) enjoy more. The whys and hows behind stuff. Always great to see what other people are doing and trying it yourself, especially if it's a problem that you've been struggling with :D!