Thunder Run: failure

This was my second 7DRL attempt (my previous one was Swift Swurd, a success last year). There is a working prototype here (running in flash in a browser): Thunder Run

My plan this year was for a tactical game about air combat in the 1960s. You control one aircraft, and the focus is on managing your pilot’s resources of time and attention. So if turns are, say, 5 seconds long, then on a turn you can scan the sky and look for enemy planes; or you can try to locate your mission target on the ground (and risk losing situational awareness of what’s happening in the sky); or you can use the radar to try and get a lock on an aircraft outside visual range, or make a hard turn, or so on. Pilot exhaustion and stress would build up over time, from SAM near-misses or pulling Gs, and this would degrade how much time you can spend on things each turn.

I would cover the roguelike bases by randomly generating the world and making the player into a mercenary, hopping from airbase to airbase and taking on missions from notice boards.


What went wrong

My original plan was to have a very simple flight model, with all planes travelling at the same speed and aircraft performance abstracted away almost completely. After all, that was not what the game was meant to be about. I had a prototype with basic flight working after the first day, but then I started thinking that it wouldn’t be too hard to model the behaviour more realistically, if I just did some research and some tweaking. This ended up as me losing most of the week to reading about power curves, aspect ratios and compression drag, and building a basic turn-based flight-sim with some physics in it but no game. That’s the prototype at the top of this post. It gives you either a light fighter (F-5) or a heavy one (F-4) and you can take it for a spin, with a few other aircraft also flying around randomly.

The other thing that went wrong is that I decided that I couldn’t do what I wanted in ASCII (since I wanted to show altitude and heading information for each plane), and that I needed simultaneous movement rather than entities moving one after another. So instead of using libtcod and python, which I had used happily last year, I used Flixel. This meant that I had to worry more about graphics, and that I had to build my own game architecture from scratch, rather than adapting something that already worked.

In retrospect, it would have been much better to embrace the limitations of ASCII and to treat this just as a highly-modified conventional roguelike, with monsters limited in how fast they can turn around, ridge-lines instead of dungeon walls, and missiles instead of spells. I still think this is not crazily ambitious, if I can keep the right focus, and am tempted to have another crack at it over the next few weeks.


Swift Swurd post-mortem

On this week’s Roguelike Radio podcast Darren Grey mentioned that it would be interesting to hear from the authors of some of the 7DRL successes, as well as the failures. I had been leaving my game to speak for itself, but I think it does a couple of interesting things, so will say a little bit about them. Mild spoilers, in that some things in the game are slightly mysterious, in what I hope is a fun way — play it!

(Download here, Windows and Linux)


My history with roguelikes is that I’ve messed with Nethack now and then, and more recently played quite a lot of Brogue, and some Dwarf Fortress. I’ve never made one before. Two things have bugged me about them, that I thought I could try to address: bumping into things and watching health bars go down doesn’t feel like fighting (although of course it gets better at deeper levels with more stuff happening), and they trivialize killing.

I started thinking last year about how to do a tile- and turn-based swordfighting game that felt more like a swashbuckling movie, possibly arising from very simple mechanics, like in the old Prince of Persia. Then I played Dark Souls, and thought that I could borrow its mechanic of a recharging stamina bar. I made a mockup:

Since the graphics would be plain ASCII, I wanted another way to spice up the visual presentation, and had the idea of changing the language. Based on vague memories of Robert Louis Stevenson historical novels, and of d’Artagnan being a Gascon, I made the hero a 17th or 18th century Scotsman, with in-game text to suit. I got as far as getting the libtcod tutorial running in Python, then put the idea aside, coming back to it for the 7DRL.

What went right – combat

This achieved the feeling I wanted. Guards retreat and advance as they lose and gain breath, so each fight moves back and forth across the dungeon, making the geometry matter tactically. Facing matters, but doesn’t get in the way when you’re not fighting. The enemies move predictably, but you usually meet them in pairs, which keeps it interesting a bit longer. The pistols give you options if you get overwhelmed (and I’m very happy with the shot effects). You die in one hit, so need to pay attention from the start. The guards are not nameless, and do not drop out of play immediately if they are mortally wounded – you have to fight around them (however a lot of the things I wanted to do with this side of the game got cut).

What went right – language

I thought of time spent on this as equivalent to time spent on graphics, as a way of giving the game some extra flavour. Scots is a descendant of Middle English, very widely spoken in Scotland but terminally unfashionable as a written language for most of the last 300 years. In particular, there’s no standard way of spelling it. The main sources I used were the Dictionary of the Scots Language and Wir Ain Leed. As I understand it, the first of these is a record of Scots as people have (haphazardly) written it, while the second tries to regularize the spelling, as part of creating a written form of the language that people can learn. The first has “swurd” and 11 variants, the second “swuird”.

It works for me at making the game feel richer and a bit different, and I’ve had some positive responses. I hope I didn’t make too many mistakes. During the competition, it occurred to me that it also serves as a version of the roguelike item-identification subgame. Finally, it had the (deliberate) effect of stopping me from writing too much — I wanted to keep to matter-of-fact descriptions of what was happening in the game.

What went right – technology

I used libtcod and Python. I found Python fun and fast to code in once I got going. libtcod is easy to set up, has good documentation, and is simple (from the user’s point of view). It was an enormous help to have the tutorial available as a guide on how to structure the game. My worst technical moments were running into an input bug in libtcod (fixed in newer builds) and spending hours working out how to set up py2exe. So, as these things go, I got off very lightly.

What went wrong

The dungeon is bare. I had planned to make it look more like the mockup, with chairs and bottles to throw, things to trip over, and lighted areas to stay out of. (Although I worked on this a little after the competition, and found that the smaller rooms in the actual game look too cluttered very quickly.) More importantly, I didn’t leave myself time to think properly about the distribution and number of guards in a level, and I suspect that the game is currently much too easy, especially once you have combat figured out. I had plans for more kinds of enemy, dogs and big guards, but they didn’t make it.

I had a story worked out about rescuing a young lady (who would reject you if you had killed people dishonourably) and escaping past your opponents’ ghosts, but this would have been hard to play straight and I felt an enormous relief when I cut it on day five. I put in a replacement (collect three pieces of treasure!) late enough that it doesn’t get explained anywhere.

Overall though, I’m pretty happy with how things turned out, and am looking forward to trying something new next year.

7DRL Success: Swift Swurd


Download (Windows .exe and python source)
Controls are shown in the game. Collect three pieces of treasure to win.

I wanted to inject some historical swashbuckling drama into the dour world of bumping into things to attack them, and I’m pretty happy with how this turned out, although I had to cut a lot for lack of time. It uses a mechanic similar to Dark Souls’ stamina to keep you moving back and forth while fencing. The text in the game is in Scots.

It’s made in Python with libtcod 1.5.2. If anyone is able to help with making a mac or linux build, that would be fantastic.