Dev Log: Playable Levels

Now that the gameplay tuned and bug fixed, I can go ham on level creation. With my years of level design experience, I managed to knock out 9 simple, yet fun levels in no time flat. I even made a few pieces of set dressing to deliver the vibes.

Level Layouts:

Level 1-1: Simple entry point to controls

Level 1-2: Slight obstacle, needing to deal with verticality

Level 1-3: Increasing control challenge. First likely moment of wall sticking.

Level 1-4: Development of verticality and wall sticking 

Level 1-5 - Little sticking playground with a bit of a challenge. Tests directional and launch power skills.

Level 1-6: Introduction of the Spinner obstacle!

Level 1-7: Development of the spinner, and tests control skills in a fun, twisty way. First left-hand side goal flag.

1-8: Tougher, larger challenge level dealing with verticality, spinners, and testing control skills.

1-9: Simple ending with a little twist. Tests control skills in a narrow environment.

I sent the APK to a few friends to play, and they all can't seem to get enough! Stay tuned for more Sticky Golf!

Dev Log: Gameplay Improvement Week

Last week was a busy week, focusing on gameplay improvements! A bunch of physics bugs were destroyed, and the gameplay and input overall feels way more responsive and clean.

Problems to Solve:

1. Input isn't set up to be platform agnostic
2. Input and ball jumps not able to be customized for input swipe lengths.
3. The ball floats in place when sticking to a moving object.
4. Bunch of weird physics bugs

The Solutions!

1. Make input Platform agnostic

I want to eventually put this game on mobile, Steam, and Switch, so focusing on a single aspect ratio won't do. The input was initially set-up on a single 16:9 landscape. That doesn't factor in different phone or tablet aspect ratios. What is a developer to do?

Well, I was most of the way there. I updated the Gameplay manager to take in the screensize values and divide my touch start and end positions by that. Boom, bam! Problem solved.

Now no matter the screen size or shape, players will have similar input results and swipe sizes.

2. Adjust Swipe input and ball trajectory calculations to be tunable

This one was fun. I wanted to be able to adjust the length a player needed to swipe to get a pre-set minimum and maximum power for ball launches. It took a bit of mathing, but managed something that works!

What I'm doing is:

• Clamping the initial input from 0,1 to prevent any values over 1 from being calculated (eg. a swipe greater than the screen height)
• Setting the clamped number to a maxLaunchInput variable if it is higher. This allows me to only require a tunable swipe length to reach max power.
• InverseLerping the new clamped number between 0 and the max input. Gives me a position between 0 and the max input to adjust the launch power between min and max.
• Lerping THAT between min and max launch power.

I can adjust my variables for the input min/max, and the launch power min/max however I like, and its giving me the desired result. Something to clean up later, but it works!

3. Make sure the ball doesn't float when sticking to moving objects.

When I stick the ball to a surface, I'm freezing its position and velocities until acted on again. This causes the ball to float when it licks against moving objects like my new rotator gizmo.

I love the solution for this, because it's simple, dumb, and effective. I still freeze the physics/positions, but I also re-parent the ball to the moving object it collides with. Whatever animation is playing on the moving object, the ball will follow.

I just needed to make sure the Animate Physics flag was set on the animator, otherwise spooky stuff happened.


4. Stabilize physics on the ball

I occasionally encountered really weird physics bugs, like the object getting stuck in corners, clipping into geometry, and sometimes rolling away through the air. Sometimes this caused player input to lock and you'd have to restart. Booooo!

I investigated for a while, and found a very elegant solution that solved a ton of my physics problems.

On collision with an object, I added freeze position and rotation logic. On jump, I unfreeze. This little velocity freeze function has made gameplay so much smoother and predictable. 

The result of all the hard work is a much smoother, more enjoyable to play experience!

Next up for gameplay improvements is to adjust my launch angle detection to ensure that players can't launch the ball horizontally and make it roll instead of jump.

Stay tuned!

Dev Log: Level and UI Management

Now that the basic UI is set up, I've started working on level management. I had a tough choice to make with how I'm managing levels, but I think my decision is the optimal one.

DILEMMA: How do I set up my level management to be scalable long term?

• Option 1: Make each game level as an individual Scene.
• Pros: 
• Simple and clean to load
• Easy to tune individual level layouts
• Cons:
• End up with MANY Scene files.
• Have to add the Scene files to the Build Settings or face a build break (scary!!!)
• Have to set up necessary prefabs and components for each Scene, like managers, ui, etc.
• Could be mitigated with a primary prefab that contains all of that anyway. Just seems like a hassle.
• Option 2: Set each level as a Prefab instance, and manage everything in a single Scene.
• Pros:
• Less build/Scene management
• Easier level loading/testing
• Easier course/level data setup and management
• Cons:
• A little trickier to debug/edit each level (need to do it in the prefab, or push overrides)
• I can mitigate this with some debug tools
• Possibility for some manager wonkiness between level loads.

I'm going with Option 2! When I go to make a new level, I want as little in my way as possible to set it up and get playing. I also don't like the idea of having a million scenes in my project.

Now how am I to structure my level management? I hit up my old whiteboarding friend Miro to work things out.

Getting the scriptable objects set up for Course and Levels took 10 minutes, maybe. Making a new Level Manager and UI Manager to run the level loading and UI updates properly took a lot longer.

I needed to do a bunch of updates to the Player Manager, and add necessary signal dispatches to make sure Levels and the Player Ball were spawning correctly based on the data. Then I ran through and made sure the UI was updating correctly. I also moved a bunch of small UI scripts into my main UI Manager for ease of use.

It's now all working, and currently bug free! See the video below for progress!

Next up on my list are the following:

• Detail out level design metrics and tune gameplay
• Create level building blocks (with updated visuals)
• Build a suite of levels to test out!

Stay tuned for more!