Amongst the many interesting things I’m lucky enough to get involved with in my role on the RIM® Developer Relations team, Near Field Communications (NFC) has become very much center stage for me over the last year. Some readers of this post may be familiar with the NFC-related articles and code samples that I’ve co-authored with my buddy John Murray (@jcmrim), which you can find listed in our NFC Article and Code Index.

Now it has to be said that it wasn’t the best summer here in the UK (though fortunately the weather gave us a break just in time for the Olympics!) and so I occasionally found myself at the weekend with “fine weather-dependent plans” cancelled and time on my hands. One such weekend, I was thinking about NFC and my thoughts turned to discussions I’d had with John about whether NFC could enrich games and the gaming experience in some way.

The world of computer games has changed somewhat in the 30-something years I’ve been playing them! It’s gone from text-based adventure games (“go north!”) played on a PDP-11 with a teletype and no screen, through the block graphics of Lunar Lander on a Commodore Pet, and onwards through Space Quest, Civilisation I, the Monkey Island series and (many) more favourites.

In the beginning and for many years, games were single-player — or at least they were single machine games. More than one player could play, but you’d have to share the keyboard or take turns. Then came LAN games, and this evolved into Internet-based gaming with huge online gaming communities (without whom, I have no doubt, the world would now be over-run with zombies). The truly great thing about online gaming is that you need never know that “goreslayer765” who just destroyed you in your favourite game is actually a 9-year-old with far more knowledge of automatic weapons than can possibly be healthy. I mean, whose fragile ego could handle knowing that?

So, both extreme ends of the single player vs. multiplayer spectrum are well catered to these days. But in what way might NFC enrich the gaming experience, and in what kind of games? I had a quick brainstorm with John on IM and we came up with a few use cases:

Start Game Two-player games could be kicked off by the two players touching devices. This could trigger an NFC based interaction which your application drives, the outcome of which could be the decision as to which of the players is “Player 1” and which is “Player 2” for example.
Your Turn Turn based games would work well with NFC being used to indicate “it’s your turn now,” with a player taking their turn and then touching the other player’s device with theirs.
Pass it on It could be cool to create digital tokens of some sort that you could pass to other players by touching their device with yours. With a web component of your game, you could perhaps track your token as it moves from player to player and perhaps travels the world!
Been there Games involving visiting physical locations could use NFC tags to allow players to “prove” they’ve been to a place and found the item with the tag. Each tag would contain unique content, including perhaps clues on how to find the next game location. Touching and reading the tag from your application would establish the “been there” credentials required.

But why would you want to do this? After all, there are plenty of other ways to trigger “new game” or “it’s your turn now” and to share data across a network. Well, the appeal of using NFC is simply this: it adds a physical, tactile element to the game. You’re sitting right next to the person you’re playing with, and having to touch devices at intervals in the game could add a novel and fun element to the experience.

We then realized our most important task. We needed a name for the phenomenon of NFC-enabled games that we were now thinking about. In a flash, I had it! Please welcome “Proximity Gaming” to the world!

Armed with a few ideas, we decided to develop a game as a proof of concept and set about thinking about what the first game would be and how it would work. We decided we’d develop an NFC-enabled version of “tic tac toe” or “noughts and crosses” as it’s known in the UK.

We decided to use NFC in two places. Firstly, players would have to touch devices to start a game, and secondly, they’d touch devices to indicate “it’s your turn now”.

We had to consider a few issues regarding the implementation. It was immediately apparent that we’d have to pass some kind of message from device A to device B and that we’d probably need several message types. In other words, we’d need a simple protocol.

We could also see several technical ways of sending a message from one device to another. We could use virtual target emulation in theory, or maybe we could use one of the two NFC peer-to-peer APIs, SNEP (Simple NDEF Exchange Protocol) or LLCP (Logical Link Control Protocol).

We dismissed target emulation and focused on the peer-to-peer options, since this was clearly a peer-to-peer scenario. We concluded that either SNEP or LLCP could be used, but that SNEP would be a little easier to work with — LLCP being a lower-level connection-oriented protocol whereas SNEP is a higher-level message-oriented protocol. We’d worked with both in the past, so we had a pretty good feel for what the coding would be like.

In conclusion, we decided to invent a simple message-oriented protocol and use SNEP as the NFC protocol, which would transport game messages between devices. The UI design was to be basic: an initial screen that prompted players to touch devices to start a new game; a screen for “player 1” to choose either noughts or crosses; and the main game screen upon which to place noughts and crosses.

We also decided to implement the game for both BlackBerry® 7 OS using Java®, and our BlackBerry® 10 Dev Alpha devices using C++/Qt/Cascades. Being able to play the game between a BlackBerry 7 device and a BlackBerry 10 device would be a nice proof of the interoperability of NFC between generations of BlackBerry technology.

Here are some screen shots from the proof of concept game, first from the BlackBerry 7 version of the game:


Figure 1 – New game screen

Figure 2 – Player 1, choose nought or cross

Figure 3 – Main game screen

And here are some screen shots from the proof of concept game, from the BlackBerry 10 version of the game:

Figure 4 – New game screen; Figure 5 – In game; Figure 6 – Game over

Thoughts on the “game protocol” crystalized properly as we worked through prototyping the game and we found we needed the following message types in the simple protocol:

Bid for player 1 The act of requesting a new game by touching devices would also determine which of the two players would be Player 1 and get to choose which of noughts or crosses to play with. The “bid” message would be exchanged by both devices and contain a random number. The device that had produced the highest number would “win” the bid and become Player 1.
End of turn After placing their nought or cross on the board, players would touch devices so that the other player’s game instance would be informed it could now let the player update the game screen. The protocol message to indicate “end of turn” would need to include information about the turn taken by the current player; specifically, which square on the board they had updated in their turn.
Reset There would be occasions where the game state in a device would need to be reset and a suitable message type in the protocol would allow this.

We’d like to tell you how we went about coding the game.

If you want to know how to use SNEP in general terms, we’ve written articles on the subject for both BlackBerry 7 and BlackBerry 10 and sample code too. You’ll find details here:

BlackBerry 7 – Peer to Peer Communication with SNEP
BlackBerry 10 – Peer to Peer Communication with SNEP

There’s a key point here: you could implement your Proximity Gaming ideas for either BlackBerry 7 or BlackBerry 10 because both have the specific types of NFC peer-to-peer capabilities that you will need.
Harnessing NFC SNEP in the way we wanted for our game was easy. The APIs themselves are very straightforward to use. For BlackBerry 7 we designed some Java classes, which represent the various message types in the game protocol. This was standard stuff if you’re accustomed to working with protocols, and we ended up with an abstract class called ProtocolMessage and a series of concrete sub-classes, one for each message type. Each of these classes implemented a marshall and demarshall method so that we could easily swap between byte array representations, which would be exchanged over NFC SNEP and Java objects for internal use in the application.

Here’s an example of one of the protocol message classes:

We also implemented classes called NfcReceiver and NfcSender, which implemented NDEFMessageListener and NDEFMessageBuilder respectively and provided the basic mechanism for sending and receiving my protocol messages.

For BlackBerry 10, life was actually simpler and we just needed to create message using the Qt QbyteArray class and then utilize the BlackBerry 10 native APIs for NFC, as shown below:

So, having designed and implemented a message-oriented protocol and coded classes which used NFC SNEP to transport those messages between devices, the rest of the effort that rainy weekend was spent on standard game development issues like creating the UI. The UI was really easy to create for the BlackBerry 10 version using Cascades™, and took a fraction of the time and effort we spent on the BlackBerry 7 Java version of the game. In both cases, the NFC part was also quite easy and took relatively little effort as a portion of the whole application.

The next step was to find some guinea pigs to test the application out. (Not real guinea pigs, of course — their paws are too small and they have claws that make working with a touch screen problematic. So instead, we decided to use humans — our respective friends and family to be precise. :) )

Testing was informal. In my case, I explained I’d developed a two-player game that allowed you to take certain actions just by touching the two devices back to back. My guinea pigs generally looked a bit blank or even cynical at this point. “Just touch them together? Really?!” But with a little coaxing I got them started and watched them carefully.

At the very start of the game, the two players are instructed to touch devices to start the game. Looking a little unsure at first, the players touched devices and held them together for a second. The devices responded, vibrating to indicate an NFC message had been received, and the game moved on to the next screen to allow the selected Player 1 to choose noughts or crosses. At this point, the expressions on the players’ faces changed — from expressions that suggested they were being asked to participate in a black magic ritual to sheer delight with big smiles all around! And from that point, there was no stopping them. They were each playing on devices with touch screens – the BlackBerry® Bold™ 9900 and 9790 smartphones, to be precise – so selecting a place to put their mark on the game “board” was simply a case of touching the screen. And passing turns to the other player? They just touched the devices together, of course!

Here’s a video showing the game in use:

[ YouTube link for mobile viewing ]

The verdict was very positive. Players liked the idea in general and enjoyed the tactile element of the game play. It seemed that Proximity Gaming was a big hit!

The two versions of our NFC-enabled tic tac toe games are available with full source code from our github repositories here:

So over to you, BlackBerry developers! How could you use NFC in your BlackBerry smartphone game?


Continue reading:

Introducing Proximity Gaming with NFC