Data Redundancy - results are precious

One of the key challenges in an application like Number.fy is ensuring the risk of data loss is as small as possible. Once the game data is submitted to the server we can be sure we won't lose it, but the step before that, transferring it from the classroom device to Flurrish servers, is more problematic and so we employ a range of redundant techniques to minimise the potential for any loss. Most problems result from a loss of wifi connection between the device and the network, however finding the cause of network related problems is notoriously difficult, and we suspect that such issues are related to wireless network access points dropping the connection to the device based on a period of inactivity (whilst the game is being played). We are looking at better ways of working around this on the device to provide more stability.

Belt and braces

In order to account for tricky network conditions we undertake a series of steps to try and ensure we minimise losing any precious game data. In simple terms, we write the game to a local database on the device and mark it as unreported - only when the server responds to say the game was delivered do we mark it as reported. This design is intended to prevent losing data (and it does), but it carries a risk - when a problem occurs as the game data is transferred to the server, the server never responds to say it has received it, so the device never marks the game as reported. When the device next connects, the application is programmed to resend any games that weren't marked as complete - and we run the risk of duplicating results.

How do you eliminate duplication?

There is a simple answer to solving this problem. Whenever you write a new game, you check to see that a similar game (same user, same results, same date/time etc) hasn't been reported. The problem is that this is slow, and results in the database doing something akin to locking itself, which is a more serious condition that would result in genuine data loss. As the Flurrish approach to learning happens in class, with ~30 pupils engaged in simultaneous gameplay, the risk of this locking problem becomes a very real issue.

Embracing duplication

All this means, that whilst we continue to find a solution for the locking issue, we have decided to embrace the duplication issue. We are taking steps to eliminate the likelihood of duplicated data appearing in results sets and expect to roll this out to the reporting tools in the near future. Simultaneously we are looking at reducing the risk of network issue occurring during "normal" conditions.

Our "user centred" approah to game design means that the teacher comes first - ensuring rapid, easy to use gameplay, in the classroom, is foremost. However "it's all about the data".... as we said in the very first blog, we don't know what our children don't know. Easy to access data underpins our reporting to help teachers find this out.