Postmortem: Mode 7 Games' Frozen Synapse
The story of how the popular and acclaimed indie strategy game took shape, straight from Mode 7 Games joint-managing director Paul Taylor -- including both how the game exceeded the team's expectations and how they were unprepared for its success.
In 2004, two guys went on holiday to France to drink beer and play computer games.
One of their diversions was Laser Squad Nemesis, the turn-based strategy game from X-COM creator Julian Gollop.
As they battled it out over the gridlocked landscape, certain patterns began to emerge: the most satisfying feints and dummies were abutted by long stretches of units waddling towards each other. Yes, a certain tension was evoked, but wasn't it all a little bit... unnecessary?
Three years later, Ian Hardingham had learned a little about designing games; he decided to test out his assumptions.
His company, Mode 7, began development on a project with the cumbersome working title of Psych-Off, a simultaneous turn-based game which foregrounded tactics rather than strategy. Over the course of four years, this evolved into Frozen Synapse.
The game went on to sell over 300k units in its first year, and took Mode 7 from quiet obscurity into the glare of the indie game spotlight.
As the company's co-owner, I was lucky enough to play my part in seeing it through to completion. Development took almost four years of on-and-off effort as we battled to fit it in around contract work and other commitments: it was certainly a significant investment of time and energy!
What Went Right
1. Refining the Core Gameplay
A couple of big work-for-hire contracts enabled us to adopt a "when it's done" attitude to gameplay iteration. We took very low salaries and kept overheads to a minimum, allowing our focus purely to be on making the best game we could.
Also, we took every possible step to lock the core gameplay before any assets went into production. Prototyping with very basic programmer art until the game was delivering the right sensations was absolutely vital.
"My motivation was highest to make a game that had interesting decisions the whole time," Ian told me.
Taking some inspiration from Counter-Strike and trying to focus the gameplay on predicting an opponent's movements, Ian was able to use this time to explore several vastly different avenues. These included one-turn matches known as "Endplays", and a mechanic which allowed the rewinding of time. Although neither of these made it into the final design, having time to explore them was vital.
A playtesting session at the University of Reading.
Robin Cox, our level designer, played the game against Ian every day; the dynamic this created enabled them to shape the design around their own emergent play.
Ian made a conscious decision to start with the basics of the multiplayer game and work outwards, designing units and adding mechanics only when a solid base had been established: this process worked so well that we'll be adopting it again for our next game.
Core mechanics such as as "time-to-aim" (units fire on others automatically; the unit who sees his antagonist first generally wins) were established early on and lasted through a variety of different iterations: a good sign that they were solid.
I would thoroughly recommend that anyone making a game do some in-person testing when they are relatively confident of the core gameplay. We had two major opportunities to do this: one was kindly provided by the University of Reading, who organized a computer lab for us to try out the game with a big group of students.
The other was an event at Nottingham's GameCity festival, which allowed us to see how the general public responded to the game with no preconceptions.
One of the reasons that this worked so well is that people aren't often able to articulate the problems they're having with a game. Witnessing new users struggling with the UI, or trying to approach the game "incorrectly", paid dividends and contributed directly to the design.
2. Minimalist Aesthetics
The game was originally going to be viewed from a "side-top" perspective (think The Legend of Zelda or The Chaos Engine) and have a pixel-art Syndicate-style look.
However, we decided to go for something more "readable" (and less expensive -- high-quality pixel art is surprisingly costly!) and so shifted to a pure top-down perspective.
Initial concepts ended up being a little too difficult to realise so we went with a more pared-down color-coded look...
The addition of 3D walls to the concept was a really key turning point -- we knew then that a selective blend of 3D and 2D elements would yield the best results.
The resulting art style meant that we had a lot of flexibility but also allowed us to suggest and evoke different types of architecture. This came in really handy for single player content creation, allowing the narrative to span many differing environments without vast amounts of concepting and assets.
Also, we wanted to hark back to the "glory days" of PC gaming, and this art style certainly contributed to that. At several points I noted -- always affectionately -- that the big, linear single player campaign coupled with the monochrome backgrounds made Frozen Synapse feel like an ancient DOS shareware puzzle game: mission accomplished!
Some ideas were kicked around regarding using the background to provide a bit more detail on specific rooms, for example tagging each room with a little bit of text that would only become visible occasionally. Ultimately, I'm glad that we stuck to our guns and kept things simple.
3. Paid Beta
In April 2010, we launched pre-orders: anyone who took up the offer would immediately receive the beta, as well as a free key for a friend.
The game was receiving some significant press at this point; we wanted to allow anyone who was really excited by the concept to jump in early and help shape the direction of the game.
The beta consisted (roughly) of a 95 percent complete multiplayer game, placeholder sound, 80 percent finished graphics and a fairly ugly front-end GUI.
Most importantly, though, it was a solid and fun game in its own right: we felt comfortable selling it as a self-contained product, irrespective of future developments. I feel very strongly that this is the place you need to be if you are considering a paid beta: products which are sold exclusively on the promise of things to come will often disappoint.
The paid beta brought in around $135,000, which enabled us to move from doing contract work to support ourselves into full-time game development.
Also, the paid beta created a really solid-yet-small community who stuck with the game because they had invested in it: it really was a case of quality over quantity.
Not only that, but it was a huge psychological milestone for Frozen Synapse. An active community of paying players showed us that we heading in the right direction and that the game would work as a product. It can be difficult to go through an extensive polishing phase at the end of a long project, but the success of our beta gave us a huge amount of motivation.
An early prototype (click for full size).
4. Use of the Torque Engine
We decided to continue using the Torque Game Engine, as Ian had six years of experience with it.
Using an off-the-shelf engine proved to be completely the right choice. Ian cites the "combination of a strict, fast language (C++) with a nice high-level string-only scripting language (TorqueScript)" as being fundamental to its flexibility.
Torque also gave us the opportunity to work with freelancers who already had some experience of the engine: this dramatically cut down on initial work getting up to speed.
While having many of the advantages of a modern engine, Torque is also modular enough that it was simple to replace the existing renderer with our our own custom tech. Also some features, like the great GUI system, cut down on hours of fiddly work which would otherwise have dominated coding.
Having an engine available for prototyping meant that very little tech had to be built early on. When your lead designer and programmer are the same person, tech can be very distracting early on: off-the-shelf engines largely prevent these early hang-ups.
Finally, Torque's multi-platform nature is paying dividends as we work on our iPad version. Admittedly, it has its problems, but we've found that it gives us a fantastic framework on which to build our own tech.
5. Original Soundtrack
Frozen Synapse was the second game I've scored (the first being our debut title Deterimance) and it provided me with a unique opportunity to put some of my long-term musical ideas into practice.
The response from fans has been phenomenal, with many people purchasing soundtrack bundles and sending me nice comments about the music.
I wanted to create music that would stand up outside the game, and I think this attitude paid off. By ensuring that every track had a strong melodic theme, and also incorporating elements of dance music production, I set out to ensure that everything would be listenable in its own right.
It is unusual to have an in-house composer in an indie studio, especially one who is also responsible for marketing, business development and PR! However, in this case it meant I was completely invested in the game as a whole: I understood precisely what the music needed to accomplish, and communicating that to another composer would have been almost impossible.
Also, there were often dead periods in development when I had little to contribute, so I could always fill this time with music production. This allowed me to go down a series of experimental routes and enabled me to create a distinctive style for the game.
I used Ableton Live, which I find to be a fantastically flexible production environment, and a lot of tools common to dance music production: I'm a particular fan of Sylenth1, Native Instruments FM8, and EastWest's real instrument sample libraries.
For mix references, I used a combination of quite heavily limited drum 'n bass tracks by producers like Noisia, Deadmau5's house stuff, and some other game soundtracks. I don't pretend to be a brilliant mix engineer, but I hope I delivered a nice combination of both loudness and detail!
Overall, I'm happy with the soundtrack: I think that, were I attempting it now, I might tend away from some of the orchestral sample libraries and more towards a purely electronic sound. However, some of our initial trailers really needed the bombast that those provided, so all-in-all it was a good trade-off.
What Went Wrong
1. Learning Curve
Frozen Synapse is a complicated game: it requires the use of a dense, sometimes fiddly UI to give orders which are both spatial and temporal. Waypoints, units and orders can all overlap each other and create giant tangles.
Also, it introduces some fairly unusual mechanics to do with timing, use of cover, and unit "readiness".
Our tutorial and the early part of our single player campaign didn't do enough to ease in new players: indeed, the first level was so counter-intuitive that it took many players a ridiculously long amount of time to beat it.
At PAX 2011, we got the opportunity to hear some feedback from the PAX 10 judges: they all cited the early part of the game as the core reason we narrowly missed out on being included, despite the fact that they all enjoyed playing it!
We have already pushed an update to that infamous first level; reworking a tutorial is extremely difficult due to the amount of special-case code and testing required, but it is something we are currently considering, especially for the iPad version.
Next time around, we really hope to have a gentler learning curve. We knew that the game needed to be deep and complex to strike a chord with our (initially) PC-centric audience, but I think we went too far in some areas and made too many compromises.
Although we did do a lot of user testing, it wasn't targeted well enough to catch this problem at an early phase. We should have used a larger group of entirely new players to test the first part of the single player, rather than mostly members of our community who were already somewhat familiar with the game.
2. Lack of an Updater
We had struggled with various auto-updating systems on Determinance, so Ian took the decision to completely avoid that in the early stages of FS. While making users re-download the entire game to test fixes was actually occasionally beneficial (eliminating annoying problems caused specifically by bad updates, for example), this thinking pervaded late into development and even past release.
Although avoiding this definitely helped us create the game, it caused a lot of inconvenience for our customers and has made it really difficult to deploy fixes quickly. That difficulty has made us avoid making small tweaks to the game, rather choosing to wrap up everything into extremely infrequent patches which have upset some sections of the community.
While there are always trade-offs, we're now addressing this issue directly by attempting to develop a robust auto-updater which will be deployed as soon as possible.
An early evolution of the game (click for full size).
3. Gameplay Distractions and Scheduling
Although I mentioned having design flexibility in the "What Went Right" section, there were also some significant problems with scheduling throughout development.
Single player design was attempted too early, and went down some very significant dead-ends before the decision was taken to completely postpone it until after the multiplayer was done. We kept circling around over-complex ideas, such as a randomly-generated "loss track", base building, and other meta-game considerations when all we actually needed to do was make a fun AI and then create a linear series of levels around it.
The long design phase also resulted in periods which weren't productive for the rest of the team: this problem has now largely resolved due to the fact that we're attempting multiple projects; however on Frozen Synapse it occasionally burned money.
Trying to come up with the exact structure of each match also proved problematic. One-turn "Endplays" were the focus for a significant amount of time and, although these led to some significant improvements in the game, ended up being blown out of proportion.
Despite the fact that these issues caused some difficulty, and we're working hard on tightening up our processes for the next game, they were integral to Frozen Synapse. It was important to have the space to go wrong in this way -- allowing mistakes can be crucial to designing a game.
4. Determinism and Difficulties
Frozen Synapse was intended to fit into brief gaps between other games, but it ultimately ended up being a very mentally intense strategy game in its own right.
It's not relaxing to play, because any failed encounter results in insta-death for the units involved, and the entire match can turn on rounding a corner too quickly, or forgetting to duck.
Many -- in fact most -- competitive strategy games have this issue to some extent, but it was something that we were particularly aiming to avoid!
Equally, because of the tightness of the mechanics, it is a difficult game to expand post-launch. Sure, there is scope for further units, new game modes, new SP content and other things, but many features that people requested simply wouldn't fit into the design.
There is definitely scope for a similar tactical game which allows a variety of actions by each individual unit -- things like rolling into cover, diving across rooms, and the addition of meta-mechanics like hacking security systems, and so on. It was disappointing not to be able to say yes to any of those wackier ideas in multiplayer!
Also, there is a constant sense of pressure on the player to make a perfect decision. Because it's possible to test plans for both your own units and those of your opponent, in most situations you feel like you could have predicted events perfectly: that's often not a great sensation for the player as it just leads to significant frustration.
We succeeded in creating a very tense and exciting game, but also one which is incredibly unforgiving.
5. Server and Community Woes
Despite much discussion on the topic, we significantly underestimated the number of concurrent users that Frozen Synapse would have at launch, and so didn't have a reasonable server solution in place to cope with them.
This was largely down to the fact that Frozen Synapse is an asynchronous game! However, instead of logging on and playing the occasional turn, many new players were so keen on the game that they wanted to sit online for long periods and play multiple concurrent games. Although we had seen this behavior before, we weren't expecting it to dominate so extensively.
One of the major reasons for this was the lack of data for similar games available. Understandably, much of that data is proprietary and nobody would want to share it, but also Frozen Synapse had some significant differences which made it hard to compare to other titles.
Also, rankings and community identity weren't structured in a way which kept people playing for a long time: good players often drifted away from the game, fearing the loss of the status they had worked hard to build up. This is a really tough issue for any multiplayer game and the solutions are currently unclear.
I was really disappointed that we couldn't deliver a perfect service to our community in the early days of the game -- it matters hugely to us that people can play without annoyances, so we're working hard on continuing to improve things.
A later evolution, nearing the look of the final (click for full size).
Conclusion
Frozen Synapse changed our lives, mostly because it proved that we were capable of making a game which people really enjoyed.
Ian worked as hard as he could on ensuring that the game had great mechanics, and that these weren't diluted by any of the subsequent additions. Without this basis and his unswerving commitment, the game would not have achieved the traction it subsequently enjoyed.
Personally, there were times when I found it difficult to believe that any kind of significant audience would be able to grasp the UI and turn-based mechanics. We were definitely making a game that no publisher would ever touch, and I wondered if, maybe, there was something to that. I completely underestimated both the strength of the design and the intelligence of its audience, two mistakes I don't plan on making again.
Creating a game around a traditional "pay-once" business model enabled us both to achieve Steam distribution and take part in promotions like the Humble Indie Bundle: two cornerstones of its commercial success. This model kept things simple and allowed us to focus purely on the design without the pressure to monetize individual aspects or mechanics; it will also make the transition to iPad fairly straightforward.
Also, it allowed us to feel comfortable with going the extra mile. There was a lot of "unnecessary" content included, things like the ridiculous number of options in the Skirmish Generator, or the Dossiers which appear between missions giving background detail on the game universe.
Ultimately, though, I think that level of polish is increasingly going to become a baseline requirement for this sort of niche game: if you're defining a niche, then you really have to allow players a lot of room to explore within it.
The indie games market is now phenomenally competitive: this year the IGF had 520 entries. Differentiation is very difficult: not only do you need a compelling art style and great presentation, but gamers now expect all of the usual back-end systems they would find in much more expensive titles. We know that, if we are going to have the same level of success with a future product, it will have to supersede Frozen Synapse: that's a tough challenge, but we're up for it.
Data Box
Developer: Mode 7 Games
Release Date: May 26th 2011
Platforms: PC / Mac / Linux / iPad (forthcoming)
Number of developers: 3 in-house; various contractors
Budget: £140k
Lines of Code: 600,000
Development Tools: VisualStudio, CVS (yes, really), WinSCP, Pepsi Max
Number of incidental audio samples derived from field recordings taken at competitive equestrian events: 1
Read more about:
FeaturesAbout the Author
You May Also Like