Implementing whole Left side and right side of screen as input

I am quite new to godot and game dev in general. I been working on developing my first game, in this game if user click/tap on the right side of screen, the player moves right and left side to move right.

Untitled-2024-02-02-0958

I am currently using two touch buttons with control anchors to fix the buttons on left and right side of the screen.

Another solution I am thinking is using InputEventScreenTouch and calculating using the viewport size to check if the touch should trigger move left or move right action but as I also need release event I am not so sure about this.

I would like to have suggestions on which method is better, because in the former method this issue has been occurring frequently TouchScreenButton sometimes stops working on Android with `Input.is_action_just_pressed()` · Issue #70951 · godotengine/godot · GitHub.

I am using godot 4.2 stable.

Thank You.

I wouldn’t worry about that bug, and just dont use is just pressed inside _process or _physics_process. Use it in _input/_unhadled_input function instead.

You can setup you action from the input function and act during the physics or process cycle.

I think you are on the right track.

1 Like

Can you please elaborate on what you mean by setup and act? How to do that?

When a finger touches the screen an input event happens. It will have a screen location and it will register an index. The first finger to touch is 0, the second finger to touch is 1 Etc.

Now because we have a position and finger we can use your screen divide technique to presume this finger wants to control the input of the left or right “thing” you want to control.

So if the fingers are touching whenever we see a drag input we can update a class finger position variable, or relative vector, that will be later uses by a process function to move a character or game object.

General concept

# global class variable 
Var direction 
Func Input:
  #set direction 
  Direction = relative finger drag movement 

Func Process:
  #Use direction variable
  Character.position += movement speed * direction.normalized

I am currently doing this :

Yea, exactly. I would even remove the state checks from the input. Just generate a raw input state your class cares about.

Because you won’t jump unless you are on the floor and have received an input event, there may be many frames before the player re-reacts because the player reacted too
early before the player was on the floor and missed the jump action. But if you generated a war input state checked it continuously in a process function, and can jump becomes true, the player will jump on that exact frame.

This would be the S in the SOLID coding principles for single responsibility of functions. Technically your input function is doing two things, test the input and check against the object state for behavior changes.

I also see some remnants of code checking input action states in another function. Not very solid :sunglasses:.

This is all hoopla anyway, not really focusing on your original ask.

Need to design a construct to keep track of a finger based on it’s initial placement.

Does your game have a split screen concept, where you would employ multiple viewports? Input events start with a viewport and work their way down to nodes. ( It wouldn’t necessarily need to be a “Split” screen if each viewport is in charge of rendering their portion of the game.)

So if you’re game can be chunked into viewports then you would only need to write code for one player and just duplicate it by creating a new sister viewport tree. the hope being that any touch events over that viewport will only go to that player.

If this would work you could expand into quadrants and have 4 player if the device is like a larger tablet.

What is raw input state?

My meaning for “raw input” is a concept of interpreting the user input into something the class can use and understand. It also means when forming the class input it doesn’t take the current state of the class into account. It is clean and raw. And just shows the players current intentions for input.

Some output examples includes booleans, bit sets, gains/speeds, and direction/position vectors.

So maybe raw is a little bad naming. Maybe it should be clean class input, raw class input, or something.

Anyway its basically an idea to just for easier development and having a single responsibility for the input function.

Then when the class begins to use the raw/clean class input you can pass it to many functions that will determine if something should happen because of the input.

This also sets you up for AI actors or a replay mechanism to take control. The actor can create a raw clean class input that can drive a character.

It also allows the code to be portable, if you have another character that uses the same input format (or even a subset of the same input format) but behaves different, you can use this raw clean input and act on it differently

Thank you. I think I understand a little bit better now