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.
Colourblindness is an interesting one with board game conversions, as you can actually test for colourblindness on the original physical game before starting any work on the conversion – there are really great free colourblindness simulators available for smartphones that simulate the different types in realtime directly on whatever your camera is seeing, so you can literally look at the game through colourblind eyes.
For a similar nice free tool for when you’re working on the conversion, try colororacle.org, simulates it on whatever is currently on your screen.
One huge deciding factor in mobile board game conversion accessibility is the choice of how it is developed. If you’re coding it natively, there’s one group of players in particular who then become astonishingly easy to reach – blind players. It’s just a case of labelling your elements sensibly and sending a text string announcement to the phone’s accessibility service any time something important happens that wasn’t a result of a player action. Then they just turn on their screenreader (Voiceover on iOS), drag their finger around the screen, and their phone automatically uses synthesised speech to read out the names of all of the elements, allowing them to visualise the screen layout.
That’s one small group though, there are obviously lots of others, including some huge ones (8% of males are colourblind, 14% of adults have a reading age of below 11 years). You mentioned general accessibility resources that might be applicable to games, here’s a nice one that is specific to accessibility in games:
There were quite a few accessibility related talks this year, one that had a question that went the other way around – in a talk about blind-accessible digital games, a question was asked about blind-accessible board games (which is also a great topic, feel free to drop me a line if you want to know more!).
Accessibility in board game conversions does have other specific accessibility potential, due to the type of interactions required, and often gameplay being about making decisions rather than anything that requires specific timing.
So just to give one example of that potential, again if you’re developing natively it’s actually again astonishingly easy to make a game that is accessible to gamers with Stephen Hawking’s level of motor ability, due to iOS7 having built-in support for the type of assistive technology that he uses.. essentially you don’t need to care about the tech, you just make a game with a simple interface, the phone automatically moves a highlight around each element in turn, then you just make an input using whatever tech you want (a sip-puff tube, infrared blink detector, big button on your wheelchair headrest etc) and that selects it.
I hope some of that is interesting! Again please feel free to drop me a mail if you want to talk about it more, it should be stored with the reply but just in case, my address is email@example.com
Hey Ian! Thanks for you extremely thorough comment! This is definitely all incredibly useful and relevant!
Very glad to help :) I’ve since seen that your framework uses UI kit, which opens up the possibility of all of those things. You may already have made highly accessible games by accident (Zynga accidentally made Hanging with Friends blind-accessible), the settings to play with on your iPhone are Voiceover and Switch, try playing with either one of those turned on.