godot-platformer-2d/GAME_CONCEPT.org

Game Concept

• Gameplay
  • Core mechanic: pulling yourself with the Hook
    • Possible other uses
    • Controls
      • Mouse and keyboard
      • Gamepad
      • Snapping
• Course
  • Teaching goals
    • Game design
    • Game creation
    • Metroidvania essentials
• Prototypes
  • Base movement with the hook
    • Questions
    • Answers from the prototype
  • Experiment with control schemes for the gamepad
    • Inspired by Ori's bash
    • Using twin sticks again
    • Questions
    • Answers from the prototype
  • Unlocking behaviors and code structure
    • Questions
  • Test RigidBody2D instead of KinematicBody2D for the hook-based movement
    • Questions
  • Improving movement
  • Design level loops
  • Predicting player motion
    • Questions

The concept is still a living document so that we have a base for design discussions. At this stage, we can still change the core mechanic, if you have something that's as versatile and that can fit the teaching goals for the project. See the first note below

Gameplay

Core mechanic: pulling yourself with the Hook

You use a hook to propel yourself instantly towards hookable targets and navigate the world fluidly, often without touching the ground.

The character's jump isn't powerful enough for you to reach most platforms. You mostly use it to hop over small gaps and obstacles, or to reach a hooking target that's slightly too far otherwise.

Possible other uses

• Pull objects and enemies towards you. E.g. pull rocks blocking the way, make an enemy off balance…
• Hold a button after throwing the hook to propel the character like a cannon ball and jump past the hooking point. Use it to go farther than usual or e.g. to break weak surfaces
• A blade so you can plant the hook in e.g. wooden surfaces, but not rock. Be it to pull yourself towards new places, or to pull objects with the hook.
• Use the hook as a propeller to glide over short distances

• Combat

  • Pull shields or armor plates off enemies
  • Hit enemies from mid-range, using the hook as a whip with the blade
  • Charge onto enemies with the cannonball attack
  • Lunge down on enemies and stun them if falling from above
• Note taken on [2019-04-30 mar. 17:49] \\

Hook would not only fit the need for giving the player a versatile tool: it would allow us to play with physics, vector math, and visually debugging the game. It also allows us to have related upgrades. I'm open to any other mechanic or tool with the same potential, e.g. the spear from one of Shaun Spaulding's jams.

• Note taken on [2019-05-01 mer. 07:29]
  The ideas above are for reference, to give us paths to build upon the core mechanic and show its potential.

Controls

Mouse and keyboard

Use the mouse to aim and to use the hook, the keyboard to move the character. Aim the hook with the mouse and <L-Mouse> to throw.

Gamepad

The hook aims in the direction the player is moving, throw with the right bumper.

• Note taken on [2019-05-01 mer. 07:39]
  I've tested different control schemes:

  • Using the right joystick to aim the hook. It's too hard to use other buttons along with both joysticks.
  • Using a key to toggle aiming the hook. Breaks the flow of the action.
  • Using the 4 ABXY keys to throw the hook in the corresponding direction. It works, but it limits the buttons left for other purposes, e.g. jump is typically on A on an XBOX controller.

  Aiming where the player moves feels most natural so far.

Snapping

Regardless of the control scheme, use a snapping system to help direct the player towards hooking points. Even on rails or long hookable surfaces, we might want to have a limited number of points, e.g. in the middle and on the sides, to help the player better hook using a gamepad.

Course

Teaching goals

Game design

• Using one mechanic for many purposes: giving the player a versatile tool.

Game creation

• Game creation workflow: the process and broad steps to follow to get a game project started, prototyping, and getting the character controller, camera, etc. to feel right.
• Making multiple behaviors interact together: especially for the character controller, getting the different moves (e.g. jump, wall jump, slide) to flawlessly flow into one another.

Metroidvania essentials

• Platforming character controller and related code structure: behaviors, aggregation-based approach.
• Level design, creation workflow, and connecting frames. Guiding the player through the environment, looping, and branching paths.
• Unlocking mechanics through upgrades and controlling player progression.
• Camera: helping the player with a camera that moves ahead of the character and looks where the player wants to look.

Prototypes

DONE Base movement with the hook

CLOSED: [2019-05-03 ven. 10:18]

Explore controls and game feel, allowing the player to move fluidly through template levels.

Movement prototype: raycast-based hook mechanic with snapping

Questions

1. How can we make the hook at the core of the platforming experience?
2. Which control scheme would work with kbd and mouse? With the gamepad?
3. How can we make the player feel both free in its movement while making the controls intuitive? Especially with the imprecise gamepad.

Answers from the prototype

1. The jump should be weak compared to the hook.
2. See Controls
3. I had to add a snapping system. Currently, it uses 2 Capsule shapes and a Raycast2D to detect snapping targets in the direction the player is looking (mouse) or moving (gamepad). It snaps to the closest target in that direction, meaning we should always space them. Also, upon hooking onto a point target, the target deactivates for a short amount of time, allowing you to hook onto the next target forward more reliably.

DONE Experiment with control schemes for the gamepad

CLOSED: [2019-05-03 ven. 13:19]

Checkout to the gamepad_alternate_controls branch to test the controls.

Henrique and another community member mentioned that only hooking in the direction the player is moving could take control away from the player. Although I did try alternate control schemes when creating the first prototype,

Inspired by Ori's bash

Use a key to stop or drastically slow down time and let the player aim with left stick. Instant hook upon hook input, or releasing the slow down time key?

Using twin sticks again

I didn't like the feel of the twin stick controls as you can't use the ABXY keys at the same time, unless you take your thumb off the right joystick. This leaves you only with the bumpers and triggers as extra controls, and prevents you from using A to jump.

However, if we use the ABXY keys only outside of the action, e.g. to grab an item in a safe environment, to open a door, or to start a dialogue, this would be fine. As the hook should have many purposes, we shouldn't need too many keys to use it.

Questions

Can alternate input schemes retain the fluidity of the motion while giving the player more control?

Answers from the prototype

Both approaches work. The slow down effect would need to be limited to retain some challenge in the motion, but using a single joystick to move in any direction is comfortable to me. We could limit it in a few ways:

• Making it a resource that depletes and refills gradually, or by touching some object in the environment. E.g. flowers that emit essence of time. This would force the player to still be fast and use the mechanic sparingly.
• Only allow the player to use it mid-air, once or twice only until the player touches the ground again. This would give you precise hook charges.

The twin stick setup also works. To me, it feels more technical, and less accessible. But it works.

TODO Unlocking behaviors and code structure

Figure out a good pattern/code structure to unlock and manage new moves on the playable character: e.g. wall-jump, new powers for the hook…

Questions

1. Most moves rely on the hook and will revolve around the same base input, to make the core control as versatile as possible. How can we make it modular, allow ourselves to hook new mechanics onto it?
2. Can we find a pattern and code style that's both modular, i.e. uses aggregation, and that stays accessible to the students?
3. Which code pattern would work best for Godot?

TODO Test RigidBody2D instead of KinematicBody2D for the hook-based movement

We have two options to handle the character's motion: controlling the physics ourselves with KinematicBody2D, or relying on the Bullet physics engine with RigidBody2D.

I expect that using Bullet will reduce our control on the character's motion, and that would lead to a different game feel and gameplay down the line: we could have the character hit objects, etc.

It's worth trying only to see if we can't make a game that feels as good or to avoid some code-related challenges.

You can use the existing hook mechanism almost as-is for this test, as it gives you a direction to hook to. The only element that has to change is the character.

Questions

• What are the advantages of RigidBody2D in practice?
• What are its drawbacks and limitations?
• Is the code easier to write?

TODO Improving movement

The base movement is in place, but it does have some quirks. It's still easy to bump into a corner and to miss landing on a platform.

Some issues:

1. Hooking doesn't reliably pull you to the hooking point

   • Hooking to a node from up close barely pulls the character, making it not reach the hooking point.
   • Hooking downwards accelerates your fall and often makes you miss your target.
   • Hooking horizontally while falling doesn't slow down your descent, so it has almost no effect on your motion.

2. The air state has a higher horizontal speed limit than when walking on the ground, so the character accelerates horizontally upon jumping.

   • The speed cap should be dynamic, depending on whether the player used the hook or not.
   • It's the hook that should provide a maximum speed boost?

3. If the player misses getting on a platform by a small shot, we could have the character climb on it using the ledge.

   • The intention behind the design being to offer a fluid experience with motion, it's not fun to miss a platform by a few pixels, and the character being agile, it could make sense for it to climb ledges automatically.
   • The goal isn't to remove challenge or to babysit the player, but to have serious challenge in other parts of the level design/gameplay, and not break the flow of the motion for a small imprecision.
   • See Dead Cells for an example

TODO Design level loops

We have some core movement and controls in place. We now need to work on level design loops that we can combine to create complete rooms. E.g. having a ledge, a pit, and a distant platform down the character that's only accessible using the hook: the loop involves falling and using the hook mid-air going down.

These loops should push the possibilities offered by the hook and explore ways to combine them. It's also an opportunity to figure out its limitations and ways to improve the movement.

You can add new mechanics or obstacles as part of this, like moving platforms, but be sure to focus on level design and to try to reuse each element as much as possible.

Use a new node branch for each chunk, and separate collision bodies so we can save the best ones as reusable scenes.

TODO Predicting player motion

It's hard to track how a hook will pull the character. It'd be nice to have tools to visually debug the characters projected arcs of motion, to get a sense for what the hook will do.

As the player can control their horizontal motion mid-air, they can deviate from the curve, but still, as it's the core gameplay, we should have some tools to track and fine tune player motion.

Questions

1. Which motions can we predict accurately?

2. Can we use this information to improve the movement?

   1. At least we can use it to better illustrate how the motion works in videos/tutorials