Reimplementing the Deal-O-Round game in Flutter - part 1

Earlier this year I mentioned  multiple times that I’ll reimplement a game in Flutter. In this blog post I’ll tell a little bit more about that game so I can draw a nice trend line while also paying a tribute to the original project. In the next post I’ll focus on the Flutter reimplementation itself.

In 2014 we formed a team named "Bad Wolf" with some of my buddies and competed at the 59 Days of Code hackathon. We got placed on the podium with an interesting card game, which has a hint of tetris feeling and also a hint of slot machines. I still remember when we were brainstorming with Tim Yopp at the Bitwise Mural District building next to the pinball machine. At that early phase all bets were off and we were just trying to figure out which direction we wanted to go, how the game would exactly look like. Tim showed a deck which had round cards and we realised that it’s unique enough that it can distinguish our game from other card games. We figured that the round cards in the game could be like poker chips. We started to mock the game logic progress on the screen by moving the cards on the floor step-by-step.

We already knew that we’d like a play where the cards will fall from the sky and fill up the card board area somewhat similarly as the gem stones fill the play field of the candy crush / Bejeweled. In tetris the elements fall from the sky towards the bottom as well, but our logic is closer to a candy crush. In Bejeweled you need to match the same type of gems for the removal of those gems, while in Deal-O-Round the player would need to find poker hand combinations. It’s hard to find five card hands, so three and four hand variations are allowed.

Mike Twohey helped in many areas, like the home screen design, background music, and I think he came up with the final name of "Deal-O-Round" which stuck. Vernon Burt was a great team member as well and he was planning the back-end where we’d allow competition of defined circles of players, basically adding a social media element to the project. Mike and Vernon designed and helped with the implementation of the level logic and a few other game areas.

I also still remember how I was submitting the first Play Store version and a few refinements well into the wee hours on the morning of the big closing convention day of the whole hackathon. What I love in 59 Days of Code is that it wasn’t just a 24 or 48 hours dash, but throughout 59 days participants can really put in time to develop an idea somewhat past an MVP (Minimum Viable Product) phase to a more mature state. Surely it required more dedication and time, but that pays off. During the two months period the team had multiple meetings a week and we needed to check in with the hackathon jury several times: pitching our ideas, creating videos and presenting our progress. At the Fresno Convention Center we had a booth with proper branded drapes and Mike also ordered branded casino chips with a QR code pointing to our website. People could test our game on Android demo devices at our booths.

I convinced the team to use the Google PlayN framework to implement the game. PlayN is a cross platform game programming framework which is able to target Android, iOS and even the web (and a few more). I heard of it in-person at a Silicon Valley Devfest in 2013 autumn. At that time some Google engineers were contributing to it and for a while it was backed by them. With PlayN you write your code in Java, so you not only get the benefits a statically typed language but Java was also a the de-facto standard for Android application development (Kotlin was picked up by Google many years after 2013). Our main target platform was Android so I knew PlayN would provide an extremely smooth path to the Google App Store. I was keeping an eye of PhoneGap (later rebranded as Apache Cordova), and Ionic would be a great choice if we’d targeted web as our primary platform, but I prefer statically typed languages over JavaScript. Several of us were also .NET skilled developers, so we also very well knew about Xamarin, which could have been an alternative, but I liked that PlayN would also provide web port of the game. This is why you can play a demo version of the PlayN version on our website.

PlayN supports the web port leveraging GWT (Google Web Toolkit) technology which was already a popular way providing front-end for Java web applications (even enterprise applications like OpenEMPI or SOMEPI. This also means that if the web platform is targeted as well then any imported Java libraries should be GWT supported (or translatable) as well. The iOS port of PlayN is somewhat complicated.

An advantage of PlayN is that for menus and non-action views we could utilize the Triple Play framework: it provides traditional 2D widgets like text box, menus, rich text, buttons. Therefore we would not have to paint these things on our own on a 2D game canvas. That can save a ton of time and design resources, one example for this is the Settings screen. Originally the home screen was also Triple Play but later we used Mike’s design.

Finally, PlayN has adequate hardware acceleration support. The web port uses Box2D under the hood which has WebGL support, and theoretically Android as a straight native path should be fine as well. However Tim Yopp showed how his old phone heated up during game play. I was shocked because although the phone was very outdated and not a flagship model, I didn’t think our game should have posed too much GPU or CPU load on the device to behave like that.

PlayN became an independent project from Google and due other industry changes the multi-platform support is provided by the RoboVM project. Over the years React Native also emerged as a popular cross-platform alternative, but just as with Ionic or Cordova I’d consider that if the game’s primary platform would be the web. The new kid on the block is Flutter and when web platform support appeared I got dedicated to reimplementing Deal-O-Round, but more on that in my next blog post.