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 ;-)

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:

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.

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

Monday, July 8, 2013

Every Adventure Needs A Beginning...

Aaaaaaand, the FussenKuh Software blog is officially live!

Looking back on things, I wish I would have created this blog months ago when I first decided to pursue creating video games in my spare time. Rather than a collection of scrawling on random pieces of paper now lost to time, I could have kept a running development log of my first game Bouncing Bombs!

Oh well, I suppose that'll be Lesson Learned #1: Document my creations. If I'm taking the time to create something, I ought to make sure that I'm keeping track of my progress in a more meaningful/useful way.

At any rate, for whomever (or is it whoever? I never remember...) is reading this, welcome to the FussenKuh Software Blog!  I'm not entirely sure what will come of this blog, but, a guy's got to start somewhere.