Dynamic Parameters Update

This version adds important coding features and completely removes those original "hardcoded" towers, but with an elegant solution..

Code and dynamic parameters

Ever since I added the ability to create your own towers by writing custom tower scripts, I wanted to completely remove the original tower, the one whose parameters were set by sliders in the main window. You have probably seen a tooltip message that the old tower is going to be deprecated and only the code-way of making towers will be used in the future. However, I received messages from players, especially kids (and their parents) that fiddling with sliders was actually the most fun part and that I should absolutely not remove it!

Until now, the only way to set code parameters was by editing code. For example, I added parameters to the top of my tower scripts, which I expected people to change and then execute again. But seriously, I doubt anyone even tried to do that... Turns out not a lot of people like writing and messing with code. There was also a fear of accidentally corrupting the script when trying to change values in code-text.

This is what I used to do:

-- parameters:
size = 4
height = 3.6
make_pillars = true
count = 100
-- rest of the code..

This presented a challenge because I wanted to retain the ease and fun of tweaking sliders, but not have a special case tower dangling there on the main window.

Enter a solution to fix both problems: Dynamic Parameters! The code you write can now have parameters which will automatically turn into sliders, fields or buttons!

The only thing you need to do is add a few handles in the code next to parameters. For example:

-- parameters:
size = 4:: int_slider("Size", 1, 30)
height = 3.6:: float_slider("Height", 0.2, 10, 0.2)
make_pillars = true:: toggle("Make Pillars")
count = 100:: int_field("Count")
-- rest of the code..

The double colon - "::" delimits the variables from dynamic parameter descriptors. This is not lua code, but custom syntax. The descriptors are automatically removed and values injected from sliders, fields and toggles upon execution. The process now had to be separated into compilation (when the code is loaded, the dynamic parameters are detected and displayed) and execution (when the values from parameters are replaced, the code is run and tower bricks obtained and spawned).

Now, when you compile the code, you will see this in the main window:

The available dynamic parameters are:

my_int = 0:: int_slider("Label", min, max)
my_float = 0:: float_slider("Label", min, max, step)
my_int = 0.0:: int_field("Label")
my_float = 0.0:: float_field("Label")
my_bool = false:: toggle("Label")

Thanks to this, I have also changed the UI. The towers are now loaded in the main window and parameters can be tweaked, while clicking on "Build!" will spawn towers. If you wish to edit the script, you can only do that now by clicking on the Edit button, which opens the code editor. In that way, the implementation is hidden from view and only the parameters are exposed, there is less chance of accidentally overwriting or corrupting the tower script files. If an error is detected when the code attempts to compile, this error will be displayed in the "Edit" window.

And now, instead of spawning the hardcoded "old" tower when the game starts, the script (that has code that describes a tower identical to the old one) is loaded at start. So, to a normal user updating to a new game version, it would seem like nothing has changed. The only disadvantage of deprecation of the old tower is that its spawning is a bit slower because the "new" tower needs to be executed from the lua code and the count of bricks is also no longer shown "live" as it is not possible to predict the count until the tower actually spawns.

Note that towers written before this update are still compatible, but will have no tweakable parameters, of course.

Resolution window timer

A complaint from a player made me realize I made a critical mistake where it was ridiculously easy to accidentally switch to an ultra low resolution (like 320x200), and which resulted in the resolution screen being out of screen bounds and hence it was not possible to revert to a normal resolution. The only way to change the resolution in that case was to dig through the Windows registry values. Now, I've added a 10 second "accept changes" prompt to the resolution window to avoid this problem. Additionally, the windows are now clamped to the screen edges so that they never appear outside of the bounds on resolution change.

Updated package versions

Burst compiler, Unity DOTS Physics, and Havok packages have also been updated to latest available versions which should provide a performance boost.