I just wrote a new Decker tutorial which walks through three different approaches for implementing the arcade classic Breakout, and along the way touches on a range of considerations for programming action games. Note that this is targeted at an audience that is already somewhat comfortable with programming. Hopefully this will contain some useful information for our more ambitious deckbuilders and lilateers!

http://beyondloom.com/blog/breakout.html

Any follow-up questions? Was there anything you learned, or felt was missing? I'd love to hear your thoughts!

These are some useful examples. My feeling is that the third method feels the most "Decker" in terms of how to do things in that making use of contraptions feels, idk, more "proper" - although this is based more on emotion.

One thing I noticed is, at least on my browser and computer, the blocking example seems to run a lot smoother than the event-driven version - I'm wondering what causes that, since both versions are basically using the same game logic. Is there something about the blocking version or something in decker that would make it more performant?

Comparing with my own attempt at a Decker action game from the last jam, I think my implementation sits somewhere in between the event-driven and contraption methods - I'm using a view handler to move my ship around as well as spawn asteroids, but the objects are all individual canvases, and the asteroids move and detect collision themselves, with an "on view" function added to the asteroid canvas's code. I guess another difference is that I'm not using contraptions as such, just canvases with the occasional bit of code inside them where necessary. But I think making proper contraptions is probably the better option. I think what I've found is that the event driven method isn't necessarily mutually exclusive from using contraptions - like you can combine techniques from both, have some things driven by a global "on view" and some things driven by the contraptions themselves. I think, using my game as an example again, while I could have done the ship and asteroids as a contraption, the spawning of new asteroids would probably still need to be done in the card's "on view"? I think this isn't necessarily something missing though, just sort of a comparison thought I had.

I find myself thinking about performance still, since in my own game I found on some devices things can get a bit laggy when there's lots of items on screen at once. I am wondering if that's intrinsic to the complexity of the problem and Decker's processing capabilities, or whether if I was just running something like the blocking example and essentially just rendering onto a canvas I'd be able to get better performance.

If I attempt an action game again I'll almost certainly use these examples as reference, though!