How should keypoll functions be designed in games?

Question

So I'm making a clone of Super Mario Bros in pygame. As of now I am in the middle of making my keypoll function, to check all the keys that are currently being pressed. I am wondering which would be better:

1. Have the keypoll function modify marios attributes (ex. horizontal direction), then based on those, have mario decide which action he should be doing (ie. walk, run, jump, etc.) and call the function cooresponding to that action (ex. mario.moveHorz())

   OR

2. Have the keypoll function call the function of the action he should be doing, and then the mario instance would decide what state he is currently in.

Here is some semi-pseudo code for the first one:

def doAction():
    if mario.horzDir == 'r' or 'l':
        mario.moveHorz()
    elif mario.action == 'jump':
        mario.jump()

 def keyPoll(keys):
    if keys[K_RIGHT]:
        mario.horzDir = 'r'
    elif keys[K_LEFT]:
        mario.horzDir = 'l'
    if keys[K_z]:
        mario.action = 'jump'

Here is some more semi-pseudo code for the second one:

def keyPoll(keys):
    if keys[K_RIGHT]:
        mario.moveHorz('r')
    elif keys[K_LEFT]:
        mario.moveHorz('l')
    if keys[K_z]:
        mario.jump()

def setProperties():
    if mario.x_vel > 0:
        mario.horzDir = 'r'
    elif mario.x_vel < 0:
        mario.horzDir = 'l'
    elif mario.y > ground:
        mario.action  = 'jump'

Both essentially accomplish the same thing, I just don't know which one is more correct.

Thanks!

Answer 1

Because key polling usually happens at the very top of the game loop, the specific question you're asking is hard to separate completely from all the other extremely important issues one needs to be aware of when designing a game loop (Gilbert's comment appears to be referring to some of them). To get those out of the way, I'll simply suggest you read this: http://gameprogrammingpatterns.com/game-loop.html Now to answer your specific question.

It is better for your keypoll function to call mario methods than to set mario properties, mainly because all of these commands are going to have at least one or two extra steps beyond setting a field on the object. mario may have an internal state machine that keeps track of whether jumping or changing direction is even allowed in its current state. It may be keeping track of how many times it's been told to move right or left in the past several frames so it can speed up or slow down gradually. It may have yet more state to help it work out when you've done the inputs for various special combo moves. keyPoll() shouldn't have to know about any of that.

By setting a field and then calling a method to do all of this work, you're essentially doing in two steps what you could be doing with one step. That's usually not a good thing. Yes, it's likely that mario will have an update() or render() method to get called later on, but those should be completely separate from the methods for handling input.

Now, whether this is the best option depends on how complex your game is, but for most games, it's better to go even farther, and not have your keyPoll() function directly refer to mario at all. In principle, the only thing keyPoll() needs to do is check the state of the keyboard, and output zero or more objects that represent commands. If you ever want to support key rebinding or multiple control schemes, that logic would go in keyPoll(). Then the main loop gives these commands to whatever entity the player is currently controlling, presumably mario. By decoupling the input handling from the specific game entity, you make it easy to add new abilities to mario or support key rebinding or allow switching between multiple characters or add AI/demo characters and other cool stuff without having to worry about both the internals of keyPoll() and the internals of mario at the same time.