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 ManagerRegion 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 EditorThe 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.