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.