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.

The game

So it’s occurred to me that there still isn’t much information about what this game actually is. Some of that has to do with the fact that I haven’t nailed everything down – there are a lot of things that might not make the final cut and there are a few things that might be done one of many ways.

I’ve also noticed quite a few games at various states of completeness, tackling a similar idea – procedurally generated stealth. This is very interesting and really cool that there are so many games like this on the scene. It’s especially exciting as none of us have even remotely the same kind of game in production. We all saw a gap and took a completely different view on it.
About my game though, because that’s why you’ve found yourself here right? It’s called Redacted because the world as you see it has been redacted. You don’t have the security privileges to see what you’re seeing so you’re only presented with the information you need to pilot the environment and get the job done. It’s also for your safety, the less you know what you’re doing, the better. People, conversations, data are all abstracted and obfuscated from you. You know they exist but you have no knowledge on what you’re actually doing.

This raises the issue of trust. How can you be sure what you are doing it right? Do you know who you’re really working for? And should you care? This is one of two themes I’m exploring. The second theme is privacy. I want to really explore how our privacy is being invaded by technology and how we let this happen. Is this a good thing or a bad thing? With so many drones, did we walk into Nineteen Eighty-Four? More on this some other time…

In this game you pilot a nano sized drone insect through a busy city. You accept contracts to spy on people, steal information, sabotage technology, many different missions based on espionage and subterfuge. The game by nature is stealth based and remaining undetected by hiding in cover or in plain sight is key. Rather than using shadow, you hide in electromagnetic radiation. Lights, computers, mobile phones all provide cover for your drone and you will need to manipulate your environment to achieve your goals. The setting is the very near future not too dissimilar to ours.


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


Basic Pathfinding in a Procedurally Generated Building

So there isn’t as much visually to show this week. I’ve hung up my geometry creating hat to focus on other aspects of the game now. Specifically, I’m moving towards a prototype enemy. This week I have a basic pathfinding structure done. The benefit of procedurally creating a building is that you know where everything is actually located. I already have all the data on doors, room sizes and corridors so after these have been generated, I can use the data again to build a node based map of each floor.


Procedurally Creating the Interior of a Building

Procedurally Creating the Interior of a Building

Over the last couple of weeks I have been working on generating the inside of buildings. The buildings in the game need to have rooms and interiors. Every building should be filled with possibilities, not just a handful. I’ve been reading many, many, many articles, watching loads of videos and trying to digest as much knowledge on the subject. I came to realise this problem was not much different from dungeon generation in Rogue-like games. Each floor of these buildings is like a level in a dungeon, just going up instead of down. Roguebasin became a very useful resource and will continue to be as this project continues.

First up was to tackle room generation. Watching that Subversion video over and over again, I came to realise they were subdividing spaces and then deleting walls somewhat arbitrary. It created very nice rooms. The common theme I keep seeing in procedural content generation is that simplicity allows for complexity. I settled on a simple Binary Space Partitioning to create the basic rooms. Using the structural pillars of the building to draw a base room unit, I would divide and divide again until it was either too small the divide further, or it randomly decided to stop. The building core would have to be accounted for so I started to four super rooms that surrounded it. These super rooms contained all the room units on the floor that would then be split to create something like the above layout.

Next I would generate all the walls that partition these rooms. Each wall had two points that defined it and these points will come in handy later. I then iterated through the walls and deleted a percentage of them to give some larger, interesting rooms and cleaning up loose walls after.

Next up was calculating the depth of these rooms from the core. The above image displays this, starting at white for the core. It goes red through to violet, nearest to farthest respectively. The depth will be handy for further generation and later on when assigning goals within the game.

I needed to generate corridors next. These will link up most, but not all rooms directly to the core. Initially, I attempted a really simple algorithm. I looped through all the rooms converting one of its free walls into a corridor. I avoided small rooms that I had labeled as cupboards/store rooms and any walls touching the external parts of the building were ignored. I then checked if there were any obvious gaps in the corridors and plugged those. I ended up with the above which was adequate for my purposes until I tested it on some other seeds. It fell short too often so I ditched it.

Instead I used the basic Dijkstra Map process over all the wall points. Starting from the outside walls, each corridor would attempt to work it’s way back to the core choosing the shortest path. This was more than adequate and gave rise to some very interesting floor plans. Finally, I looped through the rooms from the core, adding doors into walls and corridors until every room became accessible. The above is a final layout with geometry created.

There are some further additions I need to look into. I can definitely improvement the corridor design, like backtracking and selecting a different path if it can’t get close to the core. Corridors should prioritise larger rooms. There could be less doors or maybe slightly smarter door placement. For now – this will do!


Video of City Generation Progress

Here is the progress I’m making on the city generator. The building shells and egresses have been created and basic level of distance is in place. About 500 buildings are modelled in about 6 seconds so there’s some work to be done reducing this time and improving the quality of the models. The grey buildings in the background are serving as eye candy only.


On Architecture

On Architecture

So when building a city, architecture is a very big question. I’ve always been an admirer of it, ask me when I was 5 what I wanted to do, and the response would have been ‘an Architect’. So when it comes to choosing a style that fits the scope, scale and style of the game, I had to do a bit of research…

One key point to make is that all buildings with have explorable interiors. Every floor, lift, stairwell and room will be generated. This is a departure from most city generators that concentrate on creating exterior content. This is also another reason why all my buildings will be convex rectangles to keep calculations simple and fast. My work so far is the basic creation of a building, there is a lot more to do to the externals to make them more interesting.


The city is going to have three styles of architecture; The Chicago School, Le Corbusier and the International Style. These all fit within the simple squared building that will occupy the Redacted world. Their structures are easy to produce procedurally compared to say Postmodern or Art Deco. The sharp angles and lines also increase the sense of order. A large theme in redacted is the nature of reality and what can we trust. The player will view the world reconstructed by his drone pilot program and a lot of information will be redacted for security purposes. I remember the set designers on the Matrix motion picture used a lot of right angles and squares in the Matrix world to reinforce the sense of artificial construction. These styles are also quite cold and functional, adding to the sense that the world is like this and you’re on your own.



Building Plot Subdivision

Building Plot Subdivision

In most cities, a plot of land isn’t always occupied by a single building. Large buildings may do this – but a city won’t include many large buildings. So i need to divide some plots and into smaller pieces of land. I looked into many methods to do this and implemented a couple, settling on one in the end. There are three goals it needed to achieve. It must produce decent results that look real enough and produce only rectangles. Again, I kept this simple by avoiding irregular and non convex shapes. It must also do subdivide the plot quickly; in a city of hundreds of buildings, I couldn’t afford this algorithm to take it’s sweet time.

The method of room subdivision in this paper caught my eye. It would be very flexible, ensuring all plots had a road as I could grow the plots only from points where it met a road. It would also produce some nice irregular building shapes (as irregular as rectangles can be). So I set about implementing it to see some results. The hardest part of it was ensuring that the plot grown was a rectangle. This method was geared to creating irregular and concave plots. I realised quite quickly though, that this growing process was very expensive. I stupidly thought I should grow it metre by metre, not thinking that a small 20 by 20 plot would need at least 400 iterations, let alone a 100 by 100 metre plot. I was also never happy with the methods of ensuring it remained a rectangle. I ditched it.

I went back to the drawing board (thinking board?). This is too complex and i need to simplify the problem to get my result. In the end I settled for something far simpler and very quick. I would only divide a plot three times at a maximum and I would basically cut it at a random point through the length in a straight line. It was far simpler and quicker. The algorithm selects a plot big enough to be split and splits it a number of times either horizontally or vertically. I was happy with the results but a key improvement would include ensuring that cuts would not strand plots from roads as we can see in the above example.


L-System based road generation

L-System based road generation

The first thing I started building was a city generator. After studying papers online, watching many videos and how Introversion software went about it, I built up an idea of what was needed and what I would avoid. I’m just one guy and my surname isn’t Delay so I kept it real simple. The road system is set to a grid so there are no curves or even diagonals in the city. Keeps all the maths simple.

There are many systems for producing a road system and many factors you can take into account. I ignored most of them mainly to keep the scope small and to keep complexity down. I settled on an incredibly simple algorithm to generate the road structure. It would essentially draw snake roads changing direction perpendicularly based on a seeded random generator. It would spend a lot of time retracing it’s steps to create city blocks. The outcome was pretty good with such a simple system and resembled something of a city.

Modifications to this included using multiple road iterations instead of just one so the road system flowed from the center. Otherwise there was a tendency to create linear city. I also randomly removed roads and modified others to make them alleys to keep it interesting. One final thing to implement will be to remove dead ends to improve gameplay later on. Dead ends are always frustrating unless you want to build a maze.