Webmaster’s Note: Michael Emery is the developer of the Texas 42 and Texas 42 HD game apps for the iPhone, iPod Touch, and the iPad. Both apps are well done with very good artificial intelligence (AI) and attractive graphics. He was first exposed to 42 in Oklahoma by his grandparents and their friends. He learned to play 42 later from an Aggie friend. The article following his commentary was intended for publication in a programming journal; however, he most graciously consented to my posting it here for viewing by the 42 community. If you’re into programming, you will better appreciate the work that he has accomplished in developing the Texas 42 apps. Thanks for sharing, Michael. Commentary by Michael Emery
First, I’d like to give a big thanks to Paul for putting together a wonderful webpage for such a great game. Paul has personally been a huge help in getting the iPhone/iPad app to the point it is now. He even corrected some of the artwork in the game when I was too busy coding to address it myself.My history with 42 begins in the small town of Duncan, Oklahoma. I spent many hours at the kitchen table playing Dominoes, UNO, and Gin with my grandma (MaMa) and great grandmother. MaMa loved playing for money and always got a kick out of taking my dollar. Technically, it was PaPa’s dollar since I always ran back to him every time I lost. Once in a while, they would have friends over to play a very strange version of dominoes with 4 people. I never paid much attention at the time to be honest. It was such a foreign game to me that it really never held my 7-year-old interest. It wasn’t until an Aggie friend of mine introduced me to Texas 42 that I realized what the hubbub was all about. I found myself obsessed with the game and spent many lunch breaks talking about strategies. At some point, I mentioned 42 to my mom and I was a little shocked that she had already heard of it. She went on to tell me how MaMa used to play it all the time with her friends in Duncan.
When I wasn’t playing 42 with my friends and family, I was studying up on winning strategies. Texas42.net played a big role in my play style, particularly after reading Gary McClish’s “Power Bidding” commentary. I found that his bidding style suited me better than my conservative bidding. Up until then, I would only bid more than 31 on very rare occasions and never made marked bids unless they were lay down hands. My play style has morphed as I gained more experience with the game. Like many beginners, I had a tendency to try to make our bid single handedly instead of playing the game as a true partner. Not everything I’ve learned has found its way into my code yet. I think its safe to say that the logic is still in its infancy, but as long as I have people like Paul to push the app towards perfection, it will only get better with each release.
| --Michael Emery
Fightin’ Texas Aggie Class ‘03 |
 |
Development of 42 Game Apps for the iPhone and the iPad
By Michael Emery
As far back as I can remember, I always wanted to be an app writer. Wait. No, that isn’t right. My interest in software development ended during my freshman year at A&M when I was still trying to decide between becoming a mechanical engineer and a computer engineer. Pretty sure my aspirations for software writing ended when I handed in my blank Turbo Pascal midterm and walked immediately to the academic advising office to drop the course. It wasn’t so much that the class was hard as it was irritating. I wanted no part in writing software for a living.
Flash forward 10 years (oh my, I’m getting old) and I see a news story about this kid. His name is Robert Nay, and his app “Bubble Ball” has had over 12 million downloads, making it one of the most successful free apps in the app store.
And then the thought occurred to me, “If this young 14-year-old can make such a simple app and have success at it, why not try my hand at it as well?” So, I set out to make the next great app…”Angry Nerds”. I rolled in laughter every time I thought about nerds with special powers being catapulted towards a stack of trashcans.
My quest had begun! First step, convince the wife that THIS time, my entrepreneurial enterprise would work and that I needed to buy a MacBook. This didn’t go over well, so I studied up on how to run OSX on my PC. I literally spent months getting my Sony Vaio to run Snow Leopard and I cannot say the end result was very awesome. By this time, I was getting really handy with Adobe Illustrator and I had my prototype character pretty much complete.
I don’t know about you, but that face just screams success! Actually, it kind of creeps me out. Now all I had to do was learn C# so I could use the Box2D physics engine, Objective-C so I could actually develop the app, and Cocos2d so I could have a sweet looking game. Yeah, pretty much none of that happened. I was about to give up on the whole notion of app writing until a friend of mine mentioned how terrible the current iPhone Texas 42 Domino apps were. Suddenly, the mountain ahead of me was significantly reduced (or so I told myself). I didn’t need to become an artist overnight, and removing Box2D from the equation was a significant improvement. This time, I got my way and purchased a MacBook Pro that night and got to work.
I had a game plan in mind.
Step 1: Draw some dominoes in Illustrator. My grandmother gave me a set of double sixes several years ago and I finally had a use for them outside of college. I modeled my domino sprites after this set if any of you are wondering why I chose colored pips over black ones. I must have been looking at some of the deuce tiles upside down for those keen enough to notice the inconsistent slant.
Step 2: Create the game framework. The plan was to have a fully functioning game where the user controls every single player. My first snag though came when I realized I needed to shuffle the deck. I created a 28-row array that contained all the tiles, assigned each index to a position on the screen, and used a random number generator to pull out the tile index. This worked great! That is, if you ignore the fact that the code would constantly pick the same tile index multiple times (in other words, multiple players would end up with the 5:5 on occasion). It’s amazing how much thought goes into creating code that randomly picks 28 numbers without repeating any of them. Thank God Fisher-Yates invented the shuffling wheel in 1938! Do not ask me how this works. I’ve long stopped trying to understand it and have attributed it to black magic.
The next step was setting up the rules of the game. As it stood, you could select any tile you wished, no matter what the leading suit was. I spent a week just trying to get this feature to work properly, but now it was time to only allow legal moves. The end result became the basis for the AI structure.
Step 1: What tile is lead? Is it a trump? Is it a double? Are trumps doubles?
Step 2: Can the following player follow suit? If this player can follow suit, are you touching a tile that follows suit?
Step 3: Remove the tile from the player stack array, add it to the tiles in play array, and animate the tile moving to the center of the table.
Step 4. Once the size of the play array is 4, figure out who won the trick.
Piece of Cake! Actually, Step 4 was a royal pain. You had to figure out what tile was lead and whether or not a double following suit was played because you can’t just compare tile numbers. If the suit wasn’t followed, then you have to look at whether or not a trump was played. If multiple trumps were played because multiple players couldn’t follow suit, then you had to figure out which trump was the highest and whether or not the bull was played. On top of all that, you had to keep track of who played the winning tile.
The framework was complete. Now all that was left was to develop a bidding algorithm and get the computer to make moves on its own.
The human brain is amazing. You can look at a hand and immediately develop a move strategy, determine what the best choice of trumps is, and how many points you are likely to win. Programming doesn’t work that way though. I thought long and hard about how to equate the types of decisions you make to mathematical functions. The solution was to have a set of bonuses and penalties for each suit category. Have a lot of tiles that share the same suit? The hand gets a trump bonus for that type of suit. Missing the 5:5 but have a lot of 5s? Then you get a huge penalty in the 5s as trumps category. After all the penalties and bonuses are added together, the computer takes the highest score and decides what the maximum bid its willing to make.
 | |
| |
The basis behind the AI code is fairly simple… 1. Am I the winning bidder?
That’s a simplified version of the thought process of the AI. The punt algorithm looks to see if there is a safe off-tile to punt with and prefers to use it. This code is still a little too linear for my tastes and I would like to improve it with future releases. I’ve found that there are occasions where it doesn’t find anything it likes which usually results in a ridiculously bad play like in the picture above. Eliminating this type of WTF move has been my #1 focus. When the code works correctly, I think it does a rather good job. When it doesn’t though, it can make hilariously bad moves. One thing I can say through this process is that I have a tremendous amount of respect for Curtis Cameron (developer of Win42). The amount of work he put into making his program the gold standard of Texas 42 games is staggering. I’m not sure why he never got into the smart phone app business, but I’m certainly willing to fill the void. This is going to be an ongoing project for me. The first step will be developing the AI for nello game play. Then I’ll need to decide if I want to start learning android programming, or start working on multiplayer. Both will happen eventually. In the meantime, I hope everyone enjoys the straight 42 game I’ve developed so far.
Michael Emery, 2012
|
