Indie Game Dev: Platforms

If I were publishing this game, what platform would it be on? Android. Fade to black.

I'm completely serious, but let's see how I arrived there.

I'm just doing this for fun and to build out my pipeline, at least for the first project. So it's not going to be a huge, serious piece. No 3D augmented reality, no social media presence, no infinitely scalable backend hosted out of an old missile silo.

Console is out, they don't give those SDKs to just anybody, and I don't own any consoles regardless. Ouya is dead, and sadly I never bothered getting one. I'm not going to cobble something together with a Raspberry Pi, that's not the project I'm looking for right now.

PC is of course do-able, but it's harder and less fun than you might think. If you're just making a game for yourself that's one thing, but if you have any designs on publishing down the road, you have to face the nightmare that is Other People's Weird Hardware.

I really just want to bang out a quick little game using a simple system. I want something that could be published via Somebody Else's Platform, in case I change my mind and go that route. I'm a mobile guy and I (mostly) understand that space and those systems. So it's gonna be iOS or Android.

Either platform is theoretically fine, I'm equally familiar with both. Let's do pros and cons.

iOS pros:

• C-like native code -- I don't mind Objective C, it's quirky, and I like quirky
• Lots of framework support

I had trouble thinking of any others. Cons:

• Objective C is probably going away in favor of Swift, and I'm too tired to learn another language today, so very tired
• It's a closed system
• You have to have a Mac, and what's more, you have to build and debug with XCode
• You can't build and run an app on your own device without a developer's license
• The license is $100 USD / annum
• The code signing procedure is bonkers complicated, and you have to renew 3 or 4 cryptographic keys/certificates/profiles every year
• IDFA and various other monopolistic practices
• The approval process can be a crapshoot

Android pros:

• Open system
• You can develop and build your apps on any platform -- including OSX if that's your jam
• Once you've built that APK, you can install it on any Android in the world, nobody cares
• A developer's license costs a one-time fee of $25 USD, and you don't need it until you want to distribute the app on Google Play
• You create a single production key once, and signing is all automatic after that. Google will even hold the key for you.
• Advertise with whomever you want. Collect whatever data you want, provided you adhere to the laws of the countries you're publishing in
• Is there an approval process? There is, but I've never seen a rejection. Seriously, never have I ever
• Crash reports that you can symbolicate yourself

Cons:

• Java. *Sigh*. This is mostly mitigated by the NDK, but if you want to interface with any OS services, you're probably doing it with Java
• App permissions are a bit of a moving target

As you can see, I'm no fan of iOS, and the "privacy" shenanigans over the last year have not helped that one little bit. I love Woz, but everything else Apple can be launched directly into the sun.

So... Android. Fade to black.

Indie Game Dev: How I choose software and systems

Most game projects start with an idea, a design, and that seems sensible. But there's nothing better for me than having the whole pipeline worked out so I can start executing on those ideas right away. A big part of this project is having everything exactly the way I want it, so that means I'm building that pipeline.

Where to begin? There are a lot of choices, and they can be paralyzing. I've always started with the deal breakers: the things I absolutely will not do, not use, not put up with. Having some part of your workflow irritate you day after day is not sustainable, so discard those things up front, and keep them out of the ecosystem if you can.

I have lots of deal breakers, so it's easy to whittle the list down quickly. I'll discuss some of them in greater depth in later posts about specific topics.

• Java - it's a necessary evil in places, but if the stock install doesn't satisfy a given system or tool, I'm not going to use it.
• Requiring an IDE to build a resource. Make CLI tools for that, my CI/CD server doesn't have a mouse.
• Not generally a fan of obscure/discontinued tools, languages, or resource formats. The documentation is usually thin, and good luck finding answers on Stack Overflow.
• Also don't much care for Git. You heard me.

Once you've called out all your deal breakers, a swathe of additional tools will be eliminated because they involve those deal breakers. Embrace the constraints, they'll set you free.

With the distasteful stuff out of the way, you can turn your attention to things you really like, and let those things drive your next set of decisions. If you can't have a little fun, why do any of this in the first place?

• I love C and Lua. I like small languages in general.
• I like vscode quite a lot.
• I like JSON.
• I like make.
• I like Jenkins.

If it sounds to you like I've already chosen a lot of things, there may be some, but not necessarily these ones. These are just my preferences, and any real choices have to find their way through this decision tree.

Sometimes I choose things based on what I know best, even if I think something else might be better. Sometimes your hand is forced.

Next time, I'll talk about what I chose first.

Indie Game Dev: How I'd Do It Today

This is my 20th year as a professional programmer. In the early days it was a side hustle -- cobbling shell scripts together to keep the lab ticking over (I got paid, it counts), creating a web page for the company web site, that kinda thing. Eventually I'd "paid my dues" and was able to get the programming jobs I wanted.

(Total bullshit. I did do those things and many more, but I got my first programming job via a referral from a friend. That's how you get the first gig, don't let anybody tell you different.)

I'm a generalist. I've done QA automation, machine vision, network security, web apps, games. Mobile games, probably nothing you've heard of, but lots of them. I'm interested in low level bit twiddling, high level scripting, backend, build engineering, QA, debugging. I've done more time in gaming than anything else, and I continue to surrender to its siren song, but I never really specialized.

A few years back I did indie game dev for real: worked at my own studio, created and released an original title. Our systems guy called it "the best little phone game ...that nowhere near enough folks played", and that feels about right.

I find myself missing those days, or maybe just missing the freedom to do things however the hell I wanted to do them. Even then I wasn't completely free, the studio predated me by a couple of months, so there were a few preexisting systems.

What if I could start out again, do the whole thing exactly the way I wanted? What would I choose? I don't really know either, but I have a plan to figure it out.

I'm going to quietly recreate some portion of the game my studio produced back in 2014. There was a lot of content, so I'm not going to do everything, but what I do make will be top quality, fully functioning, no-sharp-edges software. It will be shippable, but for reasons I won't share here, I'll stop short of shipping it.

This is meant to be the first in a series of posts, and hopefully I can stick to it long enough to convey everything I intended to when I started. What will we be discussing here? Off the top of my head:

• Platforms - what hardware/os will this run on?
• Languages - system, scripting, tools, and more
• Source control - the source has to live somewhere
• Build tools - why is there anything other than make?
• Third party libraries - sometimes you can't roll your own
• CI/CD - because building the shipped product at your desk is The Wrong Thing
• IDEs and editors - vim vs emacs is over
• Content tools - what artifacts do designers create, and how do they do it?
• Live Ops - shipping is now the first step, not the last
• Sunsetting - when the returns diminish, what then?

I'll probably talk a lot about software engineering, because after 20 years I still don't see very much of it, and that makes me sad.

I'm writing this for myself, because we all do, but I do hope others find it useful or interesting. Hopefully I can provoke an "ORLY" once in a while.