History of Xenonauts - an independent remake of X-COM
- Transfer
The development of Xenonauts took five years. It took her ten times more time and twenty times more money than I expected, but she became such an important part of my life that I was even a little sorry that this journey ended. A lot of personal risks were associated with the development. When it started in 2009, I was 22 years old and I knew nothing about game development. I spent all my savings on this project, a significant part of which was inheritance. My office was my bedroom, I worked on Xenonauts in the evenings and on weekends, after a full-time working week as a consultant at KPMG, which included three years of accounting exams (failure of each of them would lead to my dismissal). Fortunately, it all ended well. This article is the promised kickstarter diary, in which all aspects of development are evaluated - whether I did the right thing or not. I hope this will be interesting and maybe help someone avoid my mistakes.
The team involved in Xenonauts almost entirely consisted of freelancers working remotely - for the entire time of development, almost two thousand people participated in it. Despite quite close relations with many of them, I saw five people live.
Our development process was very simple: I managed each team member directly using email. The team members practically did not contact each other - the two exceptions were the team of programmers and my colleague Aaron, who joined me full time after we moved to the office after a successful Kickstarter campaign (about three years after the start of development).
This is neither the usual nor the preferred method of developing computer games. Working in the same room with colleagues is not just pleasant, it gives a big increase in productivity and creative energy. Unfortunately, this is much more expensive - at the beginning of the development we could not afford even full-fledged freelancers from England, what can we say about a full-time office rental.
To give a general idea of our financial situation: I had accumulated approximately 25 thousand dollars when we started development in 2009. We started taking pre-orders in November 2010 and passed the mark of 1,000 copies in July 2011, which meant the availability of another 50,000 during the first two years of development (during this time, I not only worked on Xenonauts for free, but also injected money from my salaries).
We had no options other than using remote freelancers - it’s much easier to find affordable talent if you can search all over the globe. A huge amount of content in Xenonauts would cost millions of dollars at the prices of AAA-studios, but we were able to do all this for a small fraction of this amount. That is why the development of Xenonauts took five years. Cheap and gifted freelancers come across infrequently, their search takes a lot of time, looking for a needle in a haystack must be ready to sort out a lot of hay. We spent a lot of time on people who ended up being unreliable or unable to do what we needed.
After the team was assembled, we had to coordinate its work taking into account different time zones and working hours - a painful and ineffective experience. Most of the team worked part-time, which immediately limited the time that they could spend on the project. Everything took much longer than if we worked full time in the same office.
But despite all the difficulties and disappointments, it was thanks to the successful management of the remote team that we were able to make Xenonauts. We simply did not have money to create a project of this scale in any other way. This was an inevitable evil that allowed us to make development cheaper than most ordinary games.
Created 20 years ago, UFO: Enemy Unknown is still considered one of the best games of all time. A close connection with it has given us many advantages. The most obvious were pre-orders and press coverage. A huge number of XCOM fans meant having an existing audience ready to pay for pre-orders, part of which were journalists who were ready to write about the game.
It also made us more reliable in the eyes of the players and gave us a common language for communicating with the community in the early stages. Pre-order buyers could easily perceive the primitive versions and see a great future behind them, as they already knew what the missing content should look like. All this would not have happened if the original strategic game were created.
Even after Xenonauts became more famous in itself, the name X-COM remained a key feature of the game. People accidentally stumbled upon us on the Internet (for example, a lot of visitors to our site came from the X-COM page on Wikipedia) or read reviews that would simply be ignored without the word X-COM in the header.
It was also very useful for game design. There were a lot of elegant and well-documented game mechanics in the original game that I used as a starting point for my own game systems. I reworked almost everything, but the ability to see how they acted in certain situations in the original game greatly facilitated the development process.
In addition, there were two official remakes. The first one was The Bureau: X-Com Declassified shooter. For us, it was just a gift of fate - the protest against the X-Com reboot attracted a lot of attention to us and helped create the Xenonauts community.
XCOM: Enemy Unknown from Firaxis was a real monster - with its incredible success among buyers and critics. Frankly, I went through it at Classic Iron Man and got a lot of pleasure. Despite some flaws, the game really deserved all the praise it received from the press. She influenced us from two sides. The first was positive: the game attracted attention to the X-Com franchise and the genre as a whole. Usually, during the weekend we earned $ 350 on pre-orders, but this weekend we received 30,000 X-COM announcements - enough to finance the development for two additional months.
The problems with X-COM were more subtle: two projects were opposed to each other. Some members of our community really did not like the “stupid” remake and any attempt to simplify the mechanics of the original game caused a lot of accusations that we were doing the same. This is not very useful when you are trying to upgrade a game twenty years ago!
But looking back, positioning Xenonauts was one of the wisest decisions - it was priceless insurance that minimized the risk of wrecking game design / marketing and allowed us to focus on creating the game.
I cannot write an article about the success of Xenonauts without mentioning our community. We sold 30 thousand copies before the release of the game and our forums generated more than one hundred thousand messages over the past two years. We simply could not have made Xenonauts without all the money and feedback the community has given us.
Individuals often provided a lot of help in development. Here are some examples that I remembered well:
- A corporate lawyer helped us create a legal entity in the USA and open an account for our Kickstarter (otherwise we would have to use IndieGoGo);
- One of the members of the community hosts and administers our sites;
- Someone made translations possible, somehow finding a long-lost program that makes it possible to add new fonts to the engine;
- The design of the user interface of air battles was originally invented on the forums;
- The mods and maps created by the community were often so good that we added them to the official version of the game.
There were too many such people to mention all of them, but even the simplest actions, such as voiced opinions or error messages, helped to develop the game. The collective contribution of everyone who did something like this was simply huge.
An endless stream of reviews allowed us to gradually eliminate various shortcomings. Although Xenonauts is far from perfect, I’m scared to think how much worse they would be without the million hours of public alpha / beta testing taken into account on Steam before the release of the game.
It was also extremely useful because we did not have money for full testing within the team. The huge variety of the game meant that it was difficult to even imagine all the possible actions of the players, not to mention testing them. Similarly, without the help of the community, it would be virtually impossible to test a large number of different configurations of iron!
Our community was especially valuable during the time of Kickstarter. First, we presented the inventions we invented to them and were extremely surprised by very negative reviews. By reviewing them before launching the company, we avoided potential problems with low-quality awards. In addition, they provided a very important impetus. We collected 10,000 from our goal of 50,000 in a few hours (that is, before the press informed the players who are not members of our community about this) and it seems to me that we have reached half our goal of 50,000 in one day. This gave us a reputation that attracted non-community people and ultimately helped to raise 150,000. I also enjoyed the process of communicating with the community in our forums. I tried to treat the forum participants with respect and (usually) answered me the same. The discussions were usually polite, useful and constructive and in many cases led to an improvement in the game. So if you were a member of our community, thanks - you were great!
I didn’t quit my job until October 2011, when the game was almost half completed. Although this decision does not affect future projects, it still remains one of the most important.
I did not exaggerate when I said that it took ten times more time and twenty times more money to develop than I had originally expected. In the beginning I knew very little about the development of computer games (although I myself thought differently) and the project brought serious financial losses during the first years. If I made a living by developing video games, I would turn into a homeless person.
Spending all your free time in the evenings and weekends, ending the month with less money than at the beginning, is certainly very depressing, but if you continue to get paid, then you are not afraid of anything worse than despondency. My salary covered my daily expenses until the Xenonauts began to support themselves ... and in the end they were able to provide for me. Anyone who quits their job to create something new will immediately be pressured by the need to quickly succeed. His business not only needs to become profitable quickly, profits must become large enough to last for a living. This can be extremely destructive - not only in terms of stress, but also in terms of encouraging short-term thinking.
The reality of effective work in two jobs during the first half of development was not particularly attractive. It cost me a number of relationships, friends, and too much sleep, but it gave me the time needed to succeed with Xenonauts.
Saving work for these few years allowed me to quit it forever. If I quit right away, then in a year I would spend all my savings and be forced to return with shattered dreams.
I just can’t find the words to explain how important it is not to rely on game development as the main source of income, until it really is justified from a monetary point of view.
Xenonauts took shape through thousands and thousands of individual solutions. I made a lot of mistakes (about them in the corresponding section), but there were also correct decisions.
The first was the introduction of the personality of the Chief Scientist in research reports. The idea was as follows: add at least one memorable character to the game and instead of telling facts, tell in texts about research about the organization’s daily life.
For a very long time it seemed to me that this was a mistake - bad texts very much destroy the immersion and they are very easy to do wrong. It also took a huge amount of time: I wrote almost 30,000 words for research reports and rewrote them at least three times. It took VERY MUCH time. Therefore, I was very pleased with the good reviews about the texts. It seems to me that the Chief Scientist adds a lot of personal (and a bit of humor) to the game, where, with a different development of events, such things would simply be absent, I’m just glad to know that I have at least some writing skills!
The first-person user interface was also a great success. I used it to create an illusion of the world around the game, allowing the player to literally walk around the base and personally see his organization. The technologies used by artists gradually change it as the game progresses, giving the impression of the impact of your actions on the big world. It seems to me much more impressive than our old spreadsheet-style user interface.
I am also proud of the events on the globe generated by UFO activity. The original X-COM seemed a bit empty in places: you were the only organization fighting aliens, there were no signs of a global conflict raging around you. Events on the global map helped fill the void and made the world more realistic.
AI-driven local troops suddenly created a similar effect in ground battles - players simply fell in love with them. They created a lot of cool moments, about 90% of the stories on the forums included local troops saving the helpless xenonaut. I was somewhat surprised by their popularity, but they definitely turned out to be a good addition to the game. The last good solution was to simplify the game, especially the economy - an unlimited number of initial equipment and ammunition, automatic upgrade of weapons on aircraft and other equipment, and the like. It seems to me that this allowed us to remove a lot of tedious micromanagement from the game, preserving its depth.
This was a controversial decision, but I would like to clearly distinguish complexity from depth. The first forces the player to make decisions, while the second forces the player to make meaningful decisions (that is, creates pleasure). Personally, I think that I did very well with reducing complexity without reducing depth and most of the players agree with me.
Well, let's move on to the bad! Let's start with pre-planning.
Choosing an engine was the worst decision we have ever made. Playground SDK 5 is a two-dimensional engine designed for casual browser games like Diner Dash. It is not supported by developers, its source codes are not available and it can not even be downloaded anymore.
I hardly select expressions to describe it. It has several serious errors and lacks several key features that are considered standard in all other engines and we can’t fix them or add them without source codes. Almost everything that looks bad or poorly made in Xenonauts most likely has become so precisely because of the flaws of the engine.
The engine was chosen by the programmer who was the first (and very briefly) to work on the project. It was a terrible decision. If we were planning and prototyping correctly, we would quickly switch to a different engine, since the Playground SDK was simply not suitable for a game like Xenonauts. Instead, we chose a bad foundation and for the next five years we suffered, building a game on top of it.
The second major problem was the very poorly structured source code. The code itself was written by skilled programmers and was very, very decent, but we never had a single structure and common agreements - ground battles and the strategic part were written by completely different programmers, they were put together three years after the start of development.
This was a very big problem. Our programmers usually understood only their part of the code, so they could not fix errors in other areas of the game. The inaccessibility of a programmer meant a delay in fixing errors and hiring new programmers was much harder than in a normal situation. Because of this, it was almost impossible to speed up writing when, even when Kickstarter gave us money for it, and I am horrified about what would happen if one of the key coders left. All this could be fixed in two ways - firstly, I could hire a more skilled programmer to select the engine and plan the code structure. But such people are very much in demand and would hardly be interested in joining a small indie team without visible progress for demonstration and money, for the corresponding payment of their time.
We get a situation of eggs and chicken. The probability of success of the project increases sharply with proper technical planning, but the team gets access to it only after it is more or less settled down (that is, much later than the planning stage).
The second option comes down to the fact that I needed to conduct more thorough research - at least this prevented a catastrophe with the choice of engine. I could read more materials on this topic and decide on the choice of the engine, taking into account the views of the programmer, instead of completely relying on him. I did not do this because of my inexperience, but in the end I regretted it more than once.
(We could also abandon this engine at any time and start over on an engine like Unity. Turning back, this seems like a good idea. But as if the indie team didn’t complete any projects and start over on a new engine in the middle of development ? It would hardly have been well received and a negative public reaction could have killed the project. We decided to stay with a familiar evil.)
Ask any indie developer for advice on creating your first game and he will almost certainly smile and advise on something small. The reason is simple: you will make many mistakes. Having made a small game, you can quickly learn all the lessons learned and apply the knowledge in the second game.
Xenonaut is a rather big game, very few indie games have as much content as our ground battles alone. Everyone is advised to make a small game, but I made a huge one. Of course, this turned out to be a mistake.
A game of this magnitude requires a lot more money, ability and time. Its creation is much easier to fail, as many different things can go wrong.
The economy is also in question. Producing all this additional content takes time and money: Xenonauts has over a thousand research drawings, forty thousand earth tiles, twenty thousand text words and a million frames of animated animation. It is very difficult to imagine the amount of effort necessary for this before you really try to do it - but believe me, this is a very large amount of work.
The difficulty is that the acceptable price of the game does not increase - indie games cost $ 20-25, regardless of the amount of content. Thus, it is not very correct to add large amounts of content to the game beyond what is necessary to justify the price of $ 25.
Thus, the ratio of development costs and possible sales volumes at Xenonauts from the very beginning was not the best, like all X-COM games. Their doubtfulness from a business point of view was probably one of the reasons why it took so long to create an official remake of X-COM!
In any case, I had to listen to the developers who advised me to do something small as the first game - Xenonauts would be much more viable as the second game. I doubt that I would be able to scratch the preliminary planning like that if I had at least a little experience.
The remake of X-COM was a leap into the very depths of game development and now it seems very stupid. A half-finished game does not cost anything, so if I stumbled at any stage of development and I would have lost a lot of money (most of which belonged to other people), and my career as a game developer would end without having started.
This is a very serious and by and large unnecessary risk.
Xenonauts takes place in 1979, at the historical peak of the Cold War. I chose this setting for several reasons - it distinguished us from the setting for the near future in X-COM, the consciously mundane setting contrasted with exotic aliens, it was during this historical period that the aliens and their invasions were most feared.
I consider this a mistake. First of all, we did not use the setting: the distrust between the two superpowers is hardly mentioned, let alone the game mechanics. We chose an interesting period, after which we hardly used it.
But the biggest problem was “realism” - or its perception. If the action of your game takes place in a relatively modern time, you give the player a lot of recognizable objects. If their behavior diverges from the expectations of the player, they destroy the immersion in the game.
This contradicts the main goal of the game designer - to create a fun game. Differences between game design and reality are inevitable: for example, very few games forbid you to play after the death of your character.
The balance of the game process is more important than historical accuracy. In Xenonauts, Chinook is able to fly around the globe on one tank of fuel because players will be unhappy and will start complaining if they cannot respond to the appearance of aliens all over the map. This is not realistic, but improves the gaming experience. In X-Com, initially there are a lot of unrealistic moments that make the game better, like an artificially limited range of vision for game units that increases voltage. I could not change them without breaking the promise to recreate X-Com, and a realistic setting made them more obvious and led to fierce debate on the forums.
But when people made claims based only on realism, I was forced to ignore them - Xenonaut is a game, so the game process is more important than realism. I was pretty annoyed by people who snatched out individual details (like the speed of a particular aircraft too much) and insisted that they were ruining the game, while at the same time calmly accepting other, even less realistic mechanics or facts.
And although some people might be better aware of the irony of complaints about the lack of realism in the game about the alien invasion in 1979, I still made a fundamental mistake. We advertised the game as a "Strategic Planetary Defense Simulator" and weathered it in the style of harsh realism. All this gave rise to expectations of realism, which a game in the spirit of X-COM would never be able to meet.
It would be better if we used a setting of solid science fiction, based on the real world, but not limited to it. I strongly doubt that I will ever use a real-world setting in one of our future games - I really do not want to participate in all these disputes again!
Xenonauts was announced at the stage of a vague idea. Buyers gave money for their own ideas about what a modernized X-COM should be. Unfortunately, in the end they got my idea of what a modernized X-COM should be.
We could never satisfy everyone. Each had their own ideas about what parts of the X-COM formula should be changed and how exactly this should be done, very often these proposals were completely incompatible with each other.
Fortunately, most people have realized this fact and realized that Xenonauts will not completely match the images in their heads. They disputed certain points and design decisions, but agreed with our right to make some decisions with which they disagreed.
However, some people became extremely poisonous if we did not immediately accept their suggestions or made one single change that they did not like, regardless of how polite and detailed our explanation of such acts was. If the Xenonauts did not fully meet their expectations, they were very angry and claimed to have been robbed.
Although you’ll always meet a certain amount of angry people on the Internet, things could go much better if we started taking pre-orders later — a more complete product would give customers an opportunity to better understand if it is the game they would like to buy . Those who did not like the direction of the project could be screened out on their own.
The second difficulty with early pre-orders is a bit more subtle: people don't like change. Public development of the game can be difficult because players are usually angry if you remove something from the game - the human psyche does not perceive situations in which they first give you something, and then take it away. This can be a problem. A good example is translating the cost of gun shots from constant units of time to percentages of a soldier’s maximum units of time, preventing the situation in which experienced soldiers, in addition to increased accuracy, can fire more shots than beginners (i.e. returning to the system, used in the original X-COM) - it made them so strong that the end of the game was almost impossible to balance.
This change caused a real outburst of indignation in the community. The difficulty was that most people perceived the issue as players, not game designers - they had already played for several hours and enjoyed the capabilities of super-soldiers. It seemed to them that we were robbing them of toys.
The change was 100% true and 100% necessary, but if you are a community oriented developer, you cannot just ignore the community’s disagreement with your opinion. It took us several days to make a decision that would take several seconds without the intervention of the community.
Community participation in development gives huge advantages to any team, but in fact, it is better to engage the community after the completion of prototyping and the adoption of basic design decisions. Unfortunately, monetary reasons forced us from the very beginning to engage the community in the development of Xenonauts and conduct all experiments in plain sight.
Most of all, I regret the decisions related to the gameplay.
First of all, the “realistic” alien design was a mistake: almost all aliens in Xenonauts are humanoids of normal proportions in armor. The original X-COM had a much wider range of strange and amazing enemies - even standard sectoids had a tiny body with a large head that gave them a distinctly foreign look. Their images were much brighter than the enemies of Xenonauts.
It seems to me that this is partly due to the fact that I created enemies as if the game was a shooter - each had a lot of unique details visible near, but not one of them was visible on the small sprites of the strategic game. I had to focus on creating different silhouettes, not the details. I realized this around the middle of the development process, when it was too late to change anything.
I also regret that I made a flat globe. This solution has its own strengths, since a flat map shows what is happening much better than a three-dimensional globe from the original X-COM, but at the same time, the range of radars and flight routes do not take into account the curvature of the Earth - building a base in Antarctica was useful in X-COM but so pointless in Xenonauts that we just cleaned this continent. I'm a little ashamed of this.
The third mistake was UFO design. Their appearance is gorgeous and uniquely alien, but they are very poorly combined with the ground battle grid. The gray boxes of the original X-COM might look dull at times, but they could be assembled from separate tiles. This means that they fully supported destructibility and did not suffer from very unpleasant problems with visibility and passability.
The introduction of our UFO designs into the game took a huge amount of time and the results were mediocre at best. We had to completely abandon them and replace them with modular UFOs - they would be less attractive, but the gameplay would radically improve and the implementation would be much simpler.
If we did not develop Xenonauts publicly, then it would be practically guaranteed to do so - but our UFO designs were made at the very beginning of the development. I used them in all types of communication with the public for many years. They seemed to me too important an element of the game to change them in the late stages of development ... and yet I had to do it.
Another mistake was the scaling of the user interface - the font became almost unreadable on small screens. I did not pay attention to this when designing the interface (designed for 1080p screens) and received a lot of complaints. I could have prevented this problem if I had thought about it beforehand, but by the time I realized it, it was already too late to change anything.
And finally, the rhythm of the final part of the game was too slow - the game is somewhat delayed at the end. Passing the end of the game takes a whole day, which makes its balancing difficult (especially when busy with other things). Is this the biggest problem of the game? No, but I would still like to do it better.
Playing a variety of games, I always wondered how the developers could make such obvious mistakes - if they had my insight, the game would be perfect!
The reality was slightly different. What seemed quite simple from a comfortable chair turned out to be extremely difficult in practice and I made as many mistakes as those developers whom I used to continuously criticize.
But it all ended well - at the time of writing this text, Xenonauts total sales exceeded $ 1.2 million and the game has a very decent 80/100 rating on Metacritic. We definitely didn’t act in the most efficient way, but it seems to me that we have achieved a very good result for the first game.
Writing this article helped me put my own thoughts in order and I hope that its publication will equally shed light on why Xenonauts turned out to be so, and will help others better understand their own perspectives in indie development. Thank you for reading!
Chris England, Project Manager, Xenonauts.
Notes The
source code is in pdf format, which requires free registration on the Xenonauts forum to download, you can download it without registration from here .
Correct # 1: Remote Command
The team involved in Xenonauts almost entirely consisted of freelancers working remotely - for the entire time of development, almost two thousand people participated in it. Despite quite close relations with many of them, I saw five people live.
Our development process was very simple: I managed each team member directly using email. The team members practically did not contact each other - the two exceptions were the team of programmers and my colleague Aaron, who joined me full time after we moved to the office after a successful Kickstarter campaign (about three years after the start of development).
This is neither the usual nor the preferred method of developing computer games. Working in the same room with colleagues is not just pleasant, it gives a big increase in productivity and creative energy. Unfortunately, this is much more expensive - at the beginning of the development we could not afford even full-fledged freelancers from England, what can we say about a full-time office rental.
To give a general idea of our financial situation: I had accumulated approximately 25 thousand dollars when we started development in 2009. We started taking pre-orders in November 2010 and passed the mark of 1,000 copies in July 2011, which meant the availability of another 50,000 during the first two years of development (during this time, I not only worked on Xenonauts for free, but also injected money from my salaries).
We had no options other than using remote freelancers - it’s much easier to find affordable talent if you can search all over the globe. A huge amount of content in Xenonauts would cost millions of dollars at the prices of AAA-studios, but we were able to do all this for a small fraction of this amount. That is why the development of Xenonauts took five years. Cheap and gifted freelancers come across infrequently, their search takes a lot of time, looking for a needle in a haystack must be ready to sort out a lot of hay. We spent a lot of time on people who ended up being unreliable or unable to do what we needed.
After the team was assembled, we had to coordinate its work taking into account different time zones and working hours - a painful and ineffective experience. Most of the team worked part-time, which immediately limited the time that they could spend on the project. Everything took much longer than if we worked full time in the same office.
But despite all the difficulties and disappointments, it was thanks to the successful management of the remote team that we were able to make Xenonauts. We simply did not have money to create a project of this scale in any other way. This was an inevitable evil that allowed us to make development cheaper than most ordinary games.
Correct No. 2: Fidelity to X-COM
Created 20 years ago, UFO: Enemy Unknown is still considered one of the best games of all time. A close connection with it has given us many advantages. The most obvious were pre-orders and press coverage. A huge number of XCOM fans meant having an existing audience ready to pay for pre-orders, part of which were journalists who were ready to write about the game.
It also made us more reliable in the eyes of the players and gave us a common language for communicating with the community in the early stages. Pre-order buyers could easily perceive the primitive versions and see a great future behind them, as they already knew what the missing content should look like. All this would not have happened if the original strategic game were created.
Even after Xenonauts became more famous in itself, the name X-COM remained a key feature of the game. People accidentally stumbled upon us on the Internet (for example, a lot of visitors to our site came from the X-COM page on Wikipedia) or read reviews that would simply be ignored without the word X-COM in the header.
It was also very useful for game design. There were a lot of elegant and well-documented game mechanics in the original game that I used as a starting point for my own game systems. I reworked almost everything, but the ability to see how they acted in certain situations in the original game greatly facilitated the development process.
In addition, there were two official remakes. The first one was The Bureau: X-Com Declassified shooter. For us, it was just a gift of fate - the protest against the X-Com reboot attracted a lot of attention to us and helped create the Xenonauts community.
XCOM: Enemy Unknown from Firaxis was a real monster - with its incredible success among buyers and critics. Frankly, I went through it at Classic Iron Man and got a lot of pleasure. Despite some flaws, the game really deserved all the praise it received from the press. She influenced us from two sides. The first was positive: the game attracted attention to the X-Com franchise and the genre as a whole. Usually, during the weekend we earned $ 350 on pre-orders, but this weekend we received 30,000 X-COM announcements - enough to finance the development for two additional months.
The problems with X-COM were more subtle: two projects were opposed to each other. Some members of our community really did not like the “stupid” remake and any attempt to simplify the mechanics of the original game caused a lot of accusations that we were doing the same. This is not very useful when you are trying to upgrade a game twenty years ago!
But looking back, positioning Xenonauts was one of the wisest decisions - it was priceless insurance that minimized the risk of wrecking game design / marketing and allowed us to focus on creating the game.
Right # 3: Community
I cannot write an article about the success of Xenonauts without mentioning our community. We sold 30 thousand copies before the release of the game and our forums generated more than one hundred thousand messages over the past two years. We simply could not have made Xenonauts without all the money and feedback the community has given us.
Individuals often provided a lot of help in development. Here are some examples that I remembered well:
- A corporate lawyer helped us create a legal entity in the USA and open an account for our Kickstarter (otherwise we would have to use IndieGoGo);
- One of the members of the community hosts and administers our sites;
- Someone made translations possible, somehow finding a long-lost program that makes it possible to add new fonts to the engine;
- The design of the user interface of air battles was originally invented on the forums;
- The mods and maps created by the community were often so good that we added them to the official version of the game.
There were too many such people to mention all of them, but even the simplest actions, such as voiced opinions or error messages, helped to develop the game. The collective contribution of everyone who did something like this was simply huge.
An endless stream of reviews allowed us to gradually eliminate various shortcomings. Although Xenonauts is far from perfect, I’m scared to think how much worse they would be without the million hours of public alpha / beta testing taken into account on Steam before the release of the game.
It was also extremely useful because we did not have money for full testing within the team. The huge variety of the game meant that it was difficult to even imagine all the possible actions of the players, not to mention testing them. Similarly, without the help of the community, it would be virtually impossible to test a large number of different configurations of iron!
Our community was especially valuable during the time of Kickstarter. First, we presented the inventions we invented to them and were extremely surprised by very negative reviews. By reviewing them before launching the company, we avoided potential problems with low-quality awards. In addition, they provided a very important impetus. We collected 10,000 from our goal of 50,000 in a few hours (that is, before the press informed the players who are not members of our community about this) and it seems to me that we have reached half our goal of 50,000 in one day. This gave us a reputation that attracted non-community people and ultimately helped to raise 150,000. I also enjoyed the process of communicating with the community in our forums. I tried to treat the forum participants with respect and (usually) answered me the same. The discussions were usually polite, useful and constructive and in many cases led to an improvement in the game. So if you were a member of our community, thanks - you were great!
Correct number 4: I did not quit
I didn’t quit my job until October 2011, when the game was almost half completed. Although this decision does not affect future projects, it still remains one of the most important.
I did not exaggerate when I said that it took ten times more time and twenty times more money to develop than I had originally expected. In the beginning I knew very little about the development of computer games (although I myself thought differently) and the project brought serious financial losses during the first years. If I made a living by developing video games, I would turn into a homeless person.
Spending all your free time in the evenings and weekends, ending the month with less money than at the beginning, is certainly very depressing, but if you continue to get paid, then you are not afraid of anything worse than despondency. My salary covered my daily expenses until the Xenonauts began to support themselves ... and in the end they were able to provide for me. Anyone who quits their job to create something new will immediately be pressured by the need to quickly succeed. His business not only needs to become profitable quickly, profits must become large enough to last for a living. This can be extremely destructive - not only in terms of stress, but also in terms of encouraging short-term thinking.
The reality of effective work in two jobs during the first half of development was not particularly attractive. It cost me a number of relationships, friends, and too much sleep, but it gave me the time needed to succeed with Xenonauts.
Saving work for these few years allowed me to quit it forever. If I quit right away, then in a year I would spend all my savings and be forced to return with shattered dreams.
I just can’t find the words to explain how important it is not to rely on game development as the main source of income, until it really is justified from a monetary point of view.
Correct No. 5: game design
Xenonauts took shape through thousands and thousands of individual solutions. I made a lot of mistakes (about them in the corresponding section), but there were also correct decisions.
The first was the introduction of the personality of the Chief Scientist in research reports. The idea was as follows: add at least one memorable character to the game and instead of telling facts, tell in texts about research about the organization’s daily life.
For a very long time it seemed to me that this was a mistake - bad texts very much destroy the immersion and they are very easy to do wrong. It also took a huge amount of time: I wrote almost 30,000 words for research reports and rewrote them at least three times. It took VERY MUCH time. Therefore, I was very pleased with the good reviews about the texts. It seems to me that the Chief Scientist adds a lot of personal (and a bit of humor) to the game, where, with a different development of events, such things would simply be absent, I’m just glad to know that I have at least some writing skills!
The first-person user interface was also a great success. I used it to create an illusion of the world around the game, allowing the player to literally walk around the base and personally see his organization. The technologies used by artists gradually change it as the game progresses, giving the impression of the impact of your actions on the big world. It seems to me much more impressive than our old spreadsheet-style user interface.
I am also proud of the events on the globe generated by UFO activity. The original X-COM seemed a bit empty in places: you were the only organization fighting aliens, there were no signs of a global conflict raging around you. Events on the global map helped fill the void and made the world more realistic.
AI-driven local troops suddenly created a similar effect in ground battles - players simply fell in love with them. They created a lot of cool moments, about 90% of the stories on the forums included local troops saving the helpless xenonaut. I was somewhat surprised by their popularity, but they definitely turned out to be a good addition to the game. The last good solution was to simplify the game, especially the economy - an unlimited number of initial equipment and ammunition, automatic upgrade of weapons on aircraft and other equipment, and the like. It seems to me that this allowed us to remove a lot of tedious micromanagement from the game, preserving its depth.
This was a controversial decision, but I would like to clearly distinguish complexity from depth. The first forces the player to make decisions, while the second forces the player to make meaningful decisions (that is, creates pleasure). Personally, I think that I did very well with reducing complexity without reducing depth and most of the players agree with me.
Incorrect No. 1: (insufficient) preliminary planning
Well, let's move on to the bad! Let's start with pre-planning.
Choosing an engine was the worst decision we have ever made. Playground SDK 5 is a two-dimensional engine designed for casual browser games like Diner Dash. It is not supported by developers, its source codes are not available and it can not even be downloaded anymore.
I hardly select expressions to describe it. It has several serious errors and lacks several key features that are considered standard in all other engines and we can’t fix them or add them without source codes. Almost everything that looks bad or poorly made in Xenonauts most likely has become so precisely because of the flaws of the engine.
The engine was chosen by the programmer who was the first (and very briefly) to work on the project. It was a terrible decision. If we were planning and prototyping correctly, we would quickly switch to a different engine, since the Playground SDK was simply not suitable for a game like Xenonauts. Instead, we chose a bad foundation and for the next five years we suffered, building a game on top of it.
The second major problem was the very poorly structured source code. The code itself was written by skilled programmers and was very, very decent, but we never had a single structure and common agreements - ground battles and the strategic part were written by completely different programmers, they were put together three years after the start of development.
This was a very big problem. Our programmers usually understood only their part of the code, so they could not fix errors in other areas of the game. The inaccessibility of a programmer meant a delay in fixing errors and hiring new programmers was much harder than in a normal situation. Because of this, it was almost impossible to speed up writing when, even when Kickstarter gave us money for it, and I am horrified about what would happen if one of the key coders left. All this could be fixed in two ways - firstly, I could hire a more skilled programmer to select the engine and plan the code structure. But such people are very much in demand and would hardly be interested in joining a small indie team without visible progress for demonstration and money, for the corresponding payment of their time.
We get a situation of eggs and chicken. The probability of success of the project increases sharply with proper technical planning, but the team gets access to it only after it is more or less settled down (that is, much later than the planning stage).
The second option comes down to the fact that I needed to conduct more thorough research - at least this prevented a catastrophe with the choice of engine. I could read more materials on this topic and decide on the choice of the engine, taking into account the views of the programmer, instead of completely relying on him. I did not do this because of my inexperience, but in the end I regretted it more than once.
(We could also abandon this engine at any time and start over on an engine like Unity. Turning back, this seems like a good idea. But as if the indie team didn’t complete any projects and start over on a new engine in the middle of development ? It would hardly have been well received and a negative public reaction could have killed the project. We decided to stay with a familiar evil.)
Wrong No. 2: scale
Ask any indie developer for advice on creating your first game and he will almost certainly smile and advise on something small. The reason is simple: you will make many mistakes. Having made a small game, you can quickly learn all the lessons learned and apply the knowledge in the second game.
Xenonaut is a rather big game, very few indie games have as much content as our ground battles alone. Everyone is advised to make a small game, but I made a huge one. Of course, this turned out to be a mistake.
A game of this magnitude requires a lot more money, ability and time. Its creation is much easier to fail, as many different things can go wrong.
The economy is also in question. Producing all this additional content takes time and money: Xenonauts has over a thousand research drawings, forty thousand earth tiles, twenty thousand text words and a million frames of animated animation. It is very difficult to imagine the amount of effort necessary for this before you really try to do it - but believe me, this is a very large amount of work.
The difficulty is that the acceptable price of the game does not increase - indie games cost $ 20-25, regardless of the amount of content. Thus, it is not very correct to add large amounts of content to the game beyond what is necessary to justify the price of $ 25.
Thus, the ratio of development costs and possible sales volumes at Xenonauts from the very beginning was not the best, like all X-COM games. Their doubtfulness from a business point of view was probably one of the reasons why it took so long to create an official remake of X-COM!
In any case, I had to listen to the developers who advised me to do something small as the first game - Xenonauts would be much more viable as the second game. I doubt that I would be able to scratch the preliminary planning like that if I had at least a little experience.
The remake of X-COM was a leap into the very depths of game development and now it seems very stupid. A half-finished game does not cost anything, so if I stumbled at any stage of development and I would have lost a lot of money (most of which belonged to other people), and my career as a game developer would end without having started.
This is a very serious and by and large unnecessary risk.
Wrong # 3: Realistic Cold War Setting
Xenonauts takes place in 1979, at the historical peak of the Cold War. I chose this setting for several reasons - it distinguished us from the setting for the near future in X-COM, the consciously mundane setting contrasted with exotic aliens, it was during this historical period that the aliens and their invasions were most feared.
I consider this a mistake. First of all, we did not use the setting: the distrust between the two superpowers is hardly mentioned, let alone the game mechanics. We chose an interesting period, after which we hardly used it.
But the biggest problem was “realism” - or its perception. If the action of your game takes place in a relatively modern time, you give the player a lot of recognizable objects. If their behavior diverges from the expectations of the player, they destroy the immersion in the game.
This contradicts the main goal of the game designer - to create a fun game. Differences between game design and reality are inevitable: for example, very few games forbid you to play after the death of your character.
The balance of the game process is more important than historical accuracy. In Xenonauts, Chinook is able to fly around the globe on one tank of fuel because players will be unhappy and will start complaining if they cannot respond to the appearance of aliens all over the map. This is not realistic, but improves the gaming experience. In X-Com, initially there are a lot of unrealistic moments that make the game better, like an artificially limited range of vision for game units that increases voltage. I could not change them without breaking the promise to recreate X-Com, and a realistic setting made them more obvious and led to fierce debate on the forums.
But when people made claims based only on realism, I was forced to ignore them - Xenonaut is a game, so the game process is more important than realism. I was pretty annoyed by people who snatched out individual details (like the speed of a particular aircraft too much) and insisted that they were ruining the game, while at the same time calmly accepting other, even less realistic mechanics or facts.
And although some people might be better aware of the irony of complaints about the lack of realism in the game about the alien invasion in 1979, I still made a fundamental mistake. We advertised the game as a "Strategic Planetary Defense Simulator" and weathered it in the style of harsh realism. All this gave rise to expectations of realism, which a game in the spirit of X-COM would never be able to meet.
It would be better if we used a setting of solid science fiction, based on the real world, but not limited to it. I strongly doubt that I will ever use a real-world setting in one of our future games - I really do not want to participate in all these disputes again!
Wrong # 4: Early Pre-Orders
Xenonauts was announced at the stage of a vague idea. Buyers gave money for their own ideas about what a modernized X-COM should be. Unfortunately, in the end they got my idea of what a modernized X-COM should be.
We could never satisfy everyone. Each had their own ideas about what parts of the X-COM formula should be changed and how exactly this should be done, very often these proposals were completely incompatible with each other.
Fortunately, most people have realized this fact and realized that Xenonauts will not completely match the images in their heads. They disputed certain points and design decisions, but agreed with our right to make some decisions with which they disagreed.
However, some people became extremely poisonous if we did not immediately accept their suggestions or made one single change that they did not like, regardless of how polite and detailed our explanation of such acts was. If the Xenonauts did not fully meet their expectations, they were very angry and claimed to have been robbed.
Although you’ll always meet a certain amount of angry people on the Internet, things could go much better if we started taking pre-orders later — a more complete product would give customers an opportunity to better understand if it is the game they would like to buy . Those who did not like the direction of the project could be screened out on their own.
The second difficulty with early pre-orders is a bit more subtle: people don't like change. Public development of the game can be difficult because players are usually angry if you remove something from the game - the human psyche does not perceive situations in which they first give you something, and then take it away. This can be a problem. A good example is translating the cost of gun shots from constant units of time to percentages of a soldier’s maximum units of time, preventing the situation in which experienced soldiers, in addition to increased accuracy, can fire more shots than beginners (i.e. returning to the system, used in the original X-COM) - it made them so strong that the end of the game was almost impossible to balance.
This change caused a real outburst of indignation in the community. The difficulty was that most people perceived the issue as players, not game designers - they had already played for several hours and enjoyed the capabilities of super-soldiers. It seemed to them that we were robbing them of toys.
The change was 100% true and 100% necessary, but if you are a community oriented developer, you cannot just ignore the community’s disagreement with your opinion. It took us several days to make a decision that would take several seconds without the intervention of the community.
Community participation in development gives huge advantages to any team, but in fact, it is better to engage the community after the completion of prototyping and the adoption of basic design decisions. Unfortunately, monetary reasons forced us from the very beginning to engage the community in the development of Xenonauts and conduct all experiments in plain sight.
Wrong No. 5: gameplay
Most of all, I regret the decisions related to the gameplay.
First of all, the “realistic” alien design was a mistake: almost all aliens in Xenonauts are humanoids of normal proportions in armor. The original X-COM had a much wider range of strange and amazing enemies - even standard sectoids had a tiny body with a large head that gave them a distinctly foreign look. Their images were much brighter than the enemies of Xenonauts.
It seems to me that this is partly due to the fact that I created enemies as if the game was a shooter - each had a lot of unique details visible near, but not one of them was visible on the small sprites of the strategic game. I had to focus on creating different silhouettes, not the details. I realized this around the middle of the development process, when it was too late to change anything.
I also regret that I made a flat globe. This solution has its own strengths, since a flat map shows what is happening much better than a three-dimensional globe from the original X-COM, but at the same time, the range of radars and flight routes do not take into account the curvature of the Earth - building a base in Antarctica was useful in X-COM but so pointless in Xenonauts that we just cleaned this continent. I'm a little ashamed of this.
The third mistake was UFO design. Their appearance is gorgeous and uniquely alien, but they are very poorly combined with the ground battle grid. The gray boxes of the original X-COM might look dull at times, but they could be assembled from separate tiles. This means that they fully supported destructibility and did not suffer from very unpleasant problems with visibility and passability.
The introduction of our UFO designs into the game took a huge amount of time and the results were mediocre at best. We had to completely abandon them and replace them with modular UFOs - they would be less attractive, but the gameplay would radically improve and the implementation would be much simpler.
If we did not develop Xenonauts publicly, then it would be practically guaranteed to do so - but our UFO designs were made at the very beginning of the development. I used them in all types of communication with the public for many years. They seemed to me too important an element of the game to change them in the late stages of development ... and yet I had to do it.
Another mistake was the scaling of the user interface - the font became almost unreadable on small screens. I did not pay attention to this when designing the interface (designed for 1080p screens) and received a lot of complaints. I could have prevented this problem if I had thought about it beforehand, but by the time I realized it, it was already too late to change anything.
And finally, the rhythm of the final part of the game was too slow - the game is somewhat delayed at the end. Passing the end of the game takes a whole day, which makes its balancing difficult (especially when busy with other things). Is this the biggest problem of the game? No, but I would still like to do it better.
Conclusion
Playing a variety of games, I always wondered how the developers could make such obvious mistakes - if they had my insight, the game would be perfect!
The reality was slightly different. What seemed quite simple from a comfortable chair turned out to be extremely difficult in practice and I made as many mistakes as those developers whom I used to continuously criticize.
But it all ended well - at the time of writing this text, Xenonauts total sales exceeded $ 1.2 million and the game has a very decent 80/100 rating on Metacritic. We definitely didn’t act in the most efficient way, but it seems to me that we have achieved a very good result for the first game.
Writing this article helped me put my own thoughts in order and I hope that its publication will equally shed light on why Xenonauts turned out to be so, and will help others better understand their own perspectives in indie development. Thank you for reading!
Chris England, Project Manager, Xenonauts.
Notes The
source code is in pdf format, which requires free registration on the Xenonauts forum to download, you can download it without registration from here .