Input Design

The idea of treating fixed animationes and input the same is good.

Passing events through the entire scenegraph ("hello - you interested in this event? No? Maybe your children?) is pretty overheady.

You might create some kind of shortcuts from the objects to be controled to your input interpreter. ("hello interpreter, I''m the new ball in the system - would you send Move-Events straight to me, please")

I rather prefer the not Event-driven approach: Go through the entire scene graph, drawing what''s needed and if neccesary ask the Interpreter if there were any Messages for me since I last asked.

---------------------------
I may be getting older, but I refuse to grow up

Yeah, I think that I will implement the events in queue, one for each target and then when it is time for an update to poll for any messages. Although this could cause quite a memory overhead if there are a lot of targets. ANy ideas on implementing this? stl::map > a good idea?

What do you think to timestamping each message? I suppose when it comes to network programming this will become important since events will be arriving async with respect to the game loop. This way the timestamp will be used in determining whether the message is worth processing i.e. if there is a newer message with an actual position in it, then there is no point in processing a move event that occured earlier. Perhaps the Interpreter could be running in a seperate thread to check for these conditions, or even as the messages arrive, discard any that are superseeded by the new message.

James