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.

thunderrun

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.

 

1 thought on “Thunder Run: failure”

  1. Just so you know, I think this is amazing 🙂 It’s a shame that it doesn’t have any kind of goal, but the mechanic is very nice, I hope you keep pushing this forward

Leave a Reply