Getting Ready for the Beta Release

After the alpha release, the team agreed on some goals for the next two weeks.

• Camera pans down on stage complete
• Sink -> source
• Spawn new level
• Main Menu
• Level select
• Level obstacles
• Wall piece (non-movable)
• Spinning thing of some sort
• Fan (blows balls a certain direction)
• Paint (changes ball color)
• BUG: ball timeout (if it gets stuck)
• (Maybe if time)
• Update conveyor art and animation
• Ball impact animation

As were now just a couple days away from the beta release we have completed almost all of the above features.

Main Menu

The main menu is done and looks pretty good. It encapsulates a lot of what we want the game to be. For example, the vision for the game was a chaotic yet therapeutically flowing stream of movement; and I think the scene really captures that. In addition, after you click 'Play', the camera pans down to reveal the next section - just as the gameplay will have a similar mechanic.

The second part of the menu features more options. As you proceed through the menu options the camera continues to pan down to show off the continued flow of balls and more information.

The button text may appear to be fuzzy in these pictures but its actually because they are moving very slightly and as they move they are leaving a ghost trail just like the balls.

To finish off the main menu and to give it a little more life, we added a song that captures a little bit of the vibe we are trying to go with. It wasn't easy finding royalty free music... I think I listened to almost 200 songs personally.

Ghosting

A simple yet startling improvement was on the balls trails. By constantly shrinking the size of the balls trails as they fade away, you get more of a triangular motion trail. Funny how the smallest things can make the biggest difference.

The Spinner

Hopefully one of many level obstacles to come in the final days of development. Unlike the place-able gizmos, the spinner and other obstacles will be statically positioned in the scene creating difficulty in completing the path of the balls. The mechanics of the spinner are pretty simple... rigidbody physics but with a frozen x and y axis, and zero gravity scale. The result is an object that is free to spin around the z-axis. As balls ricochet off it, some pass nicely through while others might hit it funny and bounce unpredictably.

The Crucial Fix

As many of you already know, one of the persistent bugs that has been plaguing our development was the conveyor belts inconsistent interaction with the ball. Depending on the angle of the conveyor, spin of the ball, how many balls were on screen, and a couple other variables, the conveyor would behave annoyingly. Sometimes balls would move the opposite direction, spin the opposite way as intuitive, create so much back spin that the ball would explosively leave the scene.

We tweaked the ball physics, friction, bounciness, mass, angular drag, and we tweaked the conveyor's surface effector physics. Each fix iteration, we would get it to work in some case (flat conveyor belt) but it would break another (angled conveyor). Sometimes it would work fine for hours then some situation would arise that would break it again and we would start tweaking again.

The solution was just to ditch Unity's built in surface effector 2D. While it was very easy to set up and seemed like a great idea, it ultimately proved impossible to use. We created a new conveyor belt that looks and behaves identically to the old one, but has new scripts under the hood. After hours of testing all the possible breaking situations, the new conveyor belt seems to pass 100%.

Oh and the edge of the conveyor belt is now animated giving the user a little more indication of the direction of flow. Cool right?

Going Into Our Alpha build

Development has been slower with midterms but the team has still managed to get in some new features and bug fixes. We defined a few goals for our alpha release due Thursday...

• Fully working sidebar UI with drag and drop capabilities
• New iteration on the drop ball UI and mechanic
• Wall/Slow-roll Gizmo
• Win mechanics

Sidebar

The sidebar now features fully functional drag and drop behavior. Players can drag gizmos from the bar and instantiate them into the scene. Each time a player creates a new instance, the item count in the sidebar decrements. Players can drag them back to the bar to delete them. This is dynamic so we can simply drag Gizmo prefabs to the sidebar for different levels and it will automatically space and present the gizmos accordingly.

Dropball

Instead of a constant stream of balls periodically dropping from the sources, now you click the "Drop Ball" button to a release a single ball from a finite pool of balls. This means you only have a finite amount of tries to get the balls to the sinks before you fail the level. Since only a single ball is released at a time, you can use this to test your current layout to see if it functions properly and slowly iterate on your design.

Slow-Roll / WALL

The wall gizmo is the next in our series of planned game objects. It simply allows you to ricochet a ball off a surface or even slow it down with friction. This can be used to help funnel balls into the correct bins and skillfully adjust to the chaotic variance that is added by the conveyor belts and random paths of the balls.

Win Mechanics

Big change this week is the win mechanics. A large and challenging part of this task was ball tracking: Tally the balls at the start, monitor their movement and position through the level, destroy them if they leave, and score them if they make it to the correct place. This all had to be done with many balls in a computationally friendly way.

Ball Tracking

 A score keeper object tracks the total balls, reserve balls (balls not yet released), active balls (released and moving through the scene), dead balls (have left the scene), and scored balls (have made it to the correctly colored sink). We want to make every game object as dynamic as possible so that they can be used seamlessly in future levels we design. Meaning win conditions should work no matter how many balls we start with, how many sinks we have and regardless of their color (we don't want to manually adjust how many balls you need to win).
So to do this, sources self report the number of balls they bring to a scene at the start of the level (total balls). The ball self monitors if it leaves the scene or if it makes it to the sink (dead and scored balls), and the scorekeeper monitors all of these variables and defines when the game ends and whether or not the player has completed the level successfully. Active ball count is also used to determine editing mode so that the player can not edit the gizmo objects while the balls are in an "active state."