This article describes the creation of Tichu for the iPhone, iPad, and iPod touch. Tichu is available right now in the iTunes App Store.About six months ago I wrote an
article about bringing a great card game to the iPhone: Mü. Now, six months later, I'm back only this time I'm writing about another great card game: Tichu.
When I released Mü, I was almost immediately inundated with requests to do Tichu. That didn't surprise me too much, since my two favorite card games are Mü and Tichu and my experience with the hobby gaming community would lead me to believe that I'm in no way unique in that regard. These two games are often mentioned in the same breath. It's not hard to understand why. Mü is one of the best games in the traditional trick-taking genre, and Tichu is the king of the climbing games and the most popular card game of all time on BoardGameGeek.
In case you are unfamiliar with the term, a climbing game is similar to a trick-taking game but instead of each player playing just a single card to a trick, players take turns playing sets of cards in an effort to be the first to get rid of all of their cards and capture points. In a climbing game, players usually can play multiple times on the same trick so long as they are able to keep playing higher sets of cards. Other games in this genre include The Great Dalmuti, Gang of Four, Frank's Zoo, and a host of traditional Chinese card games from which Tichu was derived.
In my
earlier article I discussed securing licensing rights, setting up a development environment, the importance of researching the platform, dealing with the smaller screen size, creating a workable AI and other similar issues. Most of those issues also applied to Tichu but I won't repeat myself by going into them here. Instead I'd like to focus on a couple of ways that I took the things I learned while doing Mü and improved upon them.
Specifically, I want to focus on two areas that I felt were vital to the game's success: network play, and beta testing.
Designing For Networked PlayLet's get this straight right up front. While there are Tichu variants that allow for different numbers of players, anyone who knows the game can attest to the fact that Tichu is really meant to be a four player partnership game. If you play with any other configuration of players, you may be playing a game called Tichu, you may be playing a game that looks like Tichu, you may be playing a game that shares some rules with Tichu, but you aren't really playing Tichu. What you are playing is a far inferior counterfeit of this superb game. No self-respecting Tichu player would ever deign to play Tichu with any number of players other than four.
Accepting that to be gospel, how is a Tichu addict to feed his addiction when there are fewer than four players present? That was one of the primary problems that Tichu for the iPhone was designed to address from the start. Right from the beginning I knew that I wanted to create an excellent way for players to enjoy the game when they were short a player or two (or even three).
When I designed Mü, I had a similar goal but my focus on linked play wasn't quite as strong as it has been on Tichu. Mü suffered from that lack of focus and the linked play experience has never been as glitch free as I would like. From the start, I set out to do Tichu the way that, in hindsight, I wished I had done Mü. I wanted a linked play experience that was bullet-proof from start to finish and I think that I've largely succeeded. Here are some of the ways that I did it.
First, before I ever wrote a line of code, I decided that I wanted to carefully compartmentalize all aspects of the game so that essential information could be shared across all linked devices as a single binary blob of data, identical in every way on each and every device. That way, any change to the game state could be reflected across all connected devices simply by copying that blob of data. With this architecture, it becomes impossible for external influences to put the game in an invalid state. As each device changes its local copy of the state, the state is broadcast as a single atomic unit to all of the other devices. Should two devices try to simultaneously change the same data, the last one wins and the first change may perhaps be lost, but at least the game state is legal and the game can continue uninterrupted.
Here is a diagram showing the high-level structure of Tichu:
You can see that the game is structured around four high-level components, three of which are nested one within the other like the layers of an onion.
The User Interface (UI) is completely divorced from the game state and can only interact with the game through a well defined interface at the Local State level. Any changes in the game state result in a single update method being called on the UI engine and the UI must be prepared to correctly render the game elements regardless of whatever state the game might have been in previously. The idea is that no matter what crazy, unexpected thing might have happened to the game state, the UI should always be able to "just do the right thing". It has no knowledge of how it got into its current state. It only knows what must be shown and how the user is expected to interact with the game at that precise moment in time.
The Common State contains the heart of the game. This state object is replicated across all connected devices. Change this state on one device and bit-for-bit that change is replicated across all of them. This level has no knowledge of where the four players are seated, only that there are four numbered players. This level knows which players are human, it knows what their names are, and it knows how to communicate with them. It knows in which order the players take their turns. It also knows which of the linked devices is responsible for playing for the computer players.
Inside the Common State is a tiny nucleus of data called the Core State. This contains the minimal amount of information necessary to describe the current state of play to the Artificial Intelligence (AI) engine. Whenever the AI explores the possible outcomes of various moves, it makes a copy of this state so that when it's done looking ahead, it can put the state back exactly the way it found it. In fact, whenever the AI engine is run at all, it operates on a copy of this state, so if any of the humans in the game should make a change, it won't immediately affect the AI and vice versa.
The Local State is unique to each connected device. Among other things, it tells the UI which seat each player occupies around the virtual table shown on the screen. This is how the game knows which of the hands belongs to you. Because each human player in the game has their own unique Local State, each player can independently choose if they want play to progress clockwise (common for most card games in the United States) or counterclockwise (the direction officially sanctioned by the rules). This also allows each player to have their own preferences as to which card art to use, which input style to use, and so on.
All of this careful structuring has resulted in a linked play experience far superior to the one I created for Mü. The game plays reliably with any number of players with very minimal chance of state corruption. In fact, I am so happy with the way this turned out that I am seriously considering re-engineering Mü to incorporate elements of this same system.
Building a Solid Beta ProgramAs soon as I had a playable game it was time to bring in some beta testers. Building on the core group of testers who helped me with Mü, I also reached out to some people in the gaming community at large who I knew might be interested. I was very lucky to get some very dedicated testers who are passionate about their Tichu game. If you're a board game enthusiast, I suspect that there might be a few names listed in the credits that will be familiar to you.
Early on, I set up a private web site dedicated to the beta program. I also set up a private Yahoo group so testers could communicate with one another and receive notifications about beta drops. Having active lines of communications with my beta testers was instrumental in the evolution of the game.
As I had done with Mü, I built in some special functionality that was available only during the beta test but I went far beyond what I had done for Mü. Beta builds kept an internal log of all important events in the game, as well as binary dumps of the core state before every play. If a tester ever encountered a situation that they felt needed to be reported, they could hit a button in the game and email that log to me, along with a short comment describing the issue. I could then take that binary blob and use it to put my game into exactly the same state as theirs for debugging and further testing. The several days I spent writing that debug-only code paid huge dividends as I made use of those features every single day.
The most difficult aspect of the beta program, from my point of view, was insulating myself from all of the well-meaning criticism and suggestions that I received from my testers. Tichu proved to be a very difficult game to program and early iterations of the AI were buggy and truly awful in some respects. My testers were very direct with their criticisms whenever they found something they thought to be wrong. Many times I had to bite my tongue and swallow my pride. Most of the time, after I let my emotions cool down, I had to admit that they were right. Having someone pick apart your work day after day can be very demoralizing but I had to remind myself that this was exactly what they were supposed to be doing. I can't tell you how many aspects of the final game were the direct result of feedback from the testers. They were immensely valuable. The fact that they were all unpaid volunteers who were doing it solely for the sake of their love of the game makes it all that much more impressive.
ConclusionWhen I set out to write Tichu for the iPhone I was very nervous. I suspected that coming up with a successful AI for Tichu, particularly on this device, would be far more difficult than anything I had done for Mü. I was right. I'm still not completely satisfied with how well the computer plays the game and I will probably continue to tinker with it for many months to come but, despite that, I am so proud of how it has turned out. I can't tell you what a thrill it is for me to be able to link up with one or two friends and play a good game of Tichu. The computer may not play a perfect game but it can give me a decent run for my money. The interface is clean and well polished. It's attractive to look at and very fun to play. All in all, I couldn't be more pleased.
This article describes the creation of Tichu for the iPhone, iPad, and iPod touch. Tichu is available right now in the iTunes App Store.
You can see that the game is structured around four high-level components, three of which are nested one within the other like the layers of an onion.
