9 replies to this topic

[kburkhart84]

I suggest a sort of input manager that would allow code to work regardless of the input assigned to a given action. Right now you can do custom controls through your own scripting, I have also have the kbinput extension I created for this purpose, but I think it would be better if it was set up directly in GM's IDE so that we could use events based off of said actions instead of just the step event checking code.

First, this should be an optional way of doing things, not something forced on you, but the code wouldn't be too extensive so I don't think it would be necessary to include an option to turn it off, but it could be set like that as a global game option.

Second, the game designer defines a certain amount of "actions" which would include things like "run" and "jump" and even "left" and "right." Then they give a "default" keyboard key for each of these things. Then, GM provides functions that allow the game player to customize the controls at run-time, and the game designer calls these functions when his GUI buttons are clicked allowing this. The function call would return instantly, but set up a "thread" that waits a given amount of time(probably defined by the designer) that waits for the player to hit a key, or move a joystick axis or joystick button. Then whatever got moved gets set as the control for the given action. Also, the function would call a script(also defined by the designer) when either the control gets set, or a different one when time runs out. This is how the designer would know that the function call is finished so they would remove the indicator telling the player to press the button for an action. Assuming this was internal to GM, they could actually instead put these "callbacks" as events.

Third, at gametime, the game objects either react to the new action based events, or they call related functions, instead of checking inputs directly. This allows game code to not care if the player chose a joystick button, keyboard key, or any axis on the joystick and the game's code(or d&d) would work all the same. The exception to this could be if the designer designs with joystick axes in mind where the character would walk instead of run(or similar things).

To go along with this, you could provide different events similar to the current keyboard events, which would include the "just now pressed" event and the "is currently down" event which would fire every step until released, and also the "released" event. You could also even add a variable that would say for how long the action's input has been held down(which my extension does for you). It also needs a way to determine input "conflicts" so that the designer can advise the player if more than one action has the same input. Also very important is a way to save and load configurations, including the "default" configuration.

As far as mobile platforms go, if a game is not directly designed with touch/mouse in mind, it would mostly use virtual keys for the input, although it could use a "virtual joystick" as seen in other topics. If working with my suggestion, you would simply map those virtual keys to either "actions" or do a workaround mapping them to the "default" keys as set up for the input, though I think going directly to "actions" is better.

What does the community think of this? Right now we have to kind of roll our own code for this, use an extension(and mine is the only one), or simply now allow the player to customize the controls, which is very common with GM games. i think if GM provided this internally, many more games would allow custom controls. By doing this internally, it becomes event based, making it easily compatible with d&d, but you can also provide functions so things can still be done in step events. This caters to however the game designer feels is best to organize the code.

[Jack Indie Box]

a keybind dialog box(wording...) would be great to be implemented by YOYO both for setup in IDE and in the game like a standard one just like colour wheels exist in many paint programs and such

[kburkhart84]

a keybind dialog box(wording...) would be great to be implemented by YOYO both for setup in IDE and in the game like a standard one just like colour wheels exist in many paint programs and such

I don't think we would want to use the "default" box for run-time in our games for the same reason it was ugly to use GM's default message boxes. Of course it needs to be there for the IDE though, and for the run-time it could be as well, but it should be optional, or be able to be well customized, which would then lead me to suggest an internal GUI system that is nicely skinnable.

[Jack Indie Box]

an internal gui system would be lovely. and i think it is being picky if you want this nice feature but wouldnt be happy with a built in "ugly" one i mean windows style is on 40+% of computers in the word and we survive, i personally love windows forms

[Lune]

I think it's better off without something like that. A tutorial on how to implement something like this would be useful, but not a hard-coded feature. There are too many variables, like what key/button should be used to initiate the listening phase, how long should it listen for, is there a cancel button and if so what, do bindings get overwritten or are redundant entries allowed? This level of sophistication is better-suited to hand implementation.

Again, though, I do think making a tutorial for how to do something along these lines would be helpful to a lot of people! Not everyone takes advantage of customizable controls, but it's worth the small effort to implement for those who do!

[kburkhart84]

I see your point lune. An easy alternative would be available in extension form, if we had access to create objects as part of extensions, and we would need some way to integrate events into the ide, ehich triggers were able to do, but even then triggers couldn't be a part of extensions.

My point is that though these things can be done via scripting or an extension, it won't have that truly tight integration with the IDE that only the yoyo team could accomplish.

[kburkhart84]

I see your point lune. An easy alternative would be available in extension form, if we had access to create objects as part of extensions, and we would need some way to integrate events into the ide, ehich triggers were able to do, but even then triggers couldn't be a part of extensions.

My point is that though these things can be done via scripting or an extension, it won't have that truly tight integration with the IDE that only the yoyo team could accomplish.

[Lune]

Maybe if it was integrated with keyboard_wait() somehow, like if that function somehow returned what key stopped the waiting. Then the integration with the game is still up to the designer/programmer, but the base functionality is inherent to GM.

[kburkhart84]

The how to part of the coding isn't an issue. I have my extension and others have scripts that handle it, and the issue with keyboard wait is that it would freeze the loop, and it doesn't take into account if the player wants to use joysticks.

The issue we are having isn't how the code it, rather that we can't integrate it well into the IDE, rather only in scripts and objects. And for example for my extension, I created a separate program for creating default configs, which you then load via a function call, but it could be better if such a dialog existed as part of the game maker environment.

[kburkhart84]

BUMP...

I think this is a pretty good suggestion, but no one paid much attention.... oh well. I'm not whining

None of the devs responded, maybe I'll get lucky this time.