The Making of Starific

Starific History


Revolutions are being written one line of code at time.  Eighteen year olds can build the next billion dollar enterprise from their dorm room.  Nearly every waking moment we have is occupied by some zeroes and ones somebody else compiled.  Why wouldn’t you want to learn code?  That was my thinking.

July – August 2014

I searched around online for an introduction to programming and settled on a Python Coursera course.  I had read Python was the best language for a beginner to learn because the syntax was so explicit.  This turned out to be a good choice.   I finished  the course in about a week and began thinking about what I could build to learn more.

In my naive ignorance I decided I could make a mobile app.  Since I didn’t want to learn ObjC or Java I decided I should use a cross platform engine like Unity or GameMaker Studio.    I opted for GMS because it seemed to do a lot more hand holding e.g. an extensive built in library.

I ended up learning GML, which is similar to C, and then later C when I took the CS50 EDx course.  So much for not learning other languages.

Over the next few months I continued to study programming and subjects related to computer science.   The MIT Python course is what I would say made me a semi-competent developer.

I tinkered with GMS and made various game prototypes as I learned new concepts like graphs and algorithms.  I also learned just by making mistakes.  I learned about garbage collection the hard way when one of my projects was using 10gb of RAM.

Starific evolved out of these prototypes and one in particular, which felt a lot like Pachinko.  If you’ve played Starific, imagine there not being any paddle, or powerups.

Starific Evolution

Things got more interesting when I added bomb blocks that chain reacted.  I showed a few friends and they liked it too.  I felt the premise was viable so I started to iterate on it.   It was a haphazard process.  I remember Walt Disney once said the key to making a great product is to find something you like and then “plus one” it.  I was not doing that.

And as one might expect this ad hoc process led to various design problems.  Numerous times I hit a wall and almost gave up, each time the project was saved by a flash of insight.

What probably helped most was persistence and showing my work early and often.

September 2014

This was what I had produced after a few weeks of programming in python (Hello World!).  And then a few weeks reading up on GML.  There was a period of brainstorming and I decided on a cohort of basic powerups.  I showed friends and they liked it.

If you want a million dollar habit, here it is:  Ask people for advice and listen to them.   That doesn’t mean do what they say, and definitely don’t if they have no competency in what you’re asking about.  But even then what they say can inspire you.

That said, nobody likes a monomaniac and people will get weary if you always need something.  So I made it a point to show the game to all and sundry but never too much to the same person.  The variety helped my iteration process.

One problem with the game back then was that the rail was a square instead of our humble octagon.  This meant the paddle would jump between the sides and made corners awkward.

October 2014

To deal with the corners I made a slew of prototypes.  I wanted to maintain the chain reaction feel while diminishing any abruptness between sides.   A recurring suggestion was to use a circular rail, instead of a square.  I tried that but it meant the star could move in any direction and the lack of cardinal movement ruined what I liked about the original prototype.  So I went back to the drawing board.   This was when Spencer McKone suggested an octagon.    I coded it up and loved it.   So did my testers.

I made a hell of a lot of prototypes around this time, maybe two dozen.   The iteration was key and I was lucky I had a lot of willing guinea pig friends.   The octagon system was heavy on trigonometry, so I had to relearn my maths (thanks Khan Academy!).

Another difference back then was that none of the powerups were projectiles.  I felt this offered a level of anticipation, reading what the stars might trigger next.  Sort of like a pinball machine.  Ultimately this didn’t pan out.  Users felt robbed of their agency.

The black track pad at the bottom was a prototype control system.   I was running experiments on how to make the game work for touch devices, but everything was clunky.

November 2014

Here things came together.  I decided to take a note out of the Breakout playbook and added catchable powerups.   This was a big hit with my testers.  Now the game didn’t feel so much like a lottery but rather reflex and quick thinking.  You could risk losing the star by going after a powerful powerup or dodging a deleterious powerdown.

The art was still a mess and I was starting to take the project seriously.  So I began searching for a designer.

It was around this time that I named the game.  Up to this point the project was only a series of prototypes, by no means a real project.  Internally I had been using the name Reflector.  Because the stars would reflect off blocks.  After playing around with some naming apps like Wordoid and Namebird I settled on Starific.

December – January 2015

Deciding on an art style was difficult.  I had no design experience beyond winning a Rodeo Art contest in second grade.  In Texas grade school you have to draw art about the rodeo.  Go figure.

My first intuition was to talk to freelance designers and artists and I did.  But to tell you the truth most of these guys are just looking to fund their DOTA addiction and while they are talented and can do what you ask, they usually can’t think for themselves (or for you).  If you ever find yourself in a similar predicament and don’t know what aesthetic you want, take my advice:  Find someone who’s opinionated.  Guys are better because they’ve got a stronger will.  Western artists are the best.   Asian and Eastern artists aren’t bad but what they think is in good taste is way different from what’s appealing here.   If you know exactly what you want, and can articulate it, this is less important.

That’s what I ended up doing, I found a kid, not even graduated and he mocked up different styles for me.   I had read flat styles are best for a small budget because they’re simple to modify and easy to implement.   This is what I went with.

Not having a budget to speak of I had to get as many assets as I could for free. came in handy here.  They have an extensive collection of professionally designed vector graphics.  If you ever need menu or social icons go there.  For anything I couldn’t find free I hired a freelancer.

For the animations I looked at other games and then did a lot of closed eye visualization.  The process is similar to what I imagine a film director or video editor does.

The color palette couldn’t please everyone so I decided to offer multiple palettes.  This evolved into a big set of unlockable palettes.  I had fun making them.


The art went over well so I was now getting serious about touch devices.  I’d say this is when development started in earnest.  I had mechanics and I had an art style.   While moving your mouse around in a circle worked on PC it didn’t translate to an iPhone.  Your finger would cover up half the screen.

Since the game was radial I looked around for other radial games on the app store.   Surely somebody had faced this problem before?  Turns out yes, they have, but no they never solved it.   Every radial game I tried was a joke.  The controls were clunky, or purposefully frustrating, like that Ketchapp radial pong clone original game.

This meant I either to had to chuck the project or invent something all my own.  Being stubborn (or determined if you’re generous) , I opted for the latter.   I tried taps, I tried swipes.  I tried up and down, I tried all around.   Nothing worked.   Users pretty much hated the mobile version.

The virtual joystick had the most promise.  If you’ve ever tried, it was like that.  The problem was people’s fingers wouldn’t move in a perfect circle and there was no hand eye coordination since your eyes were on the board.  If you’ve ever seen a 9 year old play with a console controller, how they veer it to this side and that to give it more (I’m not sure) force?  That’s what was happening here but just with fingers.

Being a practical man, I planned out how I would shelve the project if I couldn’t come up with something soon.  But I had a eureka moment.  You see, I had been studying linear algebra late into the night and the next morning, half awake, I realized I could detect changes in the arc motion of the finger coordinates and based on that change the rotation of the paddle.    The other insight was to put a leash on the joystick so it wouldn’t need to be the same distance always.

March 2015

In essence it works like a joystick that follows you. You can tap anywhere and it will reorient. As long as you move in an arc it will understand.   If you move in loop-de-loops it understands.  If you move really fast across the middle, it understands too, I made an edge case for that.

Users loved it.  My intuition is you could remake a lot of radial games with this system, and they would no longer be clunky.

April – June 2015

Hiatus: I was learning C, Assembly and Machine Code.  I like to learn, and sometimes that means I trade productivity elsewhere.   I heard it phrased best by Dr. Oakley in the How to Learn Coursera course.   Everyone procrastinates, because whenever you do one thing you’re procrastinating others.   So productivity isn’t a matter of not procrastinating but choosing carefully what you procrastinate.   Replying to a text message or email isn’t as important as reading a book, and you should prioritize accordingly.  Answering your phone isn’t as important as paying strict attention to whoever is speaking to you.    You can also use procrastination techniques to help yourself get work done.   Example:  The new Game of Thrones is out?  I’ll watch it later.  You can keep procrastinating these time wasters until you’re a millionaire.

As an aside, I can’t recommend the book CODE highly enough, it really helped me grok the inner workings of computers.  Before reading it they were still magic to me.

To Present

A lot of technical guys are tinkerers.  They like to experiment but they don’t produce anything commercial.    I have nothing against them, they’re usually the ones that build awesome tech.   But my suspicion is this is because producing something commercial is a whole lot of schlep.  That’s a fancy Jew word for hassle.    Over a couple months I worked on the tutorials, monetization and other auxiliary stuff necessary for Starific to not be another garbage product.

Details matter.  Aligned text, consistent UI/UX, snappy animations.  All this takes time, and none of it teaches you anything.  What do you learn after the 20th menu you’ve programmed?  Nothing.  But this is what sells your product.  That menu animation that took you two hours is what delights somebody in ways they can’t articulate.   And that’s what makes your product successful: exceeding expectations.  Including the ones people aren’t conscious of.

You’re far better off making 1 polished product than hundreds of “GamJam” experiments.  Don’t get me wrong, experimenting makes you better at picking out what’s a good idea, but it doesn’t make your good idea any more tangible.  My theory on a product’s success is Income = Idea * Execution.   Execution is a matter of dealing with schleps, whether it’s marketing or picking fonts.   And how good your execution has to be is a function of competition.   The games industry has such low barriers to entry that it’s flooded.  Mostly garbage, but also a lot of quality stuff.   And if you want to succeed you can’t just be good.  You have to be the best.