Hello again, and a chilly November's greetings from all of our well-bundled team in 'now-Maryland-based-still-has-that-new-car-smell' Conifer HQ!
As many of you know I've been promising the past several months that we'd talk some schedule and release date soon (sometimes referred to as simply, "that thing roughly 95% of AtG followers are actually most interested in"). Well now's might be a good time to buckle up because, at long last, this is the update in which we'll finally be announcing a release date and along the way also dives head-first into a few big 'lightning rod' topics.
As you should probably expect by now, this article is fairly long and will involve going on a bit of a ride to the philosophical side of game development. However, I also know a large number of folks have better things to do than spend an hour hearing me ramble on inside their head, so if all you're looking for are the facts just skip down to the "Roadmap Breakdown" section a dozen or so paragraphs down from here.
In the next section though we'll kick things off by first looking back at the original release date "estimate" of June 2014 (!) we decided to target just prior to the Kickstarter campaign, along with *how* it's not just possible but fairly easy to come up with a date that's so absurdly off that two-and-a-half years later appears almost farcical. After that we'll skip ahead to the present and the meat of the update in which I lay out our new and basically-finalized roadmap, the process that went into creating it, and why it's actually worth putting some faith in despite its creator also being the same guy that whiffed badly at basically the same pitch only a few years earlier.
From there we'll look at a few specific elements like AI, iteration, and bugfixing that for different reasons each deserve a closer look, followed by a look at some more high-level "business-y" considerations that should always be taken into account when deciding on a release date. We'll wrap things up by providing a more granular breakdown of AtG's budget and how the hell we can actually afford to spend almost five years on this thing, and why even if impossible-to-predict bumps in the road do appear out of the blue you can have confidence in the fact that I'll always be driving this thing and doing everything in my power to make AtG the best game I can - right to the very end.
Pitfalls of Prognostication
In looking back I'll start by saying that I didn't really want to give out any dates at all, as I tend to be naturally pretty conservative on the production side of things. But given that the chance a crowdfunded project fails to deliver is always quite high the folks at Kickstarter understandably frown on taking a "hey, it'll be done when it's done" approach. And so we all dance for the overlords of that most-important month and do our best to come up with a release date we legitimately think is reasonable. Of course we already know how that turned out with AtG specifically, but the same is true of virtually every game project that's had a Kickstarter page to their name. But why is this the case?
Uncertainty is one of game development's most recognizable characteristics, and especially so the earlier in a project you are. Games are basically an interactive form of art, and this results in a development process which actually differs pretty significantly from that of most business and productivity software. Schedule be damned, if your game just ain't fun your only two options are either (A) spending whatever still-unknowable amount of extra time and money it takes to make it fun, or (B) you simply bite the bullet and release a bad game. Don't get me wrong, scheduling definitely has an important role to play in this business. But the unsolvable paradox is that until all of your game's "big questions" are answered 99% of numbers and dates you try to give meaning will end up being wrong - and as we've seen often laughably so.
Back when AtG was announced in February 2013 the game was little more than a basic playable prototype and had enormous holes that became obvious right from the moment you started a game. Although the prototype already contained a respectable amount of meat on its bones compared to others on Kickstarter because we were making a massively-complex strategy game this "head start" vanished very quickly.
The limitations having a team comprised of just a single full-time developer was something else I failed to fully appreciate at the time. That's probably something that would have been more obvious to other developers and even industry outsiders given that the vast majority of my career has been spent as one of or the only designer and gameplay programmer on massive, complex games. And it's not really the process of *building* the game that I underestimated so much as everything else. I spend a huge percent of every week answering emails, writing documents, filling out and following up on paperwork, reading feedback, and so on. It's definitely my intention to bring in some help on that front for the next game, but given AtG's budget it's simply something I have to deal with as best I can.
And to be fair, by far the biggest contributor to AtG so greatly overshooting that original date was performing what can basically be thought of as brain surgery on the absolute most fundamental aspect of the game design - and not only that, but doing so almost two years into development, which is the point when many other small strategy games are *released*. It's impossible to say for sure but I would estimate that the Clans feature will end up adding at least a year and a half to the project, and while that is a pretty huge number given how intertwined Clans are into every single nook and cranny of the game design coupled with how much it improved the game I honestly don't regret that decision at all. Making such a fundamental change to the design was obviously my decision and in spite of the cost I have no doubt it was the right move. As I've said in the past, AtG is a game like any other and that means it's inevitable you're going to run into some core issues that simply take time to fix.
The development side has been a truly enormous amount of work as well, with nearly all of it being self-imposed (which is technically true of *everything* when you're an indie, but whatever). AtG is innovating on numerous fronts and not just strictly in terms of gameplay. I'm obviously especially proud of AtG's tooltip system but there are many less obvious examples as well, like a realistic map generation system, a fairly complex graphics pipeline to produce the game's unique watercolor look - each of which having cost a big chunk of time, and our plans for diplomacy, the tutorial system, and modding all being similarly ambitious. Aside from the lack of multiplayer and the obvious difference on the graphical front AtG actually has a scope roughly the same as Civ 5 if you count up the wide variety of systems each contains. I don't remember exactly how many programmers we had on Civ but it was somewhere in the neighborhood of 20, which is obviously a little different from what Conifer can muster!
No doubt some folks would just say it's obvious that taking on a project of such an enormous scope with the equivalent of a single full-time programmer (after adding in part-timers and deducting the time I spend on non-development tasks) is just simply foolish, end of story. And if for some reason the game never ships or turns out to be crappy I'd have a hard time arguing it. But achieving that is not only something I want to do but strongly believe we *can* do - with enough time, of course. That has certainly been part of the core for one of the most important lessons I've learned on this project, one which I'll go into more detail on the next section: don't even bother with milestone dates until you have a complete understanding of how much work you're talking about. That's obviously more than a little tricky if you're working with a publisher or your game is crowdfunded, but it's something I'm at least hoping to try and apply next time around.
But that's probably enough lessons from the past - we started there to help give you an idea of some of the factors I'm thinking about once we start discussing slightly more important stuff like, well, the roadmap and a release date!
Line in the Sand
With the Kickstarter campaign now barely even visible under almost three years of Internet dust I know with each passing month it's become increasingly difficult to ignore that big pink elephant in the room yelling "So when the hell is this stupid game actually going to be done anyways?"
And given that the only word for well over a year now has been the same official line of "it'll be done when it's done" there's good reason to wonder about such things. As I noted above there's just so much uncertainty early in development that there's almost no chance any dates you come up with will end up matching reality, and while a long development cycle that feels like it's never going to end ain't exactly great it's much better than announcing a date and getting everyone's hopes up only to come back later and say "just kidding" (we obviously did so back when it was clear we weren't going to hit that June 2014 date, but I definitely learned my lesson after that!). Not only are delays unprofessional and therefore not the kind of thing I ever like to do, but doing so also burns bridges - most of the time ones you'll never find out about. Sometimes you just gotta do what you gotta do, but fortunately that's a trade-off I'll never have to make as a self-funded indie.
Eventually though the time does comes when you need to start locking things down and figuring out how to best get your baby out the door with as soft a landing as possible. AtG no doubt looked like it was in development purgatory for quite a while as we spent time iterating on major systems, but we've now reached the point where we need to shift from creating to polishing. Deciding when to make that cut off date is based on a number of factors that include rough schedule projections and how much money you have left, but at the end of the day it has to be a gut call. I'm happy with where AtG is overall, and so I decided now was the time to pull that lever. And it's a meaningful one too, because in announcing a date I'm putting everything on that, and with a fixed amount of time remaining you really have to prioritize how much time you spend on what.
Without further ado, let's move on to the next section and the star of today's show: the schedule!
After building a comprehensive list of remaining tasks then organized into milestones roughly a month part we can now announce that At The Gates will be released in Q1 2017. Yes, we still have a long wait ahead of us, but it was not picked arbitrarily and we explain below all of the factors that led to it being clearly the best option, and we'll start by looking at the official milestone schedule:
The basic philosophy is to frontload more difficult and iteration-time-intensive tasks to earlier milestones, and adding those we either know for certain won't take long or are lower priority to milestones at the end, just in case something does come up and we need to put a feature or two on the chopping block. There are a few other things worth talking about, but those will be covered in sections of their own below.
Release Date Strategy
You might be wondering why the official release date is merely "Q1" rather than a more exact date given that we've actually planned exact dates all the way out to "Gold" on January 30th of 2017 is because of something we've already talked about: uncertainty. But in this case it's not something related to game design or bugs, but the nature of the business. Let's say we picked something like February 28th far in advance and commit to not changing it. It's very common for Valve to give someone a call a couple months in advance and say something like, "hey, we have a big sales window open during the week of February 8th, so if you release your game then we'll put you on the front page of Steam for the week". Since Steam opened the floodgates the value of simply being on Steam has greatly diminished, while that of being on the front page has skyrocketed, so whether or not you're able to secure that sort of promotion can result in a difference of tens of thousands of sales and hundreds of thousands of dollars.
(I'm going to be taking a lot about sales numbers in this section, and although I know a lot of players couldn't care less about that sort of thing, keep in mind when a company makes more money the fans of that company also benefit because ultimately the healthier the company the more likely they are to continue making new games for you to enjoy.)
So how did we even come up with Q1 in the first place? The quantity and amount of time needed to complete all of the tasks on our list gave us a pretty good ballpark number, but several other factors that really helped us narrow it down even further.
For one, you never want to release a game in December. That might sound like an odd rule, but it's a pretty universal rule within the industry. By December a lot of people have used up their discretionary budget on gifts and are now looking to be more frugal. We're obviously not talking everyone here, but even losing a small percentage of sales that might not seem like a big deal can add up to a huge amount of revenue, and especially for an indie developer every little bit counts. If all you need to do to avoid losing that percent is shift your release date a few weeks it's basically always a good idea.
Another strike against December and also November comes on the PR side of things. A large percentage of the biggest games released each year land in October and November ahead of the Christmas shopping season. While someone's initial comment might be so what, as it's not like there's a whole lot of competition between the latest Call of Duty game and AtG, but in a way there actually is. Magazines and websites which review and talk about games are another important part of maximizing a game's sales. While it's easy to just think of companies as faceless, impersonal entities they all have employees, and there are only so many individuals available to create previews and reviews at a time. Were a small indie strategy game like AtG to land in the middle of the rush it would likely end up on everyone's back burner and eventually just forgotten.
And even the largest publications that are more likely to have bandwidth and those specifically dedicated to hardcore strategy games can't be relied on, because December is when a lot of folks in that line of work take a bunch of vacation time in order to unwind after working nights and weekends for the past month in order to hit their deadlines. Of course even if you do get lucky and someone is willing to review your game it's very possible the individual chosen to do so has already been completely burned out and may not be particularly excited to play your game.
Competition on the sales side is also an important factor to consider. This usually brings to mind specific titles similar to your own produced by rival companies, but you can also look at trends and use them to make educated guesses. Autumn is always a busy time for game releases even in the strategy genre, and the last thing you want to do as a small fish is launch your game around the same time as a similar game you can be sure a ton of people will be playing, such as Civ. Fortunately though, the powerhouse franchises like Civ and Total War tend to follow fairly-reliable release schedules, and you can be pretty sure September and October will be landmines most years.
So to bring things back to AtG we can take December off the board entirely, November isn't a whole lot better, and even the two months before it are risky. So just based on these strategic factors the two release windows that would make the most sense would be Summer 2016 and Q1 2017. Given that the former would have cost us a whopping six months of dev time you can see why I came to the conclusion of Q1 2017 being the clear winner.
At this point you might be rolling your eyes at the fact that deep down I'm basically just than a dirty publisher in disguise. And to a certain extent I am, I suppose, but the same is true of every game developer - it's simply a question of how much or little each one actually talks about the money side of the business. Being an indie affords me a lot of perks like, well, talking freely about these sorts of topics as well as being able to prioritize quality over profitability, but even the smallest studios need to be making money in order to survive, and those who ignore that are unlikely to stay in business long. Trust me, I'm no bean counter and as I said above I'd much rather be programming or I play testing some new balance tweak than min-maxing profitability spreadsheets, but as is true of most things in life balance is the key.
The Price of a Good AI
Having covered the release date itself pretty thoroughly now I'd like to shift gears and dig into some specifics within the schedule, the first of which being the AI.
One of the first thing you might have noticed is that a good chunk of the total time is taken up by AI tasks, and there's a reason for that. I talked about the basic blueprint for AtG's artificial intelligence in an update from a couple years ago, and while much of it is still relevant since then my AI development philosophy has undergone yet another "evolutionary leap", and one that might be different from all others over the past decade in that being the simplest, most far-reaching, and has the potential to define all of my AI work from here on out.
As with scheduling, planning can still be quite helpful when, say, designing the architecture of an AI system so you end up with a flexible framework to build off of, but the realization I had is that the real difference-maker is what I call "bottom-up iteration", or in other words, "What is the AI's biggest weakness right now? Okay, let's fix that. Rinse. Repeat."
I'll go into a lot more detail in the next update that will be about AI, but the take-away for right now is that the only way to end up with a good AI is via brute force, which in programming terms means *lots* of time.
The Subtle Significance of Iteration
Our next element is actually the opposite of our previous one, at least in that it's completely absent: iteration.
When making or evaluating a schedule it's easy to fixate on tasks that can be easily quantified in a list, have a checkbox checked off for, or immediately stand out as problems, but the real time sink in game development doesn't actually involve making pieces but about figuring out how they actually *fit* together - and especially so when working in the strategy genre. Because iterative improvements like pacing and balance are so hard to quantify all you can really do is be diligent about setting aside time for it, and this is why you'll see "Polish" listed again and again for gameplay the last few milestones.
While I don't mention anything specific in the schedule doc, I do have another list where I keep track of things I know I need to take a look at. Here are a few examples:
- Food Pacing + Economic Pressure
- Deposit Distribution + Migration Pacing
- Profession Balance
- Tech Tree Pacing
- Military Unit Balance
- Combat Pacing & Feel
- Strategic Variety
- Ensuring Clan Traits Feel Positive
- Roman Event Pacing and Feel
- Map-Wide Weather Pacing
- Difficulty Tuning
- Managing Economic Complexity
- Deposit Spawning in the Late-Game
- Incentives to Pursue Naval Strategies (e.g. Islands Filled with Goodies)
- Non-Violent Interactions with Neutral Structures
- Incentives to Cooperate With Rome
- Incentive to Fight Rome Early
- Pacing of Rome's Decline
- Instilling Rome with a Sense of Majesty
Just to help illustrate the kind of rabbit hole a designer can end up in let's dissect a slice of AtG's game design that might at first appear relatively simple and straightforward, but has already consumed several weeks of brainstorming and iteration and will probably require several more tweaks before all is said and done: distribution of resource deposits.
The simplest possible implementation would be to simply do some rand rolls and grab tiles and deposits out of a hat and pair them up in whatever manner amuses the fates. But what if someone starts without a single source of food nearby, and starves before seeing their second winter? Well, that's bad, so okay, let's put in some logic to make sure there's always food nearby. But how should THAT work? Do we simply plop a single source of food nearby and leave everything else untouched? Now it's more likely we run into the opposite problem, where a player has so MUCH food that the game becomes so easy you'll succeed and win no matter what you do - which for most people kind of defeats the purpose of playing a strategy game at all.
Okay, after chewing on this dilemma for a bit and iterating on our logic several times we now have something that allows for unpredictable variety, but not so much so in either direction as to make the game unfun. Great! But what happens after a player uses up the resources near their starting location and starts branching out? Now we find the randomness that had been working against us earlier is back with a vengeance. A player who tries to migrate away from their homeland might find a vast wasteland in every direction and eventually starve to death just as before.
Alright, a few more iterations later and we're now applying the same 'rubber-banding' logic to deposits across the entire map. But now that players can migrate safely around the map is doing so actually even, you know, FUN? Sometimes as a game designer you throw a dart and hit a bullseye in your first try - but such exceptions are few and far between. And in early builds I can promise you migration was indeed NOT particularly fun. The best approach was simply crawling a couple tiles at a time from one source of food to the next. Noticeably absent were cross-continent treks, daring stops in an enemy's backyard, or any kind of incentive to establish and pursue a long-term strategy.
The idea I came up with to address this was to have most deposits invisible at the start of the game, and then appear in subtle paths that wouldn't be noticed in-game but were very explicitly driving the action under the hood. I tinkered with this concept off and on for what must have been at least a year before I ended up cutting it entirely. It did in fact encourage (AKA "force") longer journeys as hoped, but in the end I discovered there was no more strategy or interesting decisions than before. In fact, in some ways there were even fewer, as with there were now only one or two places that even made sense to move into.
The approach I've settled on in the present day can best be described as "the kitchen sink approach". I roughly tripled the number of deposits on the map and made them all visible (but mostly unidentified) right from the start. Players now have more opportunities than they actually have the bandwidth to pursue, and must choose between a balanced or specialized approach, and if the latter what specific economic endeavor to focus on.
I can confidently say that the distribution of deposits objectively results in a more fun game now than it has been at any point in the past. But it took a long time to reach that point, and by extension all of the mistakes I made along the way in getting there. As a game designer the challenge is differentiating between "progressive iteration" that actually makes a game better, and "churn", which is simply change for the sake of change. With deposit distribution we've definitely reached the peak of the mountain, and while other nearby mountains might look like they'd be fun to climb future adventures are best attempted in another game.
That's not to say the system won't change at all between now and the game's release though. There's a very high chance that I implement some form of late-game deposit spawning or replenishment to prevent a "no man's land" from forming out of the swathes of desolation carved out by previous generations of migrants.
And similar challenges await in every corner of the game's design. Many other developers working under a fixed schedule and budget either choose or are simply forced to put such projects on the back burner until a patch or expansion pack. With AtG we have the opportunity to sidestep this philosophy and have chosen to take advantage of that. AtG will be long in the oven by the time it's released, but it will not be undercooked.
Setting Time Aside For Bugfixing
This last scheduling element I'll be covering is very similar to the previous one in that it's usually overlooked.
Every complex game title really should have at least a month set aside as exclusive playtesting and bugfixing time. We're talking full lockdown here - no changes, period. Not even that extra bit of polish to the Archer's attack animation we've been wanting to sneak in. Even the smallest change means pulling out the game development scalpel and making an incision in your game, and just as with living organisms there's really no such thing as a "minor" surgery. Break open the seal for any reason and there's a chance something really nasty will sneak inside.
While no substitute for full lockdown I've also tried to assign tasks to milestones such that the amount of risk diminishes with each until eventually reaching BETA when the only significant code changes on the docket involve the creation of a couple fairly simple screens.
While it's certainly better to be "careful" than not (which pretty much just means testing every change thoroughly before checking it in, and even then making sure you never give into the temptation to submit ANYTHING at 2 in the morning!) it's simply impossible to reduce the chance of "infection" all the way to 0. And thanks to the whole statistical probability thing that means if we throw the dice enough we WILL end up rolling snake eyes. There have already been over 5,000 check-ins to the AtG source control repository and I'd be shocked if fewer than a thousand more were made from this point on. So, yeah, I expect to see a whole lot of snake eyes in the coming year+ and tried to act like the responsible (enlightened) despot I think myself and incorporate that reality into our finalized schedule.
Having now dissected the schedule inside-out, upside-down, and sideways leaves one new question: "The Kickstarter funds must have been used up by now, so how the hell can we afford to continue developing the game for so long?"
As noted in a previous section, I'm actually the only full-time developer on AtG, which certainly makes things a whole lot easier that it could be. Everyone else is either a part-timer with some other full-time source of income or a contractor paid for specific work we've known about in advance since the Kickstarter campaign and comes in at a total of $25k, 99% which has already been paid for. Even so, our once-fat sack o' Kickstarter loot has indeed been exhausted, resulting in a initial budget shortfall of around $150k. We've done better with direct pre-orders than I'd actually expected and cut the deficit by $23k. The remaining gap has been filled by proceeds from selling my house, car, and retirement account.
This was not a final act of desperation though, and external funding has always been an option. So why take that route instead of selling off everything I own? Several reasons, actually.
Most importantly, I think it's the approach most likely to result in AtG being a better game. Working with a third party obviously isn't a death sentence in game development, but it does introduce unnecessary risk to the project. Plus, having complete control over the design is why I went indie in the first place, and I'm willing to sacrifice a lot to keep that.
There's also an element of personal responsibility involved. I brought this project into the world after all, and I'm going to make sure it survives to fly on its own one day. It also shows everyone that I'm willing to put my money where my mouth is and see this thing through. Several thousand of you have put money into this game, and it's only fair that I do so as well instead of running to someone with a stack of cash that may not actually care that much about AtG. Plus if it turns out as good as I keep promising it's going to be I'll make all that money back and then some anyways.
The most important factor of all though is probably the fact that selling everything I own honestly just doesn't feel like that big of a deal, which is most likely the result of having a personality disorder that closely aligns with schizoid PD and more or less prevents me from feeling emotions or having hobbies of any kind. It's not all bad though, and one thing I really derive a ton of satisfaction from is working on my games, and it's probably greatly helped me become a better designer and the reason why I can even make a game like AtG to begin with.
Either way, this project is far more than just a job for me, and while it might still be far away it does finally have an end date which everyone can now be looking forward to. 5,000 words from me is probably enough for now though, so that's it for now. Thanks again, and 'til next time!