Programming Blog 03 – Proceduro the Magnifico

I believe I ended my last blog detailing that I would discuss some of the details relative to the procedural generation, and its associated tools, so I guess that shall be the topic of one-way conversation this time.

Before man could cut meat, he needed tools. Similarly, before I generated a room, I needed a tool to tell it where, why, and how. And thus, the Room interface was birthed! 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.

Behold, minions, the Room interface!

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

I’ll leave you lovely people with a cool screenshot of a procedurally generated level, covered in colourful lines and circles:

All of those green lines are bits of rooms; code art!

So until next time, minions, same brown hair, same Junkfish blog. Good day everyone, thank you for reading! Your host for the evening, P.