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.

No comments:

Post a Comment