0.13 brings the first multi-device network play to Tic-tac-toe Collection, local network play. With this post I will explain some of the details about how it works and why I made certain descisions.
There are a few types of multi-device play I want to support, but I felt it was important to start with local network. The most important is that I strongly believe as much of the app should work offline as possible. In the long term, it should also continue to work if I stop maintaining any server infrastructure it uses. Another point is that local network play has fewer security considerations. I make a pretty big assumption that you trust who you are playing with, since they will likely be in the same room.
There are two quite separate parts to multi-device process, and these two parts will exist regardless of whether the game is local network or over the internet, private or matchmade, or pretty much anything else. They are device discovery, and actual game data exchange.
For local network device discovery I chose UDP broadcast. The game sends a short message to every device on the network, while simultaneously listening for broadcasts from other devices. It’s possible for networks to block broadcasts (and is quite common for public WiFi hotspots to prevent devices from seeing each other at all) but for most people at home, this will work. No real data is exchanged at this point.
For the exchange of actual game data there are quite a few options, but for the first release I decided on HTTP polling. A big reason for this was simplicity, but also the knowledge that in the future much of the code would be the same when running over the internet.
The HTTP server is implemented using EmbedIO, a small HTTP server that supports .NET Standard. The client uses Refit, a library that generates REST clients from interface definitions and my default choice for HTTP clients.
The structure of the API and data exchanged during play is really simple. There is one GET endpoint for getting the current state and another POST endpoint for sending a change. Additionally, ETags are used to avoid sending state data if nothing has changed.
Overall, the technical side of implementing multiplayer was straightforward. The hardest part by far was designing the updated UI for showing player details, both on the player setup screen and in game. I think there are still improvements that can be made.
A feedback form has been added that is accessible from the About page.
Fixed a single, significant, bug. Custom games of Drop Four allowed the user to play pieces anywhere.
0.13 will bring the first iteration of one of the biggest features I’ve wanted to add since I started work on Tic-tac-toe Collection - multi-device multiplayer.
This first version brings multiplayer to devices on the same local area network - generally devices connected to the same WiFi.
All the options currently available to single-device play are available to multiple-device play. You can join with any number of players from each device and games can be saved and then resumed later. For the first version, they have to be resumed with the same devices (although not neccesarily the same host), but I plan to lift that restriction in the future (it requires more complicated UI flow).
I hope to have a version in the beta channel shortly. I am still working to make the process more resilient to various problems that are common in multiplayer games.
As I said, this is just the first iteration of multiplayer. The next step is likely to be private games over the internet, followed by match-made games over the internet. How soon that will be, I do not know. I have other features I want to add in the meantime. So, watch this space…
Reasonable permission requests:
- Wi-Fi connection information.
Unreasonable permission requests:
- Device ID & call information.
Refusing to install an app because of unneccessary permissions may seem harsh, but is something I think more people should do.
Sadly however, in this case the app is probably not doing anything wrong, but is merely old. It supports Android all the way down to 1.5. In Android 1.5 all apps automatically had access to device ID and call information, therefore all such apps have to require that permission when installed on newer versions of Android, even if they don’t access any of it.
The solution is to release a new version of the app targeting 1.6 and above, which would not need those permissions (the 1.5 version could be left as is and would still be available). But… the app was last updated in June 2013 so that seems unlikely.
- Changed the layout of the “news” on the home page.
- Made the new mode quickplay option (currently Chain) dismissable.
One problem with developing a game based tic-tac-toe is there are already a lot of versions available. I’m confident I can make one better than most of them, but that doesn’t mean there isn’t something I can learn from the others.
So, I’ve decided to start reviewing other tic-tac-toe games. I’m going to start with free games on Android and see how it goes. The first review is already available for Tic Tac Toe by Wintrino.
A very simple version of Tic-tac-toe by Wintrino. You can play two player against another human, or against the AI with one of four difficulty levels. There are no gameplay options available, but there are a few settings to make the game a little nicer to play (turn off welcome screen and turn off “quit game” warnings).
There is a single persistent banner ad, and an interstitial video ad every few games.
- Quick to load.
- Quick AI.
- Pretty detailed statistics (albeit with typo - “Tota” instead of “Total”).
- No animation.
- No game options.
Game features missing from Tic-tac-toe Collection
- Sounds effects.
- Clear stats.
App features missing from Tic-tac-toe Collection
- Share app with friends.
- Rate on Google Play.
0.12.4 includes a signficant rewrite of large parts of the core game engine. Bits that I didn’t like had started to build up, and some plans I have for new game modes looked to be quite difficult to implement because of decisions I made earlier that seemd like a good idea at the time.
The current state of the engine is now much better, however the process does make me nervous. The changes affect not just how the engine plays the game, but also how data is saved and loaded. And people generally don’t like their save games being corrupted.
So as part of the work for this version I also wrote a tool (that I have been intending to write for a while) that checks for save game compatibility. The idea is the tool creates games with various combinations of settings, plays them through (with the easy AI) and saves the result. As part of the normal automated tests I run with each version, these save games are then loaded, the moves replayed, and the result compared with the previous result. Any discrepancies are failures that I can investigate.
Importantly, the initial set of games is based on running the tool before the big engine changes. Unfortunately (or perhaps forrunately) it discovered a bug straight away. Loading a game with “free turn” set to true (i.e. any of the Chain game modes) would not always pick up the “free turn” setting (this was fixed in 0.12.3).
So the plan is every time I add a new game mode (or change the engine significantly), I generate a new set of save files, and during every release the current set of save files is checked for compatibility. Hopefully this should keep everyone happily saving and loading.
The game engine has been extensively cleaned up to make future work simpler, leading to a small performance improvement.