Rework player movement and simplify the code

[NathanLovato]

The current player control has the cursor and player controller as separate components that communicate through global events. This separation isn't needed for player-specific controls and makes tuning the movement harder than it needs to be. Everything related to controlling the player character should be contained in one place instead: querying the game board, handling input, and visual feedback.

Code simplification

Right now the cursor emits global events that the player controller listens to. In this task I want to:

• Remove the global event signals between cursor and player
• Move all player-related input handling, gameboard queries, and visual feedback (like moving or drawing the cursor) in the player controller script

The player controller generally can be self-contained as it exists only for player control (it's not a shared or reusable thing), so it doesn't need to be built from separate components.

Movement control improvements

Currently there's this lag where you click once to set a target and the character moves there, and you can change the target but clicking while the camera is moving with the character makes it hard to select the right cell.

The usability of both mouse and keyboard movement needs improvement. Here's what would make controls more responsive and intuitive:

Mouse controls:

• Click and drag to move: Instead of click once to move, the player should be able to click and drag to continuously update where the character is moving to. The target cell should update immediately as you drag the mouse around.
• Easy stop: Players need an intuitive way to stop movement. This could be based on the proximity of the mouse to the character, checking movement direction, or something else. But it needs hands-on testing to get it right.

I would drop thinking about touch controls for now and just focus on mouse and keyboard and building the game for desktop as it's for educational purposes. If we layered mobile support on top of it it'd gonna make the codebase overall harder than it needs to be to understand. It's already a project that's going to remain complicated for learners.

Keyboard:

• Input buffering: Add some input buffering when moving with arrow keys so movement feels more responsive. We should try to detect the intention of the player and not have this slightly choppy motion. At the moment it's functional but keyboard controls are not very fluid.

---

This whole task needs hands-on experimentation to figure out what feels good. I'm just putting it up there for future reference. It's not something I'll have time to look into or work on soon myself.

We have a first version of the game demo that packs a lot of code and it's been made by @food-please with a lot of effort and a best attempt to structure the code and figure out how to approach this complicated beast (thanks again for all your help and efforts!). There's compartmentalization and components that make a lot of sense across the code base. From here on, the focus should just be simplifying what can be simplified and improving and tightening game feel along the way.

[food-please]

It's already a project that's going to remain complicated for learners.

I wonder if it would be worth "marrying" the code here with that from your RPG module, which I presume is still in the works? If this project were to conform to the lessons and expand on it, rather than be a (unnecessarily?) complex alternative, it might be more accessible. I also think that would give this repo more utility as a companion to the lessons.

Is any of the code from those modules currently available, or is it sill all in development?

[NathanLovato]

For now, we haven't produced the RPG modules yet. This could be linked. I'm not sure just yet. We'll have to see when we get to working on it. It could certainly be useful if this demo was something more advanced that still relates to the course RPG modules.

This demo will be more complicated no matter what, because when you want to add game systems and polish, the code has to change to accommodate new requirements. but certainly we can find a way to relate them more closely when the time comes: simplify this codebase a bit, etc.

[mwael-labs]

Hey can I work on this issue?

[NathanLovato]

@mwael-labs It's potentially a pretty demanding task where you have to understand the codebase and know what you're doing. If you feel up for it and you'd like to try, please be my guest. I just want to let you know that I have certain expectations for this task, I really want the code to go toward something more imperative, more co-located, and to improve the game feel along the way.

[food-please]

I wanted to link what Nathan had mentioned here, since when I had started writing the grid based movement years ago it became apparent that moving NPCs (and other changing pathfinder conditions) made things much more complex than anticipated. Worth keeping in mind, I think.

We should try to detect the intention of the player and not have this slightly choppy motion. At the moment it's functional but keyboard controls are not very fluid.

I've been trying to figure out what you mean by choppy motion, since I haven't "felt" that on my end with the current iteration. I wonder if part of it is due to the destination marker rapidly jumping around when moving with the keyboard? I had forgotten about it until I opened the project again recently. That change had popped up in a rewrite (~ 6-12 months ago?) of the movement code that moved it away from being physics-based.

I'm not sure if this is beyond the scope of the project, but you will probably want to hide the destination marker for keyboard/gamepad input. I wonder if you'll find the movement to feel more fluid without the marker bopping around in front of the player?

[NathanLovato]

It's really about how the movement feels independently from the movement marker. You don't have very reactive controls right now with the movement: the character will not very fluidly change direction or smoothly move across grid cells. And this has to do with a mix of things including input buffering or movement cancellation or those kinds of things.

As it's a feel and tightness thing, it's something that first is difficult to describe, you'd have to have the current state and a really fluid grid-based character movement controller side by side to experience and really see the difference. Anyway it's not super important right now.