I spent the last several months of 2009 working on turning Reiner Knizia’s Money into a fully functional iPhone game. Some 8,000 lines of code later, Money is now available from Apple’s iPhone store. If you’d like to support the continued development of good Eurogames for the iPhone platform, please consider picking up a copy.
With that crass commercialism out of the way, I’m going to spend the rest of this article talking about three of the particular problems that I faced adapting a Eurogame for the iPhone environment, focusing on depicting and playing the game. If you’d like an inside look at this sort of thing, read on.
The biggest problem of adapting a full-size tabletop game (estimated tabletop size: 3.5 foot x 3.5 foot) to a much smaller iPhone screen (estimated screen size: 480 pixels x 320 pixels) is sizing everything down. We were fortunate enough to get access to the artwork from the recent Gryphon Games edition of Money, and I thought somewhat foolishly that I could size down Gryphon’s beautiful designs, revise the lettering to use relatively clean fonts, and I’d be done. That’s in fact what I did for my first major playtest release of the game, and I got the response back that there were not one, but two problems with the card design:
- The numbers were hard to read.
- The suits were hard to distinguish.
Fortunately, I had artist extraordinaire, Keith Curtis come to my rescue. He revised the cards one more time and his work is what we actually used in the gold release of the game.
To the right you can see what everything looked like, with actual size of each card being 110 pixels tall. I never had any doubt that Keith would get the artwork on the cards cleaner. What impressed me more, however, was how well he made the cards really function at the smaller size.
I’d wanted to try and keep variety between the fonts on the bills, even as I simplified them. Keith, however, came in with all of the remorselessness of a game developer and cut that idea down, instead replacing everything with a simple, thick, easy-to-read font.
I’d been even more troubled by the issues with color, because I just didn’t know what to do. Keith, fortunately, showed why he’s a graphic artist and I’m not. He quickly settled on the idea of using a stripe of color around the outside, removing all of the cruft (detail) that actually appeared inside the card, and thus making it easier for the eye to quickly identify what it was seeing.
In the end we came out with something that I’m quite pleased with. I was surprised, however, at how much work just adapting the cards for the smaller size took. It probably ended up being 3 full days out of the project, when all was said and done, from initial attempts to playtest comments to working with Keith.
Next time I go straight to the artist, rather than trying to pretend that my expertise is somewhere that it is not.
The final size I ended up using for cards was 73 pixels x 110 pixels. It was up from my first try of 66 pixels x 100 pixels (and you’d be amazed what a difference 10 pixels make!). However, consider for a moment that the full table is just 480 pixels x 320 pixels. That’s really not a lot of space to fit a bunch of cards in, especially not when they each take up about 5% of that total screen space.
However, I think that Money is even trickier to display than that would imply. At the height of play you have 9-13 “decks” of cards out: 3-5 player hands, 3-5 player bids, 2 lots, and 1 draw deck. Even worse, by the end of the game, the entire deck is out and in play. That’s a lot to show!
Fortunately, the shape of the screen suggested a fairly obvious paradigm: player hands and bids to the outside of the screen, with the draw deck and lots toward the middle. It took quite a bit of fiddling to get the precise spacings right, but to the right you can see how the game ended up looking during what I call “phase 1″ of play — when everyone is making their bids for the new lots.
It’s all very tight, but the parts fits like puzzle pieces.
Most obviously, this layout doesn’t allow for a fifth player, but I was willing to omit that possibility in exchange for having cards that were more readable and a board that was less cramped (as one problem or the other would have surfaced if I’d smooshed a fifth player in, probably by making space for two players at the top of the screen). I guess I’ll see from feedback whether that was a good decision or not.
For phase 2, things got more complex, because that’s when each player has finished separating out a bid from his hand, which could have increased the 7 decks being shown on the screen during phase 1 to 11(!). I decided that knowing about how many cards an opponent had in his hand wasn’t important enough information for this phase of the game, so I just swapped all of the opponent hands for their bids. However, you do need to continue seeing your own hand. To reduce confusion I darkened out the player’s hand while simultaneously moving his bid to the right. It’s still cramped (a continuing theme!) and I may tweak my spacing just a bit in future releases, but for now I’m happy with this design 90% of the time. And I ended up only needed to show 8 decks.
Figuring out the layout of the game was another thing that took a few days of time. A lot of that was done before I put down a single line of code, while the rest tended to be little tweaks, such as when I doubled the amount the lots “fanned”, to improve their visibility.
If there’s one lesson that these two elements — the cards and the layout — taught me, it’s that adapting the visual elements of a game for such a different medium can be a lot of work, as you figure out how to make things visible, distinct, and organized all over again.
If you’d like to take a look at how those original cards would have looked in the layout, I found this early screenshot; it makes it obvious how much cleaner and brighter Keith’s work on the cards was than mine. That screenshot also offers an early look at our computer opponents, which is my final topic.
When I told people that I was going to be adapting Reiner Knizia’s Money for the iPhone, I think the most frequent comment I got was, “Wow, it’s going to be hard to write those computer opponents!” It was and it wasn’t.
Before I ever put down any code for Money a colleague and I spent an afternoon playing the game out with some mechanistic strategies used for Artificial Intelligence (AI). For example, one of the “AI” that we tested tended toward 20s and 30s, with the goal being to notch up a lot of 100 point bonuses. Now, I’ve been able to do that with occasional success in actual games, but our poor AI just sucked. He earned somewhere between 100 and 200 points at the end of our three-player game. That taught me that designing artificial intelligence for Money wasn’t going to be a simple one-step process.
When I finally sat down to program Money, I split the intelligence into three parts:
- How do you value the lots?
- Which lot do you want to take?
- What do you want to pay with?
I figured that this structure would help clarify my thinking and it would also let me design the AI with modules: you could take one valuation strategy, a second selection strategy, and a third payment strategy and combine them together. That’s essentially what I did in the finished game. It contains six different AIs, each of which has its own name and its own methodology of play, which is defined by those three aspects. (My ultimate hope is that you might come to recognize how some opponents play, but through the somewhat-opaque barrier of the screen, I’m sure that’s not quite as likely as it would be on a tabletop.) However, even with this tripartite structure, good AIs eluded me at first.
I started off looking at valuation and acquisition strategies. I don’t want to spoil how the AIs work, for those of you who decide to try out the game, but I can generally say that one of my first AIs looked at each lot (and all the player hands), calculated what their score would be after taking each one and then took the set of cards that offered the best return. That’s a considerably more sophisticated calculation then a human player would be able to do in a split-second of time, but it still didn’t produce a very good AI.
(I was the most frustrated when I’d come up with an interesting new AI algorithm, introduce it, and promptly have the AI start doing considerably worse.)
In the end, I found that general strategies tended to produce better results than algorithms; by that I mean rules of thumb worked better than calculations. For example, a really powerful rule of thumb for payment turned out to be: pay with every one of your cards except those in your top two currencies. It needed to be tweaked some and it had to be married with good strategies for the other parts of the AI, but it worked surprisingly well for something so simplistic.
When I started this section, I said that designing AIs both was and wasn’t easy. You’ve already heard how it was hard; here’s how it was easy: because Money is such a social and interactive game, the results of your play are considerably impacted by what every one else does. I currently have 6 AIs and there are only 3 potential AI seats. That means that you have (I think!) 10 different groups of AIs that you can game with, and each different group results in very different dynamics. In a less interactive game, AIs might only achieve their individual levels of success, but in a group, sometimes even Dan, my dumbest AI still in the game, can win.
(I’m sure there’s a lesson in there somewhere for all of society.)
I’m not done fooling with the AI, as they still have difficulties beating a good player very often, but I’m certainly heading on toward designing the next AI with a few more lessons firmly in place.
Around the Corner
That’s it for this week’s column. If you have an iPhone, I hope you’ll check out Reiner Knizia’s Money, play it, enjoy it, and rate it. I’ve got a long list of improvements I hope to make on future iterations of the game, if it does well enough, but suggestions on the game — either posted here or mailed to my work address — are very welcome as well.
So, what else have I been doing? My biggest recent writing project was a massive 7,500 word review of Warhammer Fantasy Roleplay, Third Edition. Even if you’re not a roleplayer, you might be interested in taking a look, because it’s a roleplaying game that takes a lot of lessons from the Euro board gaming community. That left me with time for just one recent board game review: Mr. Jack in New York.
This article copyright © 2010, Skotos Tech Inc.
Author’s Note: I’ve put five more eurogames out for the iPhone since I wrote this article, and Money continues to be our most consistent seller. I don’t know if that’s a first-mover advantage or just the fact that I choose a really good game for our first release. I’d like to think the latter, as Money has always been one of my favorites.
The AI was perhaps not as good as I thought it was when I wrote this article. More than once I’ve gotten an AI to within a hair of beating me 50% of the time, decided I was happy with the results, then had players on the internet trounce it. Go figure. In any case, it’s been improved through several updates and at least one bug fix (which kept the AI from doing what I thought it was doing).
I should end by saying we’ve made a lot of improvements to Money, and our card-game engine in general, since this first release. For example, if you look at the graphics here you’ll see an anti-aliasing problem with the card edges which I’ve since fixed and an overly-busy card back which I’ve since toned down.
My goal with reprinting these articles on Mechanics & Meeples has been to maintain their original content, with some polish and some notes, so I resisted the urge to update the screenshots in the actual article — but nearby you can see what the game looks like currently. Besides those anti-aliased cards, you can see improvements in a look of a lot of the text on the screen thanks to boxes and graphics of various sorts. —SA, 2/4/11, 6/20/12