Eight days of development

Motivation

I whipped this up as practice for participating in Game Jams. My above-all plan was "keep things simple".

Initial Proof of Concept

Among other things, "keeping it simple" warranted:

• use of off-the-shelf free assets (thank you, Unity Asset Store)
• minimally-complicated Colliders

The "minimal complexity" required a small rethink when pins were to go down. The Box Collider often resulted in pins being stuck in mid-fall against the walls of the bowling lane. A Mesh Collider, based on a convex variant on the pin shape, solved that impasse.

Other concerns relating to dynamics cropped up:

• The pins were prone to falling through the floor. Increasing the mass of the floor, curiously, kept the pins in place.
• Initially, when the ball hit the pins, all bodies tended to move in slow motion. This turned out to be an issue with the size of the objects. The ball, for example, was 3 meters wide while its real-world counterpart is only about 20 cm wide. Reducing the pin and ball sizes to 6.7% of original got the physics right.

Scoring

The scoring system of the United States Bowling Congress involves bonuses to prior frames ending a spare or strike. As this requires keeping track of prior frames, I dropped this in favor of the World Bowling system: 30 points for a strike, ten for a spare, and the total number of pins downed for a frame left open.

Central to scoring, in any event, is determining how many pins went down ("pinfall") on any given roll, and when to start counting. The latter warranted a backstop with a Collider, the collision event telling the application's control center the roll is over. Upon that happening, at hand is to find all pins whose vertical inclination is less than seven degrees - pins left standing - and subtract accordingly.

Finding a pin's inclination involved getting the angle between the identity Quaternion and the Quaternion representing the pin's world-space rotation. 

Mobile Control

[In the interest of publishing as soon as possible on itch.io, I adapted the mouse activity to present an equivalent desktop experience.]

The goal here was a control scheme for which the player presses, then drags to aim the ball, then releases the touch to launch it.

Adapting the game to Android revealed that on said platform, given two objects of the same name, one a parent of the other, the bottom-most of those with the same name gets returned by GameObject.Find(name). Depending on the Components therein, a crash could occur due to a null reference.

Getting TouchPhase.Ended to register in the new (and preferred) InputSystem required redefining the Fire action as bearing a Value rather than a Button, and a Touch Value at that.

From there came corrections to pin placement . The too-easily-attained strikes resulted from the pins being in an isosceles triangle instead of a proper equilateral triangle.

The HUD

The principle of keeping things simple warranted presenting only the current frame’s results and the cumulative score to that point. I found where I’d used the wrong variable as an array index while tallying up the per-frame scores.

Graphics concerns

By default, an Android project presents low-resolution shadows. Solving this required switching to Hard Shadows on the Directional Light, and changing the “Quality” settings. Giving the lane a proper texture warranted another trip to the Assets Store.

Next Steps

So far, I imagine adding options:

• Quick game (five frames) vs. Full game (ten frames)
• World Bowling scoring vs. USBC scoring (partly implemented)