When we first met with Paul and Ian from Mode7 and discussed FSP, we came away with a pretty clear philosophy of what needed to happen for FSP as a game and as a studio. 

As a game, Synapse as it stood had enough quality in the core game to build on, and our job was to take a heavily menued, super core game and make it sympathetic to a console audience. In practice, we realised during development that we needed to redefine our design pillars for FSP, start from the ground up and repurpose where we could. No one on the team wanted to do a straight port, this was going to be something different.

As a studio, (as most devs already know) you're usually remembered for the last thing you did. At the time, we were coming off the back of LittleBigPlanet PS Vita and this was complete departure creatively. Reputation is everything; with the people that play our games and of course Mode7 entrusting us with their baby. 

Prime represented a lot of firsts for us, many of which are the subject of other discussions; however, in 2012 it became our first self-published and self-financed project. Based on our initial estimates the original release date should have been February 2013. We released it on PlayStation Vita in September this year, just about tripling our original budget. "It’s not ready yet” was a common phrase throughout development. As gameplay and control improvements in core areas kept getting better, they highlighted weaker components in the game that we were happy with a few weeks back. Having the time to iterate and prototype was absolutely key on FSP, constantly challenging our own opinions on what felt intuitive.

To help finance it we took on other projects. We also had this thought kicking around that if Sony and Mode7 trusted us with what is most precious to them, the logic was pretty simple - who else would do the same, and could we build a sustainable business from it. The answer to that I suppose is how we grew from a Sony exclusive studio to a fairly niche developer and publisher and is a story for another day.
 

Designing our version of Synapse
- Gareth Wright, Design Manager, @Gaz_Wright

Mode7 had created something really special with their original title, nailing addictive gameplay, depth-of-strategy, and empowering players to out-think one another.

We all asked, “How can we maintain everything that was great about the original on PC, and bring it to a new, social audience on Vita? An audience who demand immediacy, intuitive controls, wrapped in a more visually impressive package.”

Bringing the game over to Vita was no easy feat, but the vast amount of challenge was not on the technological side as originally perceived, but one of design and gameplay. Getting to grips with the huge amount of depth under the surface quickly made clear why the game was so popular on PC. Gameplay over visuals was absolutely at the heart of Frozen Synapse, and that gameplay married so well with the luxury of a big screen and the speed of a mouse.

The size and portable nature of the Vita presented a number of design and gameplay challenges from the get go, but also unique opportunities with touch, to design to the platform’s strengths. With Vita we also saw an opportunity to break the mould a bit – create something that does embrace all the pick-up-and-play expectations, but could also re-imagine the strategy genre for the modern generation of Vita gamer - No mathematics or dice-rolls determining the outcomes of a fire-fight, instead total player control over what transpires.

In FSP, much like Chess, understanding the goals and the strengths of your playing pieces (units) is very simple. The strategy in each turn and the “it’s never the same game” feeling, comes with the control and freedom we can give to the player. Once that’s nailed, it’s completely down to the player’s tactical creativity.

To ensure longevity and keep the game fun and flowing, the real key for us was to ensure that the commands (creating paths to walk along or orders on where to aim for example), were easy to apply and adjust. All FSP players have their own tactics for any given scenario, and all wanted to be able move the camera, select units, create paths, apply commands or preview whether their plan would work… at any given time, and often simultaneously.

Our main design challenge on Vita was to try to empower players with that sense of freedom, make turn planning quick and easy, second-nature, and thus see the mind-games and deviousness between players rise to the top.

Through numerous focus-testing sessions, we noticed that players who knew where they wanted to place a waypoint or command, that using the cursor and control sticks could feel sluggish. Especially those used to a mouse-pointer in the original. If anything we wanted to speed up turn time and laying down plans for the Vita audience, so a lack of touch controls just wasn’t going to fly.

At first we were geared up to allow the player to pan and zoom the camera with touch, and that would be it. However, deciding to implement touch to mimic all actions mapped to Cross (selecting stuff and adding commands) made a massive difference in laying down simple and effective plans for the player’s squads.

From there we challenged ourselves to explore the possibility of full touch controls, both throughout the Front End and in game. We looked at other Vita titles but very few offered in-game touch controls that weren’t simply for the odd action here and there, or felt forced or a bit gimmicky. 

It quickly became an internal benchmark for us to provide a system that was intuitive and enhanced the experience for those who wished to use touch. Much inspiration for touch was instead taken from map and satellite navigation apps.

The easier and somewhat logical option for FSP would have been to spread a ton of touchable buttons around the screen, but that didn’t fit with our minimalist OSD aspirations and our intentions to maximize the screen real estate on Vita. As a result the OSD design and layout went through many, many iterations as our two pillars of full touch-control immediacy vs a minimalist OSD battled against one another.

In the early goings, burying commands and camera controls under layers of menus was not immediate for the player, despite providing a nice clear view of the map. On the flip-side, filling the screen with touchable buttons to select and jump between any command at any time, was hiding 3 quarters of the playing field. 

We worked very closely with Paul and Ian at Mode7, as well as player testing with fans of both the PC version, iOS version, and those who’d never seen the game before. 

At times simply expanding the touchable region of a certain button by only 1 pixel, or reducing the double-tap timing for adding waypoints by a few milliseconds, would provide a miraculously positive effect.
 

Aside from trying to create the best UI and control-scheme possible for FSP, we were deliberately cautious throughout the design, not to push either touch or button control over the other. As a result many players will subconsciously use a mix of both, dependant on what feels fast in that scenario.
 

Advanced Strategies and Touch Control Gameplay

A graphical re-imagining
- Rob Ware, Technical Director, @RobDWare

One of the most obvious changes we made to the game was to overhaul the rendering with a fully 3d camera, 3d models, lighting, animation and so on. In order to keep the original gameplay intact and avoid introducing bugs, we tried to build a new way of visualising the game whilst making minimal changes to the underlying logical representation of the world upon which the AI works. In this section I will give a few technical insights into the new way in which the player sees the Frozen Synapse world.

The screenshot below, on the left, visualises one corner of the game's first campaign map. As far as the game's AI is concerned, the map is a series of overlapping boxes, with three discrete types to differentiate walls, low cover, and windows. The first step was to clean up this data a little in ways which would make it easier for us to proceed towards the final 3d representation but without changing the 'shape' of the map from the game simulation's point of view. Although any changes to this data would not feed back into the game (as we're working on a copy of it), any differences would clearly lead to gameplay that didn't make sense, like a unit firing through a wall or failing to fire though appearing to have a clear line of sight. A simple iterative relaxation algorithm removes overlaps and erases any boxes which were completely overlapped by another bigger one,the results of which are visible in the screenshot on the right hand side.

The next step was fairly simple, we had a total of 25 hand made wall sections in different configurations of length, width and graphical features. For each of the boxes which survived the cleanup process, the code would select a selection of these models suitable to fill it up, applying some subtle scaling of both width and depth, in addition to a rotation, to create an exact fit. Of course getting an exact fit was of tantamount importance to representing the underlying gameplay accurately. Here are a few of them.
 

Finally, the original box based representation was used to create an approximation of ambient occlusion around the bases of the walls, simply by rendering the boxes to a low resolution texture which was mapped to the lightmap channel of the floor mesh.

None of this sounds particularly complicated, but where it got a lot trickier was in handling the rocker launcher units who could destroy sections of the map. And of course, the player has control of the timebar which means they can jump forwards and backwards in time meaning it had to be possible to reconstruct the map back to the  correct state for any particular moment in time. As a consequence of our 'observer' approach, these interactions simply appeared to our rendering code as a new and different map layout, so it was important to keep a mapping from the original data to the 'cleaned' version which allowed us to discern what had really changed and what had not, and to make sure that no unchanged sections of the map generated differently as a result of something happening elsewhere - the Butterfly Effect in action!

To handle the destruction itself, we originally played with destruction middleware but it quickly became apparent that to keep the tactical nature of the game intact, the destruction had to be just as precise as in the original game, and the conventional approach of pre-fracturing models wouldn't cut it. Instead, I ended up writing a module for our engine which could take a cutting plane and slice a model (in our model format) to that plane. More complicated destruction is achieved by cutting recursively along different planes. Our vertices carried a lot of information; position, normal, tangent, colour, and two or three uv sets, as well as separate streams optimised for rendering to shadow maps, this took quite a lot of code and some optimisation. All of our models consisted of closed geometry so in theory the 'open face' exposed by cutting a model to a plane is also a closed shape, which I needed to extract, triangulate, generate uv's and output a new 'end cap' model in the format expected by the rendering engine.  

To put it simply, when destruction occurs we rebuild the affected sections of the map back to their original specification, and then apply all the modifications, in order, up to current moment in time. All of this work, especially the model clipping, is intensive stuff especially for the vita so to help a little, the work is spread out over a few frames.

In addition, the destructed part of a wall section also needs clipping down to shape so that it can go on to fade away smoothly (with some additional effects applied). Finally, I used the contours extracted during the clipping process as the template for creating smoke particles such that the newly exposed faces appear to smoulder for a while...