Thursday, March 27, 2014

Gumball Fall - Shake, Shake, Shake... Shake That Booty!

Version 0.10.5 Released:


GumBall Fall v0.10.5: Web Player | AndroidGoogle Play BETA | Google+ | Twitter

Major Changes in v0.10.4 (Mar 25, 2014):
  • Color scheme updates including one with patterns
  • Tutorials re-integrated into the system
  • Highscore screen now can show Daily/Weekly/All Time scores
  • [Chaos] Shake your device and watch the gumballs shift!
  • Music volume tweaks
  • Leaderboards and local data reset (Platform ID 1004)

Major Changes in v0.10.5 (Mar 26, 2014):
  • [FIX] Gumballs in Order modes should no longer frequently become lost when chains containing gumballs from the extreme left and right columns are created. NOTE: They might still infrequently become lost
  • Reduced force imparted on gumballs when you shake your device
  • Experimenting with adding a bit more ‘bling’ when you complete a chain of 6+ or blow up a bomb. This will likely continue to change with future releases
  • While still likely not 100% accurate, Weekly and Daily scores should now report more consistently between global and local leaderboards

It’s been a few weeks now since I’ve had an opportunity to sit down to add an entry to this development blog. I would love to report all sorts of fancy new features since the last update. But, sadly, development of Gumball Fall has slowed down these last few weeks.

Why The Slowdown:


Part of the slowdown can be blamed on illness. I was useless for roughly a week. But, mostly, life has just popped up various activities that have been consuming my time in lieu of pursuing further game development activities.  But, enough excuses... onto the noteworthy updates!

Color Schemes - Round 2:


Basing any aspect of your game solely on one sense (sight, hearing, etc.) should be avoided if at all possible. Such a decision has the potential to alienate part of your potential player base. As noted in an early post, I basically ignored that advice for Gumball Fall... Gumballs are round and brightly colored! Only color will be used to distinguish gumball differences! To attempt to address my decision, I introduced a few different color schemes specifically designed to be distinguishable by various types of color blindness.

Despite my efforts, colors alone will never cover all color blindness scenarios. To better address this scheme deficiency, I decided to introduce patterns into one of my schemes. The gumballs can still be perfectly round and more folks will be able to see them! That’s a win-win. After trying a few different tactics, I settled on a combination of sports-based gumballs along with a few other random items to round out the 6 gumball types. The way I see it, while not as popular as solid colors, I’ve seen my share of ‘sports’ gumballs in machines. Little kids like losing $0.25 to chomp down on a gum-based ‘baseball.’ Why not have them in my game?


Pattern-based gumball sprites and their highlights

Thanks to a buddy, the patterns have passed their initial ‘color blind evaluation.’ We’ll see if they hold up when released to a wider audience!

Shake, Shake, Shake… Shake That Booty:


Or, more accurately, shake that mobile device… but, that doesn’t flow off the tongue nearly as well ;-)

From the moment Gumball Fall was pushed to mobile devices, there’s been one constant that everyone, without fail, as tried to do: Shake that last pesky gumball into place to create that long chain. For just as long of time, I’ve had plans to integrate a shake feature into the game. To integrate a mobile device’s accelerometer in a meaningful way, I had a few design decisions to make.

Does tilting affect gravity? Ultimately, no. I don’t want tilting/shaking affecting gravity. Once you wish to control ‘gravity,’ you have to be concerned with the device’s orientation so you can correctly determine where ‘down’ is. Is the player holding it vertically vs. horizontally vs upside down vs on some random angle? What happens if the player wants to adjust his playing angle from when he first started? What happens if (s)he pauses the game and resumes later with the device in a different orientation? etc. etc. There are multiple ways to address these questions. But, I have no desire to open up that can-o-worms. Instead, I’m just going to ignore the whole gravity control issue.

In lieu of messing with gravity, shaking will just jostle the gumballs… kinda like smacking the side of a snack machine to loose that stubborn candy bar from the metallic grasp of the machine. Now comes the question, how ought I smack that snack machine?


The accelerometer aspect of the equation was fairly straightforward: Simply look for ‘quick’ differences in accelerometer values. The basic algorithm is nothing more than:

  • Get current accelerometer value
  • Compare to previous frame’s accelerometer value
  • If current is ‘sufficiently different’ from previous → player shook the device
The one consideration to keep in mind is that the accelerometer values (at least as reported in Unity 3D) constantly fluctuate similar to what you’d see in a true analog device. To account for this, I’m averaging my accelerometer values over a few frames


With the definition of ‘shake’ completed, what ought I do when a ‘shake’ actually happens? I tried a few different ideas:


  • Approach 1: Simply apply a directed force to every gumball in the game. While this, indeed, moves the gumballs, the result looks awfully uniform. I was seeing the whole group of gumballs simply move as one big blob. It didn’t really look realistic
  • Approach 2: Directly Apply a force to the walls and/or floor and allow those things to bump the gumballs as appropriate. By adding rigid bodies to the walls and floor and clamping them to not move, I was able to apply any amount of force to them, the force would transfer to the gumballs and, the walls/floor would remain unmoved. This gave the the gumballs a more natural looking behavior, but, still felt stiff
  • Approach 3: Create a spring-loaded basket to cradle the gumballs. If I’m making a physics based game, why not take full advantage of the physics engine? Why artificially clamp the boundaries? This idea lead to the creation of a simple U-shaped ‘basket’ suspended by 3 springs, one each at the top, left and right sides. When a ‘shake’ occurs, a force is applied to the basket. As a result, the basket bounces causing the gumballs to jostle. Thanks to the spring forces, the basket quickly resets itself and is ready for its next ‘shake’


Ultimately, I like Approach 3 the best. It looks the most natural and, as a result, (I feel) it gives the most ‘accurate’ results. Ultimately, the players will decide if I’m correct. As I gather feedback, the springs will be tweaked as needed. Additionally, similar to pinball, a Tilt system may be introduced. Shake that thing too much? Find yourself S.O.L. And, if it's a complete flop... back to the drawing board!

When it's all said and done, KC and his Sunshine Band had it right. You gotta shake that thing!


Alrighty, that’s a large enough wall-o-text for this update. Thanks for reading!

Thursday, March 6, 2014

Gumball Fall - Stop & Squish The Bugs

Version 0.10.3 Released:


GumBall Fall v0.10.3: Web Player | AndroidGoogle Play BETA | Google+

There's that age old saying: Sometimes you have to stop and smell the roses. Well, what do you do if you find out those rose bushes are overrun with pesky insects?


Major Changes since v0.10.0:
  • Bug Fixes:
    • Fixed menu transition animation in Settings menu when users exit the menu via hitting the Android ‘Back’ button
    • Chains starting with Rainbow Balls will select proper color to pop when chains of 6+ are created
    • Score for selected chain now correctly displays above your finger/mouse
    • Suggested moves should work more reliably now
    • Board resets when no moves are present should work more reliably now
    • Gumballs should no longer fall when game board is clearing during Game Over
  • Ease-of-Use Enhancements:
    • Game Mode help screens can now be closed in 3 ways:
      • Tap anywhere on the screen (initially implemented way)
      • Press the newly created “close” button
      • Press the Android ‘Back’ button (i.e. escape key on keyboard). Users were constantly pressing this button and watching the game exit… which is what they didn’t want
    • Canceling moves is now more obvious: Drag your selection over the trash can button
  • Audio Updates:
    • Reworked volume settings UI in Setting menu to address audio bugs and to replace volume sliders with toggles
    • Reworked play music logic to ensure music is played at the correct times/locations
  • Graphical Updates:
    • Updated font used to render score from selected chain
    • Frank now informs you of the type of bonus you received (Rainbow, Bomb, Clear)
    • Most 3D models swapped for 2D sprites
    • Revamped gumball animation system allowing for more fluidly gumball animations
  • Various Performance improvements

Squash Those Pesky Bugs:


Over the last several weeks, implementation of featrues in Gumball Fall has been in a holding pattern. As much as I'd like to continue adding new (and, hopefully, fun!) features, sometimes you need to reflect and correct what you've done.

I've had a known set of bugs that I've continued to ignore for a while. I've dedicated the majority of my time this period to squashing them... or at least attempting to.

The majority of my (known) bugs do not cripple the core gameplay. They merely inconvenience and/or confuse the player:
  • Invalid suggested moves
  • Board reset when no moves present... Okay, this one CAN break core gameplay
  • Gumballs continue to spawn when the game is over
Without going into the nitty-gritty details, these bugs can be pretty much summed up by pointing the finger at less-than-ideal Coroutine design/usage. The logical underpinning behind each of features was solid. However, in an attempt to get these features quickly integrated, they were fired off in continuously running coroutines and left to fend for themselves. The longer a game round lasted, the more likely the coroutines' timings would drift from the actual game which increased the likelihood of these oddities showing up.

The reimplementation still uses coroutines but they now use a more event-driven one-time shot approach. For example, when the board is deemed to be in a 'stable' state, an event is fired off to make suggestions, etc. This eliminates any sort of looping time skew and ensures that the game will only perform these events at very controlled times. Thus far, the reimplementation appears to be working as intended.

Using Unity More Gooder!


‘More Gooder’ being a technical term, of course. I've mentioned in the past that, as a solo developer, I have neither the time or skill to recreate the wheel. If a suitable solution exists, I should consider using it to accomplish my goals. Well, as far as gumball animations for suggesting/selecting goes, I wasn't fully living up to my own words. Knowing full well that Unity provided a 'modernized' version of its animation system, I continued to stubbornly use their legacy system. Not embracing the new system amounted to me wasting time attempting to control many aspects of the gumball animations that I shouldn’t have had to concern myself with. Needless to say, using this legacy system forced me to introduce less-than-ideal logic into my game code that, ultimately, lead to various animation bugs.

Taking the handful of hours to migrate over to the 'modern' animation system immediately corrected these bugs. Additionally, transitions/blends between non-selected, suggested and selected gumballs look far more natural than they ever did using the old system.


All Hail Our 2D Overlords!


Gumball Fall plays out in a 2D universe, but, has historically used complete 3D models to represent said gumballs, bombs, etc. This release sees the removal of these models. They've been replaced with another new-ish feature of Unity: Sprites. The main rationale for the change came down to performance. When targeting mobile, every draw call counts. Ever extra vertex or polygon counts. I noted in a previous post that I had to make visual fidelity sacrifices in my 3D models to achieve some magic vertex count numbers to take advantage of draw call batching in Unity. While attempting to make the game more visually appealing (aka, adding more 'juciness'), the draw call numbers started to creep back up.

Sprites were the answer to my situation. The beauty of the sprite rendering system is that, with few (no?) exceptions, Unity handles sprite drawing as a single draw call. Shifting to sprites from 3D models instantly reduced my draw calls by a factor of 6. Additionally, the number of triangles getting drawn dropped from thousands upon thousands to around 800.

Overall, I'm happy with my move to sprites but, it did come with some drawbacks. Most notably, the automatic 3D shading I was getting with cube mapping my 3D gumballs is no more. My initial rendition of the new 2D gumballs were literally nothing more than solid colored circles. I could bake a shadow and specular highlight into the sprite, itself. But, if the sprite ever rotated, the shadow and highlight would rotate with the sprite... needless to say, not 'realistic.' While there are 3rd party shader options that claim to '3D shade' 2D sprites, I've come up with a 'hack' of a solution that, for now, is getting the job done. I've created a shadow/highlight sprite that simply gets independently superimposed over the solid colored circles. The circles can rotate all they want while the super-imposed shadow/highlight sprite's rotation remains forever constant. No extra draw call is needed for the shadow/highlight. Maybe not the most elegant solution, but, it works, looks decent, and has minimal performance hit on the game.

Before (left) and After (right)


It is worth noting that this solution probably will become annoying to maintain if I expand beyond just having simple gumballs. Creating/swapping/etc. the shadow/highlight entities for various shapes incorrectly could introduce some interesting visual bugs.

That’s all for this update. Give the latest build a spin and let me know what you think!