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.


The Apple Conundrum

apple conundrum and devices that i can't plug in anymoreApple, once upon a time, was the go to source for hardware for developers. Some developers may still swear by it. I however, am rolling far away from the Apple tree.

The price of current edition Mac Book Pros have gone up so much that I can not justify buying it. Apple products do not make me money. They are not required for me to do my (entire) job.

Rewind about 12 years. I bought my first 15″ Mac Book Pro. This was the first time they were aluminum bodied. That MBP was a sweet sweet piece of hardware, and as a novelty, I know I paid way too much for it. I fell for the Apple upgrades and spent about $2500 for it. That laptop lasted me about 2.5 years with one battery replacement, and a few other hardware related issues, which was unfortunate.

Move forward to 2009 when Apple released the full body aluminum models. This design was damn near perfect. I got myself a 13″ MBP for around $1700. In 2011 I upgraded the RAM to 8GB because I could. In 2014 I upgraded the hard drive to SSD and retained the original HD as extra storage because I could. In 2017 this MBP still functions fully, albeit a slightly diminished battery capacity. I’ve gotten over 8 years out of about $2200 in total. Unfortunately for me, Apple has deemed this hardware to be “no good!” incapable of upgrading it to the latest OS, which means I can no longer do part of my job (iOS development) on this fully functional hardware. This form of forced obsolescence is, quite frankly, bullshit.

Move forward to today. To get a MBP of approximately the same capacity (500+GB space and 8GB ram), ignoring “slight” CPU improvements, and a fairly under-powered GPU, I’m looking at a minimum $2229 out of the gate. And guess what? I can’t even do my job with that as-is courtesy of Apple Innovation and their desire to remove all of the ports. I’d need to add a pile of dongles or a “dock” just to get back regular USB, ethernet, external monitors, etc. That’s an extra $300 easily.

At the very most in my life I need a Mac OS machine that’s capable of running the latest Xcode on the latest OS.

Which brings me the conundrum. Do I bother to blow money on a new laptop that I (for the most part) know will not last me as long as my prior laptop?

Do I try and buy a used one that’s capable of running macOS High Sierra? The resale value tends to be a bit high too though, but at least that money doesn’t go right back to Apple.

Do I find an alternative Ubuntu capable laptop and just pick up a cheap-ish Mac Mini to do my Xcode work on? I could probably buy both of them for less than $2000 easily. Unfortunately that puts a kink in the work flow, that’s for sure.

What do other hybrid developers do? I work with web, native mobile, and other “creative” code projects. All of which are cross platform except iOS.

Thoughts or opinions welcome.


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 nginx’s auth_basic

In my prior post, Allowing the Facebook Debugger through .htaccess, I showed how you could do just that. But, as time goes on, I spend more and more time with nginx and I need to adapt my rules.

So, today, I decided I should do the exact same thing with nginx. All of the dev sites I work on are generally password protected with a standard auth_basic setup. This is great, keeps the robots out and prying eyes away. But it’s always an issue when you need to test sharing and other external scrapers.  As it turns out, doing so with nginx is just as simple as it was with Apache.

My initial ‘location’ block was a simple configuration:

location  /  {
  auth_basic            "Restricted";
  auth_basic_user_file  htpasswd;

  if (!-e $request_filename) {
    rewrite ^(.+)$ /index.php last;

To allow Facebook debugger through the simple auth_basic was as easy as adding an if check and a secondary ‘location’ rule.

location  /  {
  error_page 418 = @allowed;

 if ($http_user_agent ~* facebookexternalhit) {
         # bypass httpauth.
        return 418;
  auth_basic            "Restricted";
  auth_basic_user_file  htpasswd;

  if (!-e $request_filename) {
    rewrite ^(.+)$ /index.php last;

location @allowed {
if (!-e $request_filename) {
              rewrite ^(.+)$ /index.php last;

The first thing added was a rule for nginx to understand what I mean when I say ‘return 418’ – this is the http response code for “I’m a teapot” The if block simply checks if it’s a known facebook agent, and the third block is a custom location that strips out the authentication requirements.

It’s generally fairly simple the concept and can be applied to any other external scrapers that you may need.


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. 😉


Twitter Weekly Updates for 2012-10-14