Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411276 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 11:17:01 AM

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


View Profile WWW
« on: June 26, 2014, 06:23:59 AM »



Monstrum is a first person survival horror game by Team Junkfish which finds players stranded aboard a vast, derelict ship filled with traps, environmental hazards, and another passenger in the shape of a terrifying and deadly beast.  

With no means to take their pursuer down the player must search the ship to discover a possible means of escape, using their wits and guile to evade the monster hunting them, running, hiding and luring it away with distractions to avoid getting killed.  

Combining permadeath, a variety of different hunters and a procedurally generated ship that changes its layout every time, Monstrum is a challenging and punishing game that aims to be a truly replayable horror experience.



Features

  • Multiple Pursuers - Three different monster types, each with different behaviours and tactics means you'll need to find out what you're up against before deciding on your plan. Will you be able to work your way out of an ambush or a direct attack after being spotted? And will the same actions work each time?
  • Procedural Arena - Each time you load up the game the ship will have a different layout, putting the player's navigation skills to the test.
  • Escape Routes - Choose from multiple escape routes, each of which will require a different combination of items and methods to use, changing with the layout of the ship.  
    Dangerous Environment - Even while not being chased you will need to be on your guard, as the ship will be riddled with traps and hazards, ranging from simple alarms that alert the monster to lethal threats.
  • Distractions - Use whatever you can find to try and distract the monster to lure it away from you. Leave the lights on in a room you've just left, turn on a radio down the hall, throw items down the stairs to make noise, do what you need to avoid detection. And if that fails...
  • Hiding - Hide in lockers, under furniture, behind boxes, and hope your fellow passenger wanders on by. And if that fails as well...
  • Permadeath - Death is death. Get killed in Monstrum and you'll be starting again. In a different ship, possibly against a different monster. Good luck. Start running.



« Last Edit: May 26, 2015, 02:59:10 AM by Mr. Virus » Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #1 on: June 30, 2014, 05:47:46 AM »

Some words from our designer on the origins on Monstrum, as he hasn't got his own account sorted out yet due to being ill... Sad. Hopefully will have a few more updates on the things we've done and what we're working on just now!

So what exactly is Monstrum?

Monstrum is a survival horror game with a simple enough premise: You are trapped on an abandoned cargo ship with a deadly beast hunting you. The goal is to find a way to escape while eluding your fellow passenger, if you are caught then it's game over. You will need to use your wits and plan ahead as you explore as you could run into the hunter at any moment. Maybe it's worth leaving the light on in the room you just left? Set off an alarm in an area you don't plan on returning to? Get sloppy and make too much noise, and you might as well be wearing a neon sign. There are multiple escape routes to be found, but each is in some way broken or inaccessible so you will need to search the ship to find tools and items to make them usable. The layout of the ship is procedurally generated, as are the location of the items you'll need to find, so each time you play you'll have a different experience.

Where did the idea come from?

The idea for this game came about from my desire for a replayable horror game. While I'm a huge fan of horror games, I generally find that after one playthrough I know where all the enemies are and what their patrol routes are and it becomes just an exercise in memorisation. I had also been binge-playing procedurally generated games such as The Binding of Isaac, Spelunky and FTL, which force the player to adapt to and plan for various situations in order to progress, as each run will be different. Monstrum then came into existence as the product of applying this procedural mechanic to a 3D horror game. After fleshing out the game idea a little I pitched it to the team who were very enthusiastic about making it and that as they say was that. Inspirations for the game itself are plentiful, some of the more notable ones being Alien, The Thing, House Of Leaves, Amnesia, Lost, and of course the games mentioned above.

Why make this game?

Well in addition to it being the kind of game I'd like to play I think a procedural horror game is a cool idea not only because of the replay potential, but also because horror games seem to have become something of a spectator sport recently. I know we enjoy gathering around to watch someone play Slender, Amnesia, Outlast, etc. and the popularity of horror based Let's Plays implies we're not the only ones. So the idea that it's different each time means even after watching someone play it you can still have your own unique experience.
Logged



davidhallgren
Level 0
**



View Profile
« Reply #2 on: June 30, 2014, 06:13:11 AM »

Looks great and I think the concept is very promising. Looking forward to seeing more! Would also be interesting to hear more about your approach to generating the levels.
Logged

Current project: Vinkelvolt - Platform puzzler with 3D perspective rotation for iOS
Mr. Virus
Level 0
***


View Profile WWW
« Reply #3 on: June 30, 2014, 06:29:11 AM »

Thanks David Smiley. We're currently working on fitting newer areas into the game, but we've done some blogs on the procedural level building system before. I'll probably end up carving them up to put in here and show where we're taking it, but in the mean time hopeful these are what you're looking for!

http://teamjunkfish.com/blog/programming-blog-03--proceduro-the-magnifico - Originally building the tool

http://teamjunkfish.com/blog/programming-blog-05--ship-zones-and-paint - Making a region editor

http://teamjunkfish.com/blog/lighting-in-a-randomlygenerated-game - Handling lighting

http://teamjunkfish.com/blog/programming-blog-09--a-big-brown-deck - How we build one of the outer areas
Logged



davidhallgren
Level 0
**



View Profile
« Reply #4 on: June 30, 2014, 08:15:02 AM »

Nice, thank you for the links!

I have recently finished my first game and thus started to play with some simple ideas and prototypes for what to do next. As it happens, many of them have also included attempts to turn the typical mechanic of "protagonist killing 1000+ enemies" around. Quite a few games manage to make the player feel relatively weak and vulnerable, but often only in individual encounters. In the aggregate these encounters still add up to a very strange balance. I therefore really like the idea of having a single more or less invincible enemy that has to avoided and outsmarted instead. Mixing it up by rotating between a few different types with varying styles is then a great way to make it to repetitive and predictable.

But maybe I missed something and the player will find an awesome weapon in the lower decks which will allow him to go powered-up PacMan on a whole horde of those monsters  Waaagh!
Logged

Current project: Vinkelvolt - Platform puzzler with 3D perspective rotation for iOS
Mr. Virus
Level 0
***


View Profile WWW
« Reply #5 on: July 01, 2014, 01:32:40 AM »

No worries. I'll try get something done for TIG using them soon Smiley.

And no, no Pacman stuff ha ha. We are wanting to avoid it being a "run and hide" game though as it's been done quite a lot in horror games. You'll be able to set traps and distractions that can hinder the monster, but some might not work as well as they would on others. Just to make it a bit more strategic Smiley.

That inversion could be kind of interesting though, like leading a party of people through a dangerous environment while being stalked by something?

Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #6 on: July 01, 2014, 02:54:51 AM »

Another catch up blog, so bear with me. This one is about some of the art considerations, regarding the setting and technical aspects of the game. Namely, the procedural elements! These are pretty early (a few months old), but hopefully it'll show how things have moved on from here by the end Smiley. This post is a composite of these blog entries, in case you want to read the originals: 1, 2

---

The setting of Monstrum is on an old, abandoned cargo ship built in the mid 70's that once transported expensive goods of all sorts across the Atlantic, but now lies in disrepair. At first glance, it may seem like ordinary seafaring vessel. However, on further investigation it seems that it may have been used for more than just transporting cargo.

One of our biggest challenges with Monstrum is to create an environment that is not just intimidating, but procedural as well. A lot of games rely on scripted sequences designed to create a tense atmosphere. We rely on the game creating that atmosphere for us, leaving the level before us unknown throughout every play-though (even to ourselves), which builds the tension! 

As the environment is not linear, we have little control in how the player will move through the ship. We therefore have to design the areas in small segments that fit together seamlessly and create tension on a micro scale, whilst the game puts it together to form a level for us to build tension on a macro scale. For the artists, it's difficult to see how the level ends up until they are all put together in the game, but when it does it properly, it feels damn satisfying for everyone Smiley.




An ordinary cargo ship would be rather boring, so we've focused on the 70's theme quite a bit. We've been taking a lot of visual inspiration from the less colourful side of the 70's, police stations, hospitals, offices; the environments we have been looking at have a heavy focus on function over form with a lot of reference from British working class/industrial themes from that era. Everything on the ship is designed around equipment from that era.



Here's a shot from Tinker Tailor Soldier Spy. We've taken lots of inspiration from scenes similar to this as they provide a great visual base for us to take from, falling in line with our chosen themes. We feel this one in particular has lots of things we could use to realise our cargo decks!


Naturally, taking inspiration from 70's cop and spy dramas, we took a lot of our environmental assets from 70's police station props. One of our artists, Adam, was a fan of the dark wooden tables, storage boxes and the mess of paper, where everything was stored in physical folders whereas now we store the majority digitally.


Unlike normal cargo ship bunk designs, where most of the ship's furniture is built into the room itself, we had to build our furniture assets separate from the room for the sake of gameplay and procedural generation. A lot of our furniture items use a lot of metal bars and basic shapes to keep them simple, but functional. Fit for a working environment.

To add more personality to the more lived in sections of the ship we added pictures and old posters of the previous crew's favourite movies. One of our other artists Andy took some inspiration from 70's poster design created some posters for blockbuster releases such as “The Court Process” and “Clutch Control”, truly genre defining police action films. We're planning to add a lot more of the crew's belongings into the mix, such as books, pictures, notes, vinyl, and more posters!


When it came to some of the on-board technology in the game we wanted to make it look like it could have came from that time period too. Here's an early mock up of the security cameras that are dotted around the ship, complete with a simple, robust and suitably chunky look that helps get across how old they are.


And here's a wider shot of one of the rooms.


---

Phew.
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #7 on: July 02, 2014, 06:38:52 AM »

Today's catchup blog is on the paper prototype we made for Monstum. So enjoy!

You can read the original post here.


---

The Board

The first step was to find the main mechanics of the game and think of a way to represent them in a board game format. For the procedurally generated layout Grant (the designer/coder) looked to games like Zombies and Carcassonne, which instead of having a set board build up the play area from decks of tiles, shuffled each time so the map is always different. So both he and Simon (the producer) sat down with some paper and pencils and spent an inordinate amount of time cutting out paper tiles and drawing ruled (well, ruled at first, eventually they got lazy) squares and little details on them.

The board is built up from two decks of tiles; one for corridors and the other for rooms. Each tile has nine squares on it. The player character (pictured below) occupies one of these squares at a time.


The player has a viewing distance of one tile and tiles are placed as the game goes on based on visibility, e.g as the player can see them. For example, in the picture below the end pieces are placed as the player has a line of sight to them but as he is not in the centre no piece has been added to the right as he cannot see it.


As the game goes on the board gradually becomes a sprawling maze.


The Player

Deciding how the game would actually be played was tricky, as our game is a real time first person game, and real time board games are still fairly rare. Some way was needed to represent the time the player would spend moving about and exploring the ship and also the random element of them messing up (e.g running into a wall, deciding which route to take, getting stuck or lost).

The system that ended up being used for this was an action point system (Taken from the wonderful XCOM/Fallout games). At the start of each player turn the player rolls a d6 (that's just a six sided die for all you non tabletop gamers out there), and the result of this roll determines their action points for this turn. These points can be spent on movement, picking up items, opening/closing/locking doors, etc. and are really just a representation of the time spent doing these things in the video game. The player's turn ends either when they decide to end it or they have run out of action points.

The Monster


The monster (pictured below) is not initially on the board, and is instead represented by an alertness meter. This increases as the game goes on, mainly from event cards (explained further down), a few other things and represents the time during the game when the player is not being chased by the monster but gradually increasing its awareness of them. While the alertness meter is below 10 the player just takes consecutive turns, but when it reaches 10 the monster is placed on the board a set distance from the player and the chase begins.


At this point the player and the monster alternate turns, and the monster on its turn rolls a d4 (four sided die) and its action points are decided. Unlike the player however the monster spends all its points on movement and moves towards the player using the smallest number of squares available. The player can use this behaviour to help them escape. For example it takes the monster several points to break down a locked door, so it might not be the fastest route to the player, but because a door only takes up one square it will be the shortest route, and so that's the one the monster will take. If the monster catches up to the player it's game over, and if the player successfully hides from the monster it is removed from the board and the alertness meter is reset to 0.

While technically one player could play both roles, in the game the player will not be directly aware of how their actions are affecting the monster's awareness of them, and so we like to have someone else play the monster, and keep the alert meter hidden from the player. This adds the element of mystery and tension that would be otherwise be missing from this version of the game.

Items and Events


In addition to the tile decks there are two decks of cards, Events and Room Cards.

Events

Event cards are drawn at the end of the player's turn. These are almost universally negative and represent the more random 'things can go wrong at any time' aspect of the game. The concept of these are based on similar features of two of Grant's favourite board games of all time: Red November and Pandemic, brutally difficult, tense, and sometimes hilarious games.

The in-game events represented by these cards are things like the player accidentally setting off an alarm, getting stuck in the floor or turning the corner and walking right into the monsters field of view. They also are mainly responsibly for incrementing the alertness counter. (In our two-player method of playing the game the monster player always draws these cards, keeping their effects hidden from the player). If the player has spent more than half (rounded up) of their action points on a particular turn, this is the equivalent of them taking a lot of action in a short amount of time in the video game, and in this case 2 event cards are drawn, otherwise only one is drawn.

Room Cards

Room cards are, as the name suggests cards associated with rooms in the game. When a room tile is placed down, two room cards are placed down with it. On these cards there will be one of three things:

Item Cards

These cards are, well, items. They can be carried about by the player and activated at any time for an advantageous effect. Alternatively they could be one of the valuable key items the retrieval of which are the goal of the game.

Opportunities

These are best thought of as positive events. They are not picked up by the player, but stay in the room in which they were found and can be activated by the player when they're in the room. For example, an in-game equivalent would be a TV. Not something you'd carry around with you, but you could turn it on and leave it on as a distraction for the monster, buying you time. You would of course have to be in the room at the time to set it up though.

Hiding Spots

Hiding spots (shown below) are a valuable resource in the game as they are the only way to be rid of the monster once it's on the board. Much like opportunities they stay in the room in which they were found. When the player activates a hiding place card (which they must be in the room to do) their turn ends, the appropriate number of event cards are drawn and the monster gets a chance to move closer. On their next turn the player rolls a d6. A six is needed for a successful hide, but this roll can be modified.

For example: if the monster is 7-8 squares away from the player they will have a plus 3 to their roll, while if the monster is only 1 or 2 squares away from the player they will need to roll a natural six.


And sometimes you're just straight up outta luck.


---

Another long one, sorry about that!
Logged



Mr. Virus
Level 0
***


View Profile WWW
« Reply #8 on: July 08, 2014, 01:31:39 AM »

Another little catch up blog, this time on the music system and some of the themes for the "Brute" monster. Hoping to get on on the procedural generation up this week if I can get one of the programmers to go over it! Anyway, the original posts are here: 1, 2

---

So first things first. a quick and nasty overview of the Brute's music system. I apologise to artists everywhere for this:


The first musical theme, "Wandering", is used while the player hasn't been spotted. It's pretty pared back and empty, but should have enough going on to tell the listener that something's not right. Have a listen to it here: "Wandering" Theme (Soundcloud)

After the first chase sequence the "Wandering" theme is replaced with the "Stalked" theme, as the mood and scenario of the game shifts from "explore the spooky ship" to "get off the ship which being squished". The "Alerted" section is there in case the player triggers any actions that make the monster aware to their presense without being actually spotted, giving the cue that the monster's alertness is quite high. The "Cool Downs" work in the same way in each scenario, ramping down from their intense themes to the comparatively calmer "Stalked" theme. Finally, "Spotted" is more like a stinger, think the DUN! from Monster Hunter and you'll be in the right place.

This system doesn't take any diagetic music in the game into consideration, such as radios. But that's for another time.

As you can hear above, the "Wandering" Theme's emptiness allows it to transition into different states quite easily.

Such as the "Chase" Theme (Soundcloud)

I went for the percussion heavy trope to try and match the brute's primal, vicious nature, so a fair amount of toms to drive it forward. The pulsing triplets is actually from a running ship engine, which I warped in Ableton to roughly match the beat and ran through some distortion and amp sims to make it sound crunchier and a bit nastier. I wanted something noisy and sort of mechanical to try and match the environment's visuals, and it also adds an extra percussive layer to the track. The cymbals have some mild tremolo on them, which I felt added a feeling of dizziness and unease to the proceedings.

The other things of note are the squeals, screams and extra noises. The plumbing and taps in the place that we work in are extremely noisy, so naturally I recorded and performed some audio tomfoolery (ie. pitch shifting then running it though various things) to make it fit into the track. One of the clips had a fairly constant pitch, so I cut it up and made a sort of melody from it. The sort of static sound that pops up is actually the pressure being released from my travel mug... Make use of everything!

Also in the graph is a cool down section, which I went on to rephrase as "Hidden", where the music changes to a less intense version of the "Chase" theme. Have a listen to it here: "Hidden" theme (Soundcloud)

After the cool down the music goes into the "Stalking" state (Soundcloud).

Here I incorporated some of the elements from the "Chase" theme, the cymbals, the static and the screeches, over an ambient pad like the general "Wandering" theme. The purpose here was to build upon the uneasiness that the base "Wandering" track develops. Obviously once you're spotted the sense of dread and "OH NO SOMETHING WANTS TO KILL ME" should be a persistent and constant danger, so the pad is a bit heavier and noiser. The cymbals are used to bridge between the cooldown transition in addition to their original purpose, which the screeches and "static" come in and out to tie it even further to the "Chase" theme and Brute motif. It also sounds pretty evil mixed in there.

And that is that so far! I'm hoping to have a different motif for each monster, and given how each is being design they'll probably need their own music flowchart too. Hopefully I'll be able to post about it in the coming weeks Smiley.
Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #9 on: July 08, 2014, 02:43:51 AM »

This is looking really wonderful and I absolutely adore the gif of the building being generated. Are there any plans for outdoor areas? If you are working in Unity how do you plan on tackling UI? Do you plan to add co-op? Also I study at Abertay University and have to say you guys are hugely inspiring!
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #10 on: July 08, 2014, 03:03:50 AM »

This is looking really wonderful and I absolutely adore the gif of the building being generated. Are there any plans for outdoor areas? If you are working in Unity how do you plan on tackling UI? Do you plan to add co-op? Also I study at Abertay University and have to say you guys are hugely inspiring!

Aww shucks ha ha! Thanks very much :D!

As far as outside areas go we currently have the outer deck, where one of the escape routes is, along with walkways. We're currently building most of the remaining areas, and we should have another escape route that requires you to go outside too.

I asked a coder who said:

"We currently draw textures on 3D planes to do the UI, but will probably recode to use either the newer 2D stuff or the upcoming UI system in Unity 4.6 depending on when it is released."

But can bug them again if you'd like more info Smiley.

And no plans for co-op I'm afraid Sad.
Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #11 on: July 08, 2014, 03:10:36 AM »

Aw co-op would be cool but alas the game is still incredible! Thanks for bugging them. I'm pretty excited for the new UI system.
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #12 on: July 08, 2014, 04:14:20 AM »

Aw co-op would be cool but alas the game is still incredible! Thanks for bugging them. I'm pretty excited for the new UI system.

Cheers very much Smiley. It'd be an interesting feature, but we reckoned that it might conflict with what we are wanting from the game.

And yeah, the coders are (im)patiently waiting on it as well ha ha.
Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #13 on: July 08, 2014, 04:20:14 AM »

Yeah I can understand that, I'm just a little obsessed with co-op games seeing as I don't play many others.
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #14 on: July 09, 2014, 09:59:41 AM »

Slight deviation for the catch up stuff with some shiny new environmental assets :D! These are from the cargo hold area of the ship. Our artists did a blog on how they work into the procedural generation system here.

Enjoy~







Here's some of the stuff that will be found in the crates too:



Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #15 on: July 09, 2014, 10:16:02 AM »

This is looking better and better every time I visit. Thank you so much for the insight into how the containers are generated. Great to hear the thought process of your team trying to solve the problem!
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #16 on: July 11, 2014, 05:41:50 AM »

Another lengthy catch up blog, this time on how we built the procedural generation tool in Unity. As always, here are the original posts, complete with one of the programmer's grand prose: 1, 2

---

The Room interface is a script that should be slapped on to an empty GameObject in Unity, and holds a medley of 7 sub-headings, each of which allow different aspects of the room to be specified. The first sub-heading, “Room Settings”, allows the spawn amount of this room to be set, and what kind of room it should be, e.g. a corridor, a standard room, outside piece, etc.


Sub-heading #2, “Room Models”, does exactly what it says in the title – allows the editor to choose the models that will be associated with this room. Probabilities of the models can be set, and different textures can be passed in to help prevent two rooms looking the same.

Like #2, the third sub-heading – titled “Room Objects (Not Random)” - is how the editor can define where very specific objects will go in a room. For example, I used this to place beds in one of the crew bunks instead of leaving their placement to chance.

The “Themes” sub-heading is one of the two sub-headings that are crucial to room spawning. Themes are intended to allow artistic changes to rooms based on their location, and also contribute to where a room is placed. If we were making a hospital, and the room was going to be in the ward, Themes could be 'Dirty Ward', 'Clean Ward', or 'Closed-off Ward', for example. Same rooms, different looks.

The next sub-heading ties into Themes very heavily - “Regions (Tilesets)”. In the hospital example, the Region would be the 'ward'; where the hospital has many different areas that rooms could spawn in, but these particular rooms can only spawn in areas marked as 'ward'. This, along with Themes, combine to provide some structure to the desired chaos as we cannot have rooms appearing willy-nilly all over the ship. It just wouldn't make sense. Not at all.

“Door Data” doesn't really let the user change anything, but serves as a point of reference for one of the other tools; a separate tool is used to place where doors should go in a room and this sub-heading allows the editor to view some information regarding these door placements, such as (X, Y) position and the orientation.

Aaaand on to the final sub-heading, “Debug Settings”. This one contains a third set of fairly important variables – the size of grid that the room models will fit in. This is used to place the room in the scene, stop it from intersecting with other rooms, and align all rooms up correctly. So it's pretty important that this is set to the correct dimensions. It also lets the editor turn the visualization of these lines on or off, which is pretty cool too.

All of these contribute in their own ways to make rooms and help position them in a generated level, but this is just one of several necessary facets when it comes to crafting a room with the love and care that we, at Junkfish, so heavily emphasize. That being said, I'll go on to talk about these others tools at a later date, and you have my word that the least interesting of these tools has now been glossed over. Even if it is the most crucial of the four.

Here's a screenshot of it generating one floor of the ship:


In order to generate a map of the ship's rough layout we have a pair of tools called Region Editor and Region Manager. The Editor is fairly useless without the Manager, so let's go over that first.

Region Manager

Region Manager is a script on a GameObject, and this script allows the user to create a list of intended Regions. The name, associated themes, and colour of the Region are all defined when the user adds a new Region. When choosing the colour the alpha should be set to around 130, as objects in the Region Editor would otherwise be occluded (we'll cover that a bit more when talking about the Editor). Various vibrant colours also help when distinguishing between Regions, so the user should try to keep them varied.
The more Regions the Manager stores, the more constrained the user can make the ship through the Region Editor. Regions can be further defined by adding Themes to them. It is currently necessary for a Region to have at least one Theme, otherwise that Region cannot be added to a room.


There is also a second script hiding under the Manager called Region Control Initial Window. This script allows the entire set-up of the Region Editor to be reset, i.e. any user defined Regions in the Editor will be set back to the default of “Inaccessible”.

Region Editor

The Region Editor ties respective processes together, and tell the various bits they're in charge of, what to do, and where to go.
The Editor allows the user to define zones in the ship where rooms are allowed to spawn, through the use of Regions. When opened, the Editor can be slightly daunting. The user is presented with 2 grids of cuboids, and various buttons that, upon clicking, reveal even more buttons! A fair bit of UI for the user to get used to, but it is ultimately worth it.

The eagle-eyed user will perceive that the pair of grids are labelled with “Top-Down View” and “Side-On View”. These each represent, as you may expect, a top-down view and a side-on view of where the level is intended to go. Models that are dragged into the scene can be viewed in these grids, therefore, if the shell of the ship is dragged in, it will make life a lot simpler for the user when determining which Regions should go where on these grids. This ties back to when I was talking about the alpha of Region colours, as, if the alpha is at maximum, the colours of the cuboids would be fully opaque and draw on top of the models – preventing the user from seeing them.

Lining the top of the Editor are the Active Variables. These detail the currently selected values for the Editor variables, and tell the user where the level will spawn from (the level will spawn in the direction of positive X and Z, from that point).

Quick run down of the buttons that line the left side: each button, when clicked, will expand a list of other buttons. This expanded list contains all available values for the button the user clicked to begin with. The number in parentheses represents the current value of the button, and the colour of text for the Regions button represents the colour of the currently active Region.

   
  • Floors: This list allows the user to choose the currently active floor of the ship that they wish to edit.
  • Depths: This list allows the user to choose how deep into the ship (into the Z-axis) that the user is editing.
  • Regions: This list allows the user to choose which Region type they would like to “colour in” with.
  • Fill Size: This allows the user to determine the size of area they would fill when editing the pair of grids
  • Undo Changes: This reverts any changes the user has made since they last saved.
  • Save Changes: This saves any changes the user has made


Alternatively, to change the floor/depth, the user can also right click in either of the grids to choose the floor/depth they wish to edit, i.e. if the user right clicks a cuboid in the top grid, that row will become the new active depth.

Once the user has selected the values of everything they wish to edit, left clicking in the grids will colour each selected cuboid in the colour of the chosen Region. Thereby allotting this particular cuboid to that Region, and allowing rooms associated with that Region to spawn there. If the Fill Size is greater than 1, a cuboid around the mouse will display to tell the user all the squares that they will fill on click.


Finally, the highlighted row on each grid represents the currently selected floor/depth.

This whole tool essentially boiled down to me making a primitive version of Paint for our game, to create pretty pictures for rooms to spawn in. It's nice for the artists too.
Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #17 on: July 11, 2014, 06:33:43 AM »

This is hugely insightful! As someone who loves procedural generation and editors this tool is really fascinating. A few questions... How big is a single block on the region grid? Are there any rooms that would fill this? Second could a room span two region squares, say a large hangar? Lastly could a room have multiple themes to represent a half way state between say a clean and dirt ward? Thanks, really enjoying these dev logs!
Logged

Mr. Virus
Level 0
***


View Profile WWW
« Reply #18 on: July 14, 2014, 02:06:01 AM »

Sorry for the delay (Again!)

I asked the guy that built the tools, he said this:

"A single block translates to 2x3x2 units in Unity space (which I believe is in metres).

Corridors, certain deck pieces, walkway pieces - they fill a single node as they're made to be flexible and tend to join together to form a larger, connected section.

Whilst regions can overlap in the editor, and rooms can have multiple regions, a room is only assigned one region when it is spawned. So it will only be slotted into the region area that it has been given, though that region may overlap with other regions.

The themes don't actually play into the system that much currently, however that is possible. Rooms can have multiple themes, and a random one would be chosen at runtime, meaning that a region could be filled with rooms that all use different themes. To continue your example: a "ward" region could have both clean and dirty themes associated with it, so rooms could spawn in that use either of those themes.

I hope these adequately answer your questions!"
Logged



jctwood
Level 10
*****



View Profile WWW
« Reply #19 on: July 14, 2014, 03:26:05 AM »

Thank you very much! It is amazing to get this insight into your framework. How long was the concept for Monstrum in your sights and minds?
Logged

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

Theme orange-lt created by panic