Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

Procedurally Generating the Building Interior: Furniture and Fixtures

So I’m finally starting to make progress. I’ve emerged from the first massive refactoring of my code and game architecture in one piece and only a few tears. I’m getting closer to the point where I’m happy with it all. I’m not 100% happy with it, there are some murky parts. But the key thing is I’m close to solidifying a single method when generating everything from the city layout to where filing cabinets go.

I have the some basic offices layouts down now. It’s not the only type of building in Redacted, but it’s the key type and I’m concentrating on that to begin with. It’s certinaly buggy at the moment and there needs to be a lot more work done in many areas; there are no kitchens and bathrooms – yet. We do have basic offices, meeting rooms and from there I can start to build my game on.

Real world office planning revolves around unit boxes that building designers and furniture manufacturers all adhere to. The American standard is a 5 foot box that can fit a desk and a person on a seat. At the moment my boxes are slightly larger on the account of the desks I’m using. This might change with different buildings and desk types.

To place everything I take each room and cut it into (invisible) boxes. I find out where the entrances are and mark them down. Then I mark paths from each entrance to another until all entrances are connected. I check for unreachable boxes that do not have a path next to them and attempt to draw another path from the deepest inaccessible box until it reaches a path or door.

Then I place desks on all the non-path boxes and rotate their entrance based on where there is a path or entrace. If there are many free boxes, I alternate which to use based on the x and y box coordinates to increase the chance of alternating desk layouts like we see in real life. In the above example it is obvious there is a little more work to be done to improve this. All the rooms now have desks, chairs, cabinets, lights and light switches. There are a few more key ingredients to put in but we’re getting close!



Well, more like lost memory. Or chewing through memory. I’ve spent a while now investigating where I’m being foolish with it and I’ve been bleeding foolish everywhere. Looking into how memory is used and abused is really interesting and not something I’ve ever really delved into deeply as my previous work hasn’t required it. Now I have an entire city to look out for, I’m having to do things differently.

My main foe is modern memory management and the garbage collector. If I’m creating loads of things that only last fleetingly, then management will come in at some point and clean up all the unwanted stuff. They’re sluggish about it too, they have to look at absolutely everything and how it’s connected to destroy only the abandoned stuff. Basic game development advice always talked about object pools for things like bullets. But what about local variables? What about objects that are being rebuilt many times? Usually it’s a nonexistent issue and the new keyword will be fine to use locally. When you have so much going on though and so many local variables – it adds up. Sooner or later you’ll get the garbage collector coming in to pause your game for 1000 milliseconds. Very painful.

//Instead of
Vector3 newVector = new Vector3(someValue,0,someOtherValue);
//I’m using
Vector3 newVector = Vector.right*someValue+Vector.forward*someOtherValue;
EDIT: TenebrousP on Reddit pointed out this is rubbish and a quick test shows it’s just a stupid slow way of doing things. Serves me right for trusting a forum post without testing it myself… plain old new is more than twice as fast as the other method. TIL and thanks.

Dynamic meshes have been an interesting challenge; I don’t control the data in the mesh directly. I can set vertices fine, but can only retrieve a copy of them. Setting them more than once means the array is lost to the garbage collector and the game will freeze at some point. In order to solve this, I’ve had to wrap the mesh class with my own so that I have one array for vertices/uvs/triangles that is modified and never lost or destroyed. The array needs to be big enough for any kind of mesh it so everything is allocated at the start. It’s a waste of memory but the only way to ensure there’s less garbage collection.

public class DynamicMesh {

	public string name = "";
	public Mesh mesh = new Mesh();
	public Vector3[] vertices;
	public Vector2[] uv;
	public int[] triangles;
	private int _size = 0;
	private int triSize = 0;
	private bool _built = false;

	public DynamicMesh(int _size)
			Debug.LogError("Error: Size is not even");
		vertices = new Vector3[_size];
		uv = new Vector2[_size];
		triangles = new int[triSize];

	public void Build()

It’d be a tall task to completely eliminate garbage collection and I don’t plan on being able to. Ideally my game can run for long enough for it to not be called until I want it to be. Any pause in the gameplay like menu screens will be a good time to call it and release the memory. The user will be oblivious and everyone will be happy…ish