Feature requested in a customer review in the USA app store for 0.11.1.

Research documents:

Entry point to Apple's documentation about Game Center
WWDC 2013 session video on the topic of "Turn-Based Gaming with Game Center"
Game Center Programming Guide

Basically, what this is about is an API by Apple that helps with finding other players, organize whose turn it is, and send game data from one device to the other (maximum of 64 KB). The Apple Game Center service takes the role of an intermediary between players.

There are already a number of Go servers (e.g. KGS) that could be used for finding other people to play with, so it's questionable whether this feature makes much sense. One advantage that turn-based gaming has over a server such as KGS is that turn-based gaming is asynchronous, i.e. players can take turns whenever they have time. However, there is already the Dragon Go Server (DGS) which fills this niche, and on iOS there is the app Dragon Go Client that lets people play turn-based matches on DGS.

I think the key differences with Game Center are familiarity and simplicity. Case in point, I showed my mum (in her 60s) how to play go on her iPad and she loved it (she actually beat me in her second teaching game, albeit with a pretty hefty handicap). She'd love to play me more (I live a long way away), but KGS and IGS don't really offer the simple familiarity of a friends system and push notifications for invites etc; they generally present a sort of intimidating interface, particularly if you want to arrange a private game, just remotely. I haven't used dragon go, but again it requires some third party servers and registration. Explaining all this to my mum, and organising offline, eg via text message is a bit too much.

The apple 'ecosystem' for these sorts of things is based around the 'just-works' mentality, and I think little go could fill a gap in the market here. Since Boardz was removed and none of the paid aps I have come across seem to support a simple private pvp system, I think Game Center, with its familiarity and peer-to-peer nature could work nicely. The matchmaking could work too, but as you say the larger networks are likely to do that better. It's possible of course; a simple Elo go ranking system could work well, though I think achievements and friends and invitations and voice chat are probably more worthwhile than global leaderboards.

But anyway, I like little go and I think this is a good idea. So much so that I'm willing to implement it. The vision is mum can send me an invite, I get a push notification, can accept and we can start playing a game (eg of an evening), chat and review and save our games for the inevitable showing off next christmas! Maybe after 50 games I get the 'lose your first 50 games' achievement...

I have some ideas about how it could work which, if you're interested, we could discuss? There is a slight challenge with this in that to use Game Center in dev you need to enable it in get iTunes connect and set up provisioning profiles. I'm not sure exactly how to achieve this via a 'fork' but I'm willing to do the research, though I suspect I will require some input :)

Let me know if:

you think this is a just terrible idea, or if you think it is doable
you've had ideas about how to do this already, or any existing plans

My credentials: 10 years as a c++ software engineer at a global organisation (no formal iOS experience, but hobbyist)

I have no specific plans for the feature, I just know that it is one of the better ideas lurking in the issue queue. So if you are interested in getting this implemented, hey, welcome aboard!

I suggest you contact me via private mail under herzbube@herzbube.ch so that we can discuss more details.

Just to let you know, in case you're wondering, I've been tinkering, reading and prototyping a bit. I've made some good progress on understanding what needs to be done. It's quite a lot of work and seems to end up being quite pervasive, as you can imagine. I'll send over a more detailed update soon, just wanted you to know that I haven't given up on this. I solved the game centre problem temporarily by changing the bundle id locally for testing and setting it up myself in iTunes connect.

I do have one quick question if you have time: what's the role of fuego in a human-vs-human game? I see that by default fuego thread uses 100% CPU after a handful of moves when i play human-vs-human. It seems to be the pondering. I think that due to the use of the "default" fuego profile set to maximum strength, the app uses lots of power/battery pondering, but i can't find a good reason for it to think so hard. I suspect there's a good reason fuego is busy even though it doesn't get to play, such as in case the user hits the "computer play" button, but i thought i would check. (in game centre match, i expect to hide the computer play button - no cheating!)

Since you didn't contact me I have been wondering a bit :-) Good to hear that you were successful in setting up the project - it's always been a bit of a worry to me whether the whole build process would be intelligible to anyone but me.

Re your question: You have guessed correctly, Fuego is pondering in the background mainly so that it can provide good suggestions when the user taps "computer play". It's also useful when the user wants to see "Player influence" - more pondering time translates into better accuracy of the influence estimates.

At the beginning of the game no pondering is going on probably because the moves still match Fuego's opening book. I guess pondering starts as soon as the actual moves start to deviate from the opening book moves. Whether or not the "default" profile should be set to maximum strength is, of course, debatable. The user can change the strength, but I suspect that not many people will find those settings, so it might be worthwile to think about changing the "default" profile to strength 4 (i.e. no pondering). I'll have to think about this...

Hiding the computer play button in game centre matches sounds reasonable. Of course, given a sufficiently high developed urge to cheat, this will not stop someone from getting help elsewhere, but let's not tempt them unnecessarily :-) Do you think the button should be hidden in local human vs. human games as well? I must admit that I have never really thought about it being used to cheat, I kind of assumed that people would use it to let Fuego show them alternatives when they discuss their games.

One more thing before I shut down: I noticed you have forked the repo, so I assume that you have seen the stuff I did to update the project to Xcode 6 and iOS 8.

Well, i'm not going to lie - the build process took me some work to get going on my system. But you have documented most of it in human-friendly format and the scripts are simple enough to understand, so most of the effort (for me) was that I didn't have enough disk space on my mac to download earlier SDK versions (SSD was a great idea, except... limited) so i had to upgrade the project to iOS 8.1 just to build it.

Thanks for the explanation on pondering. Changing the strength to 4 with no pondering will likely save valuable resources on the devices. We also have the option of just not pondering of course.

One option with the computer play is perhaps to change it to computer "hint". Other go games like SmartGo have this sort of feature - it's still "cheating" but it allows you to decide if the computer move is in any way better than the one you've been reading for the last minute or so :) I think for any human-turn where computer-play is initiated, it might make sense to have a confirmation dialog. In a local human-vs-human game it is less easy to cheat because you have the risk of a punch in the face, whereas in the local-human-vs-remote-human the remote player won't know.

Yes i forked the repo. I'm new to this github lark, so I have been doing the development in my clone of the base repo. I will add my repo as an upstream and pull across from the main repo. And yes, i noticed you also upgraded the project to iOS 8 and did a much more thorough job than I did.

Finally from me for tonight, a progress update. I have a working* prototype turn-based game. For some definition of working. You can start a game, invite a player and play alternate moves in the game. Brief summary is that i'm using the "backup" sgf file as the game data (the game state stored in Game Center) and using the LoadGameCommand to load it when it is the local player's turn. This is quite slow on the iPad 2, but works lovely on the iPhone 5s and iPad Air 2. I suspect this will require more thought, but it has been a very enlightening experience in terms of the foibles of Game Center and has given me a pretty good idea of what is needed (with less hacking than in my current prototype). I have found your excellent documentation and code comments invaluable in getting to this stage, so thanks - it's something quite rare, even in the professional world! I'm still working on a complete specification/design which is starting to look more in focus now that I can see the game mechanics in action.

There already was an old feature request for "computer hint" (issue #28). You've made me think about this again, and I must admit that when I take all the implementation details into account the feature suddenly seems quite attractive. I've added my thoughts to the issue and promoted its prio a bit. Thanks for giving me these jolts! :-)
Coordinating our work: I'm pretty new myself to GitHub's collaboration features, so let me quickly write down the process that I think should yield the best results. My ideas are based on my understanding of how pull requests work, after reading the GitHub help pages in the section "Collaborating".
- You fork my repo on GitHub (you already did this).
- You then clone your forked repo to your local machine and work on the local clone. Make sure that you work in a newly created topic/task branch. The topic branch must branch off of "develop" (because that's where I finally want to integrate your changes).
- You push your local changes to your GitHub repo.
- You create a pull request that I can use to integrate your changes. When you create the pull request, make sure to select the branch "game-center-164" in my repo to receive the pull request. This is a topic branch I just created, based on "develop" but without any commits. I plan to integrate your changes via my own topic branch because I expect this to be a fairly large and possibly long-winded process, and I want to keep my "develop" branch in a clean state that allows me to create an App Store release at any time. Having my own topic branch also allows us to sync intermediate steps of your work.
- To minimize the risk of huge conflicts when it is time for the final integration merge, I suggest that you sync your repo (and especially your topic branch) from time to time with the changes in the "develop" branch in my repo. I am aware that this adds the burden of resolving conflicts to your work, so I will try to refrain from making any sweeping changes :-)
Your prototype: That description sounds deceptively simple :-) Earlier you wrote that changes were pervasive, can you provide a hint or two about that? Don't let me push you, though, I'm just curious. Regarding using the .sgf file as the Game Center data: My thoughts went into the same direction, it's quite an ideal vehicle for the pure game data. The only thing that we need to be sure about is that the .sgf file does not grow larger than the maximum size allowed by Game Center (I believe I once read something like 64KB?). Maybe check out how the file looks if a game has 500 turns? But then I guess we can always solve the problem by sending the file zip-compressed.

1, no problem :)

Yep, that approach looks great and is roughly exactly the github model. i just recently learned it by contributing to the (quite wonderful) YouCompleteMe vim plugin.
The best designs are deceptively simple, right ? :) Yes it is slightly more complicated than that, but not fundamentally. It's pervasive in that there are tendrils, the complexity of the actual logic isn't very high though. Let me try and give a quick summary of the approach so far, and what my thoughts are going forward.

Lots of the below is just brain-dump notes, so forgive me if it isn't totally coherent. A lot of the way the prototype works came about from ignorance of the game centre mechanics and the littlego architecture/mechanics, so I think now is the time to decide the approach rather than hacking much further @)

Game Center overview

The Game Center programmer's guide contains most of the information below, but I have summarised what is relevant to littlego.

Game Center players:

each "player" in game center world has a Game Center ID and represented by a GKPlayer* which the framework creates and populates
game center API has a concept of the Local Player (always seems to display as “Me”) represented by GKLocalPlayer* object (a singleton)
remote players are represented by GKPlayer* objects, usually as part of a GKParticipant* array
the local player must be “authenticated” by Game Center, and the user may choose not to (thus disabing GC capability) authentication needs to happen "asap" upon the application starting, as the application may have been started as the result of selecting the game from Game Center app, or as a result of a push notification.

Game center matches

a match represents an ongoing game, including the list of participants
match object provides ways to update the current game state etc.
matches can be initiated either from an invite, or by initiating matchmaking locally

Game Center has 2 types of match which are interesting to us (i think we can ignore writing our own comms and running our own servers!) :

turn-based match
real-time match

Turn-based matches

Game Center does a lot of the heavy lifting: The game is modelled like a table with each participant slot populated by a player. At any one time, it is one player's turn and that one player can update the game data. There's a nice video on this from WWDC 2013 - search the page for "turn"
communication works by serialising the game state to the game kit server by setting an NSData* property on the match object at the end of each turn. the device whose turn it is currently downloads the game state, plays their move, then uploads the game state.
this model works nicely for casual games, and is the "ideal" mode for mobile devices.
this model is the simplest to implement, requiring the least effort on the part of the game developer
go is, after all a turn-based game, so this mode seems attractive. The turn-based nature does not prevent the users from playing in realtime - push notifications for move changes are in my testing immediate (and can be effectively hidden within the UI)
a challenge with this mode is that the Game Center match creation returns before each of the player “slots” has been filled, so if you initiate a new game, you get back a match with only yourself in it, and one empty slot. An invitation is only sent once play is passed to a specific participant.
negotiating the game properties could be tricky, but iOS 7 provides "Exchanges" which could work well to ensure that the opponent accepts, and to agree things like who plays black/white and what sort of handicap/komi. this needs more thought; in the prototype the player initiating the game plays black and sets the game parameters (in fact, there is a massive hack in there at the moment, which i am too embarrassed to admit to)

Real-time match

both players remain connected directly via a apple-provided peer-to-peer API. GameKit handles comms and provides API for communicating. built-in support for voice chat.
This also seems to be the most popular type in terms of existing online go games (Pandanet/IGS, OGS, KGS). It allows things like thinking time and real-time chat. It does purport to require more game design, but I think it offers the most flexibility.
The matchmaking process typicaly waits until a full set of players is available
communication works by peer-to-peer proprietary protocol. i suspect using GTP is the right thing to do between the devices, but i know very little about GTP.
this mode would require more work, but may lead to a more engaging experience.

What i've done so far

Players

authentication needs to happen “as early as possible”. This requires popping up an obtrusive UIViewController* which displays the login some time when initialising the app
This needs to run in a “AsyncronousCommand” to prevent the view controller racing with the status HUD

Then we need some way to integrate Game Center players into littlego’s Player classes

integrate Game Center ID into the Player class (nil for any player which is not a Game Center player)
add “isRemote” flag to indicate that the “human” player is remote (so cannot play turns directly) and doesn’t require fuego to play for it
if playing the same remote player multiple times, find their UUID by searching on Game Center ID
create “emergency” players on the fly and store them in the dictionary “keyed” on Game Center ID
when authenticating the local player, or starting a match whose with a remote player
- if the Game Center ID is found in the player DB, use that Player object
- otherwise create a new Player object with the ID/display name from the GKLocalPlayer object
- if it is the local playe, set isHuman = YES, isRemote = NO
- otherwise, set isHuman = YES, isRemote = YES
To solve the "remote player isn't invited yet" problem with new turn-based matches, create a “magic” dummy remote player to use after matchmaking completes, but before the actual remote player is confirmed by GK. Once the remote player does something, replace the Player with the new or found Player representing the real remote player. (this feels like a hack, and i hate it. I think the whole "starting a new game" for Game Center needs reworking)

Starting a game manually (new game command)

add a new panel to NewGame view, GoGameTypeGameCenter
option for the local player to play as white or black (hack: reuses computerPlaysWhite option, and in fact doesn't really work as the initiator has to play black at the moment!)
other usual options for board size/komi/etc.
upon selecting “done”, start the matchmaking process, using the stock view controller
start a game (NewGameCommand), using dummy remote player in white slot depending on the option. if it is black’s turn and local player is white, tell game center that it is the next player’s turn. (error: currently causes the game to crash because game data is nil)

I think this needs more thought and i suspect the use-case should go something like:

user selects new game, then selects game centre
the matchmaking UI shows up, and the user can choose to invite a player or select an auto-match player
user then selects game options, such as board size, komi/handicap, etc.
it is local user's turn (always at this point). Local user issues a "Setup Game" exchange to remote.
- the exchange request includes the game configuration
- we also store the game configuration (new game model) in the game data and push it to the cloud
invite is sent to a player, and they are presented with a push notification
- when accepted, they are presented with the proposed game options with the option to accept them, reject them
- the exchange response contains accept/reject
the originator gets a notification to say the exchange is complete and we display the result
- if the remote accepted, then set up the game from the game configuration in the match data request then set the player objects up appropriately. if it is the remote player's turn, set the game data's sgf file to nil and switch the turn to the opponent, otherwise display the board etc. and play is switched when a move is played
- otherwise, complete the game, setting the outcome to something meaningful like game declined and don't update the scores

Playing a move

add "GoGame::isRemotePlayersTurn:" and have it return YES if the current player isRemote property is true
ensure that everywhere that looks at game type is updated to know about GoGameTypeGameCenter and mostly treats it like GoGameTypeHumanVsHuman.
when it is the remote player's turn prevent the local player from playing a move (TODO: haven't done this yet nor worked out how) and display a banner like "Remote player is thinking" similar to the "feugo is thinking" message (also not done yet)
after the turn is player, save the game data and switch the turn to the other participant

Game representation, GameKit data, and communication protocol

game data is just a dataWithContentsOfFile: for the sf backup file
however, this doesn't quite have enough information in it (such as which player is black!)
game data is restricted to 64K, need to test the maximum size of a game sf file and the runtime performance of compression

Receiving a turn event

use the LoadGameCommand suitably modified to read the backup sgf from a supplied NSData*
todo: remove the loading HUD if the app did not become active as a result of the notification. In testing this on an iPad 2, the loading hud is noticeable - the problem is not that it is slow, just that it is jarring. If the game is already active, we can simply pretend that the "loading" time was actually the opponent "thinking".

Ending the game

not implemented yet, nor given much thought, but challenges include:
marking of seki/dead stones. this may have to be implemented via an Exchange or perhaps a special game mode where each player is asked to mark her own dead stones, then pass the turn to the remote. Once both players have done this, we ask fuego for the score.
calculating ratings. i think to start off with we would just implement the simplest Elo rating calculation. nowadays a single player can update the ratings for all participants which helps with this.

Viewing existing games, resigning and multiple simultaneous games

also requires some thought. Currently reacting to a notification wipes any in-progress game data. that's obviously got to be fixed, perhaps by storing the current game centre data in different place and then recovering from the "local game" backup.
players can resign at any time, even when it isn't their turn. in which case the other player gets a notification and they mark the game as completed and update the scores based on win for the local player
multiple games - there can be up to 60 games being played simultaneously for a given game centre player, so we need a smooth way to switch between them, look at the current status of them, etc. It is jarring to have to select new game to "load" an existing game centre game which is how it currently works in my prototype.

FWIW if you're curious, i have pushed the hack prototype to my repo as game-center topic branch: https://github.com/puremourning/littlego/tree/game-center. Like i said it's very hacky for now.

Ben, thanks very much for your outline! I just wanted to let you know that I've read through it and made some preliminary notes myself. I am very curious about what you have there, and will take a look at your topic branch ASAP. Please give me a few days, though, the next week could be a bit stressful work-wise - and I'm also in the middle of cobbling together the new UI for the iPhone 6 Plus. I don't work on Fridays, so I should have time then at the latest.

One final thing: This issue is getting a bit long... what do you think of moving our communication somewhere else? I don't know what the best alternative would be, though. I am used to mailing lists, but this may be too old-fashioned. Or if you like we could try GitHub's wiki feature? Any other suggestions?

This was a really cool experience: Clone your repo, build everything, run, it works. Great!

I must admit, though, that I haven't taken the time yet to set up the app configuration with game center capabilities, so I haven't been able to fully test your prototype. Also, I still need to read through the Game Center Programming Guide.

I have reviewed your code changes, and for a prototype this has certainly been neat work! Even if there are some hacks - hey it is a prototype, so no need to be shy. For the same reason (it being a prototype), I think it doesn't make much sense if I am nitpicky about any details. The only thing that I would like to mention is: Do we really need a new game type? Game Center games have two humans playing against each other, so IMHO GoGameTypeHumanVsHuman is still appropriate. Maybe we could give GoGame a new attribute "isGameCenterGame"? We would also have to create a new enumeration that directs the logic in NewGameController and NewGameCommand (e.g. something like NewGameType).

Instead of moaning about code details, I have decided to write down some details how I imagine things should work. This includes design guidelines and use cases that (I hope) should cover game setup, match making, and turn play - all except the end game, which I haven't thought through yet. You can find everything on this wiki page. Some notes:

Some of the stuff I wrote covers the same tracks that you already went through in your brain-dump notes, so that's reassuring. Some of the stuff is a bit different, though, I hope you can live with that. Although I am always willing to discuss things if there are good reasons. Also I still don't know too much about Game Center, so some of the things I imagine may be plain wrong.
Use case UC2 is simplified, I was lazy, I admit it. It should be combined with your "starting a game" use case where you demonstrate a much better grasp of Game Center mechanics than I have.
I am not sure if UC6 is always the right thing to do. It very much depends on how this use case can be initiated, i.e. how is step 3. possible? Can the activation happen without user interaction? Then UC6 is wrong. Can the activation happen only after the user somehow confirmed the turn event? Then UC6 is correct.
Restoring GoGame from a .plist (see storage guidelines and use case UC3): This is an optimization that, although important to improve usability, can be added at the end when everything else is done.

My next steps

Read through Game Center Programming Guide
Add Game Center to the app configuration so that I can fully test your prototype

And some final stuff that didn't really fit in above:

Regarding real-time matches
- I suggest to implement turn-based games first and to wait with real-time matches
- When we get to it, I am not sure whether GTP is the way to go; I am using it because it is the standard way to communicate with Fuego, not because it is such a great protocol. But on the other hand we already have a certain infrastructure for sending and receiving GTP commands, so heck, why not? Let's decide when we get to implement real-time...
You may not have noticed it, but assert() does not work. The reason is that the project needs to be compiled with NDEBUG, and the reason for that are the Fuego header files. More details available on request.
And I hope it wasn't too much of a problem that the project does not use ARC.

Wow! Thanks for all the input. I will consume it greedily.

Do we really need a new game type?

Probably not - it just seemed natural as i was shoehorning the whole thing into the NewGame* stuff :)

You may not have noticed it, but assert() does not work

I didn't notice, no. Thanks for the tip! I'll use something else

And I hope it wasn't too much of a problem that the project does not use ARC.

No problem at all. I'm a c++ developer by trade so manual memory management is very natural to me. Objective-C's and in particular cocoa's approach is different, but not so scary: the rules are simple. I've never actually used ARC.

I must admit, though, that I haven't taken the time yet to set up the app configuration with game center capabilities, so I haven't been able to fully test your prototype

My experience with the Game Center sandbox has so far been that it is a bit of a nightmare. I have managed to set up 3 test user accounts in iTunes connect, and after a lot of pain managed to get 2 of them to be friends. It might make sense if you're going to test my build for me to pass you the details of the test accounts rather than you having to jump through the iTunes connect hoops. There may be some shinanigans required with the team provisioning profile, but i'm certainly open to adding your id to whatever is required.

Some advice on Game Center Sandbox:

you need to put game centre in sandbox mode (Settings.app->Game Center) https://devforums.apple.com/message/1100579#1100579
don't log in to the game center sandbox as your normal apple ID, this has the potential to screw up your normal apple ID. Use sandbox accounts which you can create in iTunes connect (instructions below), or use the ones i've already created (or i can create more). After much trial and error, here's how I do it on the device:
- Log out of game center from Settings.app
- Run the littlego "online" app (don't log in to game centre from settings.app or Game Center.app); this is required to make the device log in to the sandbox I think
- Log in to Game Center as a sandbox account
- Accept terms
- note that it says * SANDBOX * on the banner
- if you open Game Center.app now, it should say "sandbox" as a bubble (this doesn't always seem to work)
test on real devices - i wasted a lot of time trying to get a game going between the simulator and a device, but the notifications just don't work in the simulator (they sometimes don't work on the devices, but on real devices it is tons better)

If you want to set it up independently, here's the short version of the instructions

go to iTunes connect and select the app in my apps
hit the game centre tab and switch "enabled" to ON
leave everything else as-is
in itunes connect, go to users and roles
go to sandbox testers
click the (+). notes:
- you need real email addresses (i use gmail's magic + to add suffixes to my normal gmail)
- i set all my users up as in UK because i seemed to have problems when they were in different localities

Finally, the sandbox is just notoriously horrible. Check the game centre forums on developer.apple.com, for example:

https://devforums.apple.com/thread/210287?start=50&tstart=0
https://devforums.apple.com/thread/261595?tstart=15 (my question on friend requests not workign)

Elo rating

How does ELO rating work? Where is this rating done? Where is it stored? In Game Center?

http://en.wikipedia.org/wiki/Elo_rating_system

I actually wrote a very simple Elo rating system for my friends and i. The short answer is that is really a style of rating system that adjusts both players' scores based on the result and the relative strengths of the players involved. If a weak player beats a very strong player, the weak player's rating is increased (and the strong player's rating decreased) in proportion to the difference between their initial ratings. The basics are very simple, but the cleverness comes in how the various coefficients are calculated and how you map a score (an integer) to the various kyu/dan levels. Different servers and different go associations all seem to use something different. I implemented the simple algorithm from wikipedia(http://en.wikipedia.org/wiki/Elo_rating_system), and the coefficients from sensei go (http://senseis.xmp.net/?EGFRatingSystem). The rating is stored in game centre, updated by the app when a game ends. The fiddly part is players with no rating - typically a player who hasn't played enough games shouldn't affect the opponent's score while their real rating is determined (imaging a dan player just joining the system - they need to play a few games to get their rating correct, but they shouldn't be allowed to affect their opponents because their rating is so skewed). TBH i'm not sure how to solve this, without knowing how many games the opponent has played. Might require an honour system!

I'll respond to some more of the points directly on the wiki page after i've processed everything.

FYI: I just merged a branch with a lot of changes into develop. I recommend you merge all that stuff into your cloned repo before you continue. If you run the iPhone 6 Plus simulator you can admire :-) the new layout.

Design/Implementation of the new layout have kept me busy for the past month. I am currently excited by "one more thing" :-) that I urgently want to implement before I finally turn my attention back to Game Center. You have not been forgotten.

OK, so I got everything working here on my side, with 2 sandbox test accounts that are friends of each other. Thanks to your warning I first read through Apple's docs before I jumped in and configured everything. If you do everything exactly as they tell you, it works pretty well - for me the only thing that didn't work out of the box was the two accounts becoming friends. I had to log in 2 or 3 times until I was finally able to receive the friend request. I must admit though, that it seems much too easy to shoot yourself in the foot: One login with the test account on the production environment and the account is trash. I just hope that it's not that easy the other way around...

Anyway, I was able to start a new game and to go through the matchmaking process. When black played the first move, white correctly received the invitation. Great! The next thing I will do is step through the code, just to familiarize myself a bit more with the game center API, and to maybe add a few more notes to the wiki page. From then on, though, it will be your call again to make the next move :-) while I will switch back to implement the last feature for the 1.2.0 release (AGA rules).

Cheers, Patrick

Great to hear!!

Sorry i have been distracted with other things lately so haven't made much progress. I have merged in your latest changes (magnifying glass is ace!) and am ready to make progress again.

During the last month I spent a lot of time on implementing support for AGA rules (issue #221) and IGS rules (issue #223). The main problems to solve were:

Everything in Little Go assumed that a game always progresses with strict alternating play.
A game always ends with 2 consecutive pass moves.
Once a game ends, play cannot be resumed without discarding the last pass move.

These limitations are now gone, hopefully without introducing too many new bugs :-) Especially interesting is that if, during scoring, players do not agree on the life & death status of stone groups, it is now possible for them to resume play and continue to play out the dispute. While this is of limited use in a computer vs. human game, I think it is an essential feature for human vs. human games, and thus will turn out to be something we will want to integrate into the Game Center "workflow".

While working on all that life & death dispute settling stuff, it was natural to think some more about Game Center integration. I also had some notes left over from studying Apple's "Game Center Programming Guide", so I ended up dumping all that stuff into a new section at the bottom of the wiki page.

Finally, a warning: When you merge my stuff into your Game Center branch you will probably get conflicts in NewGameController and NewGameModel. The reason is that I had to somewhat redesign the "New Game" screen, because there are 3 new end-of-game rules, and with those new rules the screen started to turn into a real rule-selection monster. So I simplified the screen, throwing almost all the rules out into a separate "Advanced New Game" screen. I also attempted to simplify the internal controller logic - many of those ugly nested switch/if blocks are now gone. I hope you won't be too angry at me for breaking my promise not to making any sweeping changes. It's for the greater good, you know :-)

herzbube / littlego

Add support for Game Center turn based matches #164