Retrospective on Rakpoka

June 26th, 2013 - No Comments

One afternoon at Rancon we all got called into the meeting room. Dominating the conference table was a luminous purple playmat, with a stark contrasting yellow series of squares arranged in a cross. Upon some of these squares were numerals – x2, x3… some had No-Entry markers. On the side of the board were poker hands, listed in an odd order (with Straights being worth more than Four of a Kind), and beside it all were a stack of miniature cards, two decks thick.

This was going to be fun!

The guys at Abble Games had left behind a prototype of a big Pub Friendly version of their new game, Rakpoka. “Scrabble with Cards” was the way we were introduced to it – you get a rack of seven cards and have to play a valid poker hand onto the board, scoring some points as you do so (aiming for the multiplier squares). What we quickly found was that even those of us who were incompetent at Scrabble, myself included, started playing the game in a much more tactical, space filling format. Area denial became more important, blocking off valid moves became a strategy all by itself. Holding out for specific forms of hands to play was a more essential strategy compared to a word puzzle game (where taking what you’re given and rearranging the words in your mind were more important). We all were pretty much sold on the game as a pitch for building a new game for smartphones – particularly since Abble had already got a prototype of the multiplayer game running on their own servers.

A few weeks later we had done some research on what there was to do, and there was understandable apprehension moving into doing an entire Multiplayer game, as well as a game that would require in-app purchases to either make or break the game.  A few wrong moves and there would be hell to pay. We had three options for multiplayer – build oradapt a PHP system that would ignore anything Realtime in favour of relying on Smartphone push notifications, or use a real time Socket-Server (either Player.IO or Union were our researched options). Settling on the more powerful Union option, we built a prototype client – starting a game, chatting, sending “moves” to the server, and progressed from there.

Rakpoka Retrospective, Class Diagrams

Initial Class Diagrams drawn up to work out the Rakpoka Workflow

I spent a while with the Rakpoka rules document, something that was occasionally appended to (the team at Abble were unsure what to do with Joker cards – wild cards, which were later determined to be issued at a fixed number of cards played, with a deductable penalty of 30 points every time they were used) and built a comprehensive Move Validator in Flash. Fleshing it out, I had the framework for the entire structure of running a game in relation to it’s rules, and set about porting it to Java, the language Union ran it’s server modules in. The kinks were slowly worked out, the beginning and end of a game were written in as conditions, and soon we had the server and the client passing moves up, validating, and sending them back.

Our chosen development platform for the client was RobotLegs – a Model-View-Controller pattern for Flash. For cross-platform development for a smartphone application with a deadline it was the smartest choice we could have made. The office had all got to grips with the structure, and debugging was made easier. In the back of our minds we felt safer knowing that if Union wasn’t going to work out, we could gut the Service side of the program and rewrite it for another platform, safely knowing it wouldn’t require a rewrite of the rest of the program

Sadly, as all things tend to be, problems arose. Flash, while an amazing cross-platform tool, never has been able to run as fluidly as Native or Unity, and when the final designs went into the prototype the program started slowing to a crawl, and ultimately, crashing. We moved the entire front-end into Starling, but now time was against us – having to recode a chunk of the views, and moving the Robotlegs powered systems into a Starling fork of it.

About this time we had to send versions back to Abble Games for testing, and start building the in-app purchasing systems. Here is a place where we underestimated just how the systems were to work. A dual-login process, attempting to mirror games like “Words With Friends” that allowed for both email and Facebook logins were starting to make account tracking in Union problematic – worse yet, we discovered the administration side of Union was difficult to work with, having no built in process to track User variables. Combining this with the back-and-forth validation process we were required to take up with all in-app purchases we lost a lot of time that should, ideally, have been spent on bug fixing.

The chat messaging system was de-scoped for Ranked or Adrenaline mode games where collusion would have been a possibility. Eventually, given the number of changes we had to make to the core game’s social aspects, we worked out that Union was almost overkill for our game. With push notifications and a lenient timeout being made even more lenient, the game could have been restructured into a PHP driven process – which would have made the in-app-purchase validation easier without having to work through Union’s modules and back through PHP.

The matter eventually turned to hosting – our own local development server would be fine for testing, but when it was out in the wild we’d need a dedicated, or at least virtual, solution. UnionCloud was settled on as a compromise between the expense of hosting our own dedicated server, and we were particularly swayed by the expansion that was offered. It would later prove a mistake

Behind schedule but over all the initial problems, we launched Rakpoka and Abble Games’ own marketing department went into overdrive – happy with the product and ready to roll it out on a national scale. Of note, they were so happy with the designs our studio had produced for the board that they had printed a new version of the game to be sold in shops, using our new logos and designs as a basis, and commissioned Marvin Wheatil to work on the full board game for them.

Rakpoka Board Game

A real life version of Rakpoka, hopefully in stores soon! – ©Abble Games Ltd

And then the UnionCloud crashed. Their “extensive cloud based solution” was just a load of buzzwords. Worse, because of the difficulty in accessing user data from the backend of Union’s administration, we found that the user data was totally unrecoverable. Harsh words were exchanged, and during the next rounds of amends and alterations, we built, at cost, a proper user backup system. It’s a costly learning experience, but even for the smallest of multiplayer games which at the time only had twenty or so active players in the first week, nothing ever goes smoothly. If I’ve learnt anything from this, it’s to choose a socket server solution that has a comprehensive backend, a manual backup system, and an interface that allows us to view and alter values on the fly. Oh, and to avoid anything promising “Cloud” hosting. Yuck.

Rakpoka continues to be a bit of a cloud with a silver lining. The end product, at least from outwards appearances, appears to be a slick, polished game. There has never been a complaint of cheating, at least proving that the systems we designed to validate the scoring work, and the game continues to be played. But the game has yet to reach a critical mass of players to keep the ranked game wait time below a threshold, which doesn’t bode well as it currently stands. I’m proud of what was eventually made, and I think everyone involved is too.

Much as I enjoyed working on a multiplayer game, the next time I build one I’ll ensure more time is spent worrying about the server architecture and communication – particularly if a third party server (such as the in-app-purchasing systems for Google Play or Apple’s Store) is going to be involved

Rakpoka is available for download for free on your iPhone from here and as a Premium iPad (and ad-free) version here. A review from DailyAppShow is available to watch on YouTube here.


Leave a Reply