[FEATURE] WASD & HJKL keys for exploring the base

Question

[FEATURE] WASD & HJKL keys for exploring the base

Closed this issue 4 months ago · 15 comments

Is your feature request related to a problem? Please describe.
I am used to vim motion. This is a thing i usually find everywhere now a days.

Describe the solution you'd like
While exploring the base,
w a s d or with h j k l key should be usable to move in the maze/map.

So basically, following key combination:

Motion	Key1 (already works)	Key2	Key3
Left	Left-arrow	a	h
Right	Right-arrow	d	l
Up	Up-arrow	w	k
Down	Down-arrow	s	j

Describe alternatives you've considered
For me personally, there is no alternative to vim bindings This is just natural to me. For non-vim gamers

Additional context
For people using non-QWERTY layouts this might not be a great addition

Answer 1 · 2024-05-06T03:44:11.000Z

This seems a completely reasonable addition.

As you rightfully specified, this would mostly apply to the map view. Altough, one could quickly find that some keys are inevitably going to be needed for commands (like, m to open menu).

I say this not because it's a hindrance to this feature (there's enough keys for everything and currently they are mostly free), but because I would much rather setup the option for the user to set arbitrary key bindings for any relevant key.

On the positive side, I was planning anyway to add some configuration options, so most of that work applies to managing this kind of setting too. I'll bring that in first, and then integrate this at some point.

So this will need a bit of thinking on how I might structure for the implementation.

May take more time than "needed" for such a simple addition (just OR the keys in the check!!!!!), but that's the way I prefer to pave for future additions.

Answer 2 · 2024-05-06T06:40:02.000Z

On the positive side, I was planning anyway to add some configuration options, so most of that work applies to managing this kind of setting too. I'll bring that in first, and then integrate this at some point.

Thank you for considering this.

but because I would much rather setup the option for the user to set arbitrary key bindings for any relevant key.

Hey, it's up to you. I also agree this is the way to go, but if you provide configuration for keys.. please do it in a way so that it can be configured by editing a config-file. I mean running helapordo for configuration shouldn't be forced; One should be free to edit config file and get done with the configuration.

So this will need a bit of thinking on how I might structure for the implementation.
May take more time than "needed" for such a simple addition (just OR the keys in the check!!!!!), but that's the way I prefer to pave for future additions.

I am sad to see that this might get delayed. Considering i am not used to arrow-keys at all.
And happy to see that you have a plan for this.

I say this not because it's a hindrance to this feature

I didn't check the code because game is running so smooth with 0 bugs.. (BTW.. Great work)
If it is possible please consider adding a simple patch like,

// Replacing following:
// if (pressed == KEY_LEFT) {
// with following:
if (pressed == KEY_LEFT || pressed == 'h' || pressed == 'a') {

If it is not possible then no problem.. i am waiting for this feature both ways :)

Answer 3 · 2024-05-06T14:41:15.000Z

I mean running helapordo for configuration shouldn't be forced; One should be free to edit config file and get done with the configuration.

That is a nice idea I also wanted to integrate. It may not be available immediately, but that's probably gonna be developed really closely with the options anyway.

If it is possible please consider adding a simple patch like,
If it is not possible then no problem.. i am waiting for this feature both ways :)

This is possible indeed, and you could definitely patch a local branch of yours at these cases so that they are updated for your keys, but I might implement some form of handling this in devel in the next couple days, so you may want to keep that branch clear to pull later.

I didn't check the code because game is running so smooth with 0 bugs.. (BTW.. Great work)

There's plenty of bug left to be found... See the fixed ones.

Answer 4 · 2024-05-08T00:41:26.000Z

Current devel branch now has a prototype for option selection that will eventually lead to control on this config option too.

I just have to implement remappable keys. For now, I'm thinking of mapping one set of movement keys to both the map movement and all ncurses menus. Will be done soon.

Answer 5 · 2024-05-08T00:50:05.000Z

Hi @jgabaut, I am pretty sure there would be more parameters planned for config file.

If the general idea is planned and you are okay with the idea of opening a separate issue then please open a separate issue for config file implementation listing:

Planned config parameters
Data types for planned parameters like bool, int, float or string
Accepted range for parameters of data-type int
Accepted values for parameters of data-type string

Answer 6 · 2024-05-08T01:57:56.000Z

If the general idea is planned and you are okay with the idea of opening a separate issue then please open a separate issue for config file implementation listing:

As mentioned in #87, for now, no config file implementation will be shipped. It's going to come in a later patch and there will probably be another issue for that.

Also, the settings will be saved and loaded together with a saveslot. So each saveslot gets its own options, and you won't have to set them again on that saveslot (theoretically).
This will later compound with the config file so that the config file will override the source-provided defaults for any saveslot with no options ready.

So the usecase for this issue should still be accessible in a reasonable manner (no need to set a bunch of keys individually), I'll probably define a vim-foo option that enables hfjk for the mentioned movement set. Later on, there will be some planning around the config file.

Answer 7 · 2024-05-11T02:10:49.000Z

I've started work on this, and most of the tedious work is done.

It's gonna be pretty simple at first (literally just the usecase you wanted).

You should expect to be able to test a devel commit that offers this soon. 😄

Answer 8 · 2024-05-12T20:59:08.000Z

@khushal-banks
I implemented the missing links and now the game can select between arrow keys (default), vim keys and WASD.

You can:

Start with vim keys by running with -j
Start with WASD keys by running with -w
Switch keys after starting the game from the Options menu

Let me know if you try the latest devel.

I should have a release ready in the next days, so all of this will move to master.

I am also rethinking about the multiple options thing. I guess it makes more sense to only have one set of options, and binding one to each saveslot makes little sense. I guess there will be a separate file just to store the options, no big deal.

~~The load/save game options should come very soon, maybe tomorrow.~~

Storing/loading game options between runs was just implemented, but I haven't had time to test it good.

Answer 9 · 2024-05-17T04:51:19.000Z

@khushal-banks Have you had the chance to try out the current status? I would like to know if it's enough before wrapping up the release

Answer 10 · 2024-05-17T05:24:50.000Z

~~Did you modify the build process? I am running in some issues.~~

~~I am able to compile the code in main branch but not the devel branch. Should i open a new issue for this ?~~

~~Fixed my issues.~~
~~I am testing right now.~~

EDIT:
Keys are working for me. Although i thought both will work simultaneously.
I thought,

option -j would allow vim keys and arrow keys
option -w would allow wasd and arrow keys.

But this is also fine as they can configure it using option menu with 'm' key at run-time, so overall i am happy to see it is finally merging.

Thanks again

Answer 11 · 2024-05-17T06:10:51.000Z

EDIT: Keys are working for me. Although i thought both will work simultaneously. I thought,

About this, seek for hlpd_d_keyval and you may suggest better ways of implementing this. I was going for sheer simplicity, but later I guess the keybinds structure could be made more interesting to allow multiple keys to be bound to one symbol, or anything of the sort. This is more of a bare-bone addition, if you check out the code. The commits for this functionality should be pretty isolated.

Answer 12 · 2024-05-17T07:45:01.000Z

About this, seek for hlpd_d_keyval and you may suggest better ways of implementing this

I tried to understand what this is, can not make up my mind, seems too rigid in usage and no clear docs.

but later I guess the keybinds structure could be made more interesting to allow multiple keys to be bound to one symbol, or anything of the sort. This is more of a bare-bone addition, if you check out the code.

I will try to check out the code.

Answer 13 · 2024-05-17T07:50:41.000Z

seems too rigid in usage.

If you mean the current implementation is not flexible enough because it does not allow more than one keystroke to be mapped to a key, I may agree but I must also say this probably will need a separate patch since there would be a substantial amount of support code added. This patch is big enough like it is.

At a later point, HLPD_Key could be updated to hold an array/list of val fields, instead of just one, and a new utility to check if a keystroke maps to a HLPD_Key would be added to check the whole list, in place of hlpd_d_keyval().

Answer 14 · 2024-05-17T11:37:07.000Z

@khushal-banks

Ooops. I tagged the release, but forgot to check if all of this was still kosher for all build configurations.

Seems the raylib mockup is broken. Want to try to help with this, for the next patch?

#94

It seems I forgot to mention on-code the additions were by your suggestion, but there's plenty of history of that in the issues. I'll try to remember this for next patch, if you don't end up contributing code directly yourself by then -speaking only from github's point of view-.

Answer 15 · 2024-05-18T04:14:58.000Z

Seems the raylib mockup is broken. Want to try to help with this, for the next patch?

Thank you for the opportunity. I would be happy to enjoy playing helapordo; it's development would require me to upskill in a lot of areas i am completely unaware of.

Until then, I would be happy to assist in occasional general usage testing whenever possible.

It seems I forgot to mention on-code the additions were by your suggestion

As far as i understand it, you should not mention me.
I only requested a feature and only you added it. I didn't even look at the code.
(same applies to other feature requests, in my point of view)

I'll try to remember this for next patch

I would highly advise against it. Please only add co-authors in the code-base.

speaking only from github's point of view

Hmm, no it wouldn't be justice for the code-base.
I am mentioned in this feature request that is enough.

Now i am able to play this game with vim-keys ... this is all i wanted.
Thank you for this feature addition. Great work buddy!