Advertisement

Input interpretation, or "Do what I mean, dammit!"

Started by March 16, 2002 08:13 AM
17 comments, last by Oluseyi 22 years, 9 months ago
quote: InnocuousFox
This I like! And all it would have to do is be linked to a particular state.

Precisely. It''s so simple I''m amazed it hasn''t shown up in games yet (most of my ideas show up within a year a two, in keeping with the "great minds think alike" maxim - which makes me feel good since it means I have a great mind, right? )

Say we have a state register (and I apologize to all the pure designers to be delving this far into implementation specifics here) - 32-bits should do. This defines 32 independent binary conditions. Various combinations of these conditions result in our available states - integer values. Plug the state register as an index into a table of sort (array of function pointers, switch statement, which ever is most appropriate) and, well, this may shock you but, we''re done.

  // This example employs 4 states from a 2D Mario clone// declare some state indicesconst int state_alive    = 1; // are we aliveconst int state_fireball = 2; // do we have the fireballconst int state_feather  = 4; // do we have the featherconst int state_BFG      = 8; // do we have the BFG. I know....long player_state = 0;.inline void SetState(int state){  (player_state & state) |= 1;}inline void ClearState(int state){  (player_state & state) &= 0;}.void main_loop(){  if( /* we pick up the fireball */ )    SetState(state_fireball);  if( ?8 we get hit and _lose_ the fireball */ )    ClearState(state_fireball);  ...  if( /* we get hit and game over */ )    ClearState(state_alive);  ...  // eval states and determine action map  switch(player_state)  {  case 2:  case 4:  case 6:  case 8:  case 10:  case 12:  case 14:    // we''re dead. state_alive not set. game over    game_over = true;    return 0;  case 1:    // we''re alive but have nothing    break;  case 3:    // we have fire! (but nothing else)    ActionMap[button_1] = Fire;  // ActionMap is an array of function pointers    break;  case 5:    // gentlemen, we have the lift off!    ActionMap[button_2] = Fly;    break;  case 7:    // Aha! we have fire and flight    ActionMap[button_1] = FlyingFire; // interaction of states    break;  // etc...  }}  

Okay, so it''s a corny and simplistic example, but hopefully it communicates ideas on how easy this is to implement.

quote: Let''s work this one a bit. (You ARE going to the GDC, aren''t you?)

Unfortunately, not this year. I had planned to since last year, but my finances recently took a plunge. Next year, no doubt, and maybe some other conventions later in the year if I can return to relative affluence quickly enough.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
quote: Original post by Oluseyi

A related concept: action maps. Now many of you may have heard of DirectInput's action mapping (for the Window's developers out there), but I'm not speaking about the same thing. To me, an action map is the definition of all buttons for a particular character state. Sports games generally have offense/defense action maps, but I think utilizing deeper maps than this can also bolster "input expressiveness". Staying with the genre, if (some of) my buttons remapped when my character jumped so I could do more, different things while in the air, then I'd instantly have a deeper game. For one thing, I could possibly be able to control exactly what a player does when trying to dunk - something I have never seen in a ball game. Think about it. When I jump, my velocity is set and I have no tractional anchors with which to change direction and/or speed, so why not have my move forward/move left/move backward/move right buttons/triggers switch to raise ball/twist left/lower ball/twist right? Hit a twist trigger with the turbo, tap lower and raise - bam! 180-/360-degree double pump. Okay, so maybe not exactly with those buttons, but you get the idea.


That's a great idea. Maybe make one button an "Alter shot" button. How many times have you gone up for a shot or dunk in a basketball (video) game and realized instantly that you were going to get stuffed? Wouldn't it be nice if you could alter your shot just like in real life? I almost never get stuffed in real life- I put up some ugly bricks, but I never get stuffed.
There could also be a dribbling state to let you do better crossovers.
e.g.
press x to enter crossover mode and x again to exit. (while not in crossover mode you could just press a or something to do a generic cross)

In crossover mode:
4 (keypad) switches to left
5 to right
7 goes to left through legs
3 goes to left behind back
etc.
You could hold a button to palm it (get called for a violation if you hold for too long) and then quickly tap the other way.

That would be awesome.

I've read a lot of your posts and your game sounds great. If you ever want to bounce ideas off someone send me an email- ewiar@softhome.net . I know a lot about basketball and a little about game design and programming.

[edited by - ewiar on March 16, 2002 9:42:33 PM]

[edited by - ewiar on March 16, 2002 9:43:39 PM]
Advertisement
quote: ewiar
That''s a great idea. Maybe make one button an "Alter shot" button. How many times have you gone up for a shot or dunk in a basketball (video) game and realized instantly that you were going to get stuffed? Wouldn''t it be nice if you could alter your shot just like in real life? I almost never get stuffed in real life- I put up some ugly bricks, but I never get stuffed.

I''ll do you one better. In such a situation, you can only either alter your shot or pass out. Tapping shot again along with other modifiers (twist, pump, etc) should automatically alter the shot. The key is maintaining a balance between expressiveness and simplicity. I mean, the gamer only has 10 fingers...

quote: There could also be a dribbling state to let you do better crossovers.

Interesing ideas. One thing though, design with console sensibilities. If you don''t already have one, go buy a Gravis Gamepad Pro (if you have a PlayStation, though, don''t bother; it''s virtually identical sans the analog sticks). With those ten buttons only and with that ergonomic layout, rework your crossover idea. ''X'' is quite far from the numerical keypad, and I never play games with my keyboard (with the exception of the rare FPS game).

Here''s mine (and this should really be either another thread or private email):
Just like the "Direct Pass" and "Direct Shoot" modifiers, have a "Crossover" modifier (the current button works). Tapped alone, it executes a simple side-to-side crossover, no frills. Held, it allows you to select from 7 "basic" crossovers (the other seven buttons), modified by whichever direction you press. An alternative scheme interprets crossovers and other movements as Tekken-style combo sequences, which would be the logical interpretation of performing the basic crossovers in a sequence (basic_cross, spin, cross_through_legs, shake, shake, shutter, ball_fake, turbo).

quote: ewiar
I''ve read a lot of your posts and your game sounds great. If you ever want to bounce ideas off someone send me an email- ewiar@softhome.net. I know a lot about basketball and a little about game design and programming.

I got your email (and will be replying shortly). The game is still in very early stages - I have a functioning input system and I''m working on AI next, but I might have to bump graphics priority up just so I can have inspiration (and something to show off to my friends). I''m postponing detailed design until I have the technology in place, to make sure the game actually comes to fruition. For example, I want the game to be scriptable and moddable...

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
quote: Original post by Oluseyi
[
Interesing ideas. One thing though, design with console sensibilities.


Oh, ok. I didn''t know what you were designing for.
quote: Original post by ewiar
Oh, ok. I didn''t know what you were designing for.

It''s not for console. The idea is to design it as though it were, because console games tend to have simpler interfaces and more compact controls. When you''re thinking of a 102-key keyboard instead of a 10-button gamepad (with certain combinations precluded due to awkwardness), then you make very lax design decisions and compromise your own game. Design with PC depth but console simplicity. The result is always more robust.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
Action maps - this sounds like a job for UML State Diagrams! It may not exactly be what they were designed for, but if the shoe fits, wear it. Especially if it''s a well-documented and standardised shoe. The only problem is that it doesn''t map (no pun intended) well to concurrent states (as represented by bitfields).



If I had a decent UML tool I could show sub-states within the jumping states, allowing for the special moves Oluseyi mentioned. Something like this is clear enough for both programmers and designers, I think.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
Advertisement
Excellent diagram, Kylotan. That gives a clear yet expressive description of what is meant, and allow for deeper control. Now the piece de resistance is allowing the user to set up the action maps, and having a default handler - AUTO - for any mappings the user doesn''t want responsibility for, but wants handled. That way, you can have an extremely detailed control scheme that scales to the preferences of the user in terms of complexity. Users who prefer simple controls will have little details automatically taken care of (if set to AUTO) or ignored (if set to OFF).

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
Ah, yess, I had forgotten about the most crucial piece (for the type of game I''m musing/developing). You can have a different action map per avatar.

Take soccer, where you have eleven guys running around a grassy field after an inflatable leather bladder. Different players play different positions, and as such different skills might be more important for them. Same with any other team sport. Memory overhead? Minimal. Say you had 64 possible actions in your map, each indexed by a function pointer. That''s 64 times the system words size, times the number of avatars (which is 2816 bytes for a soccer game on Win32). Runtime overhead? A couple of array accesses and a pointer dereference. Gotta love it. I think I''ll pursue this further in Game Programming...

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
Sorry if it''s been mentioned, but I gotta get some sleep so I
didn''t read everything,

(This is all assuming that one button for blocking == cheesy
and stupid and completely unrealistic.)
I think some other genres like action, adventure, combat, and
fighting could benefit as well from this discussion.
Some martial arts games do well, I want to say Bushido Blade
but it''s been so long I can''t remember.

Mech combat p***es me off too, Zone of the Enders did better
than Omega Boost but both of them faked it, all you had to do
was lock onto an enemy and you could maneuver fantastically,
but only relative to the enemy position. From review there
was a robotech game that did well but I haven''t played it or
the new Gundam games on PS2.

I know Oluseyi said ''action'' games but the discussion seemed so
oriented to sports I thought I''d add a couple of cents.

Until there comes better input devices...

This topic is closed to new replies.

Advertisement