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

Complete Prototype

This week we completed our prototype! Our first 'playable' level is complete. The level consists of two sources of different colored balls that must cross paths to get to their respective sinks. The conveyor belt object is pretty much complete but might need some fine tuning to get the physics of the collisions just right.

Big changes this week

• Physics
• Tweaking the balls friction, angular inertia, bounciness, and mass. This took a considerable amount of time to get it to feel natural and look like a real physics system.
• Conveyor belt surface effecter was tweaked so that it would perform correctly with the new physics of the balls. We ran into an annoying issue where the force on the ball would cause a so much rotational back spin that ball would move in the opposite direction. Right now everything is working satisfyingly except that ball still rotates the incorrect direction when on the conveyor.
• Balls
• The new artwork with the X means that you can now tell more clearly when the ball is spinning. This makes the motion of the ball a little bit more satisfying.
• Ghosting: The balls now leave a fading trail behind them as they progress.
• Conveyor Gizmo
• A directional arrow to switch the conveyor's force direction
• Can now be added to the seen from the UI bar
• Gameplay
• A play button that will drop balls. In the future I think we are going to go with a 'Drop Ball' button that will drop a single ball rather than just start a continuous flow.
• Restart button that replays the scene. This is mainly for our testing sanity but this will also restart the level for the player.
• Two game cycles: BUILD and PLAY
• During the build cycle you can add, rotate, and re-position gizmos. During the play cycle, balls will fall and editing the scene is disabled.
• UI
• Drag and drop Gizmo prefabs and place them in the scene. This is a bit tricky... still working on it.

Planned changes for next week

• Second Gizmo: the wall
• Ball effects: impact collision effect
• UI: Fully working UI toolbar with drag and drop abilities
• Icons for the already present Gizmos
• 
  

Week 2

What we've been working on

This week the Flow team has been working on integrating the UI bar, finishing off our first Gizmo, tweaking physics between game objects, and fine tuning the mouse interaction.

The conveyor belt

The conveyor belt Gizmo is now fully skinned and animated. Art was originally created for several different frames of the conveyor belt to show the spinning movement of the belt. However, we quickly realized that a simple script could alleviate a lot of the art work needed while also making the animation much smoother. So rather than having different images each frame, the conveyor belt is static but has moving parts that are transformed in unity with a rotation script. This makes the belt look much more fluid and saves some time on Art

Physics enhancements

We noticed that despite unity having most of the physics already built in, our system needed some tweaking. For example, our balls were using circle colliders and rigidbodies which gives them most of the effects needed. However, we noticed that balls would sometimes stack one on top of another in a big perfect pile. Such a thing would normally be fairly unlikely in the real world given perfectly round balls. We solved this by removing the frictional forces on the balls and adding bouncing and elastic collision effect. This small force exerted on other balls plus the lack of friction gives the balls a much more realistic effect when colliding with other objects in the scene. The bouncing is also satisfying and will be nice for future use when we implement obstacles like walls.

Mouse Interaction

You can now click to rotate and re-position objects in the scene. We encountered a small problem that allows us to position Gizmos on-top of other Gizmos despite the objects having colliders. Hopefully we can get this issue solved relatively quickly and get back to the development schedule.

UI toolbar

The goal is to have a small vertical bar on the right hand side that has icon representations of Gizmos that can be placed in the scene. As with such a task, screen ratio, and dynamic sizing are a bit of pain to get working on all screen formats.

Next week plans

• Wiring the UI toolbar to the mouse interaction
• Start work on next gizmo
• Level design of the first few levels
• Ball effects (trails and collisions)

End of Week 1

This week we laid out the foundation of the game including its most basic pieces. Ball prefabs, spawning, de-spawning, scoring and ball tracking, colliders, and basic physics interactions.We also completed the scripting for our first “game object” or “gizmo” (objects that manipulate the path of the ball).The first gizmo is the conveyor belt that will put a force on the ball once it collides with it. Next week we will be adding the art for this gizmo and finish off the placement mechanics. So far we have no mechanism for placing the gizmos in the scene but we do have basic scripting for rotating and re-positioning them in the scene.We finished off the week by re-skinning the game in its first art assets. Overall, a huge improvement from the game we had at the beginning of the week.

 Before:

After: