Home > Design > How to Make a 7DRL

How to Make a 7DRL

January 31st, 2012 Leave a comment Go to comments

I had a couple of people asking me about this, so I guess I’ll try and impart some sagely advice. I’ve done two 7DRLs, a 4DRL, a 32HRL and a 1HRL. I’ve also a failed a 7DRL, so I know where one can go wrong too :) Some general points:

  1. Plan ahead. Write down your ideas in list form. Don’t get too detailed, but have an idea of how you’ll implement them.
  2. Small scope. Your game should ideally be based around one novel concept, or trying to do one thing well. Stick to just one dungeon, basic items (if any), simple mechanics. If you’re going for more than this then make sure you consider what’s essential and what’s not.
  3. Throw out the genre tropes. Identification system and hunger clock don’t add much to a 7drl and take away time from more fun things. If removing the hunger clock you’ll likely want to remove background healing too. Plenty of other things can be removed, like stairs to previous levels (so you don’t have to worry about coding persistent levels) or entire combat mechanics. Do you need to code a chance to hit and dodge or can you make things simple and deterministic? One of the best elements of 7DRLs is seeing how you can strip a roguelike to its bare bones and still have it be fun to play – maybe even more fun if done right.
  4. Reuse as much code as possible. Borrow off past projects and other games. The goal of the challenge isn’t to spend seven days writing new FOV algorithms. That’s all been done before. Make something new! Level generators are an especially big time sink – stick to quick and easy cellular automata whilst you focus on real gameplay. A lot of players turn to libtcod for a good code base to get their game development into gear quickly. The T-Engine is excellent too. Don’t be worried about your code being sloppy or a mess – if it works then just bloody well use it! You’re unlikely to touch the code again after the week’s over, so it doesn’t matter how hacked together it is.
  5. Don’t get distracted. Keep IRC closed. Don’t follow other peoples blogs and projects. Don’t blog yourself. Turn off your whole damned net connection if you have to.
  6. Keep planning and revising. Your plans are bound to change, and your expectations. Keep making lists of what you expect to do the next day, and what you need to do by the end of the week. Make sure plenty of those things are optional, since you’ll likely not have time to do them all. Personally I send e-mails back and forth to myself each day from work/home, and make notes on paper or my phone whilst on the move. If you have an idea in the middle of the day be sure to jot it down.
  7. Reserve the last day for entirely bug-fixing, playtesting and polish. Most likely it’ll get overrun by other things, but in that case at least you’ve got some extra time for that. And if you do get the time to polish then your game will be all the better for it.

Some further general points about how to make your game appeal to others:

  1. Provide a straight exe for Windows, Linux and Mac. You can sort this out properly after the 7 days if need be, since it can take time to get people on other OSes to help you out. If your game is on python or some obscure engine then bloody make sure it can be played on other peoples’ computers. Too many 7drls are flat out hard to get running. Most players won’t spend longer than a few seconds trying.
  2. Support standard keys. That means numpad and vi keys generally. Configurable is great, but not necessary. Make sure you can bring up the controls in-game by pressing ‘?’. Preferably have a readme file too.
  3. When announcing your success give a good description, some instructions to get it running, and a link to the download and a screenshot. Try and use some reliable hosting like Google Sites.
  4. Better to be too easy than too hard. If the game is impossible to penetrate no one will play it. If it’s too easy then lots of people will play it exactly once. Being in the middle is better, but if you’re going to err one way it’s best to err easy. An elegant way to do this is to have a fairly flat difficulty curve – make the player stay about the same power level throughout, and the monsters get more interesting abilities rather than simply getting more xp/damage. Cutting out character progression also makes things easier to code! Less time needed for playtesting too.
  5. Get friends to play it and get feedback. The most invaluable thing is to watch someone else play it in person without giving them any advice – seeing their frustrations and delights is both insightful and inspiring.
  6. Do a post-7DRL bugfix/polish release. Makes it more likely that your game will be played and appreciated. There’s no shame in admitting you missed out on some things during the frantic 168 hours.
  7. Have fun. I love the thrill of the challenge, and the last day always gets my heart racing. It’s also about the only time of year I get pushed into doing some real coding, which is great because my schedule’s normally too busy. Game coding presents a unique blend of problem-solving and creativity that no other past-time can provide. To create something new that others can interact with and enjoy is truly satisfying. Hopefully you’ll have fun playing your game too ;)

I also think it’s nice to throw in references to the number 7 here and these in your game (or even just in odd bits of the code). Note the number of points made here and how they’re split up. But that’s just me ;)

Tags:
  1. Soyweiser
    March 6th, 2013 at 14:29 | #1

    Got a typo. ‘reasme’ -> ‘readme’

  2. February 1st, 2012 at 22:32 | #2

    If you have time in the last couple of days to get feedback it can really be worthwhile. I’ve managed to snatch some really killer bugs last-minute thanks to doing that before. There are things others will try in your game that you won’t even think about. Of course, one might not have any time to indulge on this…

    Agreed on the must-haves and expendables. I always plan a core game and an ultimate game, and end up coding something inbetween.

  3. January 31st, 2012 at 20:57 | #3

    Wise advice. It’s worth pointing out that getting feedback should take place after and not during the challenge period.

    Also, a corollary of planning and revising and throwing out the genre tropes: have a clear, short list of must-haves, and be prepared to throw out half of it. You’re guaranteed to underestimate your development time.

    Looking forward to this year’s 7DRL challenge!

    Ebyan “Nolithius” Alvarez-Buylla
    http://www.nolithius.com

  1. March 9th, 2013 at 07:18 | #1