Conversation
|
Play this branch at https://play.threadbare.game/branches/endlessm/player-abilities. (This launches the game from the start, not directly at the change(s) in this pull request.) |
|
For now the draft ignores player modes at all (except for "defeating"), and makes the 2 abilities "repel" and "grapple" active all the time. Interact is not considered an ability. recording.webmI did a few changes in the input mapping. But I really welcome alternatives: For keyboard + mouse:
For just keyboard:
For joypad (let's say XBox):
(While doing this I noticed that the Champ quest introduced input maps to the project). What about the mouse cursor? Should it always be a crosshair except while interacting with dialogue or the game menu? We should think about: How would this affect the lore quests and the StoryQuests? Some ideas:
Some other changes needed:
|
Great combination of actions.
I tested these - it's great to have the combination of actions available at the same time! It is very hard to repel while also aiming the grappling hook with the right stick because the same thumb is used for both. We could perhaps move the repel action to a shoulder button. I was trying to think of bindings that I thought were good. It's a bit hard to google for the bindings for the game "control" for obvious reasons but they're here. In that game the right stick moves the camera, and the left stick moves the character - sort of similar. They use:
But this is something we don't have to get right first time...
This seemed the simplest way they could do what @jgbourque was asking for: a custom player script with gaps for multiple new special abilities. If we had had the changes you're drafting here with 4 actions with distinct bindings, maybe champ could have instead have (ab)used those, e.g. use the grapple action for the teleport special ability.
I would say:
Great point. And you could imagine a storyquest where the player-character gains one of these abilities during the course of the storyquest... So the persistence/restoring of these abilities needs to be factored out in some way.
I think ultimately we will need this but ironically the reason I was starting small with the combat projectile scene, and the sequence puzzle object scene, is that those scenes are unlikely to change dramatically & need updating in every storyquest, unlike the player scene where we knew that exactly this refactoring would be needed! |
5ff7cf4 to
e0ce806
Compare
Good idea! I have updated it to be the right shoulder button. I added the input mapping to the PR description. I also started a wiki page in which we can document this. I wonder since we are not targetting consoles if the joypad experience for aiming can be left as-is for now? And we consider mouse + keyboard the best experience? Up for discussion!
Interesting! I think is worth trying moving sprint to "push left stick" and LB for the repel action.
OK!
I agree, I started doing so in the last 3 commits but I'm not sure I'm doing it in the right places. I did:
I'm still thinking about the rest of your feedback (player progression). Thanks! |
I think this also gets back to our "who is the player" question. In my experience trying to teach people how to play Katamari Damacy (which is controlled basically entirely with the two sticks), the "click both joysticks to do a 180° turn" control is really surprising to people at first: less experienced gamers don't see the joysticks as being buttons as well as joysticks. But you only have to teach it once. |
Let them happen all at once without changing the actual modes for now. Only leave the mode "defeating" to disable player interaction and abilites (repel, grapple). This prevents refactoring the modes right now.
This was introduced a while ago and left invisible. It has the shape of StoryWeaver so it won't work when replacing the SpriteFrames in StoryQuests.
This could be a const, or the "repel" string can be used directly. This is only preparation for upcoming animations refactor. Note: There are references in StoryQuest "After the Tremor" that this change may break.
Rename the node that provides this ability to PlayerRepel. Adjust the scripts accordingly.
And the Area2D nodes that had this script. In 2 scenes from Void quest.
Add a signal to the repel ability and use it to play the animation when the property changes, instead of checking it constantly in _process(). Loop the repel animation in the script by adding a handler to the animation finished signal, and remove the loop mode from the animation itself. Give a class name to PlayerRepel.
For keyboard + mouse: Use right click to repel. For keyboard only: Use Z to repel and X to grapple. This is on the basis that the player will use arrow keys for moving in this case. Interact continues being Space in both setups.
To the right shoulder (RB in XBox). So it doesn't collide with A for interaction. And so it can be used at the same time as aiming the grappling hook with the right stick. Co-authored-by: Will Thompson <wjt@endlessaccess.org>
Into a new PlayerHarm node inside the Player scene. There is no actual harm today, but the "got hit" animation and handling of the projectiles entering the player hitbox are here now, split from the PlayerRepel ability. Also, connect the signals from the editor, not in the _ready() function.
During dialogue, set the cursor to the arrow. When dialogue ends, set it to the cross.
When the game is paused set the cursor to the arrow. And when unpaused, set it to the cross shape.
A boolean property. Default to false. Set it to true in the 3 existing lore quests.
As generic flags that can be interpreted by the game entities. For example, the first one can be "repel". Add an enum with 3 abilities, each with 3 modifiers (enhanced, reduced, buffed, debuffed, strengthened, damaged). Eg: longer thread to grapple. The same methods set_ability(), has_ability() can be used from the game, and they will behave differently depending if the player is involved in a StoryQuest or not.
Consider flags ABILITY_A as "repel", ABILITY_B as "grapple", and ABILITY_B_MODIFIER_1 as "longer hook" modifier for grapple.
- Grant "repel" at the beginning of ink_combat_round_1 - Grant "grapple" at the beginning of grappling_hook_start - Grant "longer thread" when collecting the powerup in grappling_hook_powerup - Grant "longer thread" when collecting the powerup in void_grappling_round_2 (although it should be already given at this point) - Remove hacky way to set longer thread
|
Update, the last 4 commits add player abilities to the game state, and use them in the lore game. There are 2 sets of flags:
The same player scene calls Grabacion.de.pantalla.desde.2026-03-11.00-25-01.mp4After a quick lore playthrough, is nice to obtain the repel ability or the grapple ability in different order depending which quest I play first. Adds a bit of non-linearity. Is also fun to replay The Void, and in the second level be able to obtain the thread directly because I already got the longer thread the first time I completed the quest :D recording.webmThere is refactor to do. For instance, the grappling_hook_start and grappling_hook_end scenes can finally become one! (if I figure out how to start/skip the cinematic depending on the spawning point). Caveat: you can abandon the (lore) quest right after obtaining the ability and you keep it! I think it should be finally granted when completing the quest. Caveat: I added 100 more lines to the already bulky game_state.gd. Note: this breaks all StoryQuest scenes that set the old player mode to grapple or repel. I hope to fix them soon by granting/removing the abilities per scene.. yikes. |
Put an Area2D around both spawn points; if the first one triggers, start the cinematic then disable the area2d; if the second one triggers, disable the first area2d? |
New input controls mapping
For keyboard + mouse (best experience):
For just keyboard:
For joypad (let's say XBox):
Resolve #1375