If I wanted to create a chess game, for iOS, that tracked both player moves (for retracing the progression of a game and for player stats), what would be the simplest route to take?

To clarify, I want to track not only the moves a player has made in a particular game, but how often that player has made that move in past games. For example I want to be able to track:

  • How many times a given player has opened by moving the king pawn up two squares (e4) as white, on move number one.
  • What is the percentage of time the player responds to white's e4 opening move, with moving his own king pawn to e5?
  • What percentage of time does he respond by moving his queenside bishop pawn to c5?

And so on. If it's not clear, the stat tracking system should also be able to report how many times this player, as black, move his queen to h1, on move number 30.

I'm using Parse.com for my back-end as a server (BaaS) service. If I were to create a class that

  • writes strings that identify move number, player color, moved piece, algebraic notation of the square (e.g. "d8") to a file, locally in the file system
  • saves the file to Parse, and deletes the temporary file from file system
  • upon opening the same game in my tableview (a la a "With Friends" game), download this file from Parse, parse through it and retrieve all stats/history, assign all relevant values to variables

Is this plan viable, or is there an easier way?

  • 2
    \$\begingroup\$ Strictly speaking you are still describing a "database," just not a traditional relational / SQL one. \$\endgroup\$
    – user1430
    Commented Apr 29, 2014 at 18:26

1 Answer 1


You can certainly do all of this by simply storing the move list for a game in a text file. That would be the simplest way to store the data, but at the expense of forcing you to build all of the query mechanisms yourself.

Something more structured like an XML or JSON file will probably make querying slightly easier (since you are on iOS, you may want to consider the APIs for reading .plist files, which are effectively the same thing).

It's unclear to me what you are actually using Parse for; your description here makes it sound like it's just a file storage system that is redundant with local storage (do you want to also collect the stats for the opposing player in a peer-to-peer game?). A SQLite DB would serve your described needs just as well and avoid the latency involved with round-tripping this file over the network. If your aversion to using 'a database' stems from not wanting to have something like a SQL Server instance up and running to deal with this data, SQLite (perhaps via CoreData, which will then give you all the NSPredicate-based queries you probably want) is worth looking into.

But barring that, your described implementation using text files seems workable.

  • \$\begingroup\$ Thanks for your response, Josh. I'm using Parse to store the players' data more persistently than just writing to the file system. In the game that I'm building, the data itself will become a key aspect of the game, so saving exclusively to the file system won't work. The idea is: the game saves to Parse every 10 moves or so. All of the local data that has been saved locally since the last update is appended to the server-side data. This way, if the device is lost/stolen/replaced, the user can come back to the game on a different device and still have all his and other players' stats. \$\endgroup\$ Commented Apr 29, 2014 at 18:36
  • \$\begingroup\$ By the way, in listening to several podcasts, I discovered FMDB and I'm planning on using that. If you don't already know, it's a SQLite wrapper for iOS and it looks INCREDIBLY easy to use. \$\endgroup\$ Commented Apr 29, 2014 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .