I’m working on a new game. Or rather, on the idea of starting a new game 😃
One of the first things that you might have to consider when creating a game is the platforms that you want the game to be available on and the programming language that you’ll use to code (or program) the game in.
The above two factors are somewhat tied together. For example, you can code your game in Swift and if you do, it would probably be only available on Apple devices such as iPhones, iPads, or even Apple Watches or mac desktops and notebooks. That would leave Android out of the equation.
Or, you could decide to develop in Java or Kotlin to support Android devices first and this could leave the Apple devices out of the equation. To be fair, Kotlin does have better cross-platform support and there’s the beginning of support for developing for multiple platforms with Kotlin Multiplatform but I’m not sure if that effort is far enough along to support games or not.
I decided to go with Flutter.
Why Flutter, you ask?
First and foremost because Flutter is cross-platform. You can build an app with Flutter and the same code will run on iOS, Android, macOS, Windows etc. without you having to customize things for each platform. It will even run on the web.
Of course, the promise is not quite there yet. Flutter builds great for some of the platforms while others aren’t quite there yet. But I’m only interested in iOS, Android, and macOS for the time being. And having developed with Flutter for the last few years, I felt comfortable enough with Flutter and its capabilities to go with it.
Sure, there are other options — Unity, for instance. It supports all the platforms that I’m interested in, is mature, and is well supported. Plus, it is free to get started with.
However, working with Unity is like learning to pilot a plane, while Flutter is more like learning to ride a bicycle 😀 Unity is a professional game development tool set. There’s a lot to learn and a lot to understand before you get to doing a game. I’ve worked with Unity before and the sheer complexity of getting started on getting something done can be a bit overwhelming.
On the other hand, Unity has a lot of pre-built components, assets, tutorials etc. that just makes doing anything so much simpler too.
At the moment, Flutter is one of my favourite toolkits to develop in. So, I decided that I’d try my hand at gaming with Flutter …
But selecting the programming language/toolkit is only half the choice 👅 You then have to decide whether you are coding the game in the language of your choice without any aid, use an existing gaming engine, or build your own game engine.
Choices, choices, choices …
I’m not masochistic enough to want to build my own engine, or even masochistic enough to want to do everything myself by working without a game engine. A game engine does a lot of the heavy lifting for you. For example, let’s say you want to load a bunch of images to animate your game character — a game engine will have the necessary code to do this with a few lines of code instead of you setting up the loading of the individual image frames, then figuring out the timing of the animation, and then drawing each frame of the animation yourself.
I first looked at Flame as my choice for game engines. It’s well-documented, seemed to be simple enough to use, and had most of the basic features I was interested in. Plus, I’d used to code games for iOS in cocos2d, and Flame kind of reminded me of the glory days of cocos2d 😄
But then I came across Bonfire, which is built on top of Flame. It had all the extra goodies that were ideal for the kind of game that I was thinking of. So I thought, hey, why not go with Bonfire instead?
I started looking into Bonfire, installed their demo game and started modifying it to see if it would work for my needs … and wouldn’t you know it? I found another rabbit hole to go down 😬
Bonfire by default required the game to have a virtual joystick on screen. I didn’t want my game to do that — I wanted to be able to tap on screen and move my character around.
So I contacted the developer of Bonfire and asked him about making the virtual joystick optional. He suggested that I (possibly) submit a PR (or a code change of my own, in case you’re not a developer) of my own for it.
I just couldn’t resist the temptation and jumped in head first down another rabbit hole 👅 I got rid of the joystick fairly easily, and then started work on more changes to add touch handling for the player.
But … I began to re-think things at this point. If I hadn’t even started the game yet and was already doing all these additions to the engine, how easy was the whole process going to be as I discovered other things that I was missing?
Should I go back to Unity and give it a try first?
I had not used Unity in about two years time and that’s a long time in computing. So now I’ve decided to check out Unity again and see how it works for what I have in mind and then make up my mind …
Stay tuned for the continuing adventures of Captain Undecided 👅
