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! |
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.
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. |
2 participants
New input controls mapping
For keyboard + mouse (best experience):
For just keyboard:
For joypad (let's say XBox):
Resolve #1375