Unique Virtual Input devices

[Lucrecious]

The way I control my player character is through keyboard/joystick input. When I press a button, a speed is calculated and its applied to the character's movement. As a result, the user has restricted control over the character - the user can't apply infinite speed to the character, for example. The user only controls the character at a high level: "walk right", "jump", "attack". Rather than, "apply vector(150, 0)", "apply vector(0, -300)", "change from movement state to attack state".

It'd be nice if I could have the same type of restrictions when programming NPCs. i.e. give them high level actions and then control them with an AI FSM.

Maybe I could map "jump" to a key on a virtual unique keyboard, as if, the NPC itself is using its own keyboard.

This could be useful for multiplayer games where in you have computer controlled characters and user controlled characters. You could use the same abstraction to control both and just give them different input devices. You could give the players joystick input and the computers virtual input, for example.

Maybe you're making an RTS type game where you can gain control of a particular character but the rest are computer controlled. You could select that particular character, swap its virtual input for a keyboard input and now the user has full control.

Even in regular games, I could use the same "character" abstractions for both my players and NPCs. I'd just pass the user controlled character a keyboard input and the computer controlled character a virtual input device.

Any thoughts?

[akien-mga]

You can likely achieve this using Input Actions. Just make your AI emit InputAction events and it will be like someone pressed "jump" or "walk right".

[groud]

Well I don't know if it's possible but there's probably a way to trigger an action from code.
But honestly I don't think this is really useful, you can easily create a simple set of functions to abstract the actions you want to perform. And it is such a corner case that, IMHO, it does not need to be implemented as a built-in feature.

[Lucrecious]

you can easily create a simple set of functions to abstract the actions you want to perform.

Fair point.

And it is such a corner case that, IMHO, it does not need to be implemented as a built-in feature.

I still think the input system should allow for this type of flexibility though because it's neither intrusive nor (seems) particularly difficult to implement.

However, part of the reason I like Godot is because it trims the fat and just gives us the most important tools we need. Maybe this would add too much clutter?

Another reason I thought this would be cool would be for cutscenes. Say a character enters a cutscene area, all you would have to do is disable the real input devices (Keyboard and Joystick), and "plug-in" a virtual device to have the computer control the character during the cutscene.

[Calinou]

Simulating input can be achieved using Input.parse_input_event(). To make it more convenient, you could probably wrap it with a single function that handles everything.

Should this issue be closed?

[Calinou]

Closing due to lack of response. See also godotengine/godot-proposals#104, which is tangential to this proposal.

[Xrayez]

I think godotengine/godot-proposals#104 covers this proposal to great extent in fact. Looking at this thread, I've seen suggestions which simply do not understand the use case, which is being able to control multiple characters, with multiple devices, and multiple players (see the same reference to RTS games). This can't be solved conveniently with a simplistic input action mapping system.

You can likely achieve this using Input Actions. Just make your AI emit InputAction events and it will be like someone pressed "jump" or "walk right".

This only works well for single character motion. Imagine you want to record/simulate different motion to multiple characters within a game (again as suggested, controlled by an AI as an example). You'll naturally want to use the same Input interface for all of them, but find yourself being limited to the global input state.

Of course everything can be worked around, but the tremendous complexity (and performance) which comes from it is not worth it (but, perhaps Godot is not really designed for these kind of tasks in the first place, and I should just simply get over it, but unfortunately I cannot compare given the fact that I've been using Godot almost exclusively for the past 3 years). 🙂