Hey there, friends! I have some wild news: I wrote a mobile game. It’s called Poker Pick-Up™ and it’s a super fun puzzle game based on the game of Poker: you pick up cards from a big grid of them and get points for forming 5-card poker hands.
I built the whole thing using React Native and, while it wasn’t my first rodeo with it, trying to build a game with React Native proved to be pretty challenging. I’ve got some thoughts and some tips for anyone else who wants to go down this path.
The best part
Obviously the best part was being able to use my regular Typescript toolchain to work on this mobile game. Being able to write–and test–in pure Typescript was, compared to writing two different codebases in ObjC/Swift and Java/Kotlin, pretty agreeable over all, though it was a little bit of a challenge to get all the type safety goodness of Typescript fully working.
The wide availability of Node modules and Cocoa pods I could use definitely made it easier to implement advanced functionality without putting too much of my own effort into it. That’s a solid win.
The worst part
A couple of times I had code that worked just fine in my simulator but not on my actual physical device. This was very frustrating, as debugging the game became significantly harder in its “production” mode running on a physical device.
Not only that, but Android and iOS handle some things wildly differently and
React Native doesn’t do, in my opinion, the most thorough job dealing with
that. As just one example, it is a huge pain in the butt to arrange components
on-screen along the Z axis–i.e. to position one element “above” or “behind”
another. In iOS, you can use zIndex, but it won’t work right unless your
components are structured just so. In Android, you can use the Elevation API
which seems to work some of the time.
Tips for doing this yourself
The first advice that comes to mind from this whole experience is to not freak out. By that, I mean don’t worry yourself over every little detail. I spent my whole career working on high-availability backend systems that needed to respond as fast as possible all the time no matter what, and for a while that clouded my thinking working on games. See, if I spend half a day working on a single web service endpoint, and I manage to speed it up by a few microseconds every request, that’s a huge win across many millions of requests to many different servers. It’s not such a huge win when you’re talking about something running on one single device, with a human watching it.
Think of it this way. Video games look very smooth at 60 frames per second, so realistically if you’re doing something like computing frames for an animation, you have 1/60th of a second to get all your computing done for that frame. That’s 16.7ms, which isn’t long for you and I but is practically an eternity to a mobile phone that’s capable of performing billions of operations per second. Once I let go of that, when I stopped trying to get maximum efficiency out of every line of code, not only did I have an easier time putting the game together but it was also a lot more enjoyable. Don’t get me wrong: I love optimizing the ever-loving crap out of code, but this way I do that when I want to, not all the time.
Get from zero to something fast
I don’t know if this is because I have an ADHD brain or if this is more universal, but I have a hard time staying motivated when I’m not making progress of some kind, even if it’s slow. Projects become boring when they’re stuck (which can then keep them stuck 😆). With game development and maybe with app development in general, getting from nothing to something, even something really simple, builds momentum that can carry you through the start of a project.
So, if you’re developing a platformer game, first try to just get a blob on screen moving in response to controls; try to make the minimum “playable” game possible to start with. I’ve found this to be immensely helpful even if I end up not keeping all the code from this initial little push towards functionality. It’s kind of like writers who start a writing project by just writing anything that comes to mind, limbering their creativity for the endeavors ahead.
Don’t let perfectionism hold you back
Earlier in this and other game projects I’ve been working on, I really struggled to get the first version out there and released. I thought I had a kind of writers’ block or anxiety but it turns out it was perfectionism that was holding me back from sharing my work with the world. I didn’t want people to see my game until it fully matched the vision I’d imagined, with all its features and beautiful graphics and everything. Every time I gave myself a deadline for a v1.0 release, I found myself too self-conscious of the deficiencies in what I’d made. I couldn’t decide what “good enough” was because I was too focused on what “perfect” would look like.
The answer was two things. First, a realization that even if my game had bugs or crashed or completely flopped, I could just address those issues and release a new version. It wasn’t like a physical product that had to be flawless right out the gate: it was more like a website that could be endlessly revised and rebuilt.
The second thing was realizing that a C-grade game is still something I can release into the world and be proud of creating. The A+ games I’m comparing myself to are built by huge teams of developers, designers, product managers, quality assurance engineers, site reliability engineers…. I figured for me, an individual person with no team, maybe I don’t need to set the bar that high.
Get feedback early, but carefully
Not everyone you know is going to be into your game, unless it’s something like TETRIS with unlimited universal appeal. That doesn’t mean your game doesn’t have an audience! Find that audience and seek their feedback as early as you can, but remember that it’s hard for people to look at an unfinished product and see it for what it is.
They’ll point out stuff that’s missing that you just haven’t gotten around to building yet, but still listen to them patiently. These initial feedback sessions are a great source for ideas for game features and mechanics you might not otherwise have thought of.
There’s probably a bunch more that I’ll think of right after I publish this. Eventually I might write a few blog posts with more details about how to solve some common problems related to React Native or game development. For now, this’ll have to do. Until next time folks!
(Google Play and the Google Play logo are trademarks of Google LLC.)