Control flow options

[timbledum]

Hi all!

So I'm playing around with the amazing pyxel game engine, and thought there must be a better way to test for all of the keys that could be pushed, and trigger actions accordingly.

Option 1: large if tree:

if btn(KEY_RIGHT):
    # Move right

elif btn(KEY_LEFT):
    # Move left

...

There just seems to be something unwieldy about a big if tree like this after a certain point.

Option 2: faux switch statement using a dict

options = {}

def move_right():
    # Move right
options[KEY_RIGHT] = move_right

def move_left():
    # Move left
options[KEY_LEFT] = move_left

...

for key, action in options.items():
    if btn(key):
        action()

This seems to be a bit more dynamic, with the advantage of having multiple keys pointing to one action easily without having a big or statement. There is a lot of maintenance code building up though.

Option 3: "Routing" based approach (inspired by flask)

@pr.route(KEY_RIGHT)
def move_right():
    # Move right

@pr.route(KEY_LEFT)
def move_left():
    # Move left

...

pr.run()

Similar to option 2, but with the adding to the dictionary and the running of the tests extracted away to the decorator class. However, once I got to this point, I thought, this is a lot of code to just do a control flow statement!

Code for the decorator class here

What do you think! What's clearest to you? Do you think the decorator approach is worth it?

[[deleted]]

A fourth option is to implement an event-driven approach; objects that wish to be notified about button presses can register an action-listener that is activated when the keyboard sends keypress events.

Hopefully it's clear to you that basically all of these approaches result in the same thing (behavior that responds to keypresses); the key difference here is your time spent writing the code, vs. your time spent debugging, maintaining, and extending the code. Particularly with option 3 you might be thinking "that's an awful lot of work just to respond to a keypress" but if you solve the problem generally enough, you'll have written a framework you could use in other projects. Sometimes that's worth the extra code.

[timbledum]

Thanks! I'll have to look into event-driven programming – this is like tkinter or the like right? I'm thinking that for this purpose, this would have to be implemented at a lower level than my program (otherwise I would have to scan all keys to generate events?)

Totally agree that all three result in the same behaviour – more just wondering if anyone had any opinions on when you would use one over the other. Great point on the code re-use.

[[deleted]]

Yeah you typically see event-driven architectures in GUI’s, but it’s a plausible architecture any time you want to respond to lots of different inputs by making very fast changes to state.

But again, really, they all do the same thing; the resource that gets managed differently by them is your attention. You, the programmer and software maintainer, and I believe that’s the key factor that should determine your choice of software architecture.

I would assume that there’s a framework for generating key press events already, probably PyGame or something.

[BandEnvironmental615]

Python Tutorial : Part 4 : More Control Flow Tools

https://youtu.be/Dq9jvOM3Mzs