Coding Games

Upgrading All My Unity Apps

Google and Apple have both had a lot of policy changes in the last little while. Google’s was far less annoying than Apple’s. Both require me to rebuild my Unity games.

Google requires 64bit build support in all App store apps as of August 2019 (with a few exceptions). Most of my older games are exempt until 2021, but since a couple were not, I opted to update them all.

Apple’s implemented some arbitrary policy that they can pull your apps from the store if they’re not updated for some unknown amount of time. One of my games is on the block and will be removed in 30 days. Who knows how many others will follow. Apple has also deemed my perfectly functional 2009 Macbook Pro to be obsolete, so I can no longer even build for iOS on this hardware. A whole different story.

So I’ll update my Android apps.

The Process

The process to upgrade everything to 64bit is a bit of a crap shoot. I didn’t know how long it would take or what I was really in for, so here’s a rough list of what I had to do in Unity:

  1. Update Unity to the latest LTS version.
  2. Open your old projects and let Unity update what it can.
  3. Change the build system to “Gradle” – internal is now deprecated.
  4. Check the “Build App Bundle (Google Play)” if you are uploading to Google
  5. Change your Target API to the Highest Level.
  6. Change your Android build settings to use .NET 4.x since 3.x is deprecated.
  7. Change your Android build tool to use IL2CPP (required for 64bit)
  8. Check off the ARM64 box.
  9. And Build…
Unity Build Settings Dialog
Unity Player Settings for Android

What Really Happened

Everything broke.

If you’re like me, You’ve probably used some extra libraries. I use Text Mesh Pro, Google Ads, Firebase Analytics, and Google Play Game Services in all of my apps. This process required all of them to be updated.

If you use these, in order to cleanly update, you must delete the old versions. The latest Google Play and Google Ads packages from their Git Hub repos install pretty cleanly. The tricky parts were with Firebase and Text Mesh Pro (TMP).

You must import the dotnet4 packages. Once you do that, the dependency resolver should fire up automatically and get any required bits and pieces from the Android SDK.

The original version of Text Mesh Pro wasn’t an official package in Unity. So needless to say, I had to re-do most of my TMP objects. The rest of the code worked fine, but it was a little more time consuming than I would have hoped for.

Other Unity Problems

I ran into a few minor issues with NDK (Native development kit) which is required by Unity to use the IL2CPP compiler. You’ll need to make sure you get the specific version and point Unity to it. At time of writing, Unity requires NDK r16b (r20-something is current). It will send you to a link to download it if it can not find it on your machine.

Final Thoughts

All in all, it was a somewhat bearable process that took a few hours per game. I’ve got the process down, so I’ll be good to go on the rest.

As a bonus prize, I was able to convert to Google Play’s signing management and use App bundles, which greatly reduced the download size of my Android apps.

Maybe this update will increase downloads a bit.

Coding PHP

WordPress and it’s Broken Core

When I develop with PHP (7.2+) I develop with strict mode and xdebug enabled. I do this on purpose because notices and warnings are both important to your quality of code. Constantly I am running into one issue with WordPress core that is quite frankly annoying.

This bug is also affecting WPEngine users a lot.

Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /[..]/your-directory/wp-includes/class-wp-hook.php on line 286
Warning: Parameter 1 to wp_default_packages() expected to be a reference, value given in /[..]/your-directory/wp-includes/class-wp-hook.php on line 286
Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given in /[..]/your-directory/wp-includes/class-wp-hook.php on line 286

The Error

The Error is pretty self evident that somewhere in the core wp_default_scripts, wp_default_packages, and wp_default_styles are all being called incorrectly. But where? and why?

Diving into class-wp-hook.php we’ll find that this is error is emitted from inside the apply_filters code. Unfortunately for us, the apply_filters code uses a lot of magic in the form of call_user_func_array – a built in PHP function that calls a user’s function with an array of arguments. Blammo. That should already be setting off your alarms. If wp_default_scripts expects a reference passing an array of values is definitely going to blow it up.

The Investigations

You’ve probably found yourself here by googling the above error message(s). You’ve probably already sifted through a few forum posts that tell you to “ignore errors” or “fix your theme” or “we have no idea!”

I’m going to start with ignoring warnings is a terrible suggestion. It always has been. Fix your code, increase your code quality. But what happens when your code isn’t the problem?

Unfortunately, a bug in core code takes time to fix. So you can report it (it’s a 5 month old bug, but the problems show up on the internet long before that). You can wait. And you can hack your core files to get rid of the error yourself.

Disclaimer: hacking your core files will void your warranty.

The Actual Problem

Since I’ve been tracking down this problem, I’ve discovered that it’s not super simple. The problem is how parts of WordPress core handle the wp_scripts object. If you write themes you’re probably aware of wp_equeue_script (and it’s friends). If you look at wp_enqueue_script you’ll notice the first thing it does is obtains a global object of $wp_scripts (I also despise global variables, but that’s another issue) and if this object doesn’t exist, it creates a new one. Easy enough.

The part that breaks is when the filter gets run for WordPress’ default filters. In there it adds add_action( 'wp_default_scripts', 'wp_default_scripts' ); and as one would expect, it tries it’s hardest to set up the default scripts. But that’s when it breaks. wp_default_scripts expects the reference to the global $wp_scripts to be passed. It’s not. It’s passed as a value and that breaks.

It would be a lot easier (and likely better) if it wasn’t passing the instance wp scripts at all and used the global wp_scripts() function, the same way wp_enqueue_script does. It would be even better if WP_Scripts was an actual singleton since that’s what they’re attempting to do with the global variable. But what the heck do I know?

The Hack

To fix this, jump into your core files and find class-wp-hook.php, roll on down to line apply_filters and make the function look like this:

public function apply_filters($value, $args)
    if (!$this->callbacks) {
        return $value;

    $nesting_level = $this->nesting_level++;

    $this->iterations[$nesting_level] = array_keys($this->callbacks);
    $num_args = count($args);

    do {
        $this->current_priority[$nesting_level] = $priority = current($this->iterations[$nesting_level]);

        foreach ($this->callbacks[$priority] as $the_) {
            if (!$this->doing_action) {
                $args[0] = $value;

            // Avoid the array_slice if possible.
            if ($the_['accepted_args'] == 0) {
                $value = call_user_func_array($the_['function'], array());
            } elseif ($the_['accepted_args'] >= $num_args) {
                $special_cases = array('wp_default_scripts', 'wp_default_packages', 'wp_default_styles');
                if (in_array($the_['function'], $special_cases)) {
                    $arg = $args[0];
                    $args = array(&$arg);
                $value = call_user_func_array($the_['function'], $args);
            } else {
                $value = call_user_func_array($the_['function'], array_slice($args, 0, (int)$the_['accepted_args']));
    } while (false !== next($this->iterations[$nesting_level]));



    return $value;

This will get rid of the warnings by passing the arguments to the default functions as references. Of course, if you upgrade PHP this hack will get overwritten and you’ll have to do it again if the fix isn’t actually put in the core.

Hope that helps you out and thanks for visiting!

Coding Games PHP

The Triviosity Rewrite

The Rewind

In 2010 I put a game online. Triviosity, a daily trivia game with occasional specially crafted challenges, has been online for over 8 year. It’s a game that people play on a regular basis and it’s always held a piece of my heart. When I originally wrote it I had full intent to make it a mobile app. An iOS app specifically. The original was built with Zend Framework 1, had a clunky API back-end with intent for the mobile app, and quite frankly it was rock solid. It ran without issues. Unfortunately the iOS app never happened, and as other frameworks and tools blossomed, ZF1 became outdated and not worth the time to build upon it.

Fast Forward

On thanksgiving weekend in October 2017 I decided it was time to rewrite my old game. It was time to switch up the technology and actually make the mobile app. At first glance I thought it was going to be a very daunting task. Switching from ZF1 to Laravel 5.5 seemed like it was going to be a huge undertaking. But it wasn’t. My data models from the original game were so awesome that porting the “beef” of it (I like to work with fat models) only took me a few days.

I sat on that small victory for months. Enter the void of hesitation. Was it too easy? Was I going about it all wrong? Was I doing this the right way? Is anyone new even going to play this rewrite?

If there’s one thing I absolutely detest it’s doing something over. I had to do this, but I hated doing this. There was a necessary evil at play – I want to build the new mobile apps. But I need to redo the old game to get there.

Then I got rolling. I don’t know what changed. I got about 90% complete then I stopped.

Who’s going to play this thing? Why am I doing this? Question, doubt, rinse, repeat.

Then the tidal wave hit. Frack it. “I’m putting this live.” It’s “good enough” and I can fix the missing parts. As a matter of fact, once I put it live, my desire to finish it and make it better went up exponentially.

On July 30, 2018 the unscheduled launch of the new Triviosity happened. A few hundred error emails later, and a bunch of random fixes, the dust had settled. And it’s alive.


There are two things that take precedence in my work. Security and Performance. Without going into too much detail about security (I can’t give away all my secrets) the new API includes request signing, encryption, and wonderful third party oAuth based authentication.

For performance, It was critical that I make this as fast as I possibly can while still leveraging my old (affordable) web servers. After launching you can see a substantial drop in load times and render times. (This isn’t just the home page either, it’s all pages.)

look at those performances
super graphs

The kicker was simple. Use the tool-set you have properly. As I mentioned, this was being built with Laravel 5.5 (and upgraded to 5.6 before my actual launch). As such, there’s one hell of a generally under-utilized tool-set available to me to use. So here’s a simplified rundown:

  1. CacheCache all the things you can. Cache your config files, routes, database queries. There are pages (score listings) that have a substantial amount of queries of data that doesn’t change often. Caching this turned render time from 500ms to 100ms.
  2. Compile / Minify CSS and JS – Laravel has a webpack config that utilizes a basic Laravel Mix out of the box. It has many nifty plugins to do everything you need. I only really needed the sass compiler, minifier, and JS minifier. This task is often overlooked and it yields some of the greatest performance boosts. The production build tool is A+.
  3. Offload to the Queue! – Using an asynchronous queue to handle things that don’t need to happen for the end user to continue is also a huge boost to performance. Things that can happen in the background: big database updates, sending emails, generating images – all done without the user feeling the slightest bit of a slowdown.
  4. Use the F’ing Framework – Far too often (I’m guilty of this too) I see code that “uses” a framework, but then it doesn’t actually use the framework. Laravel and it’s dependencies have been built up over the years to do a lot of the repetitious work. If I told you the code for the game controller was only 230 lines, you probably wouldn’t believe me. I leverage the framework’s models and view renderer to do the majority of the work. For reference, the old game play code was almost 1000 lines. Less code, same game, more efficient.
  5. Ditch The Cruft – I don’t use any external third party JS on this site with the exception of Google Analytics and Google AdSense (non blocking). Facebook, Google, and Twitter authentication is completely via server side redirects. The share buttons are just good old fashioned native links (which, as a bonus, launch the native apps on most mobile devices).

This is how you get a double A’s on speed tests.

The Future

Now that I have successfully released the best performing site of my life, I can finally work on the native mobile apps. I have no direct timeline for these. I’ll be building them as 100% native apps (Swift for iOS and Kotlin for Android) and not using some goofy cross-platform build tool so that will have some affect on the time frame. But they’ll be fast. They’ll be secure. They’ll be just as awesome and performance ready as the site itself.

Now with an even more rock-solid foundation I can build on this. We can all expect more curated challenges with great features.


It took me about 10 months to complete the rewrite. But in reality only 40 days. It kicks ass. It’s fast. It’s great. The mobile versions are coming soon.

Now go play some Triviosity. And let me know if you break something.

Coding Games

Making Games: The First Few Releases

making gamesNot too long ago, just before the start of 2016, I decided I’d start making games. I decided I would become a part time independent game developer. (cheap plug, you can find them all here: Games By Darryl)

I started out with an ultra ambitious plan to release one game per month for the entire year of 2016.

Come March, I finally released one. I released Digits! (iOS, Android) to the world on March 5th. A possibly unique game involving simple math. The initial response was pretty interesting to watch. Local friends would download it, tell people in their near proximity to download it. A classic example of “word of mouth”.

A few friends would crack some jokes “oh, so you’re a game developer now, eh?”, “mr. big time game maker!”.

One hundred and sixty six downloads later, it was pretty much over. Nothing left but the trickle that would go on for eternity of anywhere between zero and five downloads per month.

About two weeks later, I released Connexxion! (iOS, Android) to the world. This game is a remix of an older game I used to play, Chain Reaction. It was fairly simple to play, but slightly too frustrating for those who couldn’t quite understand it. It was an anti-game. It gets easier as you go, as long as you can make it past the first few levels.

I’m not exactly sure what happened but the initial downloads for this game was much higher than that of Digits. There was a lot of the same initial reaction from local friends. This game’s “word of mouth” involved a few swear words due to the initial frustration of it. But overall things were looking up.

After about three hundred and ten downloads, it entered into trickle mode.

When I released those two quickly I thought for sure I could re-target my twelve game plan. At this point I had a list. I had a list of more than enough game ideas to do this. The ideas weren’t over complicated and definitely things I could complete in short cycles. However, that plan fell flat on it’s face again.

As I started working on other games (I had at least three in-progress games at the end of March, 2016) I started getting distracted by my own other ideas. This stalled progress hard.

I released my third game, FOUR (iOS, Android) some time in May. This time based word hunt game is ugly to say the least. It had a whopping sixty-six downloads and fell flat on it’s face. It isn’t a bad game. It was just ugly and hard.

I released a two more games in 2016, bringing the total to five of my attempted twelve:

And so far this calendar year, 2017, I have released one game. A knock-off 2048 tile game; 2048 Plus (iOS, Android) – It, without going into much detail, has surpassed all of my prior games in downloads simply because I rode the coat tails of a fad.

To say the least making games requires you to ride the TIDE.


Time is critical to making games. I can make time. I did most of this stuff on weekends or evenings. The only real issue with time comes when you need to loop back and update or fix a prior game and that maintenance cycle conflicts with your forward cycle.


Ideas are cheap. Making games from the ideas is also cheap. Making them actually work and look decent enough takes design.


This is where I start failing as a solo developer. Design has a bunch of moving parts. All these parts need to work together to create a useful and entertaining user experience. I feel like the user interface elements in Digits and Connexxion were simple enough and clean enough to pass, and will likely never need an update.

Other games though suffered hard from my lack of design time. Making games like Bounce was different because of the type of game. I didn’t focus enough on design elements to make it a fun game.

Since I am not a graphic artist, I find myself using other asset packages. I pay for graphics. I build from other people’s art. There are a lot of members of the indie development community that severely frown upon this. “You’re not an indie dev, you didn’t design it all!” – it doesn’t bother me, but it probably hinders support from others. However, I will continue to kit-bash and mix and mash any of these paid assets I have or will buy, because that’s the only way I can do this solo.


When I refer to execution, I mean putting everything together. It’s one thing to make a little game, but the real nitty-gritty parts of it:

  • Testing on platforms, Apple and Android
  • Deploying to app stores (Apple, Android, Amazon, or more) takes time, graphics, writing. I have to not only make the game work; I have to try and sell it.

There’s also a lot of internals that aren’t game-play related that need to be looked after. Analytic tracking, ads (sorry, I want to make money too), achievements, leader boards. These are things that I thought I could leave out when I was rushing to make my first twelve. I found out quickly that I needed these things. As such, making games needs more time.

As this fast moving 2017 winds down, I still have a couple of games in progress, and an update to try and get out. I’ll just have to see what level the TIDE is at. In a future post I may talk about some other experiences with social media and the indie developer community.


A Quickie on Using Android Studio on Ubuntu

The original post below applies to old versions. For 0.4.x plus, you don’t need to do this. You just need to have a proper Oracle JRE/JDK installed system wide which you can do with this:

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update && sudo apt-get install oracle-jdk7-installer

With the recent preview release of Android Studio it’s important to know that it won’t work properly on Ubuntu with the OpenJDK that’s available.

Fortunately, it’s easy to get it going.

  1. Download the official Oracle JDK
  2. Unpack it (I put mine in ~/SDK/jdk1.7.0_21/ )
  3. Point your JAVA_HOME to this.
    ~/android-studio/bin$ export JAVA_HOME=~/SDK/jdk1.7.0_21/
  4. Run the android studio startup script.
    ~/android-studio/bin$ ./
  5. Make awesome android apps.

Have Fun!


Allowing the Facebook Debugger Through .htaccess

Here’s a short story; When I develop Facebook web apps, I do it under a password protected development site. Facebook hates this. It complains that it can’t reach urls, it can’t get meta data, it can’t do this, it can’t do that. The downside to not having a password is the fact that anybody can hit the site. (sandboxing is almost useless, these days.)

So, the quick solution: Allow Facebook to hit it, but only via their external meta data scraper.

A quick edit (well, not so quick, it was something obscure.) of my .htaccess rules, and voila! Facebook can debug and people still can’t hit it (easily)

SetEnvIf User-Agent ^facebookexternalhit.*$ Facebook=1

AuthType Basic
AuthName "Art & Science DEV Server"
AuthUserFile /home/dclarke/www/dev/.htpasswd
Require valid-user

order allow,deny
Allow from env=Facebook
Satisfy Any

First, set an environment variable based on if it is the Facebook user agent. Then, allow access. The key here is the ‘satisfy any’ line, which means you can get in if you have a user and password, or that environment flag is set. The downside is now you all know you can just set your user agent to Facebook and get access to my dev sites. 😉