key_state

by IainPeregrine
A small library for handling player key presses.

New Library: Key_State

Page: 1 2
Jan 31 2011, 12:20 pm
Having a complex game is not an excuse for having a poor control scheme. Console games, even RTSs, have to map their commands to a joystick, and players are better off for it.

The majority of gamers prefer a keyboard and mouse for playing an RTS, so I'm not sure what you're trying to say here. It sounds like you're on a crusade to simplify controls and you're afraid that, without the 16 key limit, someone could use your library to create a complex control scheme. Is this right?

Sure, if I didn't want to use bit flags. Again and again and again and again, I'm not going to remove a feature which I find very useful.

You're also assuming that this "feature" is desired. What if someone wants to know if a player is pressing both left and right? What if 8 and 4 were mapped to different keys instead of left and right? The way the library is set up there's no way to handle this. If the library didn't include this feature (that is, the automatic clearing of the opposite direction) it could still be implemented in a demo that uses the library. If this feature is so important I'm not sure why you thought I was out of line to say that the library is tailored for 4-directional movement.

It would be better to make no assumptions about clearing of keys (though I think keypress should be cleared automatically after they're handled) like you do about opposing directions. Instead, let the person using the library define them.

client.exclusive_keys("west", "east")


This would tell the library to treat the specified keys in the manner you're already treating them. You never know, someone might want other keys to work this way or they might want the arrow keys to not work this way,

If you want to make an NES style input library, that's fine, just be clear about what you're doing.
Jan 31 2011, 12:44 pm
Is it your intent to go over the same thing over and over again?

It sounds like you're on a crusade to simplify controls

I am.

you're afraid that, without the 16 key limit, someone could use your library to create a complex control scheme.

Why ignore what I've said in both of my last posts?: I will look into a way to include both bit flags and strings. I'm not "afraid" that people will make bad games, which they do anyway. I'm just not going to include features I don't feel are important if I have to remove features (bit flags) that are.

You're also assuming that this "feature" is desired.

You're right. I am assuming that certain features are desired, and that's why I'm writing a library. It would be very easy to release a blank file with no features in it, so as not to assume anything. Why ignore what I said before, that if I can make it accept both bit flags and strings, then I'll include the ability to opt out of this feature.

...4-directional movement

Just drop it already. Seriously. Read what is written before, I'm not going to type it again.

(though I think keypress should be cleared automatically after they're handled)

And what does "handled" mean? If you've got a library like yours where key strokes are tied directly to commands, then sure, clear the key stroke immediately. Do you even understand why someone would want key-states? The value gets stored, instead of triggering an event immediately, so that the game can check it later. If you want a command to execute immediately when the button is pressed, use the default macro system.
Jan 31 2011, 1:55 pm
I've managed to get into cyclical discussions with Forum Account on design before. While I'm sure you are happy to accept a little design discussion on your released libraries, due respect should probably be paid to the author's key design intentions when doing so. There is a point where it stops being just a discussion, and starts becoming brow beating.

One key intention I took away on first reading was the key state storage mechanism, one that is distinctly different from a purely reactor pattern key event model, and carries it's own strengths and weaknesses that a programmer will assess when picking key state/event libraries for their game.
Jan 31 2011, 3:55 pm (Edited on Jan 31 2011, 5:57 pm)
SwapMaps and DMIFonts are popular because they are the libraries for their respective topics. Your library could be useful but it sounds like you're content to make just another input library instead of trying to make the input library.

Just drop it already. Seriously. Read what is written before, I'm not going to type it again.

I'm trying to understand why you made what you made. Not to belabor the point, but the library makes some clear assumptions about how it will be used. You seem to hop back and forth between saying that wasn't your intention and claiming that's the library's strength.

I've managed to get into cyclical discussions with Forum Account on design before. While I'm sure you are happy to accept a little design discussion on your released libraries, due respect should probably be paid to the author's key design intentions when doing so.

I recall the discussion you're most likely referring to. In that instance, like this one, I can't tell if you two are releasing things to say "Hey everyone, look what I made. Isn't it great?" or if you're sincerely trying to produce useful resources. I try to point out ways that things can be improved because regardless of your intention, it's much more useful than saying "oh wow, that is great."

Edit:
And what does "handled" mean?

I'm not sure. Your library relies on it (so that attacking is handled once) but doesn't have support for the concept of handling a key press. The closest it comes is clear_press.

Internally I would mark the time when client.key_press is called for a given key. When you call client.key_press again for the same key if the time (the tick count) has increased it returns 0. If the time is the same (meaning its the same cycle) it returns 1 if a key press had occurred. This way you don't need to process the key press immediately, but there's at most one cycle where it does get processed. If you wanted an event to be triggered on multiple cycles you'd check client.key_state instead of client.key_press.
Page: 1 2