Thursday, December 19, 2013

Holiday Slowdown

Version 0.4 Released:

GumBall Fall v0.4: Web Player | Android

With Thanksgiving rolling right into Christmas coupled with end-of-the-year duties at work and home, development has been a bit sluggish as of late.  However, I feel that I've finally pieced enough together to warrant a new release and blog update.

While still a work-in-progress, I think it's actually starting to look a lot more like a real game!

Major Changes from v0.3:
  • Stat Tracking:
    • High scores will be reset in future releases... don't become attached to them ;-)
    • High scores for each game mode/type are now being tracked individually
      • The top 10 of each mode/type are being saved
    • Total gum balls collected being tracked
    • Totals for each color gum ball being tracked
  • In-Game Graphic Improvements:
    • No more BLACK gum balls... welcome PINK into the world
    • First attempt to get the gum balls to actually look more like gum balls and less like simple spheres
    • First attempt at generating EXPLOSIONS when clearing gum balls from the screen
  • User Interface Improvements:
    •  Scores & Stats screen expanded upon
    • Interface reworked to be more modular and scalable to more easily support various resolutions
  • Sound Effects:
    • Chain creation now generates aural feedback
    • Falling gum balls create noise when colliding with objects (if they hit hard enough)
    • Clearing gum balls generates EXPLOSION noises

This Period's Highlights:

Early Feedback Continues to Focus Development:

As always, the latest player feedback to be quite useful. Reddit continues to be the most popular source for Feedback. Most feedback comes from posts in /r/unity, /r/unity3d, /r/indiecode or /r/gamedev's Feedback Friday and it's always enlightening.  This go round, most folks were asking for 'cooler effects and explosions.'  While I certainly agree that things need to eventually get ratcheted up a few notches, I think the key word is eventually.

With that said, and with the game play mechanic being better pinned down, this iteration does see the introduction of several 'pretty' effects.

Internal Restructuring:

I don't know about you, but, more often than not in the software development world, there's always an ever present force urging you to "make more!" "go faster!" and "add these new features!"  Whether that force is your boss or your own desire to proceed, it's always a good idea to take a moment to stop and reflect on what you've accomplished... then improve upon it.

Knowing that I kicked off this project in a hurry (and knowing that I'm still learning C#), I knew that I'd have to tackle its internal shortcomings at some point. I've started that process. A good chunk of my code was reused from Bouncing Bombs!. Many of the internal data structures I was using back then were simply C# structs with all sorts of public members... not necessarily evil, but, not all that wonderful either. Slowly but surely, these structs are being transformed into more fleshed out full-fledged C# classes.  With just the few that I've converted, I can already see the benefits I'm getting. My code is better organized. My data is less spaghettified (yeah, I'm making up that word!). My life is getting easier.

There will always be that siren's song of "just hack something together to get the job done" calling to me. And, I'm sure I'll fall prey to it from time to time. But, if you find yourself being called by that song, when the dust settles, just remember to take a few minutes and revisit that code you've written and figure out how you can make it better!

Introducing Bells and Whistles:

A little bit of polish goes a long way. Don't believe me? Take a moment and check out this video to see how some simple bling can transform a dull 'breakout' clone into something far more epic looking.  Of course, if the game play, itself, is boring or broken, no amount of bling can save your game ;-)   ( Note to self: make sure game play in GumBall Fall is neither boring nor broken ).

Visual Art isn't my strong suit, but, thanks to Unity's powerful particle effects system, I've been able to at least create a few effects that make the game pop a little. Hopefully, as things progress, I can improve (and add more) to these game play effects.

Along with visual art, comes sonic art. aka sound effects and music. When bringing sound to my game, I had a major decision to make: Roll my own audio solution or farm it out to a 3rd party library.  For Bouncing Bombs!, I simply rolled my own simple solution. Unity provides all the basic building blocks you need to integrate simple sounds into your game. It wasn't very elegant nor very reusable in other projects, but, it got the job done.

This time around, I decided to opt for a 3rd party solution. Why, because, I don't want to reinvent the wheel. As a lone wolf developer, I don't have time, knowledge or resources to make everything from scratch. Heck, that's the major reason why I'm using Unity to begin with rather than writing my own engine from scratch. Much like I didn't want to write a full-featured GUI library (thus, I'm using NGUI), I don't want to write a full-featured audio library.  After a bit of poking around, I've decided to give the Unity editor expansion Audio Toolkit from Clockstone Studios a try. They offer both a paid and free version of the toolkit. I'm option for the free version at the moment.

As of right now, going the 3rd party route seems like the right call. In 20 minutes time, I had the package installed and 3 initial sound effects integrated into my game: Gum ball chains explode, gum ball selection gives the player some (hopefully) fun aural feedback and falling gum balls make, lets call them interesting, noises.  Needless to say, the audio clips themselves can be quickly swapped for anything more suitable if I so deem it.

NOTE: From what I can tell, the free toolkit has the majority of the paid version's functionality. however, the free version lacks any concept of resource pooling. From my earlier blogs posts, pooling is something I've embraced during this development cycle. Not having pooling with my audio could come back to bite me. But, I'm suspecting that I'll be able to get away without it because (1) my minimal audio requirements shouldn't be that demanding and (2) if need be, I can always upgrade to the paid package.

I'd be remiss to not point out that bling works just as well on the User Interface side of things. Tweened menus look 100% cooler than static ones. Sound and visual tweaks in your UI help draw the player into your game. I've kicked off my UI creation with that in mind and plan on continuing to bling it out moving forward... but, remember, too much of anything is never a good thing. Find that balance and stick with it.  

GUI System:

NGUI is both a HUGE blessing and a curse.  There's no doubt that I'd be dead in the water without such a robust and feature packed GUI system. Its developer is quick to respond to queries and is constantly evolving the product... and there in lies the curse.  Within the few weeks I've been working this project, NGUI has been updated three times. Each time has brought with it some cool new features and refinements, but, the rapid update cycle has gobbled up much of  my development time. With every new release, there's something that doesn't quite work the way it used to which leads me to spend waaaaay too much time tweaking my GUI code to account for the new changes.

Here's an example... one that I'm on the verge of undertaking. The version of NGUI I'm using (3.0.6) has some cool concepts called anchors and stretching. Anchors let you anchor one GUI object to any other point on another GUI object you specify.  Stretching will automatically grow/shrink a GUI object to the size (or some percentage of size) of another GUI object.  I'm using these two concepts to build a modular and (hopefully) robust GUI solution. My Scores & Stats screen is a fine example. Each section of the top of it (title, last game's scores, gum bank, etc.) are all modules that are anchored to each other and dynamically stretched to fit the screen resolution. I think it's pretty slick, but...

The current NGUI release, 3.0.7, just hit the streets. According to the release notes, anchoring and stretching have been combined into a single entity. i.e. All of the work I've put into tweaking these layouts might be completely for not if I upgrade to 3.0.7... damn :-/

Anywho, I'm probably harping too much on NGUI. I'd much rather have a constantly updated library than one that's just dead code.  Just keep in mind, if you're planning on using NGUI, plan on either (1) sticking with a single NGUI version for the life of your project or (2) leave extra time in your schedule for integrating all sorts of new releases.

That's all for this post. Thanks for reading and (early) MERRY CHRISTMAS!

Sunday, December 1, 2013

Thanksgiving Break(through)?

Version 0.3 Released:

GumBall Fall v0.3: Web Player | Android | Linux (.zip)

The Thanksgiving holiday resulted in a hit-or-miss development schedule this week. None the less, a new release of GumBall Fall is now available for the world.  As always, lots of concepts are still in flux and many things are still basically place holders and/or proof of concept prototyping. Minimal amount of data is (in theory) being saved. No fancy scoring algorithms have been implemented. No special effects are present. What you'll experience is (still) most definitely an early work-in-progress

Major Changes from v0.2:
  • You can now choose between 'Chaos' and 'Order' styles of play
    • 'Chaos' play has the gum balls randomly falling onto the game board
    • 'Order' presents the player multiple columns of gum balls to match vertically and horizontally
  • Completely reworked Game State / GUI system
  • Gum balls and game board should now more properly scale to screen dimensions
  • You now have 60 seconds to chain as many Gum Balls as you can
  • Your high score should now be saved
    •  There is currently no distinction between scores gained during 'Chaos' vs 'Order' play. There will be... it's just not there yet
    • High scores will be reset in future releases... don't become attached to them ;-) 


The Week's Highlights:

Early Feedback Continues to Focus Development:

v0.2 feedback proved to be quite useful. The largest discussion revolved around what I'm now dubbing 'chaos' vs 'order.' While multiple folks enjoy the chaos of the free-flowing physics of my original game concept, others brought up a good point about the thrill/reward of setting up 'The Perfect Move' in games like Candy Crush, Tetris, etc. In order to reliably set up 'The Perfect Move,' one needs to be able to plan ahead. That's difficult to do in a free-flowing world.

This discussion evolved into prototyping a more structured game board. Which leads me to...

Implementing 'Chaos' and 'Order':

The original 'Order' prototype was built by modifying what I was already doing to populate my free-flowing physics world. Instead of random placement of gum balls, their placement was restricted to six column choices and their physics movement was restricted to only the Y-axis.

After implementing the above, I had a nice orderly game board. But, I still had a problem. My game logic, still based on a free-form world, would randomly choose a column to respawn gum balls into. This meant that gum balls that were just removed from a column might not actually respawn in the same column... this, of course, led to under (and over) populated columns.

This oddity led to a refinement of my gum ball collection. When gum balls are now originally created, they are assigned a column. When removed from that column, they are respawned at the top of that column. In the case of a 'chaos' board, they'll simply fall and roll where they please. But, on an 'order' board, they'll fall nicely into their desired column.

With the game now being able to support both 'chaos' and 'order,' and enjoying both game play choices, it seemed only logical to work both options into my game. But, doing that would require some rethinking of my general game logic. However, I didn't want to jump that hurdle until I took on a more immediate task...

Scaling The Game World:

Prior to 'Order' coming into existence, I didn't give much though to the size of objects in my game world. My main requirement was to simply create gum balls that were 'big enough' for a person to easily touch with their finger.

Once the gum balls were required to be ordered in nice and neat little columns, additional sizing requirements needed to be considered. I wanted 6 columns of gum balls evenly spaced along the screen. Moreover, on phones, not all screen-size ratios are the same; the most popular ratios being 16:9 and 16:10. Building for a 16:9 screen would ensure that my game worked on a 16:10 as well, but, I'd have extra unused space on either side of my screen.

I turned to some dynamic screen size checking and Unity's Math.Lerp function to create my final solution. Lerp interpolates between two points, a and b, by value t. t is clamped between 0 and 1. So, if t = 0.5, Lerp will return the point directly between a and b. Using this, it's trivial to determine the locations of the 6 columns.

The only thing left is to scale the gum balls to appropriately fit/fill the columns. Scaling the gum balls was a simple math problem of knowing that the screen was of width X and desiring 6 columns. Each gum ball would be X/6 in size (well, a wee bit smaller since I wanted a bit of space between the gum balls).

With the above implemented, I now have a dynamically scaled game board that grows/shrinks to appropriately fill the size of the player's phone.  

Reworking the Game State / GUI System:

 As noted for v0.2, I had plans on reusing my game state system from my previous game, Bouncing Bombs!.  In Unity3D terms, after initially loading, that game used a grand total of one Scene. i.e. All game logic, menu navigation, leaderboard server logic, everything, took place in a single location.

This worked well for Bouncing Bombs! because my desire was to recreate an 'old school' style arcade experience. While not actually playing the game, the player could watch a demo of the game running behind the menus.

I had originally thought that this is what I wanted for Gum Ball Fall. Upon further reflection of the type of game I'm creating and further reflection that I wanted to incorporate different game modes, I ultimately decided that using Unity3D Scenes in a more 'traditional' manor would probably be a better approach.

As such, my Game States are now dictated by individual Unity3d Scenes. That is, the Main Menu is a scene. When the player starts a game, a new Game Active scene is loaded. When the game is over, a Game Over scene is loaded. etc.

v0.3 represents my first iteration of this new Game State / GUI implementation. While the transitions inside of scenes are still quite rough, transitions between scenes should be solid... hopefully ;-)