It’s quickly approaching Christmas, and here in the Junkfish offices everyone is growing restless… Mr. Doyle even said he’d pay us if we were good employees! Eagerly anticipating the holiday season and some family time, spirits around here are jolly despite the unpleasant weather. We’ve given each other “lovely” presents and had a good laugh.
BUT THAT IS NO REASON FOR SLACKING.
So, because I am Peter, you’re all gonna get another helping of procedural generation chit-chat. This time, I’ll go over the system we’re using to create a “map”, of sorts, of the ship’s approximate layout. I refer to the pair of tools as the Region Window/Editor and Region Manager. The artists prefer to call these ’tilesets’, but that’s silly talk!
In my last blog, I spoke of how rooms were given Regions and Themes – the Region Editor uses these, along with its own data set, to tell rooms where they can and cannot go. I’ll start off with the Region Manager, as the Editor is rather useless if nothing has been added to the 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 (I’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 1 Theme, otherwise that Region cannot be added to a room.
Bright colours for all the Regions!
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”.
The Region Editor is to the level generation process as Mr. Doyle is to our company. They tie their 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
Buttons, buttons, and buttons
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.
You can even use it to make smiley faces!
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, I suppose. And I received Mr Doyle’s signature pat on the shoulder of approval.
And with that, I shall wish all you lovely people a Merry Christmas, Happy New Year, Happy Birthday (to those who have one, our resident soundman Jaime has his today – so wish him a Happy Birthday!), Happy Hogmanay, Happy Kwanzaa, and enjoy your holidays if you don’t celebrate any of those.
Brace yourself to hear more from me in the new year,
Proceduro the Magnifico.