Nov 2020: Going Engineless, Expectations vs. Reality
When we get to talking shop with fans at conventions, one of the most common questions we get from fellow developers and craft-savvy fans is, “So did you make this in Unity?” It’s an assumption so safe to make these days in the indie world that it’s even become more frequent a question than the more general, “what engine did you make this in?” And when we answer “no,” people are hungry for answers.
Part One: Why on Earth would we make a game with a custom engine?
The short answer: it was a different world back then. When we started on development for The Day We Fought Space, Unity still needed to be wrestled into submission before it would entertain the notion of a game with only two dimensions, and its cross-platform promises were only just starting to be realized. Other engines were in similar spots -- they were options, but not necessarily safe bets.
My aversion to third-party engines was further informed by the experience I’d had with an earlier game called Primrows. Primrows was a fun little logical gardening game formelry available for iOS. I was our first offering on the platform, though not a terribly successful one. There’s a lot about this game and its development story that I could unpack, but for today, I only want to talk about the high scores.
Don’t be fooled. This cutesy, inviting array of flowers pushed me with inches of rage-quitting the game dev industry. But those stories are for another day. In private, with my therapist.
Primrows completed development before Apple’s own Game Center launched, which means we were left to find another way to implement high scores. Rather than try to set up a custom high score server, I was going to be a Smart™ indie developer and not re-invent any wheels that I didn’t need to. I found a service called AGON which was a great fit for our game’s needs, and it was especially convenient as the library took care of scores and achievements both online and offline, synchronizing them as necessary.
What was not so great was the way the service evaporated less than a year after launch.
Not to worry, there were other options to switch to, and after some late nights, I had shaved down some square pegs, written a whole mess of code to cover the gaps left behind, and Primrows was now running OpenFeint. I had, like, a dozen games just on my own phone that used OpenFeint. There’s no way that one was going anywhere, right?
Sadly… no. About a year and change later, OpenFeint got bought by a competitor who proceeded to burn OpenFeint to the ground and make some vague threats of legal action to anyone who was still using OpenFeint code or assets in their apps. More late-night sessions trying to desperately keep a game alive. Rather than get my heart broken by a third service, I pulled online score support from the game entirely. I was weary of getting jerked around by third-parties.
And this was the attitude I brought with me when it was time to start earnest development on this multi-touch scrolling shooter that we had prototyped out: proprietary third-party code was a great way to get burned.
That wasn’t the only factor, though. Performance, learning curves, and flexibility were taken into account. And so, now that I’ve finished* venting about a game that hasn’t been in the same time zone as relevancy for nine years, I’d like to move on to the actual intended subject of this dev blog: comparing our expectations to reality, for the benefit of any devs out there considering eschewing an engine for their next project.
* Spoiler alert: I’m not actually finished
Part Two: How our expectations held up to reality.
Expectation: We’d still be able to avoid reinventing the wheel
To be clear, it wasn’t third-party code that was the problem, but specifically closed-source, proprietary third-party code. Had AGON been open-source, and made their server code available, its disappearance into the aether would have been barely a speedbump.
The Day We Fought Space uses plenty of third-party code, such as the physics engine Box2D; the main difference being we had all of the code from the beginning. We could, and have, made minor tweaks to the engine in spots where it needed them. Box2D could be entirely erased from the internet, but as long as we had a copy of it saved locally, we were all good. One example of this very thing happening
In practice, while this was a very easy route to pursue during the early years of development, it became much more scarce as time passed, and these days hunting is difficult. My guess is that the kinds of people who used to post useful code snippets and libraries have, understandably, moved to repositories like the asset store.
To counter this, however, the support from Apple’s SDK has grown. For a stretch in the middle of development, however, much of this was out of our reach: we were clinging to the idea of supporting early generation iPads until fairly recently in development. It’s not ideal; so many fans we’ve at conventions were initially disappointed as they just assumed their old iPad 2 wouldn’t run the game, and their eyes lit up when we revealed that one of our demo iPads was, in fact, an old iPad 2 just like the one they had at home.
Those middle years, though, were pretty rough in terms of finding wheels in the wild.
Expectation: We’d see better performance using native iOS code compared to an engine
Surely, if we cut out the middleman and got closer to the native platform’s code, we’d see higher frame rates, right?
Reality: this was true for a time, but I don’t think it is the case any longer, though I don’t have the numbers to back this up. There was a stretch where I was barely doing anything to optimize and hitting 60fps on older hardware even with bells and whistles abounding while fellow indie developers were describing in great detail the hoops they had to jump through to keep their draw calls down when porting to mobile. That dream I mentioned earlier about supporting hardware all the way back to the iPad 2 wouldn’t have stayed alive for nearly as long as it did, I suspect, if we were using an engine.
But lately, between mobile hardware getting faster and engines learning better optimization tricks, I don’t think this is nearly as big a deal as it was around, say 2015. (There seems to be a theme here…)
Expectation: I’d be able to avoid a steep, front-loaded learning curve
Let me be brutally honest about myself: at this point, I’m an old dog. It’s hard for me to pick up new tricks. And you can only learn enough libraries or engines before your brain starts rebelling against the concept of learning yet one more meaning of the words “view,” “scene,” “layer,” and “frame” that is completely incompatible with what any those words meant in any of the last three development frameworks you learned.
And I’ve never been the kind of person to be quick out of the gate at a new skill. I was hungry to tackle a larger project than the little puzzle games I was used to doing. I had a good handle on native iOS development. To try and learn a brand new engine, at this point, would be locking myself into doing yet another Primrows or Drops of Light.
Reality: This one actually… kinda panned out. Almost.
A few years ago, I forget precisely when, I took an entire month off of development for The Day We Fought Space. (At the time, I thought it was a final break from the game before a four-to-six-month dash across the finish line… ah, optimism. I miss you, but not really. You only ever got me into trouble.)
What was my goal for that time off? Well, I was gonna learn Unity, dammit. I was gonna take the first level of this simple platformer game that I drew out in markers when I was ten years old in this notebook I found while housecleaning and turn it into a real game. Shouldn’t be hard, right? People do game jams and come up with stuff like this in a weekend.
I know that I was 10 years old when I drew this, because of all the bits that are blatant rip-offs of Zelda 2, a game which I got as a present for my 10th birthday. There’s a lot of Mario 2 and Pitfall in here as well. Even a bit of Mickey Mousecapades.
I found the learning curve pretty steep, and over the whole month I never got any further than that second door, and even a lot of that had features I had skipped over.
So where does the “almost” come in? Well… I cut my teeth developing software for Windows, an operating system with a commitment to backwards compatibility that borders on religious. The shareware games I made in the late 90’s and early 00’s, for Windows 98? Windows 10 is happy to run them, so long as you dismiss the warnings about running software from an unknown publisher.
Apple has chosen a different approach to backwards compatibility, one best described as counting to 132 on one’s fingers in binary whenever asked about the topic. Apple’s brand is cutting-edge technology, and if you want to develop for their platforms then you’re expected to sharpen that edge and start cutting, friend. This has meant more than once during development I’ve had to stop and learn some new tricks, often at times when my own development priorities would have had me doing something else entirely.
In addition, my absolutely stunning underestimation of how long this project would take certainly evens out the scales on this one. Six months of learning a new system seemed more expensive back when I thought the game would be wrapped up in a year and a half. All in all, I consider this one a wash.
Expectation: I’d have the flexibility to organize the game in a way that made sense to me
In the interim between my shareware glory days and my first ventures into iOS, I spent a fair amount of time tinkering with RPGMaker and Zelda Classic. Both of these programs are great ways to get started on a big project, but inevitably with each of them I’d hit a point of frustration where I desperately wanted to do something, I knew how to describe all of the logic, but the system just wasn’t set up to handle the kinds of things I wanted to do with it. Sure, the community had bizarre systems in place one could use to craft all sorts of wonders, but they seemed so much more convoluted than necessary and I didn’t have the patience for crafting a sixty-four nearly identical rooms in a dungeon tied together with hidden teleportation tiles just to craft a logic puzzle with six candles.
This is an extreme example, but by getting as close to the raw code as the platform would let me, I was hoping to avoid situations like this.
Reality: This one lived up to expectations.
The particle animator in The Day We Fought Space works exactly like I want it to. I’ve yet to find an animation editor anywhere else that tickles my brain in just the right spot. The same goes for motion specifications and formations and a whole mess of other structures in the game.
One of the big hangups I had while trying to realize my 10-year-old-self’s platformer was that, while there was a lot of helpful stuff in the asset store, a lot of it made assumptions about how the rest of everything was set up. I found myself backing up and rewriting things I had written so they’d play better with things I found. I found myself having to dig deep into code that just wasn’t going to work for me out-of-the-box.
Does it really count as “not reinventing the wheel” if you need to retrofit your bicycle to use two wagon wheels and a tractor tire? (I’d pick a new metaphor, but… why reinvent reinventing the wheel?)
Now, having said that… I’ve seen plenty of talks and found plenty of articles where sufficiently-motivated people were able to write their own custom animation systems and drop them on top of their favorite engine. So, explore your options. Don’t let this necessarily be a dealbreaker, just come to the table with the right expectations.
Expectation: We’d only be beholden to the whims of one company, not two
One of the tricks about developing software is that there’s simply no way to do it in any meaningful way without hardware to run it on. And, as a game developer, unless you’re a tabletop developer, that means you’ve got to play by the rules of at least one other company, which is manageable. But… if you add a second player into the mix, it can be like having two bosses. If Apple came out with a new iPhone, would I be stuck playing a waiting game while the engine I was using worked out support for the new hardware? Perhaps unable to fix
Reality: A mixed bag.
Earlier this year, Epic and Apple came to legal blows. A lot of that dust seems to be settling but there was a window of time where indie developers using the Unreal Engine weren’t sure what their future on iOS would look like. It was a relief to not have to worry about a situation like that affecting The Day We Fought Space.
But… there’s an upsetting flipside to this, and we’re going to have to finish the story of Primrows to explore it.
Hello darkness, my old friend…
In 2017, on my birthday, I got a notice from Apple. Primrows was going to be pulled off of the App Store in a month unless I could update it to a set of newer standards. Because the code base was so old, simply updating the code wouldn’t have sufficed. I’d have had to start a brand new project, do a lot of stuff from scratch. Some things would have survived, a lot wouldn’t. It would have taken me well over the month that I was being given. I had other stuff to do -- it was a very busy month. And I couldn’t justify doing all that work for a game that was lucky to see two downloads in a year. So… I let go. I let Primrows die. As much as that hurt. As much as it still hurts.
It’s true: like The Day We Fought Space, Primrows only had to answer to one higher power and not two. But… it also had nowhere to run to. It was trapped. And some nights I lie awake at night wondering if a similar fate is waiting for The Day We Fought Space. It’s a tough place to be, when both options just remind you of how small and powerless you are on the scale of the industry as a whole. *deep sigh*
And on that note…
Part Three: Asking “What If”
Before I wrap up, I want to pivot the perspective a bit, and speak not to the expectations we had before the project began, but to the expectations my fellow indie developers have expressed, looking backwards, and speculate on what might have been.
With an engine, could we have offered The Day We Fought Space on more platforms?
Probably, but only with compromises to the design and the release date.
I don’t know that much about developing for Android or for Tablet PC’s, but I’ve heard that tracking three independent touches isn’t something that is universally supported across all brands of hardware. As for loftier goals like the Switch port that many fans have requested, all I know about that is that it’s a high bar to clear and it almost certainly would have added significant development time.
With an engine, could we have finished development earlier?
The one fact about The Day We Fought Space that raises more eyebrows among my indie dev colleagues than its lack of an engine is the extremely long time we’ve spent on development. Would an engine have sped along the process?
This one, I seriously doubt.
Even if we discount the learning curve that I discussed earlier, the kinds of things that have slowed down development haven’t been the kinds of technical issues an engine could have solved. Our long development timeline comes down to matters of mental health, of other life events cutting into hours worked, and learning key things about game development along the way. I don’t care how good your engine is, it’s not going to automatically plan a convention appearance and it’s not going to replace the playtester feedback process and it’s not going to teach you time management skills.