-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unique Virtual Input devices #15373
Comments
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". |
Well I don't know if it's possible but there's probably a way to trigger an action from code. |
Fair point.
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. |
Simulating input can be achieved using Should this issue be closed? |
Closing due to lack of response. See also godotengine/godot-proposals#104, which is tangential to this proposal. |
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.
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 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). 🙂 |
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?
The text was updated successfully, but these errors were encountered: