Bitgap Games' Xenocell

I've made a promise to take some time and show you our game, Xenocell. We are currently in a closed beta and should soon be opening up to the public. We have a group on Facebook - feel free to join to get the latest info about the game, such as the soon to be announced beta download.

The plot

Xenocell is a massively multiplayer sci-fi game. It is however not very much like other MMOs out there. Well, I know what that sounds like, but I mean it. :)

In Xenocell, the player takes the role of a spaceship crash survivor on an alien planet. Through gameplay and rewards players are encouraged to form clans - but we also reward true, solo play.

Clans are fighting for resources on the planet Ibelis, that used to be the home of an already extinct alien civilization. The remains of that era are still spread all over the planet offering one way for clans to find unique raw materials and advanced technology.

This long lost race had left warp gates all over the planet leading to all kinds of places. Some are especially rich in raw materials, others hide salvagable machines and buildings, and others again lead to flora and faune with exceptional qualities.

Raw materials can be mined and refined to create weapons, armor, vehicles, turrets and buildings. Salvagable materials help the clan make research breakthroughs that unlock new blueprints to create hybrid technology. Finally, DNA extracted from the local wildlife will enhance the qualities of the player.

The technology

Back in early 2008 we've chosen Torque because of its unparalleled networking layer. Since then the graphics also grew up to our expectations with the release of Torque 3D, so we are still very happy about our choice. For this specific project, we have not found another engine that could do this better. At this price, we don't even bother looking.

Well, I'm not saying I didn't have my moments of pain. We all know that Torque's learning curve is steep, and that resulted in many misconceptions about the engine in the past. However, Torque has taught me an immense amount about games and programming in the past few years.

So yes, I am very happy to have started with Torque. That choice itself now ensures that our game is independent of every tool and every person other than our own studio. I think this is a huge plus and the whole concept of its license grabs the meaning of "Indie" perfectly.

The means

At first we went for the story driven approach. We wanted to craft many levels and zones, create a world and a lore from scratch and populate it with living breathing characters. Naralos Udal, our writer did an amazing job at turning an initial idea into a living world. Heck, I even know irrelevant things like how the respiratory organs of some of the alien species work.

After a while, I questioned my ability to be able to have this game compete with other games - even AAA class monsters - out there. I needed something to make me feel more convenient about how the game will be special, always changing and different from other MMOs.

There was also the issue of not being able to add as much content as we wanted to, simply because we couldn't afford neither the time nor the resources to make that happen.

So we made it all procedural instead.

Art

As most of the studios here, we also had at least one department we were seriously lacking. We had no artists. So, we started to gather all we could from content packs. Later on, as the prototype got more solid, my investor agreed to outsource work that we needed to get done.

Some art we received as a friendly gesture or in exchange for code from such artists as Apparatus and Maxim Lyulyukin. We can thank these guys the most important base models in the game.

Some art we paid for and not received at all. We had our fair number of PR failures until we managed to work well with contractors. This is something that needs experience, and I didn't have much. It is a lesson learned.

Some other art we did ourselves. I and our other programmer, Tamas Rehorovszky, spent some time geting ourselves familiar with the basics of art. Granted, we never really advanced on from Milkshape, but that still did the trick in most cases when we needed models merged and names changed. Where it didn't we hired people, such as Kevin Turchik, whose work is nothing short of phenomenal. I highly recommend him to anyone looking for a very experienced texture artist. He really is great to work with, and I'm not just saying that. He's still busy now, so don't nag him just yet. :)

Another very talented artist we managed to work with is Steve Finney, the guy behind Arteria3D.Com. He created many of our vehicles, some of which are available on his website, and more of which were specifically created for our game exclusively. I love his work most on the futuristic buildings and alien structures, it really adds a unique mood to the game when being around these.

As for the GUI - that was done by me. I worked much on web applications in the past, so I did pickl up some limited graphic design skills myself. I spent a little time perfecting those skills, in order to save some money there. I'm satisfied with the results, although there's plenty of room for advancement as well. (Have you seen our own Sven Bergström's ui portfolio yet? There's some nice programmer art there. :) To me, having his skills sounds like a nice goal to achieve.)

Voice acting

I really wanted the game to have a hero, who the player controls, but who also has his own thoughts and remarks about what is happening in the game. At first my initial thought was to have an AI in the player's suit that is equipped with a personality - each suit comes with a personality and an array of remarks that the suit would make while you play. Unfortunately our budget would not allow for this yet, so we ended up hiring only one voice talent for the male hero. He did such an amazing job, that we thought it would be the best if we had him do many of the NPC voices as well. That guy is Keith Murphy. I wholeheartedly recommend him. He is a new professional, has a drama background and is incredibly good at telling a story simply by chosing the right tone, accent and rythm. You can find a voice acting demo he made in a hurry at the bottom of the page the link leads to.

SFX

This was mainly done by me using game sample libraries I either had as an ex- game composer and sfx engineer, or sounds from soundsnap.com where we could pay a flat fee and get the sounds we needed for a year. That was a very good bargain as it turned out.

Some other sfx are still in development. My brother, Peter has aspirations to work in the audio department for games, so I thought it was a nice opportunity for us to work together. He's responsible for some of the vehicle sounds that appear in the game. The interesting bit is that since we use FMOD Designer projects for complex sound behavior modeling - such as the sound of a vehicle - one simple vehicle sound consists of 20 carefully planned looping mono sounds. I would not have the patience for that anymore, but he's still in his early 20s, so I capitalize on that. :)

..and the Score

Finally, the guys behind music: Jonathan Chio, Aaron Blackmar and Mike Bohn - known as Euphoria Mornings. Click the link to read an interview with them on the Xenocell score. They did such a great job, that our beta testers came back with comments like "Epic." and "Reminds me of Rainbow Six". I couldn't agree more. Music was an itch to scratch for me, as I first got into this industry as a composer. I really wanted to work on the soundtrack, but I was not allowed to. Literally. That was a clause in our contract with the investor, as he was worried that my coding would suffer from the time I spent on composing music. He was right. Fortunately these guys created a score that I couldn't be happier with.

Procedural is the way to go

I believe that procedural content generation is a double edged sword. It's easy to cut yourself with it if you are careless. On the other hand, it can make you play your own game after three years of development, which I think says a little about its powers to ignite addiction.

So I liked the idea of creating a world that I can explore without knowing what I'd find out there.

At first we divided the planet up into 5 basic ecosystems. These are groups of terrain types, models and sounds to give the player the best possible illusion in each zone - or mission/level. We also started working on several content generators.

The gameplay has clans fighting to control resource zones that will continuously supply the clan with raw materials. When materials are ready to be "harvested" - when all local containers are full - clan members will need to go and take the raw materials to the home zone back to their base using vehicles. Since the ancient alien technology employed a visible beacon to warn harvesters of full containers, when these containers become full, all other clans learn the location of the zone - and are able to hack the warp gate and attack the zone at this time. So emptying the containers is very important, and usually requires a small army of a few squads.

Procedural generation has an advantage - it is unpredictable. I wanted the zone keepers to be fighting on familiar ground while I wanted to make attackers have to explore the area and find the buildings and machinery to capture before they could capture the zone. So capturing a zone is a series of quests - but so is maintaining a zone. Procedural generation became a serious fun factor. You never knowhow to get from the warp gate to the resource silos or other objects, and you never know what else is waiting you there. It could be an artifact or it could be a titanic creature defending its breeding grounds. Or it could be an enemy clan, prepared.

Since gameplay dictates features, we had to present alternate ways to attack and take over a zone. Clans have bases, where each base has floors and rooms. As the clan progresses with its research, new rooms open up, new NPCs become availoable for hire to populate the base and so the base slowly expands.

I figured that players needed a central home city, but it also got me worried about the technical difficulties this would present with a high number of players. So, clan bases became the de facto "capitals" in the game - where you buy and sell stuff and do the more complex crafting. This is one place where you can respawn and - turning back to my original point - this is where your clan stores access keys to all the zones you control.

So, in theory it is possible for a group to enter the home zone of another clan through hacking the warp gate in a series of quests, entering the underground base, finding the room with the access keys, hacking the computer that stores them and finally getting home alive with the data storage intact. There are many things that can go wrong in such a plan. But in theory, it could work.

Since players are able to place persistent turrets in their base zone, or alarm systems that email members on a breach and defenders can zone home from anywhere in a matter of seconds, these can indeed make life harder for intruders, this feat requires careful planning and knowing the target very well. It is also immense fun. I hope to make it very hard to win such an attack, to not make the defender lose anything but one zone and to primarily make it fun full of vehicles shooting vehicles at high speeds and fighting in corridors with laser guns, robot allies and psi powers.

So another aspect of procedural generation is introduced when player bases are made. When you create a clan, a base zone is created for you. You click on the map where you'd like to build your base, and based on the map pixel color and coordinates, your base is generated with the right ecosystem and parameters - and a home base.

Players will need to become familiar with the zone and the base of course. It will take some time until landscape features, turret towers and walls can be exploited to have the best possible effect on the defense of your zone. But the same goes for the base as well.

When initially entering the base, you will find closed doors and rooms and sealed floors. Exploring your own base will be a blast in itself. Meeting the unique NPCs that are a part of your clan even more so. But the best part will be unlocking areas that present you with the really cool stuff, such as a garage to craft heavy armored vehicles, or a bridge once your base becomes an airship - a huge airborn vehicle that can travel to any of your own zones and makes invasion a lot harder to accomplish.

Zone generation tech rant

The way we generate zones is almost out of the box. Not many Torque 3D Pro devs realize that terrImport.cpp still has the neccessary functions to generate simple terrain geometry. This was our starting point. We generate a terrain with a single traversable area by clamping terrain below a given height and then clamping again to create water beds. Then we use Djkstra's algorythm for finding long enough shortest paths to have the warp gate and the resource silos or base entrance be far away enough from each other. We look for optimal positions for mob generators, crafting resource spawners, titan bosses and the like. Using AI - path finding - is an excellent way to come up with an enjoyable and playable map.

We then populate the zone depending on the ecosystem. This includes procedurally placing trees, props, quest objects and buildings around the map. And of course cliffs. Xenocell makes extensive use of the cliff shapes from our Cliff Construction Kit and Sahara, which makes our maps more believable and visually appealing.

Planning ahead on the server side

I tend to be optimistic and objective - but I also have the advantage of experience. Having already created a massively multiplayer game - albeit a browser based one, I can be one step ahead of possible problems. Some things don't change, regardless of the medium. Marketing, usage spikes and managing 50k users are problems that not many independent developers care to prepare for during development.

I believe that we will have tens of thousands of players playing this game in a relatively short time, so it is a good time to pay attention to what will happen then.

We've decided to host the game in the Amazon cloud, where we are able to start and stop server instances as needed. We've got ourselves covered with a game specific load balancer that takes care of routing players to the optimal server with an emphasis on having as little unneeded CPU use as neccessary (for example to quickly start up a new zone). This will take care of my most dreaded problem: a usage spike.

Back in 2002 I think we had PC Gamer UK write a very short article about our game, which resulted in a huge number of people rushing our site in a matter of days. Popularity doesn't always feel good, and it can do more damage than you'd think. So this time, I make sure that we will be able to scale up to millions of people if the need arises. Of course we'll continously need to adopt to some degree. Especially with the 3rd party tools we use, such as the database solution and the steps we take to optimize data retrieval, but we have a firm ground to build upon.

We also have separated base generation from the client entirely. When you as a player enter a new zone, the zone files are then downloaded to your computer and cached. It would be a waste of resources and a serious limitation to store pregenerated bases. So whenever a new zone is created, our download server receives a copy of the entire zone which then propagates the data to clients as needed. Since servers also make use of this cache, this is another way that neutralizes a negative aspect of procedural generation. It takes valuable seconds to generate a zone, afterall.

Beta testing

We started beta testing on the 23rd of September after a series of problems with being unable to package the game with encrypted game files. (It used to work, I swear. Just not when it had to.) It took a week to track the problem down to a faulty 3rd party middleware which we had to dump and find a new solution. But on the 23rd it went online and the first players were able to check out what it looked like. They didn't see much. Why?

Our very own Eric Preisz published an interesting article on Gamasutra about usability analysis: Usability Breakthroughs: Four Techniques To Improve Your Game. Driven partially by this and our limited possibilities, I came up with an unorthodox way to test the game.

We split the features of the entire game into Focuses. Focuses are periods during which only a limited set of features are turned on in the game. The following focus will add a few more features, and we don't advance to the next focus until all problems are fixed from the previous one.

So Focus 1 has to do with server and client stability, data communication, perfecting bug reporting options and other pretty basic stuff. The second focus introduced another test zone so we could test warp gates transmitting players between zones, some performance optimizations, the tactical map and - mostly - bug fixes for Focus 1.

We are about to go on with Focus 3, which will again introduce a new set of features. Some are big, such as player bases. Others are small, such as terrain material dependent vehicle tire grip. (Don't drive onto ice!) As you see, the beta test is not yet about playing the game, but we are getting there. With Focus 3 I am making the beta public. We had over 50 people helping us with testing the game. I hope that more people will be interested in giving it a try. Focus 3 enables in-game registration and character creation, so if you are interested, be sure to look out for news on the Xenocell website or join the Facebook group to receive news of when the new version is out and available for download. Each focus from now on will be more and more fun to play.

Closure

Thanks for reading through. This was a very long post, so I really mean it. :) Let me know what you think about the game, and if you have any questions, I'll be happy to discuss them in this thread.

There were many people who helped us develop this game so far. I might have missed a few names unintentionally. If I did, please let me know, so I can fix that.


@konradkiss
KonradKiss @ GitHub
konradkiss.com