Dev Blog

25.4.2020 update

(From Reddit /r/roguelikedev sharing saturday #308)

Slower week this week due to work. Only visible improvement in the game itself is options menu. You can adjust audio volumes, text size and also gameplay speed to suit your preferences.

Otherwise, I worked on level generation. I have not yet put it in game, but I made a test map generator.

Here's a live test:

Currently the parameters are tuned for level sizes approximately 50x50 to 100x100.

The cyan balls are potential exit elevator locations, entry elevator is the double cyan balls bottom middle. Grey rectangles are potential locations for map features (terminals, power cores, decorations, etc.). The floor colours don't mean anything, other than the ID number of the "digger" that created that feature.

The generator works like this:

First I dig out the main corridors inside the level using "diggers". Basically, excavate a tunnel in some direction with some width for some distance. Turn randomly, and randomly spawn new diggers. Then I use floodfill to find the undug areas.

I reject levels that don't have enough corridors, or that have any single segment that is too big. Like this gets rejected:

After that I then "seed" each area with room seeds that are spaced randomly, but at least certain distance away from each other. The unfilled circles are these room seeds. Then I "grow" those seeds left, right, up and down until that direction runs into another room, then that direction stops growing.

This continues until all rooms have stopped growing in all directions.

The remaining unclaimed areas are turned into solid walls, and each room is dug out and partitioned with walls. Walls between two rooms are placed inside the room that is larger in that dimension. So a horizontal wall gets placed in the room that is taller.

The map feature locations are added and then A* is used to path from each room to each other room. I start by pathing between random pairs of rooms once, to make some initial holes, then run the A* exhaustively between every pair of rooms to make sure every room is well connected to every other room. Each wall has a random weight assigned to it (though much higher than floor) so that punching through walls is disfavoured, but done if the path to go around is too long. This ensures high connectivity and I can also tune it by adjusting the weights of the walls for less or more connectivity. Finally corner walls have their weights doubled to highly disincentivize the algorithm from making holes in corners of the rooms for aesthetic reasons.

18.4.2020 update

(From Reddit /r/roguelikedev sharing saturday #307)

Most visible improvements this week is ability to select droids and map entities in the viewport. Each have a context sensitive action menu that opens when you click on them (in arrow mode). Scan tells you things about the target (in future this will be tied to your available sensor modules), attack will start automatically shooting at the target (you can cancel with the 'x' button on the icon bar or by selecting the target again), hack is not implemented yet.

Most audible improvement is more sound effects. Now instead of just environmental sounds, weapons and explosions make sounds as well. Sounds are not yet modulated by distance however. And you can only toggle them on and off. In future there will be an options menu where you can adjust volume levels.

I also added a short TLDR section to the start of the helpfile that tells the most important things and keys.

More invisible improvements... I worked on redoing the HTML/CSS code of the main page. Hopefully it will now scale better for different displays. In future the options menu will have a font size adjustment as well.

A lot of refactoring behind the scenes, plus the necessary infrastructure to allow the map entities to exist. Working on the class structure, etc. I think I'm finally at the stage where next week I can start concentrating on creating content for the game. Starting with map generation with actual map structure, not just a loose collection of random tiles. And in anticapation for that stuff, I have created already some graphics for a new type of robot:

Time to Crate: 50 days... (give or take a few)

11.4.2020 update

(From Reddit /r/roguelikedev sharing saturday #306)

Slower week this week. Made a comprehensive Help page that describes how to play the game (which shows automatically the first time you launch it now). Also made a new intro page that has the changelog and devblog embedded into it. The whole website is now HTTPS as well.

On actual dev side, built up framework for adding interactivity to map tiles by making them map entities. Right now terminals and power cores are highlighted in the main viewport. They are also destructible and don't react well to bullets. The current destruction is just for testing purposes, so they are destroyed by single hit with anything.

The map entities also feature another improvement - ambient environmental sound effects. The power cores hum and the terminals bleep as they process data and volume depends on your proximity. The sounds start disabled, you can turn them on with the checkbox next to the Help button. The checkbox will be remembered across sessions. Note that even if you turn it on, nothing makes sound until you move/perform an action. (Because web pages aren't allowed to make noise until user interacts with them.)

I also improved the realtiminess of the realtime. So the game's speed is now constant across machines while time is flowing. So 1 second in game is 1 second realtime. (Except for machines that are very slow, in which case the old fixed timestep is used.) Some stats are tweaked to better suit that.

Future dev plan: gave some thought on interface improvements, but will have to do some prototype testing. Then adding more sounds, hopefully some bang to the weapons. And maybe finally getting around to map generation... Once I have some more reasonable map, I'll work on adding more complex AI behaviours. And of course start adding more modules, finally. And robots. And items you can find to ugprade yourself... so much to do...

5.4.2020 update

New landing page! Which I don't think you can miss, if you're reading this text. :P

I'll be cross posting my Reddit sharing saturday posts here, and also make an update if I implement any major features. Like this new landing page. We also have a help page in-game, so lots of webdesign and text writing these past couple days. But tomorrow, back to code.

4.4.2020 update

(From Reddit /r/roguelikedev sharing saturday #305)

Major thing that I've accomplished this week was finally getting around to fixing the rendering code so that Firefox no longer chokes on it! You can now play it well on either browser. This also solved the issue with corrupted graphics on some systems (which turned out to be DPI scaling screwing with the canvas. I've also fixed the size of the canvas, so it dosen't take inordinate amount of room on such systems. This also helps with systems with smaller than 1080p screens.)

I've also implemented drawing enemy fire lines. So now you can actually see yourself being under fire, not just flash of red when you get hit.

Target lock icon is back, though it doesn't quite do anything useful yet. But at least it highlights the enemy, so you can see them better in the distance. I've also implemented a smart targeting feature so that the crosshairs target the largest contiguously visible part of the droid. This is so once I implement auto-fire it won't try to shoot the enemy through cover.

Otherwise I've been working behind the scenes to make the code more general and organized, so that I can start adding new modules and robots more easily. So instead of each robot basically having their own unique set of components, they'll be built out of standard components (with possible customizations). This way I can more easily adjust values after the fact to balance things, and create content for the player's droid to use once you can actually find new modules.

For future development, I want to start adding sensors and sensor capabilities. I've also thought some how you build your bot, what limits the modules you install. I'm thinking combined limit of slots and weight, or possibly even just weight. And I still need proper map generation. And I spent yesterday going through my sound FX libraries looking for sounds to use in the game, so soon the guns and robots might not be silent anymore...

Oh, and the robot hacking feature that was basically the very first thing I decided about this game after the 360 degree view...

28.3.2020 update

(From Reddit /r/roguelikedev sharing saturday #304)

I've continued work on my (now post-) 7DRL. I managed to fix the upload at Itchio, so now you can play the original 7DRL version there:

(Still Chrome only, I'm afraid I haven't had time to fix the performance problems with Firefox)

The current version has had a lot of behind the scenes stuff to work it towards the design spec I described in the first post of the devblog.

It doesn't play a huge amount different from the 7DRL version, but there are several visible differences, most notably the interface has had an upgrade, you can now turn off modules, and even unequip them. This in preparation for upgradeable equipment.

I've fixed a bunch of bugs, like autofire not removing dead robots. Though I removed the autofire from the interface completely for now. It's coming back later once I have more smarter aiming system.

I also added a self-repair module, so if you get a critical component shot up, it's not practical game over. Mind, it can't repair your Chassis which is your critical hit points, and it will only repair modules up to 50% of original spec. It takes up fair bit of power, so it's turned off by default. It can also repair (extremely slowly) without any power on your droid. So even if you lose your generator, it's not game over - assuming you're still alive.

I also made so that the neutral bots that get angered by your fire will now retaliate, instead of just continuing business as usual. That should make it somewhat more challenging to win. Mind you, the civilian bots are not very heavily armed, but they can still inflict significant damage to you if they get close.

Today I had some fun and worked on purely cosmetic stuff. The message log in the middle now teletype prints character at a time. If your droid's brain/CPU gets damaged, the messages print slower and more corrupted. It gets worse, the worse the damage is.

Next week will continue work to make things more generic, then hopefully some map generation, and maybe even robot hacking/takeover. At least a test version of such. And need to streamline the interface more, and add some speed controls - both to the time advancement and to your locomotion module. And also fix the performance problem with Firefox :P (I know what I need to do, it's just I need to redo a whole bunch of the map and raytracing code...)

9.3.2020 7DRL Postmortem


It was an extremely ambitious plan, like I said at the start and as can be seen from the design spec. Many of the features got axed. The one I'm most sad about was the hacking to take over other robots aspect. And also sneaking using the Transponder Spoofer. But the result is a minimal complete game and has potential for a good base for future improvements which I'm probably going to be doing after this jam.

What went right?

I'm pretty happy with the codebase. It has some ugly things, mainly how the player stuff is not encapsulated at all, input and rendering related code is all over the place, but for the most part how the robots are constructed in the code I'm quite happy with. Each entity contains a collection of modules which determine how it works. I didn't have time to make any modules beyond the absolute necessities (powerplant, chassis, brain, locomotion and weapon), but I can easily start adding more to that list now that all the code framework is in place.

Another thing that went right was the graphics. I'm very happy with how the 360 degree view looks and works for the player. I feel it's quite intuitive to use after a short adjustment period, for moving around anyway. Otherwise there is a lot of clunkyness in the interface due to time crunch...

Which leads us to...

What went wrong?

I spent way too much time on the rendering code. About 4 days was just getting the stuff on the screen, plus some more here and there. Plus because it is a free space game as opposed to strictly grid game, I had to implement collision physics which didn't take too long, but still was something that took time. Also spent time working on features that never made it to the final product, like the moving doors and destructible terrain. So effectively that time was completely wasted for this jam. (But it's there for the future now.)

But the whole carrying idea of the game is the unorthodox viewpoint, everything else follows from that. So it's kinda, yeah I had to do a lot of that work, but I could have just left it at plain walls, instead of the fancy indented walls and tiles. That would have cut the graphics engine work in about half and left me a lot more time to make a more nuanced and balanced and deeper gameplay.

So, the big failure was time management. An nothing illustrates that more than the fact that it wasn't until 30 minutes before deadline that robots shot back at you, 20 minutes before deadline that I had a lose condition and 10 minutes before deadline I had win condition. So it came literally right down to the wire whether this was a game at all and thus whether this was a success or failure.

I intentionally overspec'd the scope because I wanted to be ambitious, but I should have prioritized better. Like there is no level generation at all, the level is just each block as 33% chance of having a random tile placed on it or not. This was the bare minimum I needed for the testing and, well, never had time to make it better. (I did however come up with clever abuse of the A* pathfinding algorithm to make sure that the level is beatable so that no robot is spawned in an area that is inaccessible. Since killing all robots is the win condition.)

Also, technically this is also what went wrong: the choice of language. I picked Javascript and HTML5 using P5.js library because I wanted to learn these techs. Some things were very painful to do and took a lot longer because of that. Plus I know there's a lot of incompatibilities due to the approach I picked at start. I can fix that, but it requires redoing a lot of code, so couldn't do that during the challenge. So right now the game is Chrome only (though some people have had good results with Firefox on Linux), and even then on some machines the graphics are broken due to them doing pixel sampling differently (because of course they do... what isn't inconsistent between browsers...) But one of my goals was to learn these techs and I did learn, a lot. So teachnically bad decision for perspective of getting the game finished, but one that I had other reasons to make.

The last day

Hoo boy was the last day hectic. I came to it with an engine and the framework code, but was completely lacking gameplay. So during the final day I implemented weapons, made weapons shoot, made droids take damage, made droids have personalized behaviours (combat droids patrol, sentries guard, messengers and service droids deliver messages and work, and roomba cleans), made the combat droids able to (mostly) intelligently hunt for the player once they see you, and of course victory and lose conditions.

If there had been even just 20 minutes more I would have added a self-repair module for the player which I always wanted to add to make sure that the player won't be permanently crippled if, say, their hover module or power source gets blown up. In other words, make the player heal. So right now you can end up in a almost certain death and almost certainly impossible to win situation where you're just stuck in place. Not good for gameplay. Alas. Didn't have those 20 minutes.

Also didn't have time to make the neutral droids (yellow) start attacking as well after you shoot at them and they turn hostile (red). They are armed, just that their brains have no behaviour defined for attacking. Only now I realized that I could have just replaced their brains with the combat brain in the event they become hostile. Oh well.

From the very limited playtesting I manged to do before deadline and testing I've done after, I do feel that there is a kernel of a good game in here, so I'm gonna keep working on this in the coming weeks. And hopefully I manage to fix my page, so you can play it here as well, not just on my own server.

Final credits and thanks

Big thanks goes to Lauren McCarthy and the P5.js community for making the P5.js library. Brian Grinstead (with contributions from Marijn Haverbeke) for the A* pathfinding library. And possibly most importantly to David Griswold for making P5.js work with MS Visual Studio Intellisense and typescript type hinting. Without that, I'm certain this project would have been complete failure (because it would have taken me a lot longer to code anything and keep everything consistent).

Read rest of the 7DRL devblog at