Add some code to override the character's movement and move it quickly around the world
It should properly reset when you enter and leave the debug fly state

When using the hook mechanic at the moment the player detects a ledge, the skin animation fails to finish leaving the collision shape in an offset relative to the skin position

See the prototype description in the game concept.

This is design work. The idea is to test the current motion, see where it fails and to find ways to improve it. I.e. right now hooking going down doesn't work. Could you do some level design experiments? Create small chunks, think about a few obstacles to start fleshing out the game's feel?

I'm not hoping for a polished result at this point, but rather atomic loops we can combine together to build interesting rooms (or maybe do procedural generation?! 😉)

Now the tile set editor is better, I also want us to use the tile map system as it's much faster to edit levels that way than to create Collision shapes by hand.

Maybe it would be nice to add some sort of reach area preview for the HookTargert in the editor showing where player can reach it from? It could make level design easier in some cases

Think of this little AI agent as Mario's goombas: it's a basic enemy that's not going to attack the player directly, but that damages the player if it touches it from the sides, and dies if the player jumps on it.

We need a guide so people know when and what they can contribute. During the prototyping phase, feedback and testing would be useful and welcome. Any serious work would be welcome at any stage, anything that helps the project move forward: implementing different mechanics, level design, etc.

I'd just like all the work to be ticketed and the scope to be well-defined so we don't go overboard with features. Right now it's just a little too early. We need to have a clearer direction and target for the demo.

From @henriiquecampos:

I think a brief explanation on this take to clarify when this will happen would be nice. The major questions I have in mind are:

Will the course and the demo be done in parallel or the demo first and then the course?
In which case, when/where will contributors/learners take place?
What kind of assignment/content can they expect to be accepted?

Add the ability to jump against walls, and have the character slowly slide down slowly while against the wall

Use two nodes named e.g. Start and End, and use them in PatrolAgent.gd

Right now the code only supports having the ai patrol horizontally, but if we have mostly flying enemies in the game, it would make sense to allow them to move in any direction. Using two nodes, it would be easy to edit their path of motion.

Implement a checkpoint system that we can use to have the player respawn in different parts of the game.

We'll have to see with the game demo if the checkpoints would be the starts of every frame the player enters, the last save point, the last touched checkpoint object, or something else.

The system should work with some kind of reference to the scene and position or node the players should respawn on.

The agent has a floor detector node under its pivot. Add another raycast2d to detect walls. You only need one raycast as when the AI changes direction, the pivot flips

If you're on the ground, just pull the object/make it fall
If in the air, the object could work like a hookable point

The pulled object can use rigidbody physics but shouldn't block the player once it's been pulled. The idea is to have obstacles that act as one-time hookable points so that the player has only one chance to reach a given platform, or has to pick a path mid air to reach one of several targets.

Design a panel and menu where you can quickly display the state of a property on screen, to monitor what's happening in the code.

We should explore RigidBody2D for the character's movement. @razcoreart tested it out for his prototype, salia, and the motion was nice to start with.

I prepared a project in the prototype folder where you have the hook ready to use: when you click and hook onto something, the hook emits a signal: the character receives it and gets the hook position. This way you can focus on the rigidbody2d itself.

@razcoreart, could you tell us what advantages and drawbacks you found so far?

Tasks

• Build and test RigidBody2D-based hook motion
• Add synthetic result notes to the prototype in the game concept doc

Prototype notes

From the correponding prototype in the game concept document.

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 and make them fall using physics, 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.

The goal is to see if we can build a good hook movement with rigidbody2d, as good as with KinematicBody2D. See the questions below.

Questions

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

Notes:

• Need to set up a tilemap to quickly draw the layout of levels and get collision shapes
• There's currently no code to move between frames or scenes

Depends on #32, checkpoint system

Implement a clean death that pauses the game, except for the character's death animation, possibly a transition animation, and respawn animation before giving the control back to the player.

Keep the “death” disconnected from health: we could have multiple death or level restart conditions like falling in a pit or losing all your health, the end of a timer...

The character is going to have a health component built upon the work of past projects.

Write a concept for the demo's gameplay and related points to teach.
Come up with one or more prototype(s) to create or next tasks to move forward with pre-production.

The hook already changed and is likely to change again, see #39. We need to work more on the core mechanics first and do some rapid level design prototyping. Also, the levels should really rely on TileMaps as much as possible as it's way faster than working with collision shapes

The drawing that represents the agent's patrol in the editor is way too long

Add support for anchors towards which the camera can softly lerp, to help guide the player to points of interest. E.g. a new ability to unlock.

Remove the old hard-coded panel that displays info from the player

It doesn't need to move or do anything, just take damage and queue_free

The current camera rig relies on the player's mouse cursor position, or on the joystick's orientation, weighted by the character's velocity (I think).

This works well enough, but I'd like to try a different approach for horizontal lookahead: have a double threshold system as in some platform games:

• There's a safe frame in which the camera focus doesn't move
• If the character moves forward, in the direction the camera is looking, the camera soon moves with it to give the player a good forward vision
• there's a second distance/threshold backwards so that you have to backtrack a little more for the camera to switch focus to the other side

Today, we're doing our first test jam. I've set up some issues, a Kanban board, and a list of priority issues here: https://github.com/GDquest/godot-metroidvania-2d/projects/1

Staying organized during jams

We've missed the mark this time, but moving forward:

1. Please assign yourselves to issues you're going to tackle before the jam starts so we don't step on each other's toes
2. PR your work when done or at the end of the jam's day, even if it's not done, so that we can check everyone's progress. Use the [WIP] tag for work-in-progress jobs
3. We're in different time zones, and many hours apart. Please make sure to ask questions on tasks before a jam starts to work as efficiently as possible. Because I won't be here to help during the day

Priorities

The end goal is to produce a good, well organized game demo.

For now, we're still doing pre-production work. So I want us to focus on the game feel before coding complete systems and figuring out the details of a system's code structure

For example: there's no combat now. Before doing a complex combat system and designing monsters, we should have some satisfying base move/mechanic. We should have base combat controls that feel good. No need for statuses, equipment, special abilities, spells, or anything else until the core move is in place.

Communication

I tried to describe each issue but I'm counting on each of you to ask the information you need to tackle them well and to ensure that we're on the same page. You can ask questions directly on GitHub and I'll answer every one of them. Please do so at least a day before the event starts as we live far apart.

You're welcome to open issues to discuss ideas as well. I'd just say don't go too far down a design rabbit hole: a design goal for this project is to make the core mechanic as versatile as possible, and to focus on few mechanics and systems, but to really refine them.

For instance, Razvan added a dash skill as an unlockable skill. That's typically the kind of design ideas I'm not interested in: the hook can do what a dash offers and more, better. If the hook failed to provide this ability, it would mean we should improve the hook rather than add a new control and a new move.

It was just an example to test code architecture in this case, no big deal. But before adding a new move or mechanic, please ask.

Code quality

Keep in mind our GDScript guidelines. Keep the code decoupled if possible. Most scenes we create should run without errors on their own in the editor (F6).

When you design a new node, I recommend that you write its responsibility at the top, in the docstring, to avoid shoving too much in it. OpenRPG became too complex as we did not do that. Some nodes started doing too much, and the code became hard to track.

What I mean by efficient

Efficiency means keeping our priorities in check. Putting quality first.

The meaning of quality will change depending on the task. If you're working on a game design-related task, it relates to:

1. Game feel first. Your work should help improve how the game plays and reinforce the core design. You always want to keep the core mechanic(s) and the main intention for how the game plays.
2. The code structure is secondary but still important. We should work towards self-contained nodes that try to respect the single responsibility principle.

The single responsibility principle is a computer programming principle that states that every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.
Wikipedia

You get a constant stream of input events when using a joystick.

Movement in general is bugged with the gamepad since the change in the code structure

See the prototype in the Game Concept

Could you start working on code structure? I'd like your advice on:

• 1. Structuring the player's motion vs the hook, keeping the two decoupled (i.e. critique on the first movement prototype's code)
• 2. Managing player movement and unlocking new moves/mechanics. I've seen you used separate behavior nodes in your prototype
• 3. Folder structure to build the game

All that with the viewers in mind: the Free series is for "beginners-plus":

The Free courses are for what I would call beginners-plus: amateurs, young programming students, or developers in another domain, e.g. software developers, who have learned the basics of Godot, the basics of GDScript, and put all that in practice in a personal project. The viewer understands basic programming concepts up to what classes and objects are, what a node is at a basic level, and the viewer knows its way around the main areas of the interface.

It's a bit barebones now, but if you feel like you can get started, go ahead.

As in OpenRPG, I've opted for a Skin node for the characters' skin, so we can replace the animated characters, so an animator or artist can work on animations without messing with the code/git history, and so we can mix-and-match animation techniques without other bits of code breaking.

This makes it so to start an animation from a state, we have to use player.skin.play(animation_name). So this makes the skin property a dependency for each state that accesses it. This is +/- fine as they're all part of the same scene. But I'd like your thoughts on using this kind of code vs adding public methods on Player.gd to encapsulate functionality. In the states, this would result in having

player.skin.play(animation_name)

vs

player.play(animation_name)

And adding an extra play method on Player:

func play(animation_name: String) -> void:
    skin.play(animation_name)

Which one should we teach or recommend? I'd use player.skin.play() as it makes it clear that you're giving work to the skin node. And I think that both approaches have downsides. I wouldn't want to clutter Player.gd, the Player node being a KinematicBody2D node.

Yes, our lives as developers is complicated

Hi,
thank you for your work on this and for making this available.
Would you be willing to add a license for the code and/ or assets?

Thank you.
Johannes

As I said we'd be open about our process, I put the project's outline in the repo's README. This way anyone can read it and join this discussion.

This is a general outline that encompasses the entire project, defines its scope, and our general intention with the course. This is NOT a game concept or game design document.

I could use some feedback:

• Is anything unclear or hard to understand?
• Should we develop some sections?
• Any other questions and suggestions are welcome.

Note: this task is to discuss the project. If you have other questions about other tutorials, our progress, etc. please ping me on Discord

I've changed Skin.gd, the node responsible for playing the player skin's animations, so it has a single public play method. But for animations like ledge, you need to animate the skin moving in the game world independently from the player. So you need some information from the corresponding state. I've made this an optional dictionary:

var animation_data: = {
  from=global_position_start,
  to=player.global_position,
}
player.skin.play(ledge, animation_data)

As a result, to use this special animation, you've got to know which parameters to use in the dictionary. And you can only know that by opening Skin.gd. Can we improve this? Should skin expose animate_ledge, a special method just to animate the ledge, and unique methods for each animation that works in a similar way?

After testing the level design work from @henriiquecampos, I want to try to improve the camera and input handling. See Refine the core movement

While this is optional in most cases when the AI is simple, when the size of the simulation increases, pathfinding requests, heatmap generation, state/behavior tree updates etc can become cumbersome and slow the simulation down, requiring a lot of manual labour to determine when/if a particular AI action needs to run.

A scheduling system alleviates some of that work by centralizing work inside of jobs which can be prioritized and changed with frequency, and offset with a phase.

Initial proposal by @Razoric480

The AI system is split between 3 facilities, plus a scheduling utility, depending on project and AI complexity:

• Decision making
• Pathfinding
• Steering

Decision making

You've already covered in part with the State machine in the previous course. I don't think it'd really need to be that much more complex for a Metroidvania style enemy - WATCH, ATTACK, FLEE. Though a behaviour tree could be a fun alternative for more complex creatures. Either way, the purpose of the actionable end-node of such a tree would just be to set the appropriate flags in motion for the Steering behaviours.
Implementation: In godot, that'd be a tree of decision making nodes - either a state machine holding a few states, or a behaviour tree holding its parameterized branches and actionable leaves.

Pathfinding

Depends on the terrain, and how smart the enemies have to be. Given they're in the air, frequently that might mean 'no pathfinding', but if they're going to head around corners, then yeah, you'd need something.
A star is the the classic solution. Split your level into a graph and run a heuristic driven path through it. You can also go for a hierarchical a star if you expect the AI to do some very large sweeping paths from one end of the map to the other (this is where you have multiple levels, top, more coarse level representations, and more granular levels below. For example, top level is a bunch of interconnected cities, with the level below that being the inside of the city, and the level below that being inside individual buildings.)
Heatmap as you've called it, or a repulsion/attraction, field flow, etc. I've seen it with quite a few names. Your gameworld is split into a grid, and each of the cells contains a vector pointing to where an entity has to go to reach the goal. The only issue with it is that it doesn't really scale all that well when the 'target' direction is a player, because the field has to be recalculated when they move. Though this can be mitigated by having the target be the 'area' the player is in, and the AI is then expected to move in a straight line once they get there - then you only recalculate when they change rooms. Or, if we're diving into C++ and threads, we can probably afford to recalculate it on the fly, depending on the complexity of any given environment.
The big advantage is that all an entity needs to do to pathfind is to check which cell they're in and request the direction they should be moving. Then you can have thousands of entities move extremely cheaply - a swarm of locusts, or pathfinding particles. Nothing stops you from having multiple pathfinding systems, then again, based on the entity's needs and complexity.
Implementation: In Godot, they'd both live as an over-node that has access to level data.

Steering

This is where the actual action is calculated, and is the most modular part. The behaviour is passed the information it's going to need (the actor it belongs to, its direction, acceleration, position, the target position, acceleration, etc), it does some math, and out pops a linear vector and an angular rotation - this is where the entity feels it has to go and/or turn. The actual movement code takes that vector and does the actual movement.
You can then have an inherited system with a common 'calculate' method, and you can prioritize (move away from imminent obstacle) and/or blend them together (a Pursue behaviour AND a turn-towards-target behaviour.)
Implementation: In Godot, that'd also be a tree of nodes, next to the decision making tree.

Could have an AI scene for each AI types that contains decision making and steering trees, and just re-use it for every enemy of that type. Godot is nice like that.

Scheduling

AI can get expensive. The bigger the levels, the bigger the maps, the more cells, targets, behaviours, and entities you have, the longer the whole thing can take. Threading can help, for sure, but another solution is to only iterate over how many entities you've got the time budget for. Instead of just iterating over each entity, you create a job that maintains a state until it's done. You tell it to run for a maximum of 1, 2, 6 milliseconds, and when its time is up, if it isn't done, it puts a bookmark where it left off, and next frame, it'll resume until it's done or it runs out of time again. Until an entity has had its recalculation completed, it can use its last result.

Produce a pilot tutorial to use the backers' feedback on the recent form.

Use the work from #5 as a base, but without the hook: this is a beginner tutorial.
The goal is to start to integrate the feedback below to improve the quality of our tutorials. As you'll see they're mostly small improvements that should help make the tutorials feel more structured and cohesive.

Some notes for this one:

• Mention/explain the advantages and drawbacks of Rigid Body physics compared to Kinematic bodies (you can use the 2 prototypes from hook for that)
• No need to add graphics to the game demos, you can rely on colliders (and basic drawing if need be). Again, you can use the hook prototype work as a base, just remove the parts you don't need. Or code a simple demo if you feel it could be faster.
• The target audience for this tut (and upcoming ones) is the target you'll see in the readme.

The Free courses are for what I would call beginners-plus: amateurs, young programming students, or developers in another domain, e.g. software developers, who have learned the basics of Godot, the basics of GDScript, and put all that in practice in a personal project. The viewer understands basic programming concepts up to what classes and objects are, what a node is at a basic level, and the viewer knows its way around the main areas of the interface.

For the rest, the structure of the tut is up to you. If you need feedback on the outline or anything, you can reply here and ping me anytime.

Checklist for the tutorial

1. Goal and project-driven: clearly define the teaching goals for the tutorial, explain what the viewer is meant to get out of the tutorial
2. Give a summary of the tutorial's teachings in the intro
   • Explain and show what the viewer is going to learn
   • Feature a table of contents with timecodes in the video description if the video covers multiple techniques or has distinct chapters
3. Remind the viewer what you covered at the end of the video
4. Mention common pitfalls or limitations of the tool/topic at hand and provide solutions

Text-based content

I.e. companion text file, pinned comment, video description

I will take care of this part when preparing the video for release. Could you just keep any link or page you use when creating the tutorial and that you find useful around and paste them in this issue?

1. Pre-requisites: link to content the viewer can use to get started in the description
   • Briefly mention to the viewer they can find pre-requisites and tutorials to watch first in the description
2. Provide resources to go further
   • Godot docs
   • Great tutorials from other tutorial makers
   • General article on the subject, if applicable
3. Table of contents and timecodes to jump to specific sections
4. Create an assignment to help the viewer put what they learned in practice

The character currently reacts to the hook with a force applied to it. The force scales based on the distance to the hook. The issue is it's not reliable at all: you may jump way past the hooking point, and the jump (starting velocity) affects the motion, which I feel it should not.

I think the hook should work more like in Flinthook or the old Zelda games now, where it pulls you reliably to the hooking point before taking you back to the air state. In which case a hook state or behavior should take control of the player.

@razcore-art do you think this can work with the components we have for the skills instead of a state machine?

When the character collides with a StaticBody2D that has its CollisionShape in the Hookable layer it teleports when the collision is in the air, especially with a strong horizontal velocity.

I can consistently reproduce this behavior

Goal: get a sense for the students' expectations and gather qualitative feedback about improving our material and resources.

Questions that need answers:

• Who is going to watch the course? Who's the student? (past experience)
• What do you expect to get/learn from this 2d course series?
• How can we improve tutorials for you, compared to the ones we make now?
• Would you use assignments to put the techniques you learn in practice?

This issue is to help me keep track of what main parts of the project are still missing

• Health component
• Combat: taking damage, damaging enemies, death
• Respawn and checkpoints
• AI system and Enemies
• Level design
• Visuals
• Sound
• Transition between frames

Start to think about how to separate topics, what to teach, what to keep in or not to stay within the video budget.

The focus should be on producing and delivering the 2d course, then the 3d one, in a timely fashion, and to extend them later if the budget allows for it.

• The Free series is self-contained, project-driven.
• Keep extra series or topic ideas in modules that we could use to extend the project later.

Simplify the Hook code and reproduce a HFSM like in the Player node. Hook is independent of the Player states so it needs a separate state machine.

Prepare the Hook to be able to assign "skills" to it.

Implement flexible moving platforms, that cycle through waypoints, represented by Node2Ds (or Position2Ds, any type of Node2D should work).

• Merge the waypoint platforms from the corresponding tutorial
• Replace the moving platforms implemented by @henriiquecampos with this unique system

What's left to do for this task:

1. Attaching a DamageSource to the Hook's arrow
2. Making the hook react to clicking on an enemy, but not making the character go to the hook state
3. Making the enemy take damage
4. Giving the hook attack some cooldown

• Have the enemy patrol between waypoints, but also detect gaps and walls, as an example of simple AI
• Separate the wall and gap detector and the AI agent: the AI should have behaviors like "turn" or "stop", and another node, the detector, trigger these behaviors
• Use the notifier nodes to turn the AI on/off automatically (performances)

Can you make a 2D bloom shader effect tutorial?

Design a short level made of three separate frames

Create a few short connected frames to test our level design workflow, and components like the camera. The start and the end of frames should connect well.
The goal is to use the result of this job to figure out an efficient workflow to create, arrange, and connect frames.