Write a game concept for the game and the course

[NathanLovato]

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.

[henriiquecampos]

In the current iteration of the Game Concept I think we might have a design problem regarding the controls.

In the Gamepad section the approach is to shoot the hook in the direction of the movement. This is dangerous and can cause some frustration:

• Player is on and edge, falling will kill the player, there is a hookable object, in order to hook the player will have to move towards the direction of the hookable object, possibly falling in the void and dying.
• There is an enemy close to the player, player has to both avoid and shoot the enemy, the time the player shoot, it moves towards the enemy, the times the player avoid/flee the player loses target from the enemy.
• There is a hookable obstacle that the player can pull, between the player and the obstacle there is a danger (water/lava/acid) player has to pull the object to the danger, moving towards the danger, increasing the danger thread and chance to kill the player.

Besides, there are some other games that use that approach, and I remember they were all very annoying, Flinthook being one of them, especially with the gun aiming, besides the hook, other players also share this feeling with me.

Alternatives

• Have an hooking stance, entering this stance will make the L-Stick behaves as an aim. This stance can be triggered by one, or both, Gamepad triggers. This is similar to [Ori's bash] which in all honesty is one of the most rewarding mechanics in the game. But here player would be free to perform this, in Ori it is only possible to Bash enemies, projectiles or lanterns.

Mastering Bash - A Level Design to develop player's skills with the bash mechanic Guinso Tree Escape - A Test to take a proof of player's mastery with the Bash mechanic.

The later is one of the climax of the game imo. So I think the concern regarding the game's flow can be mitigated allowing for a rewarding game experience.

Also, this "pause/slowmo" when in this stance is one of the workarounds players found in Flinthook, using its Chronobuckle.

---

• Have an intelligent hook that would detect where to and what to hook, taking rid of the aiming. This is an approach Spiderman games take for instance. Then in order to change targets we could use the gamepad triggers to switch to next/previous target, e.g. if there are 2 hookable objects. Kinda like an aim-lock, but without having to aim nor to lock, these would be done automatically.

Players on Flinthook seem to complain about that kind of aimbot "help", but I think that this is due to the game not being designed around it, is just a workaround for a design flaw. I couldn't replicate this aimbot feature in my save, to get the feel of it and compare.

[NathanLovato]

In short

1. Figuring out good controls takes experimentation, and getting a good game feel tests and adjustments.
2. So I'd like us to do actionable work, more prototyping, testing, review work, and not too much discussion-driven design, which I consider less productive than build/test loops.

Longer reply

As I wrote in the concept, I've coded and tested different control schemes. With the gamepad, the current scheme was the one that felt best in hand with the intention to offer a fluid platforming experience that revolves around the hook.

First line in the concept:

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

The prototype is already using some snapping system, your suggested alternative number 2. Note that Spiderman, or e.g. Sekiro, that I played recently, don't get rid of aiming entirely, they use some kind of snapping system based on where you aim the camera and move your character. I'd expect something like that to have taken a ton of work to get right.

there are some other games that use that approach, and I remember they were all very annoying

Is it only about your personal experience? If not, unless you know all the players and all the games, you can't say something like that. Having even a large a fraction of the players complaining about controls doesn't mean that the control scheme doesn't work or can't work. It can mean that it could use more adjustments, that the players in question aren't the target audience... speaking of which, if there's one thing that's missing to point out in the game concept, it's the lack of target audience.

Ori took over 5 years to create, there's a ton of polish that went into the game. The bash mechanic is great, but don't forget it builds upon what felt to me like excellent movement and level design, which I'm not sure we can achieve for a quick demo for a course.

I'll pass on the potential sources of frustration for the player as they're thought experiments. Whether these issues arise or not will depend on how the game actually plays. Issues like these can arise regardless of the control scheme, depending on the level design and the way you code the mechanics. They're still good to have in mind moving forward with the project though.

Game design is complex. I can't set my mind on whether a mechanic or controls are wrong on paper or not without quite a lot of experimentation and testing. I'm sure that the alternatives you outlined could work. They would also lead to different gameplay and feel.

Conclusion

I'm open to testing other schemes and controls. I'd just like us to use prototypes and actual experiments to critique and figure our solutions or improvements over just talking, as I believe it will be a lot more productive. It took me 30 minutes to write this answer alone.

I'm aware of some flaws and things I'd like to keep working on in the first prototype, e.g. how in practice you're mostly hooking in 4/8 directions with the joystick, as you also use it to move.

Once more, I'd just I'd like our design work to be tangible whenever possible, not spend too much time with logic and thoughts. I've done that too much in the past, it's been time-consuming and didn't help to move projects forward fast in my experience.

E.g. it took me 30+ minutes to write this reply, I'd bet it took you at least as much to write your feedback in the first place. That's more time than it would've taken me to test alternate controls in the prototype.

[NathanLovato]

We have a base concept and prototypes outlined now: https://github.com/GDquest/godot-metroidvania-2d/blob/master/GAME_CONCEPT.org