My good god, its been three months since I posted an update here. Wait. That’s how I stared the last blog post. I’ve not been very good at updating this thing really. I’m sorry. Well, I don’t think you really care that much – plenty of other things going on the internet.

I’m here to say Redacted isn’t dead. It’s still alive, and kicking. It’s just going to be a little different. After BuildR, I’ve been working away at the game and it’s slowly coming along. It’s not going to be a city (not the first version at least). I’m trying to keep it simple for now and get the basic gameplay going. Not much more to say at the moment but when I have some more things worth sharing, I’ll post them.

My good god, it’s been almost three months since I posted an update here. You might ask yourself if it’s still a live project. I certainly wondered that for a while. I’m not going to make excuses though. Well, I am actually, as with all challenging projects, there are a lot of things to learn. I ignored the advice! I just steamed on through with the mission of making Redacted. Realising my ‘vision’, blindly. And it hurt.But let’s stop for a second. I have good news; some shameless plugging! Useless plugging to be honest (February 26th). I’m plugging something that can’t be sold yet. For the last two months I’ve been working hard on BuildR. It’s my second entry into the Unity Asset Store and a project that I’m quite excited about. It’s come directly from my work on Redacted. Go check it out. I’m aiming to release in middle March a public beta of sorts.
I’ve also relaunched my own personal blog/website. I had the old portfolio running until I moved to Hong Kong. I then just had a crap holding page with links to this project and Camera Path. Now I’ve brought everything back together into a site I’m happy with.
Redacted itself took a hard turn though. More like a car crash in mid December. I’d creatively worked myself into a corner and I had no way out. Following the tech dream rather than the gameplay dream was the big issue here. So I decided to cut it loose and leave it for a while, I had just had the idea to do BuildR so I thought it would be a good time to jump onto that. I could also get come critical distance and reassess Redacted. I’m currently back into a private prototyping phase with some cool ideas to move forward with though. The game itself hasn’t changed much as I hadn’t mapped out anything specifically yet. I feel like my feet are back on the ground now and hopefully I’ll have some cool stuff to show off by the end of March…

I didn’t think this would happen but I’m finding it hard to work not because of procrastination or things getting in the way, but plain old fear. I’ve become very fearful of this game I’m making. As someone who generally ignores their own feelings and tried to get on with things, it can be hard to change tack when you need to work out how you actually feel. And more importantly, why.

Fear of failure. Fear of unfulfilling a dream. Fear that I’m not good enough to pull this game off. It’s easy to do something you have little investment in. If you’re doing it for the money or for fun, there is little to lose if it doesn’t work out quite right. When you’re creating something that is coming from deep inside you and it turns out to be utter crap – that is scary.

I’m constantly revising the scope of this project to try to fit it into my deadlines and what will remain loyal to my greater vision of Redacted. There is a constant fear that what is in my head won’t work, or I won’t be able to complete it to a satisfactory standard. I’m scared that I’ll make something very personal, very me, and people just won’t like it. Hell, maybe I’ll end up hating what I eventually make…

Development can feel like a bit of a cave dive. The start and the end have specific landmarks, but mid development can feel empty and no progress is visibly made. You feel like you’re doing the same thing everyday and what you do produce just sow seeds of doubt. I guess this is a big problem with working on your own. No one to bounce off. No one to feel lost with in this middle ground. No one to fail with.

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.

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.

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

So it’s become a little quiet lately on Redacted. At least when you look at this website it looks that way. However a lot of the work in the past month isn’t the visual kind, and I’m going through a large shift in the city generation code architecture so i can have bigger and more stable cities.
I’ve also had house guests, a 30th birthday and a trip to Japan eat into development time. But I’m getting on with it!

One thing I wanted to touch on was motivation, especially with projects you’re doing yourself and when you’re working from home. How can you deal with all those distractions? How can you keep going? I’ve noticed my productivity correlates to how clear my goals are. I’ve seen this even in my normal jobs. If I don’t really know what i should be doing, I won’t do anything.
As a lone developer, it’s sometimes been hard to keep yourself going. The trick I’ve been using has been to keep my goals small. Very small. Couple of hours small. I feel like I’m achieving stuff and I’ve always got more goals to achieve. I also need to get this game done, I’m super excited!

I just want it done! To finish off – here’s an amazing video on motivation I keep watching…

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.

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 readingmany, 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!