A Proposal for Beckett Tickables
I'd like people's opinion on this.
Tickable objects have no inherent logic on their own. They have a list of children and can be updated or drawn. Updating a bare Tickable runs through any children and updates them, same with drawing. If your scene is only bare Tickables, nothing seems to happen. To make a Tickable that does things, you must subclass it into for example a Sprite or PanelLayout.
The Beckett demo/test application has Buttons that take lambda functions to execute when clicked, using them to switch between scenes. Keep this use-case in mind for a bit.
Beckett Tickables are basically Godot Nodes.
Here’s the title screen node setup from the old shmup project I used to learn a bit of Godot:
(Using an image because Tumblr doesn't like nested lists.)
The Node2D has a script attached that has the following event handling functions:
_on_animation_finished(string animName)
Simple stuff. The Button and AnimationPlayer have signal slots or whatever they're called set up to call the latter two.
Give every Tickable an optional script file reference. On update, don’t just recurse through the children but also, if there is a script with a tick function defined, call that. No real need right now to consider drawing.
Give every Tickable a bag of arbitrary properties so that for example every button in the test application’s scene switcher can share the same script but still tell which scene to switch to.
One idea I originally had for Project Special K specifically can be generalized here: when loading the script, generate a unique identifier (it’s allowed to change between runs) and assign that to the Tickable. In the global Lua state, have a table with that unique ID for a name and make all the functions defined in the script members of that table. When calling a function, the this argument points to the current object’s table.
(Using an image because the closest thing to monospace Tumblr has to offer has its own rules regarding colons.)
Leaving out how these buttons would be captioned and positioned, they’d otherwise be perfectly identical if not for the data-tag keys, but clicking them would show the difference in the log.
Less need to write subclasses in C++ and recompile whenever more specific behaviors need tweaking. Instead you just change the relevant Lua file.
In the above example, the script file is processed three times over and the click function  is defined in three separate tables (which each connect to the buttons). This is the kind of stuff that Godot has those slot connections for.
... So what do you all think?
