-
Notifications
You must be signed in to change notification settings - Fork 17
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
Input buffering #16
Comments
As long as the implementation proves to be useful, I think this could be added, but I have questions! I don't particularly understand why the sequence has to be encoded as Have you implemented such a class in GDScript before? For things like this I'd start prototyping in GDScript at least, and show that's it's useful in a general-purpose way, I haven't stumbled upon By the way, prototype implementations can be shared on https://github.com/goostengine/goost-examples repository.
Signals don't have
If we go treat the sequence as
Again, this could be:
I've actually submitted a PR to Godot for retrieving the action press/release (toggle) times: godotengine/godot#36460, but it wasn't met with much enthusiasm from the core developers.
I can see how this could be needed if you want to implement replay system (?), I'm not sure whether the buffer would require much memory for that for other more simple use cases. Also, memory usage vs. performance might be mutually exclusive goals to achieve? That said, I think it's possible to provide both types of API to work on the level of |
Hmm I didnt tought on using string name of the input actions, its a interesting approach. |
An observation: |
@Xrayez I could be mistaken since I haven't dug into that PR a lot but it's probably because it's intended to be general and possibly used for more than just input, such as syncing positions or whatever. (Although even in the general sense these can be considered inputs for the backend as well) |
Yes, to clarify, I'm not suggesting renaming the proposed godotengine/godot#36460 presents something which involves the time factor as well, so maybe the logic could be combined somehow. It would make sense to me that those input sequences could be added and fetched just like input actions in the input map, for which there's If we go with the singleton approach, I'd add
That would be core functionality, of course it would be up to you to decide how you can fill out those input sequences, but an editor could also be created for this, in theory. In the OP:
Input actions are saved as part of |
Made A GDScript prototype, any feedbacks are welcome @Xrayez @asheraryam InputBuffer.gd:
Command.gd:
Test.gd:
Goost edit: test project |
Describe the problem you are having in your project
Describe the feature and how it helps to overcome the problem
Input Buffering is common in various game even nowadays like in dark souls used for combat system, also heavily used in fighting games like street fighter and Mortal Kombat, Cheat codes can be easily implemented using input buffers
Describe how your proposal will work, with code, pseudo-code, mockups, and/or diagrams
Implementing a Inputbuffer class:
The class must inherit Resource, this way the user can save the sequences.
Use case example:
Is there a reason why this should be in Goost and not in Godot?
I like to think goost as a bridge for perfect Godot PRs, first make it work, then PR it to godot!
Solve a already made proposal?
Yes, it solves godotengine/godot-proposals#100
** Observations **
Yeah this can be implemented by the final user via GDScript, but I'm into performance, to archive this I'm proposing this relying on bitsets (direct bit manipulation) and way less memory usage, to check in a case where for example a character has like 30 combos into his moveset, the same for cheats and so on!
Pure c++ implementation can be found here -> https://repl.it/repls/RubberyCruelRectangles
The text was updated successfully, but these errors were encountered: