Day 1 - Game Plan

Share this post:

What am I even making?

Last time I talked mainly about my approach to the process. But what is it that I’m even working towards currently? I have an idea for the world that this game is going to take place in but I’ll keep to the gameplay mechanics for now.

The main idea for the gameplay is a mishmash of different gimmicks that have stuck with me over the years, including but not limited to:

Platform wheel from Yoshi’s Island that moves along a path using velocity that the player applies to it + fangame style platforms
Celeste dashing (but only downwards)
Infinite climber type generation (but with an altitude goal)

Why did these gimmicks combine in my head? I don’t really know, but they did, and now I’m excited about trying it out. I’ve got a few theories for how this could work out.

The player can jump through and snap to the wheel’s platforms. This can be used to generate speed fast by standing on the edges of the wheel and jumping up through the platforms.
The player can jump off a platform and use its’ momentum to stay in the air for longer. This can be used when the platform enters a treacherous section but has enough speed to make it through on its own.
The wheel gimmick combines well with other gimmicks such as:
- Gravity flipping (all four directions)
- Vi’s butterfly gimmick
- Lava moving from side to side engulfing the wheel in short intervals
- Etc. etc. etc.

With all these ideas on top of the fairly complicated mountain-scaling-device that is the wheel itself it’s beginning to sound like a hard-to-learn AND hard-to-master type of deal. If that turns out to be the case then it’ll still hold up to fangame difficulty curve standards (maybe lol). But if I can make this feel really good and introduce some of these ideas in a smooth way, then maybe it can stand on its own to some degree. The near future will tell.

How about today’s progress?

I started today by setting up the hack n’ plan’s programming tasks since those will be the ones I’m going to tackle first. I set up which tasks would have high priority, estimated how long each would take, and started programming.

Today I managed to hook off 4 things on the list, which was… underwhelming.

The problem was the platform snapping behavior.

I wanted the player to snap only when the player’s feet where under the platform in the previous frame, and over it in the current. Sounds simple enough, especially since there’s not too many different combinations of nodes you can do to solve this problem.

- KinematicBody2D (RigidBody2D and StaticBody2D seemed unfit in this case)
- Area2D
- RayCast2D

At first I thought the platforms had to be of type Area2D because KinematicBody2D nodes seemed not wanna overlap with each other, ever. But there is no signal in KinematicBody2D that lets you know when it is overlapping an Area2D, and connecting to all platforms’ body overlap signal on ready seemed counterintuitive.

For a short period of time thereafter I wondered if I should make the player use an Area2D instead. That would mean that I would have to handle all collisions manually, but at least I’d have my precious overlap signals right in my player class! It sounded possible but it would take more time than I was willing to sacrifice then. Besides, there should be a better solution to this, right?

I got an idea for a hybrid solution of sorts. The player’s main body would be a KinematicBody2D, and it would have a Area2D or RayCast2D to detect platforms with. When I detect platforms using my new platform detector I can start using the KinematicBody2D’s move functions in a platform-logic-y way.

That’s when I got stuck for real. I couldn’t find a way to do this in a way that satisfied me. No matter how I thought about it, the thought of there being a better way was still irking me. Then I remembered how the Godot 2D Platformer example project had moving platforms that the player could jump through. How the hell did they do it?

Turns out there was a crucial detail I had overlooked. CollisionShape2D (yeah, not KinematicBody2D) has a one-way-collision boolean. Finally, the puzzle pieces all stuck together: When on top of the platform the player is automatically moved along with the platform (because it is a moving KinematicBody2D as well). When moving through the platform, some distance checks done by two RayCast2D’s at the feet of the player will trigger a snap. ON GOD. And that would’ve been the end of the story if I hadn’t decided to also implement a state machine for the player to clean up all this code.

And that's my progress today; from a fresh project to this.