When we released the original Sanctum back in 2010 we didn’t know much about game development or digital platforms. We didn’t have any money and had to release the game to get some cash flow. We were very excited when we saw that people actually liked our game and we were extremely happy to be among the top 10 selling Steam games at that moment. Then the summer sale came, and we went soaring to #1 on Steam. We were totally blown away and danced and cheered as we realized we could continue making games!

We released a lot of patches for Sanctum. We included free maps, introduced 4-player coop and a lot more. We still had so many ideas for the game, but many of them were too big for Sanctum, so we decided to make a follow-up.

We wanted to take everything we liked with Sanctum and expand upon that. Instead of just releasing the game with a few changes and new content we decided to rebuild the game from scratch. Because we were, and still are, hungry developers eager to learn new things and always moving forward. And since we were our own, we had it in our power to do whatever we wanted. We also felt that we had a truly indie-hit potential since we had sold so many copies of the original game, that we wanted to make the leap to consoles. After all the engine supported it, so how hard could it be?
 

We set up a few internal goals with Sanctum 2. These were:

We tried to summarize our core vision of the game and came up with “deep strategy and intense action”.

Concept for two of the main characters

What went right

1. Planning for change and diversification

The first couple of months we made some prototypes. We wanted to prototype everything before it was actually put into the game. We started with the mazing. In Sanctum, we had grids where you could build. If you could build or not depended on resources and if you blocked the maze or not. If you could build, you got a blue hologram, if it was red, you couldn’t. Quite simple.

Early prototype of the free mazing system

Since free mazing was one of our big new features, we put a lot of time into this system. But with every step forward we took we encountered new flaws with the system. What we wanted was that the player could decide start- and end points of a wall. Without going into detail how much effort we put into this, we scrapped the system and started over half a year into development time. We realized the system we had in Sanctum was good enough so we continued with that. Being able to cope with changes like this was a huge success and we managed to deliver the best game possible because of it. It’s possible that some of these problems could have been highlighted if we had done more research around the subject, but there is no better way to test a system than to actually test it.

Late version of the free mazing system

Code-wise we were able to design systems that made it easy to come up and design new features as well. We realized from the beginning that we wanted many and diversified abilities, perks, towers, weapons etc. That is why we spent a lot of time writing and rewriting systems for these things, so it would be easy for us to implementing them. We also knew from our first game that having specific people on specific tasks could be very frustrating if they were sick or on vacation. So what we did was always being two programmers for every major implementation feature, as well as rotating work between us. Later in the project we were forced to abandon this idea due to time constraints, but it worked really well in the beginning and there was always someone at work who knew how a specific system worked.

2. External TCR/TRC testing

We had heard about these requirements that consoles put on their games, but we could never imagine them being so hard to fulfill as they were. We allocated a couple of days for us programmers to test all the requirements. We thought that we could test them, fix what went wrong within a couple of weeks and be done with them. We had obviously read through all of them before we started the development so we knew from the start how we should design our game and UI.

We couldn’t have been more wrong. After the first day of TCR/TRC testing we had only gotten through a handful of them and realized just how big the task laid before us was. Luckily we got in touch with a testing-company that were available in a short notice and got them to test it. We had a huge list of failures reported to us which we never saw coming. Luckily we could focus all our staff fixing these failures instead of finding them ourselves.

3. Focusing on what we were good at

Since we could do pretty much whatever we wanted with Sanctum 2, we had a lot of crazy ideas. One of them was to add a loot system where enemies would drop items, and stat points to give an RPG touch to the game. We decided to go far enough and implement this as a prototype in the game (with cats as placeholders for loot). However, even if this sounded great in theory, it brought along many design issues. With stat points, players would become more powerful as they leveled up, which would mean that we would effectively split up our community in multiplayer, as high level players wouldn’t want to play with weaker and less leveled up players.

Instead of focusing on mazing and strategy, players would be able to grind their way to power and beat the game with their superior stats. Since we were still on finite development time, the main problem of adding a new system was that it would take away time from other things that were more vital to the game than something cool on the side. That’s why we decided to scrap this and focus on what we were good at - FPS and Tower Defense.

4. Listening to player feedback and supporting after release

Right after launch we noticed that a lot of players didn’t like some of the changes we did. Instead of automatically allocating resources to every player before each new enemy wave, we dropped the resources at the base. This was to allow players to share their resources with one another, and to give them the possibility of deciding who was going to build each turn, as we noticed that it was very common in Sanctum 1 for players to delegate the building of the maze to one person at the team. However, what happened was that everyone rushed to get the resources first and a lot of players felt that they were never given the chance to build anything. When we tried out this system at the office, it was fine, but when strangers played together over the internet, it didn’t work at all.

So right after release, we decided to crunch again to implement a system that would automatically allocate resources to each player, but still allow players to give away resources to others if they wanted. It did cost us some development time, but the community response was extremely positive - people were very happy that we listened to feedback and made changes that they wanted to see. It’s impossible to know if this translated into sales later on, but the forums have been much friendlier, and we’ve earned a reputation of supporting our games after launch, which is very important for a lot of players.

5. Environments

Instead of having lots and lots of different assets for our game, we let the level designers work with fewer assets and having them build lego instead. What we did was create very general assets and create different textures for them instead. So they could be used in different environments and create new things out of other things. If we needed a spaceship, we didn’t create a new mesh for it. Instead it was built up from various other meshes. The screenshots below will give you a better understanding of this.

A spaceship built out of other parts

The big SOKOL is entirely made up of existing meshes. The base is made out of Cannon towers f.e.

Since we were very limited by the consoles we also had to do many optimizations level-wise. We used many assets to naturally occlude other things on our maps as you can see from the screens below.

Here we put up a big wall in the middle of the map so we didn’t need to draw the whole map any given frame

Since transparent meshes are very expensive we had to limit how many tubes you could look through at once

What went wrong:

1.Not iterating enough

A lot of core features of the game were prototyped in the beginning, but were never really evaluated until it was too late. We implemented the feel for the weapons early on and just put it up to the designers to tweak some values, but we never sat down and actually evaluated them. The tutorial map was done pretty late when we understood that we may need one. The result was ok, but not quite as good as we would have wanted. And then we had the big bomb - the resource system. This was something we should have iterated much sooner since it’s such an essential feature of the game. In the end we had a system none of us really liked, but we thought it was good enough. As we mentioned earlier, after receiving a lot of negative feedback right after release, we ended up changing the system anyways. In the end, the new system was much better than anything we had done prior to release, both in our opinion and the players’. It would have been easier and more cost effective to just do it right from the start.

The biggest mistake here was that we didn’t pinpoint exactly what we wanted to test - we just tested the game internally once in a while. We had a few closed beta testers that helped us a lot, but we should have done much more testing externally.

2. Consoles

Having developed this game for consoles has actually been a double edged sword. On a positive note we have a much more stable game and have been able to lower the PC-requirements with quite a lot because of the harsh testing and optimizing. On the other hand we were forced to crunch a lot in the last couple of months of development because of hard deadlines and failing to fulfill all the TRC/TCR’s. Since the consoles weren’t able to deliver the game we wanted them too, the game had to take some hard punches. Limitations on how many enemies we could have and introducing a tower cap wasn’t something we wanted to introduce, but were forced to since we couldn’t release a different version of the game on Steam. Our core vision of the game was getting in trouble here, and there was nothing we could do about it.

Probably a third of the development for the programmers was getting the title ready for the consoles. Unfortunately the payoff hasn’t been anywhere near the work. Seeing all your hard work resulting in sales that don’t come near the effort is very demoralizing.

3.Not learning from mistakes

So what did we do when we realized that the XBOX 360 and PS3 sales were bad? Instead of just letting it go and working on new stuff, we wanted to do a DLC for them. The PS3 had so abysmal sales we actually didn’t even consider it, but we went on ahead with the XBOX 360. We took the first two DLC’s and merged them into an expansion pack.

One of our arguments for continuing working on the DLC was that we already had done so much work for it. Before we knew sales we had started setting everything up for DLC since we thought we were going to strike gold. Or at least find a silver vein. In retrospect we . We should just have looked at the figures and seen that the work wasn’t going to pay off and killed our darling with a hatchet.

4. Focusing on bugs

This may sound like something that is actually good, but we probably overdid it. We did regular internal playtests of our game. We even had some external beta testers(in a closed beta). But we had our noses stuck up in our rear ends and didn’t acknowledge the feedback we got for real. The only thing we really listened to was bug reports, and we fixed all bugs submitted. What we didn’t do was fix gameplay related issues. They actually complained about the resource system in the beginning, but instead of understanding why they had a problem with it, we explained to them why it was better the way it was at the moment. We believe that much of the damage control we were forced to do when the game was released could have been avoided, had we actually listened to what our testers had to say.

The Focus Tower

5. Wrong DLC plan

As I’ve mentioned earlier we thought that Sanctum 2 was going to be a huge success, so we looked at other DLC plans that games had and liked the idea of having a Season Pass. What we didn’t think of was all the consequences this would have. Just like Sanctum we wanted to continue the development for a long time after the game launched. So we aimed at releasing 4 DLCs. By selling a season pass we forced ourselves to do 4 DLCs since we promised it to our customers. Don’t get me wrong, we have gotten back the development costs for them, but what if we wouldn’t have?

Also, what we didn’t anticipate was the trouble with discounts. As we’ve learned from Steam, discounts is when you really can make some money, and how would we go about discounting released DLC vs Season Pass? In the end we were too afraid of discounting the Season Pass until all DLC was released so to not upset our customers that had bought the season pass on day one.

Conclusion

We didn’t manage to meet all of our initial goals, but we still had a hell of a good time, learned a lot, and made enough money so that we could continue making video games.

In retrospect the console ports were a bad idea - we’ve made about 95% of our revenue from PC, so having a day 1 port is not something we want to do again. We’re still unsure of why we sold so much more on Steam than on consoles, but if we’d take a guess we’d say that it could be because visibility is much easier to get on Steam with daily deals, free weekends, etc, compared to consoles, where we got pretty much no visibility at all.

We did experiment a lot with new gameplay features, some of which were very successful, some of which were not. In conclusion, we could have done way more testing of our game, primarily on people outside of the development team.

As a final word I want to share a little anecdote from our development that highlights how important feedback is. A thread on our forums had a discussion about the “Range Spire”. Some said it wasn’t working correctly while others argued against them and said that it worked great and described tactics they used with it. What it did in theory was that it extended the range of all towers around it. When we checked the bug we noticed that it didn’t do anything at all besides changing visual feedback for towers.. Nothing at all. We obviously fixed the bug, but the tower had gone through internal and external testing, and almost everyone thought it worked great. That’s what I call good feedback!

Data Box

Developer: Coffee Stain Studios

Publisher: Coffee Stain Studios on PC, Reverb Publishing on XBLA/PSN

Release Date: 15 May 2013

Platforms: PC, Xbox 360 & Playstation 3

Number of Developers: 16

Length of Development: 1 year and 6 months

Development Tools: Unreal Engine 3