Making Horde, and stalling

Last November, I started telling a few people about a new game I’m making. It’s called Horde, and it’s very much an experiment. It started out as a proof-of-technology for a different project, which I want to work in a very specific way; I wanted to see if I could get Twine to do certain things with loops and time-based variables, and to use a different project to learn. Something that would give me a tangible thing to play and to work on, while also learning new skills.

But as it grew and got more ambitious, Horde started to make sense in its own right. It’s an incremental game, a sort of text-based Cookie Clicker, in which you build a horde of barbarians and send them out on increasingly peculiar errands. It’s a tricky thing to build, mechanically, especially if you’ve got no experience of coding, but macros and new features in Twine make it possible to build this sort of thing on the shoulders of work done by other excellent people who know what they’re doing.

So I put it up as an alpha build. And suddenly people were playing it and telling me about it – giving me incredibly useful bug reports that helped me sort out some tricky problems, but also suggesting new avenues for development, giving me ideas, being excited about what was coming next.

That’s an incredible feeling, by the way. It’s a gift, when people play your unfinished work and give you thoughtful responses. Not all the feedback is always useful but the fact that anyone cares enough to offer it is a sign of support for what you’re doing, and that was enough to tell me that Horde is worth carrying on with, worth trying to turn into something finished, or at least vaguely feature-complete. (Whatever that means.)

I started putting up a new build every week, or trying to. I started making sure that I gave it a little time, a couple of hours at the weekend or an evening, and that time started to expand. I put up little incremental tweaks, and then a few bigger updates, and then found myself rewriting it to make the coding less weird and icky now that I understood more about what I was doing. Then, in the middle of an attempt to make a particularly sticky system, in a problem to which there’s no right answer that will make it work perfectly how I want it to, I hit a wall.

I stalled. I’m still stalled, a month later. I hit a page full of red errors, and instead of trying to fix it, I walked away. I’m not massively proud of that reaction. All that work is still there – all those hours I’ve poured into it have made a solid base to build on – but I hit a problem that felt insurmountable and as yet I’ve not managed to pull it apart into small enough chunks to work on.

Learning to code is hard, especially when you have no directed support; learning anything around the edges of a more-than-full-time, stressful and pressured job is even more difficult. Creating things when you spend a substantial part of your work day creating is tricky, too. Tiredness creeps in. Things distract you. Often, and perfectly legitimately, it’s quite nice to stop working, even when that work is self-chosen and self-directed.

But I can find time, or I can make time, if it’s what I really care about. That’s always been true. Horde is something I care about making, even though it’s a very silly game and a draftwork, because enough other people thought it was worth playing and talking about. Hopefully by this time next week it’ll be at least a couple more hours closer to completion. Even if that’s all, that’s a start.

Published by

Mary Hamilton

I'm an operations specialist, analytics nerd, recovering journalist, consultant, writer, game designer, company founder, and highly efficient pedant.

3 thoughts on “Making Horde, and stalling”

  1. Y’know, I was just wondering if you’d made any more progress on Horde.

    Coder’s block is common and horribly pernicious; from my own experience, the direct way to beat it is to split the overwhelming job into smaller victories, even if (in and of themselves) those little victories aren’t immediately useful to an end user. Thankfully, code is /very/ well suited to this process, though you need to make systems that give you, the coder, the positive success feedback you need to keep going. Unit testing can be a big part of this – building tests that acknowledge the little successes you make while you’re still en route to a grander, more imposing deliverables.

    And if you need any help, you can always throw code at me and demand answers.

  2. I did play the hell out of Horde for a while, but then the H&S research bugged out (waiting 60000 seconds only to be told that actually you still need to research the thing you’ve waited for and wait another 60000 seconds was awkward, especially as it seemed to slow Firefox to a crawl. One game second would take about four normal seconds to pass and using the computer for anything else was impossible.) I also had about 70 million barbarians at that point, which may have also slowed stuff down.

    Still, I had fun. Do come back to it and I will eagerly play again.

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.