The Texas Rope ‘Em Story
We all love a challenge, especially when it involves playing with some cool new toys. So when Quicksilver was asked by Candy Lab to help them create a fun, original game demo for the 2017 South by Southwest event, we jumped in enthusiastically. But there was a catch — we’d have to get it done and in the App Stores in only six weeks. How could that be possible?
Here’s the story of how we did it.
Pick Your Battles
If you only have time to do one thing, figure out what it is and then make it as cool as possible. In our many years of game design, we’ve learned that having one super-engaging play mechanic is so compelling it can pull in players and keep their attention for hours on end. With Star Trek: Tactical Assault, for example, we nailed the effect of that classic spaceship flying through a star-field, banking left and right just like in the series. We found ourselves mesmerized by the simple but beautiful visuals. Applying that same mechanic to poker, we knew that building a poker hand is tons of fun, and we quickly zeroed in on making that as much fun as possible.
We wanted to add a little more strategy to the basic game, which often relies on a combination of luck and psychology. Since our version wouldn’t have a human opponent to stare down, we decided to give each location not just one but two cards and give the player a choice of only one. This is intensely compelling for several reasons. First, it’s really easy to understand. Second, it’s fun to have a choice. People like to be able to control the outcome of the game, and this very simple play mechanic allows them to do just that. Third, it’s just a little bit frustrating. Why is that good? Because getting two cards that are BOTH good is just a tiny bit exasperating. It’s like a near-miss on a slot machine. You know that you’ve lost the chance to get that special card because there’s only a single deck, and now you want to try again and do better the next time.
By the end of the first day in our six-week adventure, we’d already outlined this and other key gameplay design decisions. And we knew that it was going to be fun to play, because simply explaining it to other people made them smile. If you can describe your game in one sentence and draw a smile or laugh, you know you’re on the right track.
Seek Out Solid Technology
There’s no sense re-inventing the wheel when there are great ones already available. This is where working with Candy Lab’s tools and Unity3D was so important. This project posed multiple complex technical challenges. We had to build a game for both iPhone and Android with minimal duplication of effort. We had to be able to easily place virtual objects alongside the real, physical world. And we had to implement enough server-side gameplay that we’d be able to track what users were doing and implement a sweepstakes drawing. Any one of those could in theory take months or at least weeks of work. And we had six weeks.
Candy Lab came to us with a fully functional application built with their tools. This included a Unity3D application plus a dashboard that enables a designer to quickly and easily add, move and edit virtual objects. With a proven core, we knew we wouldn’t need to implement and then try to debug the complicated interactions with real-world issues like GPS coordinate systems. They already had a general-purpose system for defining objects with arbitrary characteristics that our game could use in guiding what the player would do.
Plan, Review and Revise
It’s easy to be an optimist. As programmers, we like to think we can do anything. But we have to temper that with the setting of realistic expectations and the prioritizing of goals. So we make plans and put the hardest tasks first. Make sure the engine can actually play a game. Make sure the cards are dealt properly. Then worry about making it prettier and adding cool animations, if there’s time. And, if the plan works well, there will indeed be time.
For this game, the Quicksilver-Candy Lab team went through numerous paper outlines of the user interface flow and what would be on the screen at each stage. We set expectations clearly, so everyone knew what we were trying to do. Equally important, though, we were able to communicate clearly when things changed. When someone came up with a better idea, or discovered that something was going to be too hard to get done, we were able to explain why and update the design very quickly, since everyone already had a clear idea of what was being done and why.
We also tackled the highest-risk technical issues right up front. We set up the development tools, made sure we had the correct versions (not always a simple task, and it turned out to be critical) and immediately attempted to build a first functional application. This allowed us to identify new design requirements and have plenty of time for the tool team to make changes to the engine for this game while we turned our attention to the gameplay. As a result, we were able to work two parts of the project completely in parallel.
We also added backup resources to the project, and challenged them to “make it cool.” Separating this task from the primary development path minimized schedule risk. If we missed out on a pretty graphic, the game could still be released on time. As it turned out, this strategy worked exactly as we’d hoped. We managed to get a nice animated opening sequence and an animated card selection screen into the final product.
Actually, we didn’t have to panic at all. But we did try to imagine where we might have to panic, and do it very early. Only a few days into the project, for example, we did a detailed risk analysis of whether the game engine and back end would be able to handle the load of having thousands or even tens of thousands of users. And we also did a review of what sorts of prizes we could offer, and how we could minimize the chances of trouble. Questions like these are sometimes hard to answer, and they did take several hours for multiple team members working together. But they did get answered very early, making sure that we didn’t have any terrifying “oh no” moments in the final days before releasing the game.
The term “agile development” is very popular right now, and for good reason. Setting very clear goals but also being able to change course is the most efficient way to get a great product done on time. Having a combined team that was able to examine new ideas dispassionately even after development was under way allowed us to fit in some very nice tweaks to the basic design. Everyone on the team, from management to the programmers, shared a common desire to make the game as good as possible and was willing to adjust expectations when refinements presented themselves. They were never locked in to a need for particular features and in some cases made decisions to remove or modify features even late in the process when they knew that such decisions would advance the user experience.
Good tools, a good plan and a great team at Quicksilver and Candy Lab brought a clever, original game online in just six weeks. This version is designed just for the SXSW event, so it only works in Austin, TX at the moment. But, given the success of this project we expect to do a lot more with the game and the underlying technology frameworks. The sky is the limit now.