The story behind Pogo Bug

Pogo Bug spawned from my curiosity about what made Flappy Bird so addictive to so many.  Questions like that is what, in general, attracts me most to game design.  I spend a lot of time observing and analyzing the games people enjoy.  I don't know if I'm skilled at understanding it, but I like to think I am.  I also enjoy the pursuit of fairness and balancing fun factors in rule writing... but that doesn't really apply much to this terribly simple game.

I have no reason (or desire) to hide the Flappy Bird origins, so I don't.  Still, Pogo Bug is not Flappy Bird.  Flappy Bird requires taps at no specific timing.  Pogo Bug requires swipes at regular intervals.  Otherwise, they are indeed fairly similar in that a bird must hit a gap between pipes and, here, a ladybug must hit a group of aphids above the (healthier) carrot greens.  Pogo Bug gives you a bit of forgiveness if you jump too high but none if you jump too low.  Flappy Bird gives you no forgiveness for missing the gap in either direction.

But, wait!  There's more.  Much more.

Pogo Bug started as a game-jam game... but not really.

I had been thinking about and writing the bylaws (I guess) for possibly starting a local group for open-source game dev work.  For both as a community-building tool and as an education tool.  Thus, I had been shopping around for (preferably) open-source tools to be part of the official toolkit.  The requirements I wrote for game-engine selection are terribly restrictive.  Things like: open, thin builds, cross-platform, industry-diverse scripting language.  Yikes!

Anyhow, I eventually landed on deciding to test Qt and QtQuick for game development.  (I had also recently loaded Ubuntu Touch on a new/old-stock Nexus 5 that I had just bought [I can't afford much right now] to eventually replace my end-of-life Windows Phone.  Ubuntu Touch supports Qt as its tier-one toolkit, and that was a big part of this testing decision.)  Another tool, Felgo, is targeted at Qt and game dev but, after installing and testing it, I decided I didn't need it for this test, removed it, and just stuck to the default Qt libraries.

Global Game Jam was approaching around this time.  So, I used GGJ as an excuse to jump into this test -- while also decidedly not being part of GGJ.  Curiously enough, I don't like GGJ's open-source requirement much... even though I like open-source work.  I just don't like it mandated.  It should be optional.  Pogo Bug, while a test in my open-source tool search, was not meant to be open source itself.  Besides, my schedule didn't perfectly align with GGJ's either.  I started installing and testing Qt on Thursday, skipped Sunday, and finished Monday.

Using some open-source Flappy Bird clones written with Qt, plus Machines vs. Machines, as guides for Qt game dev work, I got the core of Pogo Bug working in about 2 days of work.  Then, it took up to 2 weeks to polish, tune, finalize the art, and make and add sound effects.

I had all this running in QtQuick/QML on my Ubuntu Touch phone.  Then, it all turned crazy and the project got big.  I couldn't publish Pogo Bug on Ubuntu Touch.  I had glanced at Qt's licensing coming into this and I thought I was good for both open source and commercial... but I wasn't.  The LGPL is a funny animal that requires you to host the source code to all the LGPL tools you use, on your own site.  A big annoyance but, okay, clone all of Qt to GitHub or whatever.  The LGPL also has conflicts with Google's or Apple's store (I forget which).  The bigger problem at the moment, however, is that the version of Qt that Ubuntu Touch currently supports doesn't include the QtQuick Compiler under GPL or LGPL.  Thus, I would end up publishing Pogo Bug's source if I published on Ubuntu Touch.  As I mentioned before, this is not really what I wanted to do with Pogo Bug even though I'm willing to do that with other games.  Then, there's the insanity of Qt's commercial license.  It is prohibitively expensive!  There is no pricing ramp here for small enterprises like so many other tools offer these days (and, yet, Felgo offers such plans for their Qt bolt on... but you still need to license Qt under that).

Given this idiotic hole in Qt's target market, I dumped Qt as an option, and went looking for a new dev tool to test.  During my Qt-fiasco web digging, it sounded like Flutter was emerging as the Qt replacement for mobile apps -- and it was much more open.  So, I restored the Android OS to my Nexus 5 and began porting Pogo Bug to Flutter/Dart.

I found the somewhat-popular game engine for Flutter, called Flame, and began the port with that.  But, the work was really slow.  Painful compared to Qt.  Correction: Painful compared to all of the other game engines I've used.  Flame is, simply, a mess.  A scattering of logic.  This is not meant to be an angry criticism but, really, more of an observation that Flame is an example of how an open-source project can suffer from too many contributors of various skill, and not enough oversight.

After a week or so of struggling to work with the super-fuzzy and nebulous definition of a "component" in Flame, and struggling with their underly-useful and overly-complex sprite image slicing, I decided to rewrite at least their sprite and animation "components" into something much more usable and much easier to understand.  I submitted a PR for this work and, not surprisingly, it was rejected because the changes were too breaking (even though Flame is not anywhere near version 1.0 yet).  Some asked that I refactor in smaller pieces.  ???  Some refactors can't be done in small pieces.  This route was hopeless.

I then decided to go "all in" on fixing the basic design problems of Flame.  I added the concept of game entities to the engine and redefined what a component is.  Really, I just made it look quite a bit like Unity in that regard.  This, of course, cascaded into a ton of other changes and improvements (which are tl;dr'd in the Pogo CHANGELOG).  After about 2 months of work on this, I then released the results as the Pogo Game Engine and, finally, got back to work on Pogo Bug.

The port of Pogo Bug to Flutter then came together almost as quickly as working in Qt (and with better performance -- but, to be fair, the game loop in QtQuick was a pretty lousy and lazy timer event instead of something more proper).  Anyhow, a week of porting, a week of even more polish, and a week to add the nag/donation system (something I wasn't going to add to the Linux version), and Pogo Bug was finally released for Android.  (I can't say when I might get to the iOS release.  I only have an old Mac mini I bought off eBay on the cheap cheap for some Mac testing with another game.)

Another interesting point here is that web apps can be installed easily as native-looking apps on Ubuntu Touch.  And, considering that Pogo/Flutter games appear to compile just fine to web, I could go back and publish Pogo Bug as a web app to Ubuntu Touch (with minified JS for obfuscating the code).  If I had a spare Nexus 5, I just might do this.  But, I don't, and Ubuntu Touch, as a phone OS, is missing too much for me to want to go back to it.  Little things like swipe typing and an option to use a more-legible font are important to me.

And, that... is how a one-week project turned into 16 weeks (1 week short of 4 months).  But... we did get a new and open-source game engine out of it... if anyone cares.  All the momentum is still with Flame, and I don't have time to try to turn that around.  So be it.  People can keep punishing themselves with Flame if they like.  If I can find time to build more tiny games for mobile or web (and, soon, depending on Flutter, desktop), I'll continue to use Pogo.  It is currently as least as sufficient as QtQuick was (except, maybe, in audio handling, which I hope to find a better Flutter plugin for someday when I have time to address it).  If I ever launch my open-source-game-dev-organization plans, Pogo will likely be the 2D engine of choice.  I am biased, yes, but it is open source, cross-platform, and builds tiny (Pogo Bug is only 11MB installed).

And, now, back to the impossible job hunt.