NOTE: This engine has not been developed to a usable state, but you can help if you want to. Stay tuned!
My biggest personal hurdle to writing pretty projects that I can work on it routinely without losing motivation is UI. Unfortunately, boredom also applies to this UI engine I am trying to work on. If you have devised any ideas, fear sharing not.
I would recommend using sprites for UI elements. You can clone the turtle sprite, change its scripts with “my scripts” (so you can add interaction) and set that as a variable (or in a list). Then, just clone THAT sprite for each new UI element. Snap! already provides a couple sprite features you can use for this (anchoring, parenting, etc) that’ll help. I might make a mockup when I get home.
Yes, I was considering that. I just need to draw the costumes of the sprites first, using the write () size () block because the EDC library does not like emojis for some reason.
Oh, yeah! Canvas API by owlsss | Snap! Build Your Own Blocks
Fair warning: The code is held up by duct-tape and is mostly written in smoke and mirrors.
I tried to make this recreation as faithful as possible to the original. I don’t really see a real or practical use for this; I just did it because I wanted to see if I could. It’s not really finished or in a state that I’m incredibly satisfied with, but it’s a working proof-of-concept nonetheless.
It could be because the “set __ to __“ block has video capture as it’s default option. If this is the case then please fix the issue, because it is kind of out of place for a UI engine block to turn on your camera.
I also plan on making this engine highly customizable. There will be progressively more and more advanced options in the future if there interest in developing this persists stably, like menu textures.
$gears set UI setting [dialogBGColor V] to (color [rgb(220,220,220)])::rgb(78,132,149)
It is evident that it is not finished. All it does for menus at the moment is determining the menu width, and for dialogs is still to be worked on.
How does an object input intervene with it working? I chose Object because these lists of two-items are also called “objects” (see the OOP library), rather than List to clarify that the user should not drop a manually crafted list in there.
I know Object has other uses too like sprites or media, but which to pass as an input for Object should be common sense.
I have mixed angles about this. I am more used to declaring this many variables though.
go to (pos)
set size to (size ::variables) %
point in direction (dir)
switch costume to (cst)
is more readable than
set x to (item (1 v) of (stats))
set y to (item (2 v) of (stats))
set size to (item (3 v) of (stats))%
point in direction (item (4 v) of (stats))
switch to costume (item (5 v) of (stats))
