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!
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