I'd also like to let you guys know that I'm going to be teaming up with some other folks to start working on some really cool projects. Can't talk about just what that entails yet, but you'll find out very soon, and I'm sure nearly all of you will have heard of them. I'll be splitting time between AtG and this new endeavor, but in the meantime, I'll also be posting an update for AtG every few weeks to keep everyone filled in as to what's new.
Alrighty, that's it for today, I'll be back soon to talk about the game's full roster of factions and leaders, and specifically how they'll be unique from one another.
Hey all, sorry for disappearing for a while there, and thanks to those who have reached out. Everything is fine, just hit a burnout point and needed to step away for a bit. We're taking the scenic route, but still very much intend to finish the game.
We'll be posting updates again fairly regularly, and next week will include a breakdown of all remaining tasks and the rough time each will take in order to give you guys an idea of where we are and what's left to be done. In the meantime, here are a couple things we've been working on recently...
Map Editor & Imported Maps
Jonathan first started on the map editor fairly early on in the project and set it aside to work on more core game tasks, but we've gone back to revisit it and it's now starting to come together. Having spent much of my Civ modding time working on maps, I wanted to make sure this was a robust tool, and that meant adding, above all else, the ability to undo and redo actions. There's nothing more frustrating than needing to go back and reload your last saved map because you screwed something up so badly, so we prioritized this functionality right from the start.
We recently added an extra-special new feature which allows an image file to be imported and converted into an AtG map right from inside the editor. This was actually a project I originally undertook early in my tenure on the Civ 4 team, and I was so happy with the results we decided to bring back the feature in a new-and-improved form.
Here are a few examples of maps that have been created in this manner by pulling source images from Google Earth:
The only real downside to our fancy algorithms is that it has a really tough time picking out rivers, but given the source material I think this is probably about the best we can get. Not too shabby though!
How accurate the map looks compared with the source material will depend on the resolution of the map you produce. The 'standard' map size is around 110 x 80 tiles, which I think is about the right number for an average game, though it will be possible to play on something much smaller or larger (if your computer can handle it!) if you so choose. There will be at least a few maps of Europe in particular that you'll be able to play on, as I know that 'base' experience is part of the allure for a lot of people. It was certainly a large reason why I spent so much of my time making maps back in the day!
The editor also currently lacks the ability to place objects (like cities and clans), and maps loaded into the game can't yet be automatically populated with objects like random maps are, but these two items are next on the list.
The big gameplay advance since the last update is the solidification of the design for the victory conditions. I've decided to make them fairly straightforward, as I think that's better than a less intuitive approach that can be confusing in the early going.
Roman Conquest: your goal is simply to capture Rome (or Constantinople). The Romans then give in and allow you to build a kingdom without their interference.
Tribal Conquest: it's unlikely you'll be able to wipe everyone else out before completing some other condition along the way, but should you do so victory is yours!
Tribal Council: after having met all of the major factions, a tribal meeting will take place a few years later, and you win if you have a certain amount of wealth with which to pay everyone else off. An alternate model would be for players to spend a certain amount of wealth in order to pay off each tribe individually, but the exact details will be worked out during playtesting.
Roman Successor: you win upon completing 10 quests for one of the two Roman factions, the last of which is guaranteed to be quite tough. Each failed quest counts against you though, and you only have one shot at completing the final quest, so make sure you're prepared!
This should provide a good mix of conquest, economic, and diplomatic goals to pursue right from the start of each game. Things are obviously subject to change between now and release, but these are the four victory types I'm happy with.
That's it for this week - I'll be back next to go over the task list.
P.S. Our email server also crashed a few months ago, so if you tried to get in touch with us that way please try resending your message to firstname.lastname@example.org (e.g. if you've requested a refund, or just said hi and haven't heard back yet).
First off, apologies for the lengthy absence - I was dealing with some health problems earlier in the year and just as I was getting back to work I broke my ribs and have been recovering from that over the past several weeks. Needless to say, it's been a tough year! As you might have guessed, this will push back the release of AtG a bit, but development on the game is still very much underway and now returning to full steam. I'm in the middle of updating the schedule and will let you all know what things look like here within the next few weeks.
Speaking of which, to better keep you guys in the loop we'll be hiring someone to handle the communications side of things so that the rest of the team (especially yours truly) can continue to focus on the nitty-gritty details involved with finishing up the game while still ensuring you guys aren't in the dark along the way. So hopefully no more lengthy periods of radio silence from here on out!
As for the game itself we're still knee-deep in AI work but one of the fun things I've started getting back into the swing of things with is unique factions and traits. For those of you in the alpha program I posted a new build last week (v22.1.6) that includes some basic functionality on this front, and a lot more will be coming soon. The goal is for a faction like the Huns to play very differently from a more basic one like the Goths (think completely nomadic, no structures, etc.). To commemorate this feature I'll give you guys a sneak peak at a couple of fun new leaders: Alboin of the Lombards, and Cerdic of the Saxons (both of whom also happen to have names whose modern versions swapped some letters around - hooray for pointless trivia!):
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
Tech Tree Pacing
Military Unit Balance
Combat Pacing & Feel
Ensuring Clan Traits Feel Positive
Roman Event Pacing and Feel
Map-Wide Weather Pacing
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!
At long last, we're finally back with a new edition of 'Jon rambles for too long about some esoteric game design topic (and along the way mentions AtG once or twice)'. Today's lucky recipient of this most distinguished spotlight is the game's user interface, or "UI". I know this topic might sound roughly as exciting as watching paint dry, but I really do encourage you to stick around because once you've seen things with your own eyes I think you'll understand why our bold claim of AtG's UI being "revolutionary" isn't just pre-release marketing hype.
It may also come as a relief that this update is actually a 3-for-1 deal where 'Jon waxing poetically about his eternal love for UI and the beautiful soul it hides from the big, bad world' is reinforced by two additional features.
The second member of our update trifecta is a fairly detailed bullet point outline of what's new and cool with AtG's UI, and provides the most bang for your buck if you only have a couple minutes to spare. I've attached it to the end of this article, so to check it out just scroll to the very bottom of this article and then back up until you see "UI Feature Outline" in big, bold text.
The real the star of our show though is this hands-on video preview of the UI (total of 66 minutes, split into 2 parts roughly a half hour long):
The old "seeing is believing" mantra sums up UI perfectly, and so much so that even a designer and UI fanboy like me can't do it justice simply by describing it. So even if you don't normally watch game videos I strongly encourage checking this one out. If you're in a hurry skip ahead to the 11-minute mark, as that's when we introduce AtG's secret weapon.
The rest of this article makes up the final member of our trifecta, and is a dive deep into a number of UI-related topics that include: why good UI has never been (and never will be) the kind of 'sexy' bullet point that helps sell magazines, why in spite of that developers should still care, what makes UI design so difficult, where the idea for AtG's Adaptive Tooltips came from, some of our UI design 'rules', and a look at the design process behind a few UI features we've put a lot of thought into so that players won't have to.
Discipline of Shadows
The first thing that came to mind when I started writing an update about UI was "Won't this sound boring to most people?" An encouraging start, I know! But given what we had to show off I remained confident in the idea, and the second thought I had was "Why?" It's a complicated question to be sure, but the simplest way to approach it is to put ourselves in the shoes of each of the two stakeholders: players/press, and developers/ownership.
From the player's perspective UI is something that might as well live in the ether, as it's forever out of sight and out of mind. Even truly terrible game UI is rarely identified and lambasted as such. Players who bear the brunt of it rarely play for more than a couple hours, whereas everyone who sticks around eventually grows accustomed to it, eventually reaching the point where they genuinely don't even see the flaws any more.
Ultimately, the mythical "perfect" UI from any player's perspective would be labeled such precisely because it's so intuitive that it becomes completely invisible. Our ability to learn, adapt, and tune things out is part of why we enjoy games at all and helps us in many other ways, but motivating us to pressure profit-driven companies into fixing endemic flaws in their consumer products certainly isn't one of them!
But what about the developers? Unfortunately, a large number simply don't find UI very much fun to work on. Most programmers want to spend their time building systems and solving interesting problems and not on tedious, never-ending polish and bugfixing (there's no better example of the ninety-ninety rule in game development). Most artists want to express themselves by creating something beautiful and admired, not something where recognition is inversely correlated with quality, and many of those who do actually enjoy working on UI still approach it like any other art task, striving for beauty and admiration.
But someone ends up stuck making the UI for every game, whether they like it or not, and as you'd expect the end result is usually something well-architected and beautiful, but not necessarily intuitive or feature-rich from the perspective of those actually playing the game.
Crafting a good UI requires putting yourself in the shoes of your players and actually experiencing your creation as they would. This requires a certain degree of skill and know-how, but far more important is simply the dedication it takes to spend months or even years playing your own game over and over again, then come back the next day and tackle whatever new tedious bit of polish you think might make the game 0.0001% better. With a smile, preferably.
To be sure, there are amazing graphic designers and user experience (UX) specialists out there… but the problem is these talented individuals already command far higher salaries outside of game development. And because the value provided by UI is intangible the same is true of its impact on sales, and without that data even supportive members of management will be fighting an uphill battle making the case for adding those big salaries to the books.
So in the end there's rarely pressure from below or above to make UI a priority, and so it remains trapped in stagnant purgatory.
What UI Don't Know Can Still Hurt You
Okay, so only a few people actually care about UI. What's the big deal?
As I hinted at above, UI is really just a subset of "User Experience", a field which encompassing not just games or even software but every single man-made object we interact with throughout our lives.
Installing new carpet that feels like walking on a cloud (and happens to be in your favorite color) has a very real effect on your quality of life, even if the bristly mustard-colored stuff you replaced it with never seemed so bad. A pair of headphones that fits so well you can't even tell they're on is a similarly huge upgrade over a pair that was always a bit too tight and got uncomfortable after a while, even though you might have owned the latter pair for years and never really gave it much thought. Hell, even replacing a noisy fan with a quieter one can improve one's environment and therefore mood.
Just because we don't think about something affecting us that doesn't mean it doesn't affect us. Games take this a step further because learning and acquiring information the road to mastery is, in many ways, the whole point. This is especially true of strategy games, where both the challenges and the satisfaction of overcoming them is often elevated.
But that road to mastery quickly stops being fun if you start getting the feeling you're lost without a map or anyone around who might be able to give you directions. Strategy games are fundamentally about making tough, meaningful decisions, and to feel confident in and responsible for them you need information. Without it you're just stabbing in the dark, and it becomes easy to blame the game for any misfortune which befalls you, and from there it doesn't take much to just give up and never play again.
And that outcome is bad for everyone whether you're the player himself, the dev who likely loses sales, a fan of the game who wants it to succeed, or even someone who's not but might have become one had more people been talking about it.
On the flip side, there are several very real, if subtle advantages to investing seriously in UI. Gamers who've had an interest in the genre but bounced off of other titles within it might give yours a shot if they hear it's easier to get into. UI is a lot like a AI: neither has an impact you can easily measure, but go the extra mile and people will notice. Many will become your biggest supporters and lifelong customers, but even those who don't are likely to speak fondly of your game any time it, a similar game, or even the genre as a whole comes up in conversation - and for not just a couple weeks or months but years to come.
"Making a better UI" also shouldn't be misinterpreted as "simplifying your game to make it easier", and in fact the opposite is true. Information is just information and there are no rules or limits on how it can be presented. Packaging it in the right - or simply, a better - way actually creates room for more depth and complexity. This can result in an amusing bit of irony where the biggest beneficiary of a more intuitive UI isn't the casual player who's still probably won't play for more than a few hours, but instead the hardest of the hardcore, and the one most likely to scoff at the idea of spending precious development resources on UI!
A Problem of Perspective
Remember that mythical "perfect UI" we talked about above that's invisible to the player? Well, when we say "the player" what we really mean is every player. And that's not only total newbies to the genre and top-10 ladder players, but people who simply will not read a block of text more than two sentences long, people who are colorblind, people who have screens so enormous the corners (AKA the best place to put UI) falls outside their field of vision... okay, I think you get the picture.
The biggest challenge by far though is balancing the interests of new players against those of experienced ones, especially when designing a strategy game. You can try to imagine yourself in the shoes of either group you'll never actually be able to see things as either one does. You're too close to the game to have a chance at noticing most of the issues that will trip up newbies, and although your perspective is much closer to that of the veterans the depressing truth is that the best players will only only be far better than you, but you're also too close to the game to see things from their perspective.
Experts don't have any preconceived notions about how things should work. If it's possible to open up the diplomacy screen and check in with every leader every turn and use a loophole in the trade AI to exploit them for a bit of cash, then, well, that's how your game plays! At that point it doesn't matter what your intention was. This example obviously a problem that extends beyond just UI design, but it still highlights the disadvantage you as the UI designer are at.
To be honest, this is one part of UI design where there really is no substitute for experience, skill, and intuition. But even that only makes it possible to create a good UI, not guaranteed. The most important ingredient is dedicated playtesting and iteration and the massive time investment that entails, and even then there will still always be one more thing you could add or tweak. You just eventually reach a point where it's time to put a bow on things and actually ship something people can play.
Alright, that's enough metaphysical navel-gazing, let's bring things back to the game this article is purportedly related to!
Meanwhile, Back at Conifer HQ
There's a lot of potential to do more than what's been done already - it's just a matter of actually doing it. Fortunately, I'm one of those people lucky enough to have been born with both a passion and at least some aptitude for UI design. I think we really raised the bar for strategy game UI with Civ 5, but not being some sort of all-powerful Game Development God working all by my lonesome on Mount Olympus there was never an opportunity to lock myself in a room for two months and focus exclusively on UI.
Well, fast forward a few years to when AtG is first starting up and things have changed a bit. While I'm still no deity of any mythical mountain, I'm now at least a minor spirit in charge of that one hill people sometimes use for sledding. But hey, at least it's my hill! Anyways, as supreme overlord of my little mound of dirt I decided this would be the game where I'd hunker down and see how far we could push the envelope.
Naturally, I dove into the deep end of this concrete pool head-first by tackling the most difficult - but also most impactful - challenge of all: making it so that learning the game was, you know, not nigh-impossible for a human adult of above-average intelligence.
At the same time though, I absolutely didn't want to achieve this by simply "dumbing things down" and making the game mechanics themselves simpler. You see, that's cheating. And I'm no cheater. So where do we go from here then? My starting point was the UI design tenet which shapes pretty much everything I've ever made: don't put more on the screen than you absolutely have to.
The problem is that every player has their own opinion as to what 'has' to be visible. And to complicate things further, that opinion will inevitably change as they become more experienced. What we needed was a UI that not only adapted to different types of players, but could also 'evolve' with them.
Laying the Groundwork
In some games not only can you mouse over UI elements to get a basic tooltip, but if you keep the cursor there a little bit longer the tooltip will 'transform' into a far more detailed one. I'd considered this approach for AtG, but I didn't like that there were some pretty big holes in it: not only does it force experienced players to endure that delay hundreds or even thousands of times, but neither is it really ideal for the new players who are apparently expected to get everything they need within that 3-second window.
But I could tell there was still some untapped potential in the concept, it was just a matter of rearranging the pieces in just the right way. And then it hit me: why not make the trigger condition position-based instead of time-based?
Virtually all computer programs use what I like to call "ghost" tooltips that can be seen but not interacted with, but there's no reason why that has to be the case. Let's say a tooltip remains fixed in place after appearing and then remains so as long as the cursor is over either it or its 'parent' control... suddenly each tooltip is just another UI control like any other. I knew this could be something big, something that could transform the ethereal into the corporeal. Over several months that tiny spark would not only catch fire but eventually mature into an unstoppable inferno: AtG's Adaptive Tooltips system.
From there it was just a matter of how we could best take advantage of the system. While cramming tooltip-laden panels and buttons into the tooltips of existing panels and buttons would come in handy, I felt that there was the potential for something truly revolutionary if we took things a step further and made it possible for individual words to have their own tooltips. Have no idea what "Apprentices" are, how they work, or if they're even worth worrying about? If words can have tooltips then it becomes trivially easy to find answers for not only those questions, but virtually any question.
Of course, that was easier said than done. Getting this feature online and fully functional took several weeks, mainly because much of the UI system had to be rewritten to not only allow for individual blocks of text to masquerade as UI controls, but to do so while still contained within other UI controls. If one of those parent UI controls is hidden, or moved, or told to allow clicks to pass 'through' to controls behind them, then so too must the text be.
We ran into several other technical hurdles along the way, none more aggravating than ironing out the endless parade of issues related to overlapping tooltip stacks. Sometimes a tooltip halfway down would think it was the one on top and everyone else above him would just vanish. Or you'd click on a button deep within a stack of tooltips, but some other part of the UI would think it was being clicked on. I probably spent the equivalent of two full weeks tracking everything down, and let me tell you, I was pretty sour by that point.
A couple weeks is just a drop in the bucket compared with the amount of time it takes to flesh out a truly polished UI. With the foundation for the Adaptive Tooltips system now in place it was time to zoom back out and focus on the design.
Inside Santa's Workshop
At this point it's probably best to switch gears and focus more on the sorts of high-level design principles that helped shape AtG's UI, rather than a blow-by-blow account of every decision we made. After all, life is too short, this article already too long, and we've only scratched the surface with the tooltip system, let alone the rest of the UI.
One of the most important traits for a UI designer to have is contextual awareness. How should everything fit together? How does it right now? What do players actually care about? What do they not care about? If I move this piece to there does it make the tower stronger or weaker?
No decision is made in vacuum, and losing the forest for the trees can have far-reaching consequences. Even a seemingly-benign choice like what background color to use can reverberate throughout your game.
A good real-world example of this in AtG was our choice to make the 'fog of war' tiles you haven't yet revealed look like parchment paper. What at first appeared to be a single decision would eventually balloon into dozens. A paper background means the screen usually dominated by a light, warm color. Anything we place over the top of the world that we want to stand out now needs to be dark. Well, if every background panel and popup in the game is going to be dark that means our text needs to be light.
If AtG instead had light panels and dark text it wouldn't make the game unplayable or anything, but it would make things just a little bit tougher for some people. Even if each incremental upgrade or downgrade only grows or shrinks your audience by a tiny amount those little slivers eventually add up.
Something else I'd like to talk about that our choice of background color also had an effect on is our buttons. Another big "Jon Shafer UI Design Rule" is that anything you can click should share a clear and consistent style visually distinct from everything else in the game. We decided to make all buttons in AtG either solid gold or at the very least have a gold rim around them (e.g. the Profession buttons in the Study Screen).
So why gold in particular? There are actually several reasons. Even long before we came up with the current art style I liked the idea of making all of our buttons look like some kind of metal. Why metal? Between the bronze age and the invention of plastic most man-made items we manipulated with our hands were metal, be they weapons, tools, or toys, and as a result whenever we see a shaped metal object a tiny voice deep inside tells us it must be something we can use. This was definitely not the case for the stone buttons in our old UI, and given how, uh, non-interactive most rocks are I doubt that voice was whispering anything nice about them into our ear!
After the gold buttons had been in for a while we actually considered changing them to silver or iron because we was worried gold was too close to the parchment background, but in the end we kept it for a few reasons. For one, most of the time when you push a color closer to white or gray the more indistinct and unimportant it seems. If asked what white reminds us of "blank pages and empty walls" is more likely to be someone's answer than "interesting thing I want to use or learn about". With silver now off the board, iron isn't far behind, mainly because it just doesn't have nearly the appeal of gold, a metal that's universally desirable not only throughout time but across cultures.
I also came to realize that the gold buttons not standing out as much over the top of the paper fog may not actually be a bad thing. The only buttons which don't have some kind of dark panel behind them are part of the basic World Screen, which of course is what you're looking at 95% of the time. It won't take long for players to familiarize themselves with this screen and its contents, and the fact that the buttons don't 'pop' as much actually improves the overall feel of the game.
This is a good reminder of the fact that few rules in UI design are hard and fast, although I feel pretty strongly that the "consistent, distinct style for buttons" rule I talked about is one of them, and unfortunately many devs break with gleeful abandon. This is usually done in an attempt to make their UI more "beautiful", but in a tragic twist of irony for most new players the thing they notice the most about the UI is that it's nearly impossible to tell anything apart.
Don't Cross the Streams
Which brings me to our next 'rule': UI is UI and the world is the world, and trying too hard to blur that line usually only makes it harder to learn your game. It's great if a creature's posture changes with its mood, but you probably also want to stick a big icon over their head to make sure it's crystal clear. Because otherwise it probably won't be, and not only will many players be in the dark as to what individual creatures are up to but they may mistakenly conclude things are just random and downgrade their opinion of the game generally.
That's not to say your UI has to look gaudy and ugly. I think the on-map unit flags in AtG look quite nice on the map, despite packing quite a bit of info and being completely out of scale with other map elements. But we made it that size for a reason, and had we instead tried to push things too far by making them in-scale with everything else on the map we'd be spending time on something only the developers care about. On the whole players are very accepting, and most don't even notice or think twice about incongruities which keep developers up at night.
Leave Room to Breathe
Another similar rule is that smaller isn't always better. While you probably don't want half the screen to be covered in UI at all times in map/world-based game, today's monitors have enough pixels that you don't need to cram everything together so tightly that it looks like it came out the other side of a trash compactor. A UI needs room to breathe, and negative space is an essential tool for establishing a hierarchy of importance.
This rule also has an important corollary: Don't be afraid of text. Many games try to save space by replacing words with icons wherever possible, but this is a huge no-no in my book. A lot of the time these 'naked' icons appear inside tooltips, but unless the tooltips work like AtG's there's no way for you to actually figure out what it is. Once you have it memorized, sure, those extra few pixels are nice, but the price paid is completely disproportionate with the payoff.
But what if those few pixels here and there do add up into something veteran players legitimately care about? Well, then just make two versions! Yes, this requires work, but so does everything! If building a good UI that works well for all types of players is actually one of your priorities then these sorts of features start looking like really smart investments.
Consistency and Learning
Our final rule is a simple one: Be consistent. As new players are learning your game they're subconsciously building a mental map of how things fit together, what that icon over there means, which screen contains X and which contains Y, and so on.
By establishing everywhere in the game that red text indicates something negative or bad but then make one exception for the announcement which appears at the top of the screen when you win a battle you damage the player's faith in their mental map. They usually compensate by erasing something, leaving a gap that may never be filled in. The player would have actually been better off had you not attached ANY color to that announcement text. Preventing these sorts of traps is rarely difficult, and usually only requires establishing a clear style guide early on and being diligent about sticking to it.
An even better (or worse) example is sometimes found in more complex games with lots of screens. In providing multiple ways to navigate to the same screen or accomplish the same task might think you're doing players a favor, but much of the time these good intentions backfire. When learning one of these bad boys building that mental map takes much longer but is even more important, but if the player discovers that there are two or even three ways to get to the same screen that map starts to unravel quickly. They'll start looking for locations they remember being next to those they've erased next to one of the others, further undermining the map. The end result is often players simply giving up, or 'quarantining' much of the UI and never venturing outside of the few areas of their map they still have trust in.
But like most UI design rules this is a "soft" one that's more guideline than dogma. Including hotkeys could be thought of as providing multiple entry points, but they're not only accepted and often expected, but I can't even think of any drawbacks aside from the time it takes a developer to add them.
A less clear-cut example from AtG is our inclusion of two independent methods for training a clan in a profession: while in the Clans Screen clicking on one of the 'clan cards' will open a new screen showing all the professions it can be trained in. The Clans Screen also has a button at the bottom you can click which allows you to pick the profession first and then the clan. So why offer both? Because even though the end result is the same the actual process involved in getting there is not. Sometimes you know you need an explorer and it's just a matter of figuring out which clan is the best fit, and others you have an idle clan that needs something to do but you don't have anything in mind yet.
Will some players be confused by this? Without a doubt. But UI design is an art, and like all art you sometimes just have to go with your gut and accept that it won't - and can't - be for everyone.
Phew... Alright, I think that's probably a good stopping place for now, I do truly enjoy working on and talking about UI, though if you've actually still reading this that's probably pretty obvious! If you haven't already I encourage you to check out the video we just posted showing the UI in action.
'Til next time!
UI Feature Outline
Adaptive Tooltips - Links
The key feature of AtG's UI
Tooltips Within Tooltips - "like Wikipedia, except with tooltips"
Even words can have tooltips
Confused or interested? Dig deeper to learn more
Simpler on the surface, but more powerful under the hood
Makes it easy to see how things "fit together"
Adaptive Tooltips - Customization
Complex tooltips are broken up into expandable panels
Customize in 'real time', instead of from an options screen
Allows the UI to evolve with you as you learn
Game-Wide Memory, by type (e.g. Professions VS Structures)
Other UI Features
Hotkey Hint Display when mousing over button or pressing ALT
Can use WASD keys to move camera (along with traditional controls)
Upgraded versions of Civ 5's 'Notifications' and 'New Turn Banner'
'Floating Text' appears when a resource is produced or spent on a map tile
Colored 'Sticky Notes' can be attached to Clans or map tiles
Cursor color changes subtly when mousing over something with a tooltip
In-game Patch Notes, its contents filtered using the date you last played
Localization Framework now makes (unofficial) translations possible