Cyber Crime Driver was made for the 7-Day Broughlike challenge. It's a turn-based game where you have to navigate a hexagonal map collecting briefcases and avoiding cops.

The main design goal was to create a tactical roguelike without combat - the map becomes steadily more and more crowded with cops as the game goes on, and there's no way to remove them - but the player character is faster than the cops when on highway tiles, and has an ability to switch places with them when on slum tiles.

What worked

The design

It has long been a goal of mine to make a non-violent roguelike that is still interesting, and I think CCD is by far the closest I've got to that. I think evasion/outmaneuvering carries enough of the tactical positioning element of roguelikes to support a full game. I definitely plan to explore this more in future, probably by post-jam updates to CCD.

There is admittedly a lot more that I wanted to get done in CCD - I think it's state, as of the time of submission, barely qualifies as a roguelike. There's not really anything to "explore" - there's only one kind of enemy, only one map, there're no upgrades or different starting packages. Even in Brough's most pared-down games there's always an element of discovery, and CCD doesn't have that.

That said: it's a real game with depth, and I'm so happy with how that came out. When making games I'm always looking out for the point where I start losing time because I get distracted from debugging the game because I start actually playing it, and CCD hit that relatively early. It doesn't have a ton of depth to it, but it's enough that there's a noticeable progression from being bad at the game to be being good at it, and you definitely need to balance when to be cautious and when to be aggressive.

The tech

I was messing around with LOVE recently and really enjoying it. I can absolutely see the advantages of using a gui-driven engine like Godot but I'm just able to get into flow state much more easily when the game is 100% in-code. LOVE uses Lua as its scripting language, which is fine - I was originally really down on Lua because it uses 1-based indexing rather than 0-based, but... now I think that is a silly concern. I've found that if you keep to using iterators rather than manually indexing it barely ever comes up.

The main thing that I don't like about Lua is how verbose it is. You have to write "function" and "do" and "end" so many times oh my gosh, and there's no "+=" operator. But I discovered Moonscript, which is extremely concise. It's a scripting language with a toolset that allows you to compile it to Lua, and I was able to get a build system together that gave me a pretty quick turnaround between editing some code and seeing its changes in-game. I think there's an extension to LOVE to allow it to run Moonscript natively but I didn't want to mess around with compiling LOVE from source or anything.

But yeah: LOVE is neat, and Moonscript is extremely good for smashing bits of code together really quickly.

The bits of polish

I think sound design is one of the biggest factors in a game feeling polished. I think the sound effects came out acceptably - there's such a big jump in gamefeel between "no audio" and "has audio" that I think it's almost always worth it to try and make sure you get at least some audio in there. I was really happy with the intro/winscreen sting, it's such a jam.

I'm also really happy with how the minimal token movement animations work. It's really easy to follow the pieces as they move around the board, which is of course crucial in a game like this.

What didn't work

The instructions! The instructions!!

I didn't really get the opportunity to playtest until the submission deadline had already passed, and the game definitely suffers for it. I wrote the instructions in the half-hour before submission, in a real hurry, and I think it shows. They're a weird graphical mismatch, all hand-scrawled because I didn't have time to bother with laying out text, and the wording is extremely terrible. The movement system - the backbone of the game - is explained with "you have three movement points" and that's it. What's a movement point, McLean?

The game highlights which tiles you're able to move to, but my post-launch playtests revealed that most people still assume that you're only allowed to pick the adjacent ones until they're explicitly told otherwise. And, yeah, the explanation of how the moves are calculated is woefully inadequate; even after learning you could move more than one step in a turn, people were still like "how come there're more moves available sometimes? is it just random?" The speed boost you get on roads is crucial to the strategy of the game, and really needs to be explained better.

The disorientation mechanic is also really terribly explained. I think it's something that needs to be called out every time you move in to a slum tile, rather than... noted once without context at the start of the game.

Similarly, the way that cops and briefcases spawn is too opaque. Every game I make I become more convinced that there's really no limit to how much you should surface your gameplay mechanics. If you have something that is running without its function being transparent to the player, they're just gonna assume it's random or not notice it. If you call it out, people can factor it into their gameplay, or at least appreciate it.

Really, I think the "right" way to do this would probably be to have some kind of tutorial level, a hardcoded map with a low health limit that requires the player to correctly use the highway and slum abilities to be able to succeed. Telling someone that they can do a thing will just get ignored; it's better to make them figure it out in order to overcome an obstacle.

The balance

The game is pretty swingy.  Lucky spawn locations for briefcases and cops can make victory trivial, unlucky spawns can (I think) result in a genuinely impossible run. I think it's good to keep at least some aspect of this - mainly to give players a taste of victory even as they're starting to figure out the strategies - but in its current state it's much too random.

I think a second pass at this would involve adding a heuristic to try and spawn cops and briefcases in less densely populated areas of the board. I'm not really sure how that would affect things, though - this is one that I think just needs a lot of iteration, which is a luxury I didn't have in the jam's time constraints.

Overall though

I'm really happy with how CCD turned out. I really didn't expect to even finish the 7DBL jam at all, much less finish it with something I was actually proud of. I had a lot of fun doing the 7DBL, so a shout-out to the organisers & to Michael Brough for founding the genre in the first place.