I was very wrong about how this year would turn out.
A year ago, I set out on an adventure to make my own video game. Shortly thereafter, life became significantly more demanding. For reasons that I won't belabor here, it became almost impossible to work on my game for the past nine months. Unexpectedly, this experience has made me incredibly grateful and I feel far from frustrated. Like a plant that is belligerently growing from inside a crack in a bit of concrete, I am surprisingly still making games.
It has been good to realize that I want to develop games enough that I am willing to keep going in the face of setbacks and failure. Everything else I truly love requires effort and now I know that game development is no different. I have also been learning some important lessons along the way. Well - writing that I have "learned" the lessons might be overstating it a bit. Let's just say these things are making an impact on my thinking today:
My first project was waaaaay too big
But it was not too big because my game idea was overly ambitious. It was too big because my game idea was not narrowly defined enough. Having a rough idea can be great for getting started, but keeping it undefined as you go along can also lead to an immense amount of scope creep. Much like this quote from Tom Francis, I found my time wasted on possibly unnecessary features:
"Every hour you spend working on something before you have the core part of it playable is an hour that might be wasted."
My first project got stuck in the deepest part of the weeds
And as if an enormous amount of scope creep wasn't bad enough, I also found myself polishing code instead of making progress most weeks. This is an all too familiar trap for programmers. Instead of worrying about my core game, I was obsessing about the efficiency of my home-brewed AI waypoint system. Perfecting code is an insidious killer: it feels like real progress, but it isn't.
My first project was expensive to test
Prototyping inside of your game development environment is not always the best idea. Even simple ideas can require a huge amount of objects and functions in order to test. Taking a page from my day job as a web developer, I am re-learning to prototype my game ideas outside of code:
This endeavor cost me thirty minutes plus some dining table real estate and saved me two years of working on a bad idea. After even just five minutes of gameplay and feedback, I was immediately convinced that this idea was no good.
The new rules
With all of the above in mind, I'm moving forward on my project and taking to heart some new rules. I gathered these from a talk Tom Francis gave at the GDC after launching his fantastic game Heat Signature. And although that game is one of my favorite games of all time, Tom has been the first to admit just how difficult it was to develop and how that challenge has produced these guidelines:
Choose an idea that's quick to prototype
Prototype the important parts
Decide what should be the core
Creep as far as you like in that direction
As far as I am concerned, I think he is onto something: I've made more progress in the past three weeks than I have in the past four months.
Last week, I did not make any commits to the code base for Hardcastle. I would love to write here that I lost momentum because I was spending extra time with family, doing something incredibly noble, or even just having a bit of rest and relaxation. Unfortunately, it was because my normal 40 to 50 hour per week job became more of a 70 to 80 hour per week job for the last several weeks. But I am not writing here to complain about the job. I truly enjoy the people on my team, the work is interesting, and it keeps the roof over our head. That being said, it was a stark reminder that I have a day job, and that day job is not making PC games.
I knew that there would be weeks where my day job would come into conflict with my not day job, but I regret it all the same. Happily, I can state that returning to game design this week after a forced hiatus feels great. Absence has made the heart grow fonder, as they say.
But maybe I needed a break anyways. The week before last was arrow week. During arrow week, seemingly simple challenges were becoming overwhelming as my brain was overloaded between life, work, and game design. But failure and I are becoming good friends. I love capturing moments of bad development like this:
...almost as much as I love capturing good moments:
After reducing the number of arrows per soldier, adding collectible arrows that stick into both movable and unmovable objects, and tweaking arrow velocity, I was able to land on a fairly playable build that felt appropriately tense:
The title "Glenn LaBarre immediately regrets this" is a friendly jab at myself to help me overcome years of inexplicable fears of writing in public. It is also a respectful tip of the hat to a favorite game designer:
... I was determined to have [a title] even if I immediately regretted it. After trying several I immediately regretted, I gave up and left it as the placeholder: "Tom Francis Regrets This Already". I still regretted it, but neatly, the more I regretted it the more appropriate it became.
Last week, I landed on a title for my current project. I decided to name it Hardcastle. Judging from the title, the game is apparently hard and also takes place in a castle. It is entirely possible that both of those facts will change before I release this game, but it is nice to have a project name instead of continuing to refer to it as "that game project I am working on that should probably have a name".
Playing Adventure from the floor of my childhood family room is one my earliest video games memories. For a game experience that is almost four decades old, it has held up incredibly well. This Youtube player sums it up well:
... One of the beautiful things about this game is just the crazy situations it throws at you sometimes. And it's a great example of how simple rule sets in video games can often lead to very unpredictable and very fun results and you don't need to make an incredibly complicated and fun game from scratch. Sometimes just putting simple rules in place and letting them do their thing is all that you need to do. And that's kind of how Adventure works.
Warren Robinett's Adventure only has a handful of colors. The characters are blocky and simple. And yet it was among the very first video games to ever merge action and adventure. It emerged from the soil of legendary text-based game Colossal Cave Adventure which is the very same game that also gave rise to the "roguelike" game experiences named after the titular Rogue). And like Adventure, Rogue is a game of systems over graphics.
During a talk at GDC, there is this beautiful moment where Warren Robinett answers a question about the clearly aging artwork of Adventure. As a bit of a joke, the questioner asks, "... which end of the sword is the hilt and which one is the tip?". Warren's reply:
I don't know. That was not a question I ever worried about or even thought about and - you know what? I'll tell you something. I did not agonize over things in this game. I had certain problems that were clearly problems to me that I worked hard to solve.
Warren Robinett's Adventure is a great reminder that good systems can produce good results alongside graphical simplicity. And this is especially encouraging when you are just getting started.
All I have are systems
Last week, I mostly overhauled several subsystems that really deserved attention such as this unintentional rave:
But the best news of the week was in the way that the very small tweaks to simple systems began to produce challenging and unexpected results:
What seems at first to be a straight-forward set of gameplay options - kill slow moving red things, navigate the environment to the exit - quickly becomes a strategy - quickly look ahead, backtrack, dodge down different hallways, watch your back. The thing to keep in mind here is that I am forming a strategy while I am playing even though I am the game designer. I should already know what to do, but I don't. The game is making me question my own decisions as I try to make progress through the corridors. The fact that my character reaches the exit marker at the end of the video is a result of my own understanding of my options after repeated failures.
Sometimes just putting simple rules in place and letting them do their thing is all that you need to do.
Likewise, these same systems rapidly swing my game experience from "I got this" to "I am completely trapped" situations. But instead of it being unfair, getting trapped is mostly a result of moving too quickly and not calculating the available options:
As a game designer, being caught off guard by my simple systems feels like a great start.
Collision is that bit of code where one thing runs into another thing and both things have to decide what to do (or not do) about it. My collision code I cobbled together last week clearly has bugs. But this week, I did something very foreign to my previous experience as a programmer: I did not work on these problems and I moved on.
... for a project to progress as a whole, the individual parts have to progress at relatively equal speeds. You have to know when what you're working on is good enough to put on hold and it's time to move on to something else.
He goes on to explain that being a problem solver makes it "hard to leave a problem not fully solved." Similarly - while brushing up on procedural generation last week, I read something from Tom Francis that slowly took root:
I don't polish or improve things until all the other systems are in.
It turns out that this is terrific advice to a fledgling game designer. As a person who wants good systems, I often overcompensate by trying to create "perfect" systems. In programming, perfect systems are rarely perfect and trying to create one is generally a black hole for progress: time and energy go in, but success rarely comes out.
Adding arrows and death
Instead of focusing on my terrible collision code for what was quickly becoming some kind of twisted crate simulator, I decided to give my world some actual gameplay in the form of monsters, workable AI, some arrows, and death. As week two of development came to a close, I was finally able to enjoy several minutes of a thrilling, brutal world. With monsters swarming me from obscure angles, I could not make it to the castle's exit - not even once...
... and trying to protect the Monarch (currently represented by a gold circle) was almost impossible:
Stopping my work on collision and moving on has paid off. I now have a game (even if it has miles to go). Again from Tom:
It is easy to stop polishing the silverware when you realize how much of the house is on fire.
Tom Francis, one of my favorite game designers, started somewhere:
I'm making a game! I will probably never finish it! But I thought I'd start talking about it anyway, to keep my goals straight and get feedback on my ideas as I go.
I'm doing it because Spelunky, one of my favourite games ever, was made by one guy in a program called Game Maker. Obviously it doesn't follow that "If design/coding/art genius Derek Yu can do it, I can too!" But it does make you realise that game-making programs aren't just for shitty test games. Since that was pretty much my last remaining excuse for not doing this thing I've had a constant urge to do most of my adult life, I started doing it.
Spelunky and Derek Yu started somewhere too. And Derek's advice is to start actually making the game:
It's easy to confuse "preparing to start the damn game" with "starting the damn game".
And so, in the shadow of giants, I am happy to announce I am making a game! After finishing a series of brilliant tutorials from Tom Francis, working on my first game for the past month, and owning up to both of those facts by posting to Twitter and this site, I am ready to officially consider my first milestone complete.
What am I making?
Great question. There are about six, potentially good game ideas in my head right now. The one I have landed on as my first outing is not necessarily my best idea. I chose it because it is straight-forward and should be something I can efficiently create. It is about a procedurally generated castle that has fallen under a curse from an offended wizard. Your role? To undo the curse and save the monarch (of course). Alongside not having a title (because my clever title "Cursed Castles" was already taken), I really do not have much to show for it yet. But, like Derek Yu said, I have started "the damn game".
In the interest of avoiding self-aggrandizement, I have decided to post my progress alongside my failures as a good first step. This means that moments like this, where my collision code is working successfully...
... are best accompanied by moments like this, where my collision code breaks completely:
Well, there you have it. I have managed to make a character push some objects around. Obviously it doesn't follow that "If Tom Francis / Derek Yu can do it, I can too!". I really have no delusions of grandeur about my current skill as a game designer. But I have decided writing about it here is a part of the process - even if I fail to produce a good game. Again, from Tom:
Writing about it here is one way I'm trying to improve its chances of reaching a playable stage. Explaining it to someone else forces me to keep my thinking clear, explaining it to you guys might be a good way to get feedback, and explaining it publicly makes giving up all the more embarrassing.
I'll have more to share once I get some more progress.