Actions

From AlephWiki

Handling User Actions

Return to History

Ben Thompson

In this effort, I am simply trying to pave the way for many new capabilities by making a more intuitive, object oriented way of receiving input for various sources and providing it directly to the game engine.

I don't mean to get off on a rant here (Dennis Miller quote)...

What exactly would you consider overdoing it? Do you mean, you are happy with the constraints of a single 32 bit ( could be wrong, haven't looked at it in a while) piece of memory which contains the all of the users actions (each frame)... The same piece of memory which causes network desyncronization because a single instance of this input is lost across the network. You're happy being limited to hacking away at the engine to produce fake mac os events to achieve the things that you want?

I see many faults and limitations to what is and has been present since 1995. Why do we continue to beat around the bush while something as important as "how the users actions are handled" is left un-addressed (with exception to a few significant improvements). What I see here is an opportunity to give the scripting and xml languages something to build upon by building an event based system in which you could add new actions or capabilities to the game through a couple lines of scripting and then bind it to a key on the keyboard. Even something as simple as "jumping" could be scripted and bound to a key.

Imagine making it so that you could script a rocket or grenade jumping by pressing a single key. Does anybody else see the same possibilities that I see? I have heard Loren's side of this a year ago. As he mentioned, I had proposed this before but had too much other work on my hands (http://www.vrjuggler.org and http://www.vrac.iastate.edu, both I was closely associated with for about 1 1/2 years; and, of course, classes) to address it myself. I would like to hear from some more of you guys (and gals).

I am starting to think that the keyboard features of InputSprockets are too limited for the complexities of what we are currently doing and can be doing in the game. It might be wise to pull this functionality out in the future. I understand pretty well how ISp works, and it doesn't seem like a very good way of addressing a dynamic input system (one which I can envision the A1 project taking in the future). I think InputSprockets should be left with the mouse. The other option might be to address ISp at a lower level and configure it manually without the standard dialog. This may be too complex for what it would really offer us.

I also have a few thoughts regarding network desync prevention and then resync. However, it would require timestamps and dynamic event history. If anybody is interested, give me a ring, I would be happy to share with you. All of you programmers out there, if you haven't already yet, there is a good article at www.gamasutra.com about predictable game behavior. Very interested topic which touches on some of the things I feel we are lacking.