In Part 1 of this three part series, I explained why I chose Elixir for the back end of our flagship game, Breakfast of Champions. Here in Part 2, I’ll talk about the decision process for the frontend tech.  There will be three frontends because we’re planning on making the game playable through browsers, an iPhone app, and Android app.

Unlike the backend tech, frontend seems pretty straight forward right? For browsers, JavaScript; for iOS, Swift; for Android, Java. However, there is still a lot of gray area for each of these platforms, so let’s get into it.

The Browser

One of the nice things about Phoenix (the Elixir framework I’m using for the backend) is that it comes by default with Brunch, a Javascript transpiler.  This way you can write ES6 code right out of the box. However,  another nice thing about Phoenix is that it doesn’t force this decision on you. You can easily swap Brunch out.

Since I was already making the jump from Ruby to Elixir, I also thought about making the jump from JavaScript to Elm, a statically type, functional language that compiles down to Javascript. It claims to never have runtime exceptions! What?! Crazy.

As enticing as Elm sounds though, I am worried about performance. I’m sure its performance is good or even great for “normal” web apps, but I’m making a game. I’ll be calling a loop ~60/second, and I’d rather have full control over the js, as opposed to letting Elm compile the js for me. I will definitely be trying Elm out in future projects though. Also, if someone has tried out Elm for a game before, please let me know how it worked out!

Framework or No Framework?

Now that I’ve decided to go with js, the next question is whether to use a framework. There are a ton of game frameworks out there, and I looked at many of them. The questions I was trying to answer about each framework were:

1. How big is this framework? Will it slow down my game’s load time considerably?
2. What features does it offer? How many of the features that it offers will I actually use?
3. What’s the documentation like? Will I be left scratching my head and diving through source code to find my answers? Is there an active community around this framework?

In the end, I decided Breakfast of Champions will be too simple of a game to warrant the use of any framework.

Winner: Vanilla ES6 JavaScript

Mobile

Much to my chagrin, canvas rendering performance on iOS and Android is bad. Like really bad. I haven’t found any good benchmarks online, but I’m talking like at least an order of magnitude worse than on OS X and Windows. I would love to be able to just stuff the Breakfast of Champions site into a web view, then bing, bang, boom, I’ve got an iOS and Android app for my game for very little extra work. Sadly, because of performance, this is not an option.

So what are my options? Well, it’s clear I’m going to have to go native for the actual game portion of my code. Swift and Java, here I come! But for the home screen and menus and such, there are some options. Perhaps I will use this React Native that startups are losing their freaking minds over. Maybe I’ll decide that’s overkill and just write some vanilla Swift and Java like I did with the browser js.

Anyway, I plan on creating the browser version first and then duplicating the js class design in the mobile languages, so I’ll punt on the React Native vs vanilla decision for now. What do you think? Is React Native worth using for a few screens and a menu? Come on back for part 3 of this series to see what happens.