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


No comments:

Post a Comment