SRL : Post Mortem

SRL : Post Mortem

SRL : Post Mortem

It’s time for a full blown post-mortem. This is written more of a journey as it was only 7 days I can pretty much remember the whole development cycle so it’s pretty detailed. Enjoy!

SRL was created in 7 days (pretty much exactly) for a challenge known as the 7DRL (or 7 day roguelike). I started development on Saturday March 5th at about 21:30. I uploaded the finished build at approximately 14:00 on March 12th. I then did a tweak’n'bugfix build on the same day…
So as far as the challenge was concerned… It was definitely a success!

The key to any rogue-like game is of course, generative dungeons that are different every time you play so this was what I should of been getting done first. But no not me, as with all games I make I have a “let the passion be the leader” philosophy and then rain it in if it starts going mental. So the one thing I really wanted to do was the lighting. I wanted the really spooky feel even before I’d decided it was to be set on a spaceship, so I got to work on that. It turned out it was nice and easy to create the effect. In Unity, I just used deferred lighting and a single pointlight with shadows, Ambient light set to 0, and BAM: instant creepy shadows. So in the beginning I had a sphere, moving through a bunch of cubes on a grid, to test this cool lighting effect.


It wasn’t until a friend asked me on twitter what the theme was, that I thought about it… and went straight to my goto genre of Space/Sci-fi. Once I’d commited to a space theme in the form of a twitter message, (that shit’s basically legally binding). I then built a test level with assets (no code / generative levels at this point) and nabbed the player model I’d used in Surrender (gave him a self illuminating texture to make his highlights glow a bit, but apart from that, it’s identical… this was 7 days man, re using stuff is A-OK!). Behold! the feel of SRL was taking shape. I got the player moving around on a grid and instead of doing any path-finding, I just made it so you could travel to or activate an object if you have line of sight. Much easier, and still feels natural enough once you realise what’s going on!
On selecting objects: I made a funky selector that looks like corners of a wired cube that conform to what your selecting. Looks nice and techy… it was done with a 3D mesh of a corner piece that is duplicated 8 times and aligns each one to the corners of the selected object based on its collider. Simples! but cool looking.

As the passion was still leading over any to-do list or common sense, I decided to make some music (!) … (You know that dungeon still isn’t generative right?) So loaded up Cubase 4, dropped in 8 generic “spooky” pads, exported and closed it. The whole music track was made in less time than the total length of the music track. That is not an exaggeration I didn’t listen to it through all the way before it was rendered. Made a super fast intro with 2 3D text fields and some hot ‘Bokeh’ DOF. Then put the first youtube video out.

Arguably the most troublesome part of the development was in fact the dungeon generation, so I tried finding algorithms online and I found a standard roguelike implementation in C, and totally destroyed it. The basic premise is this, the player always starts at a certain point.Work from that point and make random features (a feature is either a corridor or a room, and if its a room, randomize the size and pick a type of room), check if that features fits in a spot connected to the last feature (or the players start), if it doesn’t… try again until either you finished the desired feature count or you hit a hard limit (if that ever happens sometimes the maps come out a bit smaller than they should) Then on a seperate pass add objects and an end point.

I had two types of room, ones with corner pieces to make them hexagonal, and ones without that are rectangular. This added some nice variety to the maps and added a little complication to the generation but it was worth it.

You might of noticed in the pictures there’s an awful lot of lights for a game without any light? Well! during the game you can activate the lights for 1 minute of lit gameplay giving you the edge of being able to see what is in the next room before opening the door and so on. All those lights were because the initial way I was doing this was having a light source on EVERY WALL. I thought, screw it! it’s deferred, lights mean basically no overhead right?… wrong. I eventually had to keep them all off and just raise the ambient light when the ships lights come on. Dissapointing as I had a really cool effect for when they all turned on (which I left in the game as a secret option called ‘sexy lights’) See video below:

 

Sadly ‘sexy lights’ is just a dev feature now as the majority of machines just couldn’t cope with 400 lights no matter how ‘deferred’ the lighting renderer was.

Some other interesting problems that occured were with the rushed nature of the project (7 days remember!) I had a problem with some of the room walls had gaps between them due to the geometry of the hexagonal room and the rectangular rooms and corridors differed slightly. This meant occasionaly light would seep out of the map and you’d see through the wall. I solved this by “blocking out” the level with solid black cubes (and triangular prisms for the hexagon room corners) which meant even if light escaped it would just hit the solid black object behind and it would be untraceable.

The final thing I’ll talk about is the GUI. For a while I’ve been using a custom version of a gui system that was developed by Prime31 called GUISpriteUI. I jumped on board this one and have been using it for “The Core” as it is a touchscreen only GUI system. Although I’ve added some extra functionality since porting it back to mouse and keyboard (dual mouse and touch screen support (and auto switching depending on the device its being played on), 9 slice scalable sprites, resolution scalability, aligned sprites, and a few different button types), at its core it is a great 1 draw call solution so is great performance wise. I plan on releasing it in the future as a fork of Prime31′s gui system, but it’s quite messy at the moment so will need some clearing up. You can pick up the original for iOS and Android applications at Prime31′s github repository here.

That about wraps up this post mortem, it’s been written a bit more dev-diary than post mortem but hopefully you found it entertaining or picked up some tips.

Thanks for reading!