If I'm getting it right, I think the comparison is a bit wrong.

There's event-driven software (like Word and such productivity software), where the program waits for your input, elaborate a response on that input and then waits again (for another input) and time-driven software (like games) where the program keeps elaborating data and some extra elaboration if you enter inputs.

So, in the first place noting happens if you don't do anything, while in the latter events do happen and your opportunity is to change their destiny.

Alternatively, you can compare instant-taken input versus buffered input.

In the first case you read the input and elaborate (almost) immediately that just-read data; the point is that if there are multiple inputs arriving subsequently you just read the one which arrives when you issue a read instruction (so if the user presses 'a' five times and your program has an instruction 'read_a()' the data will be read only if the user presses that key when the instruction is executed, losing all the other keypresses).

In the second case you store somewhere the inputs and process them in the order they arrived, no matter what the user actually is entering at a certain time. In this option you do not loose any input.

In my opinion, buffered input goes well with event-driven software, where the application works 'ignoring' the time. When comes to time-driven software, instant-taken input is the only option, because the user makes keypresses reacting to what it sees on screen, which directly depends on the time of execution.

So if your software takes too much time elaborating on a keypress and you're buffering the other keypresses, the user will keep entering input while not seeing a direct change in what is on screen.

This happened in, IIRC, some FIFA games in the last years, where while playing I pressed the 'pass' button while the character didn't control the ball, then, after one or two seconds he got the ball. In this second time my intention is almost surely changed due to the new situation (an enemy being closer than before) so I probably want to make a different move, but, because the game was buffering my input, no matter if I wanted to change direction, my character passed the ball.

I hope I got the point

After my previous post, I think that's not a proper question.
Please reformulate

I agree that it is personal choice. But beyond your observations, having an event driven messaging system at the core of your app can also decrease code complexity. For example, if you can receive application quit requests and attach a timer to your event queue for properly timed CPU reducing sleep then you've probably saved complexity over a pure polled method. You've also probably increased the amount of time you can sleep for.

It also depends what you want to do with your input. Supposing you have a move that is triggered by a double tap (e.g. running in Golden Axe or Streets of Rage), then if you had time stamped events coming in the implementation of that would be comparitively trivial. Ditto if you want to do something that requires sequences of keystrokes with well defined timings (e.g. Street Fighter 2 or any of the 1,000,000 other games like that). You also obviously simplify the task of detecting changes in state rather than just current state, which is useful for some games (e.g. steering out of a spin in Road Fighter).

Conversely, if you just want an Allegro-style key array then you've obviously complicated things. Not by much, but you could say the same about simulating an event driven input system with only a state array.

If I were designing a brand new cross-platform game API, I would probably go for events with timestamps because the reality of implementation on most modern OSs is that many input devices are event based and the timestamp information is easy to collate with a thread that just perpetually waits on new input then reformats the OS specific messages into the platform neutral form. Timestamps are inevitably artificial for devices that are inherently polling based (e.g. analogue joysticks), but without an event based input queue there is no way to keep the timestamp information where it can be determined reasonably well.

I believe new-API Allegro features a proper input queue as well as a simple state query interface. SDL already does the same. Alas I don't think either have timestamping.

As I agree with everything they said about event driven, it really does require your code to be structure differently. That is you have to put more thought into the structure when using event driven. Obviously these events are changing some data. So that means they need access to this data to change. The same event could mean many different things based on what state your game is in. So you have to take that into consideration. So unless you make everything global, and have a bunch of switch statements on the game state in each event method, it requires some solid structure.

Unless I'm missing something, either you add the complexity of how to structure your code upfront when using event driven, or you get it inside your code, when not.

There is a reason they have locking mechanisms in threaded enviroments, you know... Lock the resource while you are using it and unlock it when you are done if anyone else can use the selected resource. This way, only one person can alter a given item at a time (which, in effect, reduces your program to a single threaded application temporarily (sorta)). This prevents someone else coming along and giving you an inconsistant state, because for the time being you are the only thing allowed to even interact with a particular chunk of data.

I know, but I thought we were talking about making coding easier...

I see it, but I still think that that would add some 'false' separation from the actual user input (what he wants to do depending on what he sees on screen) and the data actually processed, won't it?

This thinking about processing an event at each frame, or are we talking about emptying the whole queue before proceeding to the next frame?

But how to determine if there's no more input? I do see, though, that the speed of input is far less than the speed of processing...

Well, after all looks like event-driven is better than polling...

What I was thinking was what if the player keeps pressing keys...

Anyway, it's all clearer now

I do not know if it has been said, but event-driven input comes in two flavors: blocking and non-blocking. In games, non-blocking event-driven input is better, since the code to check for keys pressed, mouse clicks etc is intergrated with the update loop. In apps that there is no update loop, the program should block while there is no event, in order to decrease the CPU load.

In any case, event-driven input is better than polling, because with polling one might loose critical events. For example, If I press up and release it almost instantly and my character does not go up, users of my game will complain.