Friday, November 22, 2013

Week 2: Development Continues....

Version 0.2 Released:

GumBall Fall v0.2: Web Player | Android

The week's work has culminated in a new Web release of GumBall Fall.  As always, lots of concepts are still in flux and most things are still basically place holders and/or proof of concept prototyping. No player data is retained/saved. No fancy scoring algorithms have been implemented. No special effects are present. What you'll experience is most definitely an early work-in-progress

Major Changes from v0.1:
  • Must now 'start' a game. Simply click the Start button and you'll have 45 seconds to chain as many Gum Balls as you can
  • When time runs out, any chain you were making in mid-selection will be added to your score
  • Chain selection is no longer required to be sequential

 

The Week's Highlights:


Early Feedback is Key:

Right now, the biggest issue is the need to sequentially select gumballs when forming a chain. As long as a gumball is 'close enough' to the chain, one ought to be able to select it at any time. Code has been altered to address this problem.

Introducing 'Proper' Game States:

The game will use a dual game state mechanism: One tracking the actual state of the game (over, active, paused, etc) and one tracking the UI state (Main menu, options menu, active, etc.). This decision better ensures that actual game logic and UI logic remain better decoupled from each other. If desired, any UI state can be associated with any game state. This allows me to independently tweak UI elements without affecting any game logic.

Publish-Subscribe Pattern at Work:

During the early development of Bouncing Bombs!, game objects were quite depended on each other. Tweaking any given object had the potential to have a ripple effect across many objects. In other words, my objects were rather tightly coupled to each other. Needless to say, this was bad. Messaging saved me and it will be used for GumBall Fall.

The basics of this design pattern are straight forward: Publishers post messages to an intermediary message broker or event bus, and subscribers register subscriptions with that broker.

When a game object has something to report, it simply publishes its data. Any game object interested in that data simply subscribes to it.

This system effectively decoupled my game objects. Individual objects no longer need to know about the existence of any other objects. They report data without caring who needs it and receive data without caring who sent it.

GUI Implementation Has Begun:

In my early days of experimenting with Unity, I quickly learned that, while any GUI support is better than none, the Unity GUI support was, well, lets just say not good. Creating Bouncing Bombs! lead me to the NGUI UI solution. While not cheap, it certainly is light-years ahead of the built-in Unity GUI tools in many ways not the least of which are performance and ease of development.

NOTE: The developer behind NGUI is currently reworking the native Unity GUI system. When that officially comes online, there likely won't be a need for NGUI or other GUI frameworks. But, since the new Unity GUI frameworks isn't live yet and since I took the plunge and bought NGUI for Bouncing Bombs! it's a no-brainer to use it for GumBall Fall.

Having only been away from Unity for a few months, I wasn't expecting to see drastic changes in NGUI. Turns out, I was quite wrong. The NGUI 2.x experience I was familiar with was replaced with NGUI 3.0. Many concepts remain the same. But, many of the improvements meant it was time to relearn how to use NGUI. Lucky for me, the creator had some nice NGUI 3.0 YouTube videos to get me started: http://www.youtube.com/user/ArenMookR5

With a refresher course under my belt, it's now time to get the User Interface blocked out. Building off what seemed to work with Bouncing Bombs, the UI communication will be handled using the same Publish-Subscribe pattern used by my game objects. When interacted with, buttons, sliders, etc will message a mediator with a request. The mediator will ultimately get to decide what action to take and will, in turn, inform the rest of the game's components. Taking this messaging approach should better ensure that my UI will stay decoupled from other game components.

Friday, November 15, 2013

Meet GumBall Fall

GumBall Fall v0.1 (Unity Web Player)

With the tech demo complete I was still looking for some sort of original game idea... or, more likely, one to rehash.  Staring at the cubes fall and pile up, I figured that their numbers needed to go down. The demo was already capping the number of objects on the screen. If too many were on screen, ones from the bottom would be destroyed and new ones would be created and dropped on top.  Why not force the player to destroy said boxes?

Think Candy Crush or any other of the thousands of 'Match 3' games that are out there. But, think of it in a more free-flowing organically physics way. Boxes fall to the floor. Player matches similar boxes. Boxes get destroyed. Player gets points... or something like that. Details can be refined later.  Proof of concepts must be built!


First Cut:

I already created code that created falling boxes on the fly and destroyed said boxes at a later time. Now it was time to do something more useful. Below are my first set of accomplishments:
  • Don't auto destroy the boxes; the player must do that
    • Easy enough to do. Simply remove my auto-destroy code
  • Allow player to select boxes
    • Here's where I hit my first real snag. In the 3D physics world of Unity, there are multiple ways one can use touchscreen touch-location pixel data to determine if the user has selected an object. Ultimately, those 3D ways boil down to the fact that 3D objects have a 3D collider attached to them. In the Unity 2D world, no such 3D collider can (easily) exist; you're dealing with 2D colliders that fail to work in quite the same way as their 3D counterparts.  After a bit of struggling with how to make selection work with 2D, I ultimately decided to (at least temporarily) throw in the towel and revert back to my familiar 3D physics world. This is something that I plan on investigating further at a later date
    • Comfortably back in 3D, selecting any number of random boxes was a straightforward task
    • Once selected, the list of boxes were simply destroyed. A new collection of boxes, proportional to the destroyed set was then created and dropped on top of the pile 
  • Allow player to select only boxes 'close enough' to the last selected box
    •  Unlike most 'Match 3' games, this game board is free-flowing. There are no grids to easily tell if a player is selecting adjacent objects. Call on the Unity physics engine to save the day!
    • Given a location in the world and a radius, the physics engine can return me a set of objects that fall inside of that space. If the location is the previously selected game object and the radius is sufficiently chosen, I can easily tell which objects are 'close enough' to my currently selected object. If the user touches one of those objects, then the game will select it
  • Allow player to select only boxes of the same type as the currently selected box
    • Once a player has attempted to select a nearby box, we need to ensure that said box is the same type as the box he previously selected... we're trying to match similar objects, after all.
  • Don't churn objects
    • In Bouncing Bombs!, items were created on-the-fly. When they were collected, they were simply destroyed. This can lead to a lot of needless resource thrashing. Thanks to most devices being rather powerful today, this thrashing isn't typically noticeable. But, it was the cause for an occasional hiccup in Bouncing Bombs!, so, I wanted to handle things differently this time around
    • Enter Object Pools: Instead of creating objects on-the-fly, I'm now initializing a bunch of objects at game start up that will be reused throughout the game. The trade off is that it takes a bit longer for the game to initially load and a bit more memory is reserved at the start of the game. The benefit is that I should, hopefully, see no framerate hiccups from on-the-fly object creation and destruction. Only time will tell how much I benefit from this approach
  •  These aren't the Boxes you're looking for
    • So, now I have 80-100 boxes falling and forming a massive blob at the bottom of my game board. The player can select a bunch of them and destroy them. But, the resulting blob looked a little funny. Boxes tended to overlap on each other a bit, large 'holes' in the blob formed, etc. This made selecting chains of boxes difficult at times. Additionally, the boxes just looked flat and dull. Sure actually applying textures to them could eventually fix that issue. But, I've not started dealing with art assets yet ;-)
    • Call on spheres to save the day! Why be a square when you can be smooth like a sphere? Converting the boxes to spheres, in my opinion, has made things much nicer. Interesting 'holes' still crop up in the blob, but, the game board just seems more organic now. And, the (still untextured) spheres look much better than the 'flat' look of the boxes
  • What's in a Name?
    • Well, with brightly colored spheres now on the screen, all I could think about were gum balls. And what are these gum balls doing? Falling! Thus, the name: GumBall Fall
    • Yeah, really original, I know. I have no idea if the name will stick as the game evolves. But, for now, that's what it's going to be called
Welcome to the world, GumBall Fall!

Game #2 Begins

After a bit of a hibernation from developing after releasing Bouncing Bombs! I've gotten the development bug again. With Unity 3D 4.3 having just been released, I have the perfect opportunity to 'kick its tires' and take it for a test drive with this new adventure.


Tools:
  • Unity 3D 4.3 - Multiplatform support. Easy to use. Fantastic community. And, of course, free.
  • Subversion (version control) - Lesson learned from Bouncing Bombs!: Always use a version control system. In my real line of work, I use such a system every day. But, in my 'fun time' programming last go around, I was simply too lazy to setup such a system. Dang, that was a stupid idea!  That'll be rectified this time
  • Scoreoid (high scores) - I succeeded in using this free service on Bouncing Bombs! As it's completely REST based, it should meet my multiplatform needs just fine. There's no reason not to consider using it again, but...
  • Google Play Game Services - These came out after Bouncing Bombs! was released. They offer leaderboards, cloud saves, etc, etc. I plan on at least looking into this service
  • Paint.NET and Gimp - A guy's gotta create some game art, right? Free and easy to use for a non-artist like me. I'll hopefully make some stuff that doesn't look completely butt-ugly
  • Audacity - You need audio to go with the visuals. Audacity gives me the ability to capture/create/edit those sounds. And, again, it's free
  • More to come...

Game Concept:

Hmmm... good question. The new 2D tool kit in Unity 3D sounds interesting. Perhaps I ought to delve into that. One less dimension to worry about.


Initial Tech Demo:

 2D physics tech demo time! From some previous prototypes from a year or so ago, I knew I ran into some issues pushing 100+ simple physics objects on an Android phone. I'm sure there were multiple reasons for the poor framerates I would occasionally get, but, I was curious to see if the Box2D Physics that now comes packaged with Unity would provide better performance over their 3D physics offering.

In an attempt to keep the API familiar to Unity vets, the Unity folks have built the 2D interface to mimic much of the 3D interface. Instead of Physics components, you have Physics2D components. Most functions and such follow the naming scheme of just tacking on 2D to the end of it. It made my journey into the 2D world much easier to understand.

I quickly coded up an object manager that would simply drop 2D physics squares onto my screen at a quick clip. The goal was to allow the squares to accumulate and interact with each other. I also added some basic touch controls that would let a finger interact with said squares.  The demo was pushed to a few phones for testing (Galaxy S3 and S4, Droid 4, Nexus 7 2012 and 2013). As one might expect, newer hardware produced better results, but, even the Droid 4, the oldest of the bunch, still showed respectable framerates with 80-100 objects interacting on the screen.

So, the tech demo looked kind of promising. Now I just need to come up with an idea...