Get ActionChess Now

Play Go Tetris Now

Catchup Release Date, Trailer

July 15th, 2014

I’m happy to announce here that Catchup will be released on August 7th, 2014.

Last wednesday I put together the gameplay trailer (above) for Catchup and showed it at our local IGDA Twin Cities meeting. I’ll be showing the game again tomorrow night at our Multiplayer Mixer. Then next month, the week after launch, I’ll also be heading to GenCon in Indianapolis to show off the game on their expo floor.

This is definitely the most work I’ve put into a game. (If I were following my standard launch M.O., I’d have already pushed the release button in iTunes Connect.) This time around I’m trying to follow more “game release best practices”. This is mostly because I feel like this game deserves more attention. There are a couple of reasons for this, and the first is that it’s an absolutely great board game that I really like playing! Of course every game I make is one that I want to play, but it’s extra true in this case. I can’t wait to have dozens of async games going of this. (One of my beta testers has already reported playing over 25 games in one sitting, which speaks well toward engagement. Don’t worry if you signed up to be a beta tester, we’re going to be starting the “official” beta testing push sometime later this week.) The second reason for giving this extra marketing is that I think this app is some of my best work. It’s definitely well into the realm of the quality and polish that I would prepare for client work. I’ve been trying to squash every bug as soon as I see it. (There are of course one or two that I haven’t had time to fix yet, but nothing major.)

Another contributing factor to officially spending more (time, effort, & money) to market this game is that Nick Bentley, the game’s designer, has committed to doing so also. He’s already started writing about the release, offering an extremely generous “stretch goal” if we can reach 10,000 downloads. He’s going to be helping out with trying to get reviewers to write about it, and joining me at GenCon. My feeling is that getting 10k downloads is basically next-to-impossible unless we get an app store feature. But if we can get there, I have lots of ideas for additional features, including a very cool new game mode Nick has already been putting some thought into balancing and designing. I guess another reason for all this buzz and pre-release is so I can play that new game mode. I hope we can make it happen.

Color changing in Catchup

July 8th, 2014

Previously on Chesstris…

I have already written a couple of times in the last year about color customization in iOS. My post on how to change the color of a transparent image on iOS is actually one of my most popular posts (based on “organic” traffic coming from google). The other instance was when I posted the slides from my talk about Customizing iOS UI (subtitled “Fonts, Controls & Color”). Neither post stated this explicitly, but basically the main reason any of this was relevant to me was for use in Catchup, a forthcoming game release which will allow you to customize the colors of the entire application. Here are some screenshots from Catchup’s game screen, in the three “default” color schemes:


Color changing with [Style sharedInstance]

In the beginning of the project, after implementing a centralized “style” class, (as I sometimes do, usually to facilitate getting a font), I realized that it would be relatively easy to implement color customization throughout the app. That “relatively easy” feature turned into dozens of hours of extra work, and I’m going to go into detail about some of those hours here.

The basic technique was to keep track of four UIColor properties in my style singleton, loading them at application startup, and then making sure that all of my UIViewController subclasses made sure to set all the colors appropriately in viewDidLoad or viewWillAppear:. This necessitated lots of (otherwise often unnecessary) IBOutlets, but that itself was not a lot of extra work. It was definitely more work to just decide which of the four colors in the scheme should be used for each UI element, but I would not consider even that to have been a pain point.

navigation bar hell

So… I was taking my time with Catchup. Early on it was going to be a quick project, but then I decided it was a great game, and this was a showpiece for my board game conversion prowess! I wanted to do it right. That meant it was going to be done when I felt it was done. Long story short, I thought I was maybe half-finished with development when iOS 7 was announced (with its complete graphic design overhaul).

Screen Shot 2013-02-18 at 9.29.38 AMThis wasn’t necessarily a bad thing! I’d already decided to go for a flat UI design, (especially because I was drawing nearly all the graphics programmatically!) So the aesthetic of the app didn’t need to change, but in those early days, I hadn’t been using navigation bars. I was using a navigation controller in the project, but pushing and popping the view controllers with custom buttons everywhere (to the right is an early screenshot from that era). This made sense if I wanted a flat design in iOS 6, but iOS 7 was flat by default. During the iOS 7 beta, I spent an hour or two experimenting with the look of the new nav bars, and really liked how the look of the game changed with a consistent iOS 7 style nav bar.

So I bit the bullet and ripped out all my custom buttons and implementing a more traditional navigation bar based navigation. For whatever reason, (somewhere between translucency settings, barTintColor vs tintColor, not to mention Extended Edges) it ended up taking a long time to master the nuances of the new iOS 7 navigation bars. It was a lot of work just figuring out the best way to arrange my storyboard elements, but additionally I needed to change all the nav bar colors based on my color scheme! I tried a lot of different techniques before I settled on the ones I think are definitely “working” in the app today. First I tried using the appearance proxy, but that was super problematic and the colors seemed to be cached weirdly. At one point I thought I needed to style the nav bar in every UIViewController subclass, but eventually I figured out that all I needed to do was call this code on app launch (and any time the color scheme changes):

	// tintColor for the whole app (status & nav bar)
	NSArray *ver = [[UIDevice currentDevice].systemVersion componentsSeparatedByString:@"."];
	BOOL isiOS7 = ([[ver objectAtIndex:0] intValue] >= 7);
	if (isiOS7) {
		// tint color affects the navigation bar links
		[[[UIApplication sharedApplication] delegate] window].tintColor = fontColor;
		[[(UINavigationController*)[[[UIApplication sharedApplication] delegate] window].rootViewController navigationBar] setBarTintColor:[Ketchup_StyleHelper color2]];
	else {
		// ios 6
		[[(UINavigationController*)[[[UIApplication sharedApplication] delegate] window].rootViewController navigationBar] setTintColor:[Ketchup_StyleHelper color2]];
		[[UIApplication sharedApplication] setStatusBarStyle:UIStatusBarStyleDefault animated:YES];
		[[(UINavigationController*)[[[UIApplication sharedApplication] delegate] window].rootViewController navigationBar] setTitleTextAttributes:@{UITextAttributeTextColor: [UIColor whiteColor]}];

As you can see, a lot of this was to keep my backward compatibility with iOS 6, but unfortunately that meant one really big compromise — there would be no flat nav bar aesthetic in iOS 6. I’ve made my peace with that. The app looks pretty horrible in iOS 6, but it’s totally functional, and… oh well.

One additional thing I spent time on was changing the status bar text to white or black, depending on the darkness of the tint color. This only applies to iOS 7, and looks like this:

		// dark or light determines styles for status bar and nav bar
		UIColor *colorThatMatters = self.neutral;
		CGFloat hue = 0.0f, saturation = 0.0f, brightness = 0.0f, alpha = 0.0f;
		BOOL success = [colorThatMatters getHue:&hue saturation:&saturation brightness:&brightness alpha:&alpha];
		if (success) {
			if (brightness < 0.7) {
				[[UIApplication sharedApplication] setStatusBarStyle:UIStatusBarStyleLightContent animated:YES];
				[[(UINavigationController*)[[[UIApplication sharedApplication] delegate] window].rootViewController navigationBar] setTitleTextAttributes:@{UITextAttributeTextColor: [UIColor whiteColor]}];
			else {
				[[UIApplication sharedApplication] setStatusBarStyle:UIStatusBarStyleDefault animated:YES];
				[[(UINavigationController*)[[[UIApplication sharedApplication] delegate] window].rootViewController navigationBar] setTitleTextAttributes:@{UITextAttributeTextColor: [UIColor blackColor]}];

Watching the status bar when you manually change that color from dark to light is actually pretty cool, so time well spent, IMO.

Actually Changing Colors – compromises, or lack thereof

Once I decided color schemes were in, there were a number of additional questions. Would I implement a “fixed” (hard coded, but changeable later, of course) set of color schemes and allow the user to select from those? Or would I give the user rope to hang themselves and allow them to change each individual color willy-nilly? (If the former, I needed to pick some good ones, but it would also give me the option of in-app purchase for additional ones, or “unlocking” them via achievements or something.) And finally, could I allow them to choose a single color, and make a scheme programmatically from that color?

IMG_2203Eventually I decided I’m a big fan of the infinite color schemes, so I definitely wanted to give the user a color picker. That didn’t leave reason to do in-app purchase or unlocking, so that was out. Right now there are three default color schemes, but you can change each of the four colors at any time. I also implemented choosing the scheme from a single color without much trouble (you can see a purple version of that on the right), which allowed me to also throw in a button to change the scheme to match any of the 5C colors. I spent some time trying to figure out if there was a way to get at the color of a user’s phone which would allow me to default to their 5C color, but I couldn’t find a sure-fire way, and I don’t like the single color schemes quite as much anyway, so I dropped that after an hour or so of googling.

For the really curious, here’s the code I’m using to generate my four-color schemes from a single color:

	CGFloat lightBrightness = 1.0f;
	CGFloat darkBrightness = 0.2;
	CGFloat neutralBrightness = 0.6;
	CGFloat baseBrightness = 0.8;
	CGFloat hue = 0.0f, saturation = 0.0f, brightness = 0.0f, alpha = 0.0f;
	BOOL success = [newBase getHue:&hue saturation:&saturation brightness:&brightness alpha:&alpha];
	if (success) {
		self.color1 = [UIColor colorWithHue:hue saturation:(saturation/1.5f) brightness:darkBrightness alpha:alpha];
		self.color2 = [UIColor colorWithHue:hue saturation:(saturation/1.5f) brightness:lightBrightness alpha:alpha];
		self.color3 = [UIColor colorWithHue:hue saturation:saturation brightness:neutralBrightness alpha:alpha];
		self.color4 = [UIColor colorWithHue:hue saturation:saturation brightness:baseBrightness alpha:alpha];

RSColorPicker vs NOT RSColorPicker

There are a few open source color pickers out there for iOS. After I found one I liked pretty well, I didn’t spend much time looking around. (I found out later I actually know someone who maintains one, and felt slightly guilty for not using it.) Unfortunately, the one I picked, RSColorPicker, while it had a decent interface and an API that I liked, really ended up being a pain in the ass to use. I updated the code to work with a new version of it at least twice, and both times spent at least a day wrestling with it. Oddly, my initial integration probably only took a day, so my initial impression was that it was great. I think the first time was when I decided Catchup should be universal. Turns out the color picker didn’t handle @2x very well, so it was slow on iPad. Supposedly this had been fixed… but it wasn’t as easy as just updating to the latest, there were some hacks that had to be applied. I lost at least a day.

Then another time when I switched to using Cocoapods for the project, I figured this was perfect, RSColorPicker was a cocoapod! Only, no it wasn’t. They had a podfile in there, but the project didn’t use tags, and as far as I could tell it had never been added properly to the pods repository. I’d probably totally forgotten what a pain it was to update the previous time, so after a day or so, I threw up my hands in frustration and ripped the whole project out. (I had been running into compiler issues trying to just use the latest version, and it was starting to feel like amateur-hour to me.)

IMG_2201I looked around briefly for another open source project. (Evaluated my friend’s picker, but the UI wasn’t as customizable as I wanted.) Eventually I just thought to myself, “Can’t I use an image and just pick whatever color the user’s finger lands on?” That’s the solution I went with, more or less implementing the colorAtPosition: method outlined in this stack overflow answer. After all that RSColorPicker hassle, my new solution took only a few hours to implement. (You can see the picker open to the right.)

coming to color conclusions

It remains to be seen whether any of this work was “worth it”, but I definitely enjoy showing off the color changing feature because it demos well. I guess that’s basically what I’m doing in this post. Thanks for reading!

Watching videos — WWDC, Swift, POP, and grid-based games

June 5th, 2014

This week has been all about learning, and specifically about watching videos to learn. Mostly because this week is Apple’s big WWDC conference. The list of developer-specific stuff they’ve announced this week is perhaps slightly larger than usual (including a new programming language called Swift — more on that later), and I have been watching a ton of talks pouring out of San Francisco in video form. (Special thanks to Apple for releasing them so expediently!)

Normally I am fairly un-enthusiastic about watching videos to learn. I’m much more of a do-er than a view-er. I’ve got to be working with the code in order to absorb a new programming language, so the Swift videos in particular have been somewhat frustrating. I did spend most of Tuesday with the OSX 10.10 and Xcode 6 betas, and Swift specifically, but after spending a lot of unnecessary time tripping over syntax, grammar, (and copious crashes) decided to go back to videos (and getting some actual work done).

My impressions of Swift are pretty mixed. On one hand, I love that they’re trying to make a language that is simultaneously more accessible and also less prone to bugs. That is as fantastic and commendable as it is self-serving. On the other hand, I’m not yet convinced it’s going to be an instant switch for me. I had lots of little niggling problems with the syntax. For example, I’m not sure the benefit of declaring strongly typed variables using generic keywords (var and let). In the c-based syntax languages I know and love, you declare the variable with the type. So in swift:

var view = UIView()

vs Objective-C:

UIView *view = [UIView new];

Now, the first example isn’t ambiguous or anything, but how about this one:

var views = UIView[]()

This is how you declare an array of UIView objects. I do like that it will always (and can ONLY) be an array filled with UIView objects, but I do think it’d be incredibly easy to miss the brackets. Overall though, most of the problems I had weren’t with the language itself, but with the tools, which I think are just not ready yet. I mostly agree with Austin Zheng when he says (from the comments of his 2048 port to Swift): “Xcode is as unstable as always. The background compiler/code analyzer kept on crashing and restarting itself. Xcode was functional enough to allow the project to be brought to some state of completion. The debugger is horribly broken though.”

All my video learning this week actually started on Monday (while waiting for the WWDC keynote to start) with watching Facebook’s video on building the paper app. This is also the one in which they announced their open-source animation framework pop. (And was recommended to me to learn about why it might be useful.) At an hour and a half, it’s a long video, but worth watching not just for the pop stuff (which is absolutely interesting, particularly if you already use Core Animation in your code), but for a multitude of other insights into how Facebook writes it’s apps. (There is some seriously interesting iOS engineering going on over there, something I did not expect given their history and track record, particularly in the quality department.)

Finally, yesterday (after fully maxing out on more WWDC videos), I randomly stumbled onto a talk about SpriteKit and grid-based games. The first half of the talk, by Scott Kim goes into great detail about several different kinds of grid-based puzzle games (on iOS specifically). He more or less breaks the talk into categories organized by gesture, which I think is an arbitrary distinction. (I’ve talked before about how I think the best games provide both tap and drag control schemes that are not incompatible.) Otherwise I think he does a really great job with the topic, and while it’s nowhere near comprehensive, it’s a very nice introduction / survey of the topic. This is very close to a talk that I’ve been thinking seriously about writing. (I first mentioned this idea in a previous blog post.) But since I haven’t (yet) written my taxonomy of grid-based games, Kim’s talk is, at the moment, much better than mine.

Catchup for iOS – the last 10%

May 20th, 2014

I just looked back through older blog posts on here, and realized that I have not talked about Catchup as much as I should be talking about it given that it’s my next big game release. (I didn’t even have a blog category for Catchup until I added one just now!)

The game is really starting to shape-up and near completion. A few weeks ago I posted the vine above of the new hex particles when I got those working, and I don’t know why I didn’t post that here. My list of bugs is basically just down to one, and the list of features I want to add is also miniscule. Oddly, my TODO is still super long, but the only real tasks that I’ve committed to completing before release are: 1) Flush out achievements (there are a few in there right now, but potential for so many more), and 2) really hammer on the async code to make sure I’m utilizing all of apple’s push notifications to their full effect. This second one includes writing some code to show the async move as it comes from the server, if you happen to be looking at the game screen when that happens. It’s an edge case that a lot of apps ignore, but I feel a relatively frequent use-case, given the short-timeframe nature of turns in Catchup. Also, it will allow you to essentially play games in real-time, even though it’s still async code through-and-through.

One question I ask myself a lot is why it has taken me this long to get Catchup this near completion. There are lots of factors, of course, but I’d initially scoped the game (back when it was Ketchup) as a very quick-and-dirty conversion, really just the simplest game I could think of that would allow me to write the GameCenter asynchronous code that I’d been wanting to write. But after I got Tysen Streib to agree to help write the AI, and as soon as the game was playable against that AI, I quickly decided I should really make an attempt to put out a “full featured” board game conversion on my own. This meant a lot of things to me, but psychologically, I think the scope of the game ballooned WAY out of control. For a while there, I really thought I was going to write ALL the features I put in the TODO. If I’d had nothing else to do the entire year, from when I started Catchup in Jan 2013 until now, I might have completed all those features. (Instead, I spent about six or seven months of last year working freelance gigs so I could pay my bills.) I’ve also taken relatively frequent “breaks” to work on other games, mostly game-jam scope games, but I’ve spent over a month at this point working on Action Go, as well as about a week writing universal updates for DrawCade and my Fez Translator.

There are a lot of posts I could write about Catchup for iOS. Here are some ideas for topics:

- Why (else) has it taken me over a year to put this game out? (Short answers, which could all probably be their own blog posts: Polishing a game is hard! Managing scope on a personal project is hard! A “minimum” list of features for successful board game conversions turns out to actually be A LOT of features. And finally — this could probably be its own post — how bugs in your code can move into the realm of psychologically demoralizing and depressing, and possibly keep you from wanting to work on your project.)

- About Color customization, or why you shouldn’t allow your users to customize the colors in your app. (How I did it for Catchup; why it was “easy” but still took up A TON of time; and the trials and tribulations of using an open source library that is poorly written.)

- How catchup uses Generic Game Model. (Which is basically the story of why GGM has hex support at all.)

- About the features that I cut for version 1.0 of Catchup: showing a list of games with visual previews (like in Carcassonne!); ELO for online games; saving of all completed games, and the ability to review them turn by turn; IAP and/or Ad supported version of the game, Player avatars (or even just showing GameCenter avatars in-game). I could talk about how I chose (or basically, for a long time, didn’t choose) which features would “make it”, and which wouldn’t.

- A post about how much money Catchup needs to make for me to break even. (I’ve actually started this post already, but didn’t get too far, as it’s rather a depressing topic.)

- A post about the Game Center asynchronous code, possibly including making my GameCenterAsyncHelper class available publicly.

- A post about convincing other folks to work for nothing on your personal projects. Why it’s generally (I think now) just a bad idea. I suppose this could also be a post about paying for artists versus just making all the art yourself (where I started versus where I ended up).

Let me know in the comments if you really want to see a particular one of these ideas flushed out, or if you have some other specific question!

Quality vs Quantity

May 7th, 2014

Advisable or not, I clicked through this morning from twitter to an article titled Apple Is “Nearly Invisible” On GitHub, But Does It Matter?. As I mentioned in reply, I think there’s some hyperbole there. Specifically, the numbers are being interpreted in a way that spins the article, but I did find the numbers interesting!

I really just wanted to comment longer-form on this one quote from the article:

41% of Android developers said they finish apps in one month or less, while only 36% of iOS and 34% of Windows Phone devs said they could achieve as quickly a turnaround

Now, if it took more effort to make exactly the same application for iOS than I would see that as a problem. But in my experience (and I do have knowledge of several parallel projects for both platforms) the effort is pretty similar. (Some things on either platform take longer on one or the other, but I think it generally averages out.) Now, as any software developer knows, you can either make something good, or you can make something fast… So given that data point, one interpretation of the quote above, at the risk of maybe pissing off some folks, would be that this generally speaks to the quality of the average Android application. Essentially (and again, this is just one possible interpretation), iOS applications might take longer as a trend because more effort is put into making them. Or alternatively, possibly they are just worth more to whoever is funding their development.

thoughts on CCG & LCG apps

April 16th, 2014

Today Hearthstone is finally available worldwide, and I will definitely be spending some time with it on my iPad. I have played it a bit on my desktop, enough to get the feel of it, and decide I wanted to wait until it was available for iPad. (Mostly because that’s where I spend most of my time gaming.)

I’m not really interested in commenting on the F2P mechanics, (since enough has been made elsewhere of how “gentle” they are in Hearthstone, or how “right” Blizzard is getting it), I’m more interested in a study of the game mechanics independent of the monetization strategies (no matter how closely they may be coupled). From what I saw at GDC, Blizzard really spent a lot of time trying to make Hearthstone accessible to the masses. This manifest in a lot of different ways, but essentially they are balancing card abilities and deck compositions (for pre-built decks you encounter and use early in the game) to help new players.

I never really got into Magic the Gathering. I know there will be some of you that stop reading at this point, but I guess what turns me off about it (and, realizing this, the entire genre of deck-based-fighting-games) is the direct conflict. Most of the card abilities deal with combat. Dealing damage to your opponent is a (if not THE) central mechanic, and I guess I just find that emphatically boring.

A month or two ago, I did get pretty into Card Wars, a LLG (CCG?) inspired by an episode of Adventure Time. It was a great episode, and made everyone who saw it (well, everyone I’ve talked to) want to play the game. It’s a lane-based game like Solforge, Spectromancer (or it’s sort of predecessor Kard Combat), or Kongregate’s more recent Tyrant Unleashed.

The first Hearthstone talk I saw at GDC (I saw two) was one about the AI, and I was pretty much entranced by it, loving this slide of the overall architecture:

I guess this is another one of those posts where, if I had infinite time, I would dissect the mechanics I like about each of these games, and draw a cool diagram or something, but I don’t have the time, and I’m going to go download Hearthstone now, before I forget.

An Introduction to Generic Game Model

April 10th, 2014

Here are my slides from the presentation I gave tonight at the MN Cocoaheads group about my open source 2D game framework, Generic Game Model.

Martin Grider will share and discuss a few classes he re-uses from project to project allowing him to rapidly flush-out 2D games. The classes themselves are not all that notable, as most developers could probably re-create them in an afternoon, but the techniques are particularly suited to rapidly prototyping turn-based games. He’ll discuss some of his favorite rapid prototyping techniques, as well as talk about “juicing” animations in UIKit, (with a bit of quartz core, as well as a bunch of external libraries thrown in for good measure).

As you can see, if you looked through the slides, I have already used this code in a rather large number of projects in the last two years. I was surprised myself, to be honest. At least 8 projects use this thing, 3 of which are in the app store.

My first Cocoapod
While prepping for the talk, I also turned the project into a Cocoapod. I had played around with cocoapods once before, only long enough to install it and run pod install on a test project, (a process which is, if anything, too easy!), but actually creating a pod myself was a new experience, and bit more work than I’d expected going into it. Anyway, you can now add pod 'GenericGameModel' to your projects to try it out for yourself.

Thanks to Bob McCune for running the show and letting me speak!

My GDC 2014 talk is available in “The Vault”

April 8th, 2014

The GDC Vault has a ton of old Game Developer Conference content. I think they’ve been recording all the sessions (or most of them) for at least a few years now.

Anyway, my talk Usability Lessons from Mobile Board Game Conversions is now available over there. If you follow that link without being logged in, you’ll be able to see the slides (which are also available in my blog post). I’m not sure about the pricing for premium access, but if you had an “all access” pass to GDC, a vault membership is included. Anyway, if you’re logged in, the full video of the talk is available, in a pretty neat player that includes both my talking head, as well as the slides.

I wanted to talk about the Q&A at the end. After I gave the talk, I left feeling like I’d done an okay job with the Q&A, but when I asked my friend August his honest impressions, he essentially said that part was a train wreck. Watching it again, it was worse than my initial impression. I essentially didn’t answer anybody’s questions clearly. Not sure what was going on, but my brain was basically mush. I thought I’d summarize the questions here, and give some “real” answers if I can. I apologize in advance for not having anyone’s names. None of the questioners introduced themselves, and we have no video of them, so I essentially have no idea who asked these questions.

Why no love for Stone Age?
The first question was about why I hadn’t used any example screenshots from the Stone Age conversion. As I said at the time (maybe I did answer at least one question adequately), I had intended to include some screenshots of this, but essentially hadn’t been able to get a screenshot that I liked or that illustrated one of my points well. Another reason is that my talk was originally about twice as long, and I cut a ton of it to fill the 25 minute slot, so there’s that. I’m sure I could also come up with a list of other games I would have liked to include but didn’t. Looking at the folder of async games on my phone, Stone Age and Lost Cities were the only two that I didn’t include.

Board Game Accessibility
The next questioner was essentially asking about comments or best practices for accessibility in board game conversions. I was not prepared to talk about accessibility at all, I rambled a bit about player colors and how it was a good idea, but had no real suggestions. I think accessibility is a HUGE topic, and essentially my mind was boggling with the various ways I could have tried to tackle it on the fly. I think the first and most obvious point is that you should think about your audience. As with usability, you should be intentional about your accessibility, and by that I mean you should spend some time and think about your audience. Then think about how you intend to make it easy for them to play. If it’s important that you help color blind people play your game, you’ll obviously want to do testing to make sure that they can. There are numerous resources available for online accessibility, and a lot of those probably apply to games, but there is at least on site devoted to the topic of video game accessibility. There is also an IGDA SIG (special interest group) devoted to game accessibility. Note that the questioner was asking about how any of this might apply to Board Game Conversions specifically, and unfortunately, I still don’t have a good answer for that.

Watching and commenting on game plays
The next questioner was asking about watching play-throughs (especially of “expert” games), as well as commenting on those games, and wondered if I had any suggestions for how to implement such a thing. In my rambling answer, I mentioned that the Go community highly values this sort of thing, and that there are a few Go apps that do include this sort of thing. (The same is definitely true of Chess, although I’ve seen fewer apps that allow you to comment or add your own comments.)

I guess any practical advice for allowing others to replay and/or watch game replays would probably depend on a lot of factors. Where will it be played? In the application only, or do you also want to capture physical playthroughs? (If you don’t have cross platform, you’re limiting the audience for the replays, and probably not capturing enough of the games that are being played to be seriously meaningful.) But if you allow the games to be viewed outside of the application, (say on a website or better yet by publishing your file format specifications and the gameplay files themselves), then you’re opening up another big can of worms. How long does the game take to play? Will these playthroughs take as long to watch as playing a game? (Ideally, they would not.)

I think a salient point (that of course I failed to make at the time) is that there is a file format specifically for recording games called SGF (Smart Game Format). SGF is used to record quite a number of simple games, but is limited to two-player games. It’s quite commonly used to record Go games, and for a long time I actually thought SGF stood for “Smart Go Format”. I’ve evaluated it once or twice, and essentially found it too confusing to seriously consider implementing. It’s not a human readable format (though it is text and not binary).

Any conversion will already have to think about how best to save the game. Sharing gameplays is as easy (or hard) as sharing that format. But of course, not all formats allow you to re-play the game. I guess I feel like allowing the game to be replayed from the beginning is a feature you should strive for (ideally) anyway, and of course one benefit of that is that it allows the replay to be watched by someone else. Ideally, you’d then build some kind of commenting system on top of the save format, saving the context of the comment (when it occurs) as well. Of course then you have to build an interface for viewing those replays as well as viewing the comments on the replays. Finally, I think it’d be important to have some kind of moderation of the replays. If you simply made all games played *ever* available for viewing, it’d be too hard to find the expert games. You’d probably want to allow the community to rate the replays or otherwise allow your community to filter and/or otherwise determine what replays have value. Eventually you could filter by actual engagement, ie, how many comments does a game have on it, how many times has it been viewed, etc..

Thinking about usability for the system that allows you to watch the replays will be a big deal. (And probably highly dependent on the game itself.)

I clearly do have some interest in this sort of thing. It’s a shame my comments at the time were so inadequate to the topic.

I have to admit that after several listens, I still couldn’t quite understand what the final questioner was asking. He sounded eloquent but I don’t really feel he got his question across. He was asking about examples of “specified language or tools” specific to individual games. At the end he gave the examples of Monopoly or Go, and seemed to be asking how tailoring a conversion for one or the other might be different. I guess my response should probably have been that EVERY game does of course have its specifics, and a general study as I have done will of course not be able to capture the nuances of each game. I guess I feel like all games have a language, or definitions anyway, and one of the first things I do when writing a board game is decide whether I need to include a glossary at the beginning of the rules/instructions. One of our jobs as designers is to shape those rules unambiguously, and attempt to reduce semantic or subjective misunderstandings.

For The Win app — relaunching soon & app store rejection

April 4th, 2014

003.ftw_splash@2xSo I mentioned in a previous post that the For The Win app I worked on for Tasty Minstrel Games was removed from the app store, (embarrassingly right before I spoke about it at GDC). When I emailed Michael at TMG, he revealed that it was just not making enough money to justify paying the $99 to apple to keep it there, and he was happy to let me put it back in the app store under my own account.

So I spent some time last Friday and updated it for iOS 7, fixing a few minor cosmetic bugs here and there, finally submitting it around the end of the day.

Long story short, Apple rejected the app, for the following reason: “11.1: Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected” They clarified with the following statement: “We found your app inappropriately unlocks or enables additional functionality with mechanisms other than the App Store, which is not in compliance with the App Store Review Guidelines. Specifically, your app allows users to unlock avatars by subscribing to a newsletter, following on Twitter, or liking on Facebook.”

Okaaaay… So a couple of reactions: 1. Obviously, this functionality was approved in the original app. But maybe they just didn’t catch it then. And 2. Doesn’t like every 3rd game in the app store do this? I mean, seriously, I see games giving extra currency for FB likes or even just twitter comments ALL THE TIME. Doesn’t candy crush unlock each level pack with Facebook interactions? (Although now that I think about it, those interactions take their friends back into the app, which is maybe how they get around this issue.)

Alright, so my arguments probably amount to “But everybody else does it!” I’ll be making some changes to just give everyone the avatars all the time (and probably re-word the achievements) and upload a new binary… probably sometime later today.

Oh, and by the way, since the app was in the store for about a year, and presumably some people paid for it in that time, I’m just going to put it up again for free. So the folks who downloaded it before can get it again without having to pay. I am considering adding the following functionality in an update: making it Universal, and asynchronous multiplayer. If and when I do that, I’ll probably shout about it some, and then make it paid again.

Five Years in the App Store

March 29th, 2014

It’s pretty amazing that it’s been five years today since I had my first app approved.

Screen Shot 2013-11-21 at 11.23.05 AM

It’s been a fun ride.