Snaccoon Devlog 01

This month was a lot of project organization, design docs, logistics planning, and other fancy words for the non-programming/non-art stuff that comes along with gamedev. That being said, I did find some time for some locomotion refactoring.

Guided Platforming

Most platformers allow/require the player to traverse gaps/elevations by providing jump height, speed, and air-control values. These values are finely tuned to coincide with platforming level layouts to provide a desired pace, difficulty, and cadence. A consequence of this design paradigm is that, due to the need for adequate space on and between walkable surfaces, a certain amount of “airtime control headroom” must be provided by level design, which can take away from the realism, creativity, and artistic freedom of a space’s design. This isn’t inherently a bad thing, but it does run contrary to the desired physicality I’d like for Snaccoon.

Ideally, the city environment that the player will navigate will be close in scope/detail to a real-life city, in terms of density, layout, spatial rules etc. Real-world spaces have walkable surfaces & gaps that are very inconsistent with traditional platformers. (Unless their scales & placements are artistically stretched and skewed.) The Assassin’s Creed series gets around this by building an entire “controlled parkour” system, where the player can simply hold down a button and move along their desired path, and the character will automatically conform to their obstacles, performing vaults, jumps of widely varying lengths, landings grasping ledges, etc. This works well for solving the platforming constraints in realistic spaces discussed above, and the difficulty is instead pivoted towards player pathfinding & memorizing spaces, as well as stuff like combat and stealth.

In a similar vein, I wanted to first take an approach that blends somewhat precise platforming controls with the guided system in the AC series, where the player must move in their desired direction, but vertical pathing must be done by timed presses, and those timed presses will trigger an environmental query to determine which surface/object Snaccoon should jump to next, based on the space from their current position to a safe landing position, the object’s alignment with Snaccoon’s current travel path/the player’s movement input direction, Snaccoon’s speed, etc. At first I thought that if no land-able space is found, a standard forward jump would be applied, and the safe landing/grasping of a climbable surface/fall from the platform spot will all depend on the player’s reaction. However I quickly determined that this simply doesn't cut it, and the moments where the auto-pathing fails to find a spot completely sucks you out of the movement flow. Ideally the locomotion system would be extremely effective at finding where Snaccoon should go next, and the procedural building tools that will need to be developed to flesh out the city environments will also take into account the way that this system functions, but it's clear that the way in which I'm calculating jump-paths is not going to cut it in the long haul.

My first attempt (what I spent some time on during the initial prototyping days in 2020 and what I tried to refine this month) revolved around firing specific traces in front of and around Snaccoon to try and find places to jump to, which has an advantage of being highly dynamic, but also pretty difficult to keep consistent with what the player is trying to do.

Here we can see a trace firing out from Snaccoon and hitting an obstacle. A secondary multi-line trace tries to find the height of the object, and if it falls within a certain jump-height threshold, a landing spot is identified, as evidenced by the white cube appearing near the edge of the platforms.

Next up, I needed to determine the actual arc and movement of the jump path. To do this I constructed a spline with start and end points at Snaccoon's location and the landing location, if applicable, and tweaked the point tangents based on the angle of the jump, its distance, Snaccoon's speed, etc. It returned some promising results, and I was able to modulate launch velocities based on spline length & jump height/distance to have Snaccon jump and land fairly predictably.

The main problem that presents itself with this approach is that finding a jump path relies very heavily on the direction Snaccoon is facing, and so the indicator jumps around quite a bit.

Coupling this issue with my desire for very tightly-packed, physically believable spaces, I need a way to have the landing indicator present itself before the player can actually jump to it, and then "light up" when they're in range, all while staying relatively steady in-place so as to be as readable as possible. My next plan is to explore the use of "nodes" at landing positions on objects, either through mesh sockets or some other instrument, and have pathing checks running to determine which of the available nearby nodes is best suited for navigation, again based on the player's speed, rotation, etc.

Outside of platforming exploration, I set up some cool source-control stuff that auto-updates a water-mark in my development build with the latest revision I have pulled from Perforce. This is pretty niche/nerdy, but if any tech-centric people are interested, I posted a brief breakdown with some Python code in this tweet thread.

That's all for now, as I said this month was a lot of management/organizational stuff. Hoping to have some solid updates on the core platforming in June, so I can start expanding to other systems.

Cheers!