T3 Bandits – A postmortem

                This is look back at the development and design of T3 Bandits. Who this paper is for: mostly myself as a reflection, and continued practice of concisely setting my thoughts to written word; and anyone who enjoys game theory, or wants to understanding the process and decisions behind this games development.

Link to the game in Google Play: T3 Bandits

A brief history

                T3 Bandits started as a code test for a game development company. The parameters for the test were to develop a tic-tac-toe game, using any language, for any target-platform, with any level of AI (including completely random picks). On submission to said company the game was a single looping game of tic-tac-toe. It had some basic animating characters, a hero and a monster, that would attack on placing an ‘x’ or ‘o’, get hit when the opponent place theirs, and fall over on defeat. AI was limited to a simple random pick. Other visual elements included a moving turn indicator and an AI “focus” indicator that moves from the monster to the grid-space it was looking to choose. All of these features remain in the release.

The decision to turn this coding test into a game was a design challenge of sorts. Why? Tic-tac-toe is a zero-sum game, aka an exercise in futility. For those not familiar with the term: a zero-sum game is one in which the outcome of optimal opposing moves always equates to zero (in terms of a payoff matrix). Or in non-theory-lingo, and relating to tic-tac-toe, given two players who know how to play, the game will always end in a draw. This is why the final monster in the lineup declares, “I am Zero-sum! You cannot win!”

How tic-tac-toe became T3 Bandits

                To begin with, I looked at the three core pillars of a game: the spectacle (visual/audio), the gameplay (mechanics/tech), and the narrative (story). I already had a solid start with what I had submitted for the test, in terms of the spectacle. The mechanics of tic-tac-toe are pretty limited, so this was what I assumed I would need to bolster the most. And the beginnings of a story are already in place with the assets I’d used, the hero and the monster. You’d be surprised at how strong a narrative you can weave with little to nothing, just look at games like Journey or Two Brothers. So, now I just had start building up each. And as you will read in the following sections each of these pillars bleeds over into the others; so none of them truly stand on their own but help to support the others, and the overall game.

The Spectacle

                As I mention previously, the spectacle was already well into its development with the animation system. To add additional ‘umph’ to the animations I added a smoke effect to key events and transitions. I created scripted sequences for an intro and the win/loss events; these tie themselves nicely to narrative development. Additional monsters were added for a better sense of progression, progression being an intrinsic element of gameplay. And a more subtle addition, but no less important for the spectacle is the addition of sound effects and different music for win and loss.

The challenge with the spectacle is the assets required. Not only in cost of acquiring them, but in the space they use. In terms of app development that means meeting the size requirements of the platforms you want to distribute through (Google Play, iTunes, etc). Naturally, more assets make for greater sizes. One way around that is to have your uses download the assets on first run. Which of course has its own issues; server and bandwidth costs being the big one.

The Gameplay

                This is the area that needed the most work and took the most time. In order create a true sense of progression the game cannot rely solely on additional assets (more monsters), they must change. That meant increasing levels of difficulty. So, new AI for difficulty, and a coin toss for some pseudo-randomness.

• Monster 1: Complete random choices
• Monster 2: Coin toss for first play, try for center spot, random otherwise
• Monster 3: Try for center, then trying for completion of own lines, then random
• Monster 4: Coin toss, same AI as Monster 3
• Monster 5: First move: try for center otherwise a corner; thereafter try for AI win, followed by blocking player win, random otherwise.

The challenges of creating the gameplay can be divided into design and development related ones. On the design side the biggest challenge is how to make a zero-sum game winnable. My answer? Trickery! Using a narrative related hook, I built in a cheat for the player. There is a subtle hint in the monsters speech and a direct one in the games info panel. Development-wise the challenge is the time investment to create all the systems needed for every little bit of the game. I don’t think the average person realizes everything that goes into making a game. Every sparkle, every shrinking and expanding element or wiggle and shake relies on some logical set of instructions. Using an engine like I did (Unity) has its benefits and drawbacks. The benefit: you have a backbone to work from, and most of the core mathematics are already set to code. The drawback: you have to work with the engines architecture and with its overhead. Ultimately, for this project, the benefits far outweighed the drawbacks.

The Narrative

                As mentioned earlier, the idea for the story came from the initial selection of character assets. The game, such as it is, does not require it to have a complex story. That being the case, it was a simple task to add a story to the game. And it is told entirely from the single opening speech bubble, “We have to save my family! The bandits are coming!” With those two sentences the story then unfolds through gameplay, having a call to action, a beginning, a middle, a climax and an end. The call to action is the ‘Begin Battle!’ button, which leads to the beginning, the middle has a learning curve (potentially, depending on the players knowledge of tic-tac-toe), climaxing with the ‘zero-sum’ battle, and ends in either victory or defeat. The conclusions of either end are implied with their respective scripted event.

However, it would have been a waste to create the system for the speech bubble and to only have used it that once. So, with some minor tweaking I made the system (and assets) reusable and added speech throughout the game, using it for very basic teaching, hints, and general banter.

Final Thoughts

                It was fun! I really enjoyed the process and challenge of developing the game to its final form, and yes even the coding test that spawned it (which is essentially rapid prototyping) and will use some of the things I learned moving forward. Probably the biggest thing I learned came from the code-test critique: magic numbers everywhere! Admittedly my coding was on the rushed side and it has been a hot-minute since I’ve coded in a professional manner/environment. The solution will be to reacquaint myself with a more organized and standardized form of coding, best practices and such. Looking forward to future projects and endeavors!