Case Study: Battle Isle Threshold Run

Battle Isle Threshold Run was a project I worked on in 2013 while at Thunderdog LLC. We were approached by Stratotainment, founded by original Battle Isle creator Thomas Hertzler, to reboot the franchise for the modern era. From the get go, this game was to be optimized for tablet devices and utilize high quality 3D graphics built on the Unity3D framework.

This project underwent many months of design iteration and feature exploration. During that time I led the user experience effort through 2 major product pivots before the project was put on hiatus.

What began as a single player narrative focused strategy game for tablets ultimately became a competitive multiplayer game for web. This page is meant to serve as a design chronicle of Battle Isle Threshold Run and the many changes it went through.

Goals & Constraints:

  • Create a user experience optimized for touch screen tablet input
  • Create a scalable gameplay system with expansive monetization opportunities
  • Include all the major game play features of a typical desktop strategy game
  • Streamline the user flow for easy-in and easy-out game sessions
  • 8 month development budget

Contributions: Game Direction and Design, User Experience and Interface Design, Prototyping, Documentation, Concept Art, Brand Development

Tools Used: Adobe Illustrator, Photoshop, AfterFX, GameSalad, Unity3D, Atlassian Confluence



The original Battle Isle was a turn based strategy game that featured a hex based movement grid in which users were constrained to set routes on each map. This was our initial direction with Threshold Run, essentially recycling the core gameplay mechanics of the original but with new 3D graphics.

This approach, however, conflicted with the monetization requirements of the game. Early on, the team knew that we were going to implement a monetization structure for additional campaign content as well as unlockable units and unit gear. In order to make this gear meaningful we would need to expose more attributes and stats for players to customize via mixing and matching gear. The first problem that came up was trying to fit non-incremental upgrades within an incremental system.

This impacted the movement system the most. I wanted users to be able to tap the grid location of their choice to be able to move towards it. My first solution was to decrease the size of the hexes on the hex grid to allow more levels of movement range upgrades. At some point, the experience became severely damaged when the grid spaces were so small that they were difficult to both see and touch without a big margin for error. To counter this, I prototyped some visualizations that felt more organic but were still based on a static grid navigation path.


It was clear that the best way to free design up to sustain the desired monetization structure was to abandon the grid system for a more “pixel perfect” solution for all gameplay systems. This included movement, attack range, area of effect radius, line of sight range, and visibility range. This posed a huge design challenge regarding interface and user interaction. When creating a desktop game interaction points can be incredibly small since the user has the input precision of the keyboard and mouse. For a tablet game, however, touch detection must be generous and you always have to be mindful of the user’s hands and fingers obscuring important parts of the screen. So pivoting to a free from system for action attributes was necessary but definitely challenging for the form factor.


In order to reduce screen clutter and increase the size of action buttons I opted for a modal user interface that switched actions and information displays based on context. This was most utilized in unit action interface as each unit could be capable of 5 or more unique actions and/or sub-actions. As a user selects their desired unit, the unit’s stats populate the outer UI while its available actions expand in a radial pattern from its center point. I nicknamed this the “cross bar” and it would become a design that survived all future iterations. This solution was designer friendly, as I was able to move action buttons around easily; it was also user friendly in that it preserved easy-to-identify buttons, reducing frustration and maintaining a smooth interaction flow.



The amount of variety capable within the cross bar action design was immense. Every unit in the game, whether ground based infantry or airborne jets repurposed common actions as well as included unique actions. In order to ensure users would know how to use each unit without extensive tutorials and help prompts, I divided each cardinal direction into a specific action category: Up = movement actions, Right = attack actions, Down = passive modifiers, Left = unit special actions.

To overcome the input precision limitations of the touch screen I decided to go with a 2 touch flow where the user would tap a desired action and set its trajectory and then tap again to confirm and execute. This system allowed users to fine tune their trajectories before committing to them. Initially I pushed hard for a single touch system that triggered action upon release. However, user testing proved that while faster and more efficient in theory, single touch led to more errors and unintentional movements.

Actions were designed to be simple and intuitive, requiring only basic taps and dragging motions. For maximum accessibility all interaction could be completed with a single hand.

UI feedback was also designed to communicate valuable information in real time. For instance, as users dragged the movement spline over a non-traversable area, the spline would change colors to indicate restriction. If a player’s unit was within attack range of an enemy, that enemy would be highlighted. Player awareness and empowerment was achieved by integrating this type of visual communication.


The user interface surrounding the borders of the core game play screen did not deviate too much from the initial concepts. I always knew I wanted to keep the center of the screen free from as much clutter as possible so I placed all passive information and high level menu actions at the corners and borders of the screen. If you look at the series of layouts below you can see a mostly consistent concept of unit information resting bottom center with modal switches and and end turn button at the outer lower corners. This approach would ensure the user kept their hands at the lower portion of the display 90% of the time, reducing the risk of physical obstruction. It was only toward the end of the project that a lot of common UI made its way to the top of the screen, but that was the result of swapping to a desktop platform that afforded us mouse input and lifting the touch screen restrictions.

As a means to elevate the potential for user engagement and conversion to monetization the lower UI started to become more and more graphic, including thumbnails of unit selections. I knew that we needed the user to become emotionally attached to the units they had purchased or earned through the game in order to care more about customization and upgrades. Eventually the UI became a cycling carousel of unit “cards”. The added benefit of this style of unit browsing was the reduction of panning and scrolling the game camera to find your desired unit. Players could quickly flick the carousel, find the unit of their choice, tap the card and the camera would automatically pan over to the unit on the field. This style of input really helped streamline the play experience and reduce moment to moment frustration.

The final iterations of the outer game UI put monetization front and center. Taking a page directly from popular games such as World of Tanks, the UI integrated vital high level stats such as player rank and XP, but also exposed basic and premium currencies at all times. In addition, monetization hooks were available at all times via upsell buttons and prompts. By the time we got to this design, my goal was to keep the UI as tight and out of the way as possible while also being incredibly easy to navigate.




As the business requirements of the game evolved, so did the meta structure design and front end user flow. I spent more time iterating on the front end than any other UX task.


The initial scope of the project focused on a linear single player campaign that had a few optional side missions to unlock extra gear and units. The player would start the game with a small handful of unit types and as the story unfolded new units would become available giving the player new options for completing mission objectives. Players could replay previous missions at any time for mastery and high scores. The core game loop revolved around completing missions, earning gear, applying gear customizations to your units, and then playing more missions to get more gear, etc.

We were only going to deal with a handful of unit types so much of the interface for unit selection was not built to be scalable. In fact, scalability of content was not one of our first assumptions considering the short development timeline. So small and simple front end screens were the name of the game.


This revision saw the first scope increase to the game, coinciding with the shift to the free terrain system of movement and actions. Now that all unit stats could be manipulated and upgraded, the overall unit research and upgrade system expanded into a much more dynamic web with many points for player choice and deviation. This not only posed a challenge to system design, but also created challenges in presenting the upgrade tree with as little clutter as possible. My early attempts to make each screen incredibly readable and user friendly became compromised for the first time since more and more information needed to be shown per screen. Fonts got smaller, as did buttons and prompts.

Also increased was the potential for narrative expansion. Initially, this game was to take place in Germany right after the events of WWII. Though, in design sessions with the client new ideas surfaced that spanned globally via expansion content post-launch. I redesigned the mission map flow to begin with a world view. Initially only Germany would be a selectable locale, but in the future other locations around the world could be picked. Once picked, the camera would zoom in to display a close in shot of an area. In this case, the user was shown Germany, with various cities highlighted. The narrative campaign took the player through major cities in Germany and new cities would unlock as the campaign progressed. Once a city was selected then the camera would zoom in and show a more traditional mission list. This was my first attempt at scalable mission content as lists could grown and shrink as needed.

The last major front end update was the unit selection screen layout. We began expanding the overall unit list beyond original projections and needed a more categorized layout. This afforded us larger clickables and icons, but required a tab system that combined with a horizontal scroll bar. This created a few usability issues and was not the most elegant solution.


This version was the beginning of a reduced focus on linear narration in favor of a modular map system that allowed random missions and mission expansion. During this time I pitched an innovative new form of casino style monetization tied to randomly occurring challenge missions. For completing a mission a player would get to choose 1 of 3 rewards, but for a small premium they could take all 3. This type of thinking convinced the team to create more dynamic gameplay systems, levels, and scenarios so randomization could be possible with infinite recurring monetization opportunities. The big challenge behind a linear narrative game is that once the player has seen all the content, what incentive do they have to continue to upgrade, play and come back? Random challenge missions were our solution and driver of monetization.

The UI changes in this draft of design reflect layouts and content meant to be scalable. I dropped tabbed views in favor of list view popups that could scroll infinitely. The world map became more abstracted and less geographically accurate compared to the previous draft, allowing new levels and campaign content to be added easily. Unit upgrading was reworked to act less like hard incremental upgrade nodes and more like a coin sink that the user would apply their research points with the click of a single upgrade button. It was an extremely efficient, functional and scalable solution, and probably my favorite of all the drafts.


This version was by far the most complex and expanded the front end scope immensely. At this point the target platform had shifted to desktop which made many of the previous user experience decisions redundant since screen resolution, touch controls and physical obstruction were no longer major constraints.

Gone was the narrative structure completely in favor of multiplayer skirmishes set in a revolving series of battle maps. Due to the asynchronous nature of the game, players could be engaged in multiple battles simultaneously. My first task was to create an easy in-and-out battle map which I actually modeled after the old versions of Battle Isle. I depicted active battles as HEX icons on the map which was reminiscent of the original hex-grid game presentation. Players could jump in and out of battles very quickly as well as start new ones.

Now with a multiplayer focus, it became important to personify the player a bit more so I added the concept of “captains”, which were characters the player could assign their armies like an avatar. Captains could be upgraded and customized just like battle units opening up yet another avenue to monetization.

The biggest shift in this design I think came from realizing that the player would actually spend more time in the front end planning for battle than in the battle itself. Previously the strength of the single player campaign was based on mission scenarios and interesting gameplay challenges. Now, users would be more engaged by customizing, fine tuning, and managing resources to have bigger and better gear than their opponents. Because of this, the front end interface expanded more than twice as much and could be infinitely scalable. The core game loop became more monetization focused adding sub routines for monetization conversion and resource maintenance. While many of the core game play systems remained intact for this iteration almost all unit balancing had to be reworked as well as level maps.


Late in the game’s development the business goals for the product shifted hard left away from touch screen tablets and a single player narrative focus. Inspired greatly by the success of free to play asynchronous multiplayer games the decision was made to switch focus to a free to play model that could be enjoyed across browser as well as mobile platforms at some point in the future.

This version of the game did not survive for very long before the project was terminated amicably. By that point the scope of the game had far exceeded the initial expectations, design and budget.


  • adding multiplayer to a game balanced for single player is non trivial and requires its own math model for unit and gear stat balancing. Core base game systems may be able to carry over but units balanced for a satisfying single player experience will feel broken and/or overpowered in a PvP setting
  • it is really important to design around your monetization goals. Changing your business model mid development can send tremendous ripples causing a lot of discarded design and engineering
  • it is very difficult to strike the perfect balance between hardcore game systems and casual-friendly interface and control. Touch screens have advantages and disadvantages. Be prepared to make compromises to both your UI and game systems in order to find the best harmony and user satisfaction
  • Unity3D is a great development tool with fantastic support and readily available extensions that can help speed up your development. That being said, it is still requires a lot of hard work (and good engineers) to get fully polished commercial products made
  • if a picture is worth a thousand words then an interactive prototype is worth a zillion. I was able to get design concepts across for client approval much more quickly and effectively than if I used static wireframes alone


Creator and Executive Producer: Thomas Hertzler – Stratotainment

Game Direction and Design: Billy Garretsen – Thunderdog

Systems Programming: Quoc Tran – Thunderdog

Gameplay Programming: Kain Shin – Independent

Producer and Design: Adrian Glover – Thunderdog

3D Art Lead: Jeff Arthur – Independent

Quality Assurance: Jack Reed – Independent


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s