INTRODUCTION
Xenonauts took exactly five years to develop. It took ten times as long and cost twenty times as much as expected, but has been such a big part of my life that I am somewhat sad that the journey has come to an end.
There was a lot of personal risk involved. When development started in 2009, I was twenty-two and had no knowledge / experience of game development. I sunk all of my own savings into getting the project moving, most of which was inheritance money. My office was my bedroom; I worked on Xenonauts in the evenings and at weekends around a full-time consultancy job with KPMG that included three years of accountancy exams (failing any would have left me unemployed).
Thankfully, everything turned out well. This article is the “development diary” promised on Kickstarter, an appraisal of the aspects of development that I felt went well and those I felt went badly. I hope it is of interest – perhaps it will prevent someone else making the same mistakes!
WHAT WENT RIGHT #1: REMOTE TEAM
The team on Xenonauts consisted almost entirely of remote freelancers – perhaps two hundred of whom were involved in production of the game across the entire period. Despite having built a close relationship with many of them, I’ve met perhaps five in person.
Our production model was simple: I managed every team member directly via email. The team had almost no contact with one another – the two big exceptions being the coding team and my colleague Aaron, who joined me full-time when we set up an office after our successful Kickstarter (roughly three years into development).
This is not the normal way to make a video game, nor is it my preferred way to work. Not only is it much more enjoyable to work in the same room as your colleagues, it also brings large productivity and creativity gains. Unfortunately, the costs are correspondingly greater – paying the hourly rates
of competent UK-based freelancers was out of the question early in development, let alone full-time wages or desk rental.
To put our funding situation in perspective, I had about $25,000 in savings when we started development in 2009. We began taking pre-orders in November 2010 and hit the thousand sales mark in July 2011, meaning we had around $50,000 available to us during the first two years of development (during this period I was not only working on Xenonauts unpaid, but using my salary to inject additional money into the project).
Our only option was thus to use remote freelancers – it is much easier to find affordable talent if you can search the entire globe for it. The sheer amount of content in Xenonauts would have cost
millions of dollars to produce at AAA-studio rates, but we had to do it on a fraction of that.
This is why Xenonauts took five years to develop. Cheap, talented freelancers are a rare commodity and finding them is time-consuming; those looking for a needle in a haystack should be prepared to find a lot of hay. We wasted a lot of time with people who ultimately proved unreliable or unable to deliver what we needed.
Even once the team was assembled, we then had to co-ordinate across multiple time-zones / working hours – a painful, inefficient experience. Most of the team were part-time themselves, naturally limiting the hours they could put into the project. Everything took far, far longer than it would have had we all been working full-time from the same office.
But despite being difficult and frustrating, operating a remote team successfully was the primary reason why Xenonauts was successful. We simply did not have the funds to create a game of this scope using any other method! It was a necessary evil that allowed us to undercut more mainstream games on cost.
WHAT WENT RIGHT #2: REMAINING FAITHFUL TO X-COM
UFO: Enemy Unknown is twenty years old and widely considered one of the best games ever made. Associating ourselves with it as closely as possible brought us a multitude of benefits.
The most obvious benefit was the pre-orders and press coverage it brought. The sheer quantity of X- Com fans out there meant that we had a ready-made audience prepared to pre-order the game, a number of whom were journalists willing to give us coverage.
It also lent us a veneer of credibility and provided a shared language of communication with the community early on. Our pre-orderers were able to look at primitive versions of the game and see the potential because they already knew what the missing content was supposed to look like. That would not have been the case had we been making an original strategy game.
Even once Xenonauts became more established in its own right, the X-Com name remained a key attraction. People inadvertently stumble across us when browsing online (we draw quite a lot of website traffic from the X-Com Wikipedia page, for example) or read a preview they would otherwise have skipped because they see the “X-Com” subtitle.
It was similarly useful from a design perspective. The original game had a lot of elegant and well- documented game mechanics which I used as a starting point for our own game systems. I reworked almost all of them, but being able to look at how the original game handled a particular issue made the development process much easier.
Then there were the two official remakes. The first was a shooter called The Bureau: X-Com Declassified. This was a godsend for us – the backlash against X-Com being rebooted as a shooter gave us a lot of publicity and helped establish a community around Xenonauts when we first announced.
XCOM: Enemy Unknown by Firaxis is the elephant in the room - it was a huge critical and financial success. For the record, I have completed it on Classic Iron Man and enjoyed it immensely. Whilst it does have a few flaws, I believe it fully deserves the praise it received from the press.
It affected us in two ways. The first was overwhelmingly positive: it raised the profile of the X-Com franchise and the genre as a whole. We used to make around $350 in pre-sales over a normal weekend, but this hit $30,000 the weekend XCOM was announced – enough to support an extra two months of development on the game!
My complaint about XCOM is more subtle: the two projects were defined in opposition. Elements in our community strongly disliked the “dumbed down” remake and any attempt to streamline the original game mechanics was met with endless accusations of us doing the same. Not exactly helpful when we were trying to modernise a game from twenty years ago!
But, in retrospect, positioning Xenonauts as a remake of X-Com was one of the wisest decisions I made – it was an invaluable safety net that minimised the risk of screwing up the game design / marketing and let us focus on the execution instead.
WHAT WENT RIGHT #3: THE COMMUNITY
I cannot write an article discussing the success of Xenonauts without mentioning our community. We sold thirty thousand copies prior to release and our forums have generated more than a hundred thousand posts in the past two years. We simply could not have completed Xenonauts without the money and feedback the community gave us.
Specific individuals also often contributed enormously to development. A few examples stick in my mind:
• A corporate lawyer helped us set up a US company and corporate bank account for our
Kickstarter (rather than have to use IndieGoGo);
• Our websites are hosted and admined by a community member;
• Someone made translations possible by somehow tracking down an long-lost program required to add new fonts to the engine;
• The air combat UI design originally came from the forums;
• Community maps / mods were occasionally good enough to add to the official game;
There are too many others for me to be able to mention them here, but even the simple act of posting an opinion or bug report for the game was helpful. The collective contribution of everyone who did so has been immense.
This endless stream of feedback allowed us to gradually polish away at the game’s rough edges. While Xenonauts is far from perfect, I dread to think how much worse it would have been without the million hours (!) of public alpha / beta testing it logged in Steam prior to release.
It also came in very useful with regards to bugtesting and QA, which we did not have the time or budget to do internally. The sheer scope of the game meant it was very difficult to dream up all the different behaviours a player could use, let alone test them. Similarly, it’s almost impossible to test large numbers of different hardware configurations without help from the community!
In particular, the Kickstarter sticks in my mind as a time when our community was valuable. Firstly, I ran our proposed reward tiers past them and was genuinely surprised by how negative the feedback was. We revised them before launch, avoiding potentially crippling ourselves with sub-standard rewards.
Secondly, they provided important momentum. We hit $10,000 of our $50,000 target within a couple of hours (i.e. before the press coverage informed non-community members about it) and I think we were halfway to meeting our $50,000 goal after a single day. That gave us the credibility to attract people from outside the community, and eventually took us to over $150,000 in total.
I’ve also enjoyed the overall experience of interacting with the community on our forums. I try to treat forum goers with respect and the favour is (usually) returned. Discussions are usually polite, helpful and constructive and on countless occasions the game has been improved as a result.
So if you are / were part of our community, thanks – you’ve been great!
WHAT WENT RIGHT #4: KEEPING THE DAY JOB
I did not quit my day job and work on Xenonauts full-time until October 2011, nearly halfway through development. Whilst not relevant to our future projects, this was still one of the most important decisions I made.
I was not exaggerating when I said development took ten times as long and cost twenty times as much as I original anticipated. I knew very little about video game development when I started (though I thought otherwise) and the project made a significant financial loss in the first couple of years. Had I been relying on game development to pay the bills, I would have ended up living in a cardboard box.
It is a rather disheartening experience to spend all your free time at evenings and weekends working on a business and end the month with less money than you started, but if you remain in paid employment it will be no more than disheartening. My salary covered my day-to-day living costs
until Xenonauts became self-sustaining … and then eventually successful enough to sustain me too.
Anyone that leaves their job to pursue something new is immediately putting themselves under pressure to succeed quickly. Not only must the business turn a profit quickly, it must turn a sufficiently large profit to pay their bills as well. This can be highly destructive – not only is it stressful, it encourages short-term thinking.
The reality of effectively working two jobs for the first half of the development process was not a particularly pretty one. It cost me a number of friendships and relationships and far too much sleep, but it gave me the time I needed to make a success of Xenonauts.
Keeping the day job for another couple of years allowed me to leave it forever. Had I quit immediately, I’d have burned through my life savings within a year and had to return with my dreams in tatters.
I simply cannot stress enough how important it is not to rely on game development as your main source of income until the finances justify it.
WHAT WENT RIGHT #5: GAME DESIGN DECISIONS
Xenonauts took shape through thousands and thousands of individual game decisions. I made some mistakes (which have their own section), but I made some good choices too.
The first was giving the Chief Scientist a voice in the research reports. Instead of dry factual description, the idea was to give the game at least one memorable character and use the research text to hint at what everyday life in the organisation might actually be like.
For a long time I was genuinely concerned that I had made a mistake here – bad writing is a terrible immersion-breaker and it is very easy to get it wrong. It was also hugely time-consuming: I wrote
30,000 words of research text and edited it in full at least three times. This took a LONG time.
I was therefore very pleased to see the writing get good reviews. I think the Chief Scientist adds a lot of character (and a little humour) to a game that would otherwise be rather devoid of it, and from a personal perspective it is nice to know that I possess at least some writing ability!
The first-person UI style was also big success. I used this to try and create the illusion of a world around the game by actually placing the player inside their base and allowing them to view their organisation first-hand. The technology used in the artwork subtly changes as you progress through the game too, suggesting your actions are having an impact on the wider world. To me, it feels much more immersive than our old “spreadsheet“ UI style ever did!
I am also proud of the Geoscape “events” spawned by UFO activity. The original X-Com felt a little empty in places: you felt like the only organisation trying to fight the aliens, with no hint of a wider conflict going on around you. The events on the Geoscape help fill in the blanks and makes the world feel a little more realistic.
The AI local forces apparently had the same effect on the ground combat – people seem to love them. They generate a lot of cool moments; about 90% of the stories on our forums involve local forces somehow saving a hapless Xenonaut from death. I’ve been a little surprised by quite how popular they have proved, but they certainly seem to have been a good addition to the game!
The final good decision was streamlining the game, specifically the economy – e.g. making starting equipment / ammunition / flares unlimited in quantity, automatic upgrade of aircraft / vehicle weapons etc. I think this made removed a lot of tedious micromanagement without actually reducing the depth of the game.
These were controversial decisions, but I draw a distinction between complexity and depth here. The former forces the player to make choices, while the latter forces the player to make meaningful choices (i.e. generating enjoyment). Personally, I think we did a good job of removing complexity without removing depth and I would say general public opinion seems to agree.
WHAT WENT WRONG #1: (LACK OF) EARLY PLANNING
So, onto the bad stuff! Let’s start with the early project planning.
Our choice of engine was the single worst decision we ever made. Playground SDK 5 is a 2D engine primarily designed for casual browser games such as Diner Dash. It is not supported by its developers, does not include the source code and is no longer even available to download.
I can scarcely think of enough bad things to say about it. It contains a number of serious bugs and is missing several key features that would be considered standard in any other game engine, and we cannot fix or add these things without the source code. Anything in Xenonauts that looks low-quality or poorly-made is almost certainly due to a problem with the engine.
This engine was chosen by the first coder that (briefly) worked on the project. It was a terrible decision. Had the planning and prototyping been done properly, we would have quickly moved to a different engine as Playground SDK is plainly not suitable for a game like Xenonauts. Instead, we laid bad foundations and then spent the next five years struggling to build atop them.
The second major issue was a poorly-planned codebase. The code itself was written by competent programmers and is more than adequate, but it was never assembled to any defined overall structure or shared conventions - the ground combat and strategic elements of the game were coded separately by entirely different programmers, then joined together about three years into development.
This was a massive issue. Our programmers generally only understand their own part of the code, so cannot fix bugs in other areas of the game. Unavailability meant bugfixes could sometimes take
days, and recruiting new programmers was much harder than it should have been. This made it almost impossible to speed up the coding side of things even after the Kickstarter gave us the funds to do so, and I dread to think what would have happened if one of our key coders had quit the team.
These situation could have been resolved in two ways – firstly, I could have employed a better- trained programmer to choose the engine and plan the codebase. But those sort of people are much in demand and is unlikely to be interested in joining a small indie team with no visible progress to show and no money to properly compensate them for their time.
This leads to a chicken-and-egg scenario. Projects are much more likely to succeed with proper technical planning, but a team will generally only have access to the expertise required to do so once they are better established (and thus long past the planning stage).
The second solution would have been me doing more research - this might have averted the engine choice disaster, at least. I could have read more widely and made an engine choice that was informed by the programmer’s opinion, rather than delegated entirely to him. I did not do so due to my inexperience, but I ended up regretting it for a long time afterwards.
(We also could have dumped the engine at any point any started over in an engine like Unity. In retrospect, this could have been a good idea. But an indie team with no proven track record starting over in a new engine halfway through development? That would not have gone down well and the negative publicity could have killed the project. I decided to stick with the devil we knew.)
WHAT WENT WRONG #2: THE SCOPE
Ask any indie developer for advice on making your first game and they will almost certainly smile wryly and advise you to make something small. The reason is simple: you’ll make a lot of mistakes. If you make a small game you can take all the lessons you’ve just learned and quickly apply them to your second game.
Xenonauts isn’t a small game – few indie games contain as much content as even the ground combat section alone. I was advised to make a small game, and I instead decided to make an enormous one. Predictably, this proved a mistake.
A game with such a broad scope requires vastly increased amounts of money, talent and time to produce. There are so many more potential points of failure than in a small project because there is so much more that can go wrong.
It is also questionable economics. All this extra content requires money and time to produce: Xenonauts contains more than a hundred research paintings, forty thousand terrain tiles, twenty thousand words of writing and a million frames of rendered animation. It is difficult to appreciate how much effort this requires until you actually attempt it – but believe me, it is a lot of work.
The problem here is that the acceptable price for the game does not increase accordingly - indie games will top out at $20-$25 irrespective of the amount of content they contain. It is therefore a bit of a mistake to include large amounts of content beyond that required to justify a $25 price tag.
Xenonauts was therefore expensive to develop relative to what it could be sold for, as all X-Com games tend to be. The fact that they are a little dubious as business propositions is almost certainly one of the reasons why it took so long for X-Com to get a proper official remake!
Anyway, I should have listened to the developers who told me to make something small as my first game – Xenonauts would have been much more viable as our second game. For instance, I somehow doubt I’d have screwed up the early planning so badly with a little more experience under my belt.
An X-Com remake really was jumping in the deep end of video game development, which in retrospect was foolish. A half-finished game project is worth nothing, so had I tripped up at any point in development I would have lost a lot of money (largely belonging to other people) and effectively ended my game development career before it even began.
A big risk to take, and a largely unnecessary one.
WHAT WENT WRONG #3: REALISTIC COLD WAR SETTING
Xenonauts is set in 1979, the historical height of the Cold War. I chose this setting for several reasons
– it differentiated us from the near-future setting of X-Com; the intentionally mundane setting contrasts with the exotic aliens you fight; it was the historical period with the greatest fear of aliens and alien invasion.
I consider it a mistake. Firstly, we wasted the setting: the mistrust between the two superpowers is barely mentioned, let alone factored into the gameplay mechanics. I took an interesting period and then did nothing with it.
However, the biggest issue was that of “realism” – or, rather, the perception of it. If you set a game in a relatively modern time, you are giving the player recognisable objects. If they then do not act in the way that the player expects them to, it breaks immersion.
This conflicts with the goal of a game developer, whose primary objective is to make an enjoyable game. Divergence from reality in game design is inevitable and often beneficial: few games will prevent you from ever playing again if you character dies, for example.
Gameplay balance thus takes priority over historical accuracy. The Xenonaut Chinook is capable of flying around the world on a single tank of fuel because players get frustrated and complain if they cannot respond to terror sites globally. That is not realistic, but it improves the game experience.
An X-Com game has a lot of inherent gameplay conceits that improve the game, such as artificially limited unit sight ranges that increase tension. I could not change these without failing in our promises to remake X-Com, but combining them with a realistic setting in many cases just made them more obvious and led to a lot of heated forum debates on such topics.
But when people made objections based on realism alone, I had to disregard them – Xenonauts is a game, so gameplay is more important than realism. I found it particularly frustrating when people would cherry-pick individual details (such as a specific jet being able to fly too fast) and insist they ruined the game, whilst happily swallowing other mechanics / facts that were clearly much more unrealistic.
Whilst I believe some people might perhaps better appreciate the irony of complaining about realism issues in a game about battling an alien invasion in 1979, the fundamental mistake was mine. We advertise the game as a “Strategic Planetary Defence Simulator”, and I chose a gritty and
realistic tone for the game. Both of those things create an expectation of realism that an X-Com-style game was never going to be able to meet.
It would have been better to have used a hard sci-fi setting that hinted at the real world, but was not constrained by it. As such, I seriously doubt we will use a real-world setting for any of our future games – I’d rather not have to put up with the arguments for a second time!
WHAT WENT WRONG #4: EARLY PRE-ORDERS
Xenonauts was announced when it was little more than a vague concept. Buyers put down money
for their idea of what a modernised X-Com should be. Unfortunately, they actually ended up with my
idea of what a modernised X-Com should be.
We were never going to be able to please everybody. Everyone has different ideas about what parts of the X-Com formula should be changed and how that should be done, and frequently these suggestions were completely incompatible with one another.
Thankfully, most people recognised this fact and knew Xenonauts was not going to match up exactly with the idea in their heads. They debated individual issues and design choices but would accept us making a few decisions that they disagreed with.
However, some people would become extremely poisonous if we did not immediately adopt their suggestions or made even a single change they did not like, no matter how patient / detailed an explanation we gave them in our refusal. If Xenonauts was not built exactly to their specifications, they would get incredibly angry and claim that they had been ripped off.
Though the internet will always bring you into contact with a few angry internet men, things might have been better had we waited longer before accepting pre-orders – a more developed product would have let buyers better decide if it was really the sort of game they wanted to buy. Those who did not like the direction the game was taking may have filtered themselves out.
The second issue with early pre-orders is a little deeper: people do not like change. Developing a game in public can be difficult because players tend to get annoyed if you remove something from the game - the human psyche does not like to be given something and then have it taken away.
This can be a problem. A good example was switching weapon fire costs from static TU values to percentages based on max TU, preventing experienced soldiers being able to fire more shots than rookies in addition to being more accurate (i.e. returning to the system the original X-Com used) and becoming so ludicrously overpowered that the late-game was impossible to balance.
The change ignited a firestorm within the community. The problem was that most people were approaching the issue as players rather than game designers – they’d played a few hours of the game and enjoyed having super-soldiers. It felt like we were taking away their toys.
The change was 100% correct and 100% needed, but if you are a community-focused developer you cannot simply sideline your community when they disagree with you. It took days to push through that change, whereas it would have taken a few seconds had the community not been involved.
Having the community involved in development is of huge benefit to any team, but I really feel the optimal point to bring them in is when the prototyping phase is over and the design is largely settled. Unfortunately, financial reasons meant the community had to be involved with Xenonauts right from the very start and all our experimentation had to be done in full view.
WHAT WENT WRONG #5: GAMEPLAY DECISIONS
So, the gameplay design decisions I regret most.
Firstly, the “realistic” alien design was a mistake: the aliens in Xenonauts are almost all armoured humanoids with fairly normal proportions. The original X-Com had a much wider array of strange and wonderful enemies - even the standard sectoid had a tiny body and a massive head, which makes it look distinctly alien. They had a lot more character than the enemies in Xenonauts.
I think part of the problem was that I designed the aliens as if the game was to be an FPS – each has a lot of unique detail when seen up close, but none of this is visible on the small sprites of a strategy game. I should have focused on giving the aliens unique silhouettes rather than different detailing. I realised this about halfway through development, but by then it was far too late to change anything.
My next regret was the flat globe. This was not objectively a bad decision, as a flat map gives a lot more situational awareness than the 3D globe of the original X-Com. However, it also means flight paths and radar ranges cannot take the curvature of the Earth into account – e.g. building a base in Antarctica was useful in X-Com, but in Xenonauts it was so pointless we removed the continent entirely. I think that was a bit of a shame.
The third mistake was the UFO designs. The art is great and they do look genuinely alien, but they work incredibly badly with the tile grid of the ground combat. The grey boxes of the original X-Com looked a little boring at times, but could be built out of individual tiles. That meant they fully supported destructibility and also suffered no frustrating walkability / line of sight issues.
Making our UFO designs work with the game consumed huge amounts of time and produced results that were mediocre at best. We should have ditched them entirely and replaced them with modular UFO designs – they would have been less attractive, but the gameplay would have been dramatically improved and implementation would have been much easier.
Had we been developing Xenonauts in private, that almost certainly would have happened – but our UFO designs were done early in development and I had used them in all kinds of publicity over the years. I felt they were too big an element of the game to change in the later stages of development… but I really should have done it anyway.
Another mistake was UI scaling – the game font becomes almost unreadable on small screens. I did not consider this as much as I should have when designing the UI (intended for a 1080p screen) and it caused a lot of complaints. Things could have been done to mitigate the problems had I planned them in advance, but by the time I realised my error it was again too late to do anything about it.
Finally, I think the late-game pacing in the release version of Xenonauts was a bit off – it drags on a bit towards the end. It took a full day to play through to the late-game, making iterating the balance there difficult (especially when we were busy with other things). Is it the biggest problem in the game? No, but it is still something I would have liked to have done better.
CONCLUSION:
Every time I used to play a game, I would wonder why developers made so many obvious mistakes –
why, if only they were gifted with my insight, their game would have been perfect!
It turns out that was not the case. What looks so easy from the comfort of a distant armchair actually proved exceptionally difficult in practice, and I have made just as many mistakes in my own game as those developers I used to endlessly critique.
But things ended well - at the time of writing, the gross lifetime sales of Xenonauts have ticked up past $1.2 million and it has a very respectable Metacritic score of 80/100. We certainly did not do things in the most efficient way possible, but I think that we got a pretty good outcome for our first game.
Writing this article has helped me to put my own thoughts in order, and I hope that sharing them has either shed light on why Xenonauts turned out the way it did or helped others considering venturing into indie development. Thanks for reading!
Chris England, Xenonauts Project Lead.
