In the past I''ve always done stuff like this:

if(hitting right arrow)
  player.x++;

if(hitting down arrow)
  player.y++;

 

This works, but it is very sloppy and inflexible. What are some good ways to separate game input from game logic?

I''m not exactly sure where to start(that''s a BIG question), but I do have some comments about your specific example..

The player should be a seperate entity..

there should be a basic messaging system for the entities, such as move_left, jump, etc..

when you hit the keys, you should send the message to the player entity telling it what to do:

if(hitting right arrow)
SendMessage(player, "move right");
if(hitting down arrow)
SendMessage(player, "move down");

You could send messages to any entity from anywhere in the code, so you could record sequences and play them back..

In this way, control of the player(or anything else) is not directly tied to the input code..the keystroke simply sends a message, the player entity doesn''t care where the message came from, it will simply respond to the message..

"Like all good things, it starts with a monkey.."

So far the only suggestions have been basically the same thing you gave as an example. Instead you could have an event system for the input engine. An event listener could register itself with the input engine, and then when the key is pressed, the input engine sends an event to all the listeners that have registered to recieve that event. Or you could do a more passive system in which an entity checks for input on its own, rather than putting all the checking in the main function.

It would do well to bind the input system to commands. In other words, make the keys generate console commands.

From there, it''s the standard command interpreter stuff.

Please don''t start asking about performance. This is a thread about flexibility.

My engine works a lot like what Dog_Food suggested. This is how you get a function to be called when the left mouse key is pressed (in my engine, just to show you the style of how I chose to do it):

rID ID; /* ID for later deletion of this event if needed */rVoid MyLeftDownFunc(rVoid *Data) {  /* Left mouse key was pressed, data happens to be a     pointer to a coordinate in this case. */}rEventAdd(RI_EVENT_LEFTDOWN, MyLeftDownFunc, &ID); 

I have a lower level structure called rTrigger which has a linked list inside of it. When you call rTrigThrow(&ATrigger,SomeData) it calls all of the functions in the list with the data supplied. The event functions are just refering to internally stored triggers. Whenever an event occurs it throws the trigger for that event. Triggers (or whatever you choose to call them) can also be used for a lot of other game related code, so they''re pretty useful .

[Resist Windows XP''s Invasive Production Activation Technology!]

hahahah what a supid idea!! - SendMessage
HELLLLLOOOOWWWWWWW you are programming a GAME not an application

one of the main goals in game is to do everything you can in the fastest way!

and using SendMessage and then switch or if statements to know what kind of message that was... is just f#@$king slow!

-----
or maybe i didn''t get your idea well,did i?

Arkon
[QSoft Systems]

quote:

---

Original post by Arkon
hahahah what a supid idea!! - SendMessage
HELLLLLOOOOWWWWWWW you are programming a GAME not an application

one of the main goals in game is to do everything you can in the fastest way!

and using SendMessage and then switch or if statements to know what kind of message that was... is just f#@$king slow!

-----
or maybe i didn''t get your idea well,did i?

Arkon
[QSoft Systems]

---

Your old-school attitude to game development does not befit being spread.

hm, if you dont want to use messages and are just trying to seperate them, you can use some kind of input structure.

if it''s a simple game using a simple char might work with each bit meaning an action (l,r,u,o,fire...). when a button is pressed you just set the corresponding bit. later on you handle those bits and by now it doesnt matter if it was set by player-input, ai-decisions or a playback function (for that you should find a way to get the timing right too).

if you''re using more than that you can use a struct with all the actions being member variables. especially if you''re using a joystick you can use a ints or floats instead of bools. so this approach might use a lot of memory if you have a lot of objects.

so i dont think the messages are a bad idea at all. if you''re game is more complex than pong or pacman you will probably need something like that for ai anyway.

f@dz
http://festini.device-zero.de

this is one of the most difficult things I ran into when started on game development, but with a little of experience, and after reading some books and others game code I found very usefull doing this:


first you have to make your character (or whatever you''re moving with the keyboard) work as a State Machine, where it can take different states like MOVING_LEFT, MOVING_DOWN, TRANSFORMING_INTO_SUPERSAYAJIN_3, or whatever...

then, when yo detect the player is hitting a key (e.g. right arrow) you change your character''s state into MOVING_RIGHT:

 // other player input codeif( right arrow down )  goku.state( MOVING_RIGHT );  // more player input code 

and in the "goku" internals whould go simething like this:

// "goku" is an object from class "character"Character::state( int s ){  state = s;} 

and in the logic section of your game you do all the stuff:

goku.play(); 

and into the internals of "goku" would go something like:

Character::play(){  switch( state ){    case MOVING_RIGHT:      x++;      // if you whant to have any animation you would have a      // counter here to keep track of the time or frames has      // since the animation started, so you can stop it when is      // needed   }}gottit ?intresting way of doing things huh?jakovo    

State machines are a good idea, but I would go further and implement properties (that''s right, "properties") for each object as in Dark/the unreleased Siege. I''m confident that at LG the "state machine" was simply the momentum/velocity/physics data. There was no "switch" statement. On each iteration of the loop, the physics system would calculate the time difference between the previous iteraiton and the current iteration, and then move objects accordingly. If you happened to hit a wall in that time period, I think the collision system would detect that because the loop that moves you one velocity unit would halt if you hit a wall, and post a collision on the event queue.

I hope that didn''t go way over your head.