I was hoping to get something more from this post. It didn't really lean in on any direction.
Was there a major stumble because of JavaScript? Something surprising?
How was building the controls or getting the frame rate right without use of a js framework like kontrajs or phaser?
Or How was the mobile experience? How did your kids like it?
Great questions and feedback! Thank you! Is it OK if I use them to augment my article?
Please find below my reaction. I may work this into the article some time this week.
Yes, there is a major stumbling block due to Javascript: it doesn't multithread well. One can use asynchronous programming (either with or without promises) or, as I did in that implementation, use time-outs. But none of that is very nice or elegant when it comes to continuing to process the game while accepting user input. They are a far cry from actually starting a separate processing thread, which is possible in other programming languages. Those can be used now that browsers started supporting WASM. Unfortunately WASM cannot interact with the DOM, meaning it won't help for GUI-intensive games.
Getting the frame rate right was a bit tricky. It depends on the time-outs set for refreshing the screen and moving the tetronimos. As the game speeds up, those time-outs get smaller and shorter. Lacking a frame-rate framework my program has to keep track of it and control it. That required some additional architectures that probably are handled better by phaser.
The mobile experience is interesting at times. I had built the GUI specifically with mobile devices in mind: tablets and smart phones of various sizes should be able to play the game without much of a problem. That's why the game buttons are positioned on the sides of the grid: within reach of the sides of the mobile device, to be operated by thumbs. And that's why there's 2 sudden drop buttons: one on each side.
One of the features of smartphones is to zoom in and out on double-tap, but since this game relies on fast tapping I had to build in a way to avoid that causing unexpected zooms. Another feature is scrolling in response to sliding ones fingers across the screen. With fast button pressing and switching, chances are some motions get misinterpreted as slides / swipes. Thus I had to disable that specifically. That can be a bit awkward when someone attempts to scroll the game display intentionally. I have not yet figured out how to work around that. Maybe I can add more room on the sides.
Over time more differing screen form factors appeared, and some phones (like the one I use today) differ so much from what I had available in 2014, that it makes game-play slightly more difficult. They make it so the game has to be zoomed out more than is comfortable for the button size. That has to be large enough for thumbs, and zooming out the entire game makes them too small. I can work around this by making the width the tetronimo grid a function of the available screen width.
The game is completely unplayable on smartwatch. It would need a separate form factor altogether.
My kids liked it just fine. Their biggest complaints were that the tetronimo blocks didn't move as soon as they pressed the move buttons, and that the game didn't have a soft drop option, like found in other Tetris clones. To this day they enjoy playing Tetris... even if it isn't the clone I built.
Again, thank you so much!