Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Lil is not intended as a flavor of xTalk; it is its own programming language. As I note in the language manual  it is primarily influenced by Lua and Q. I feel that a small, expressive language is easier to learn than a large, verbose language with a great deal of case-specific syntactic sugar, and that a functional, expression-oriented structure is more flexible than a statement-oriented structure.

Decker has a number of intentional limitations which I feel produce interesting creative constraints, which give it a unique texture and flavor, and which in some cases aid in providing pixel-perfect cross-platform consistency. I have written rationale for some of these design decisions here.

Decker does support color images; it uses a configurable 16-color palette. This thread details how to import color images. There are a wide variety of ways a user might wish to adapt a particular image to a 16-color palette, so in the interest of simplicity I make no attempt at an exhaustive suite of knobs and buttons. Web-Decker embeds the entire editing environment into freestanding, self-executing documents, and every feature must be carefully weighed against its cost in the form of that runtime stub's size. For the same reason, Decker avoids reliance on  external libraries wherever possible; even if a third-party C library might be helpful in some situation it would invariably need to be ported to and maintained as JS as well (or vice versa).

As you observe, it is currently possible to generate and play sound on the fly, so an enterprising user could indeed furnish something resembling HyperTalk's "music notation" as a Lil module. See also Millie's JankyTunes contraption and other musical experiments. A built-in sequenced music playback mechanism based on a subset of the Amiga Module format is planned for the future.

I do not wish to have any involvement with LLM-based technology.

(2 edits)

Thanks for the fast and thorough response.
Never heard of Q lang (will look into it), but I've spent some time with Lua and that's pretty OK.
While 'Lil' may not be intended to be xTalk-like lang it comes close to reading like one... maybe that's an unavoidable consequence of implementing an HC-like event driven environment?  Its close enough for me and  has the Deck(Stack)/Card metaphor. I like it.  It seem\ to have at least a subset of xTalk, but it also has list and dictionary data types,  custom control widgets / contraptions, and more modern features, so that's super useful!

xTalk has the transient 'It' variable and 'The' (which is largely ignored by interpreter) which can go a long way towards making scripts read more like a natural language sentence. Being English like helps English speaking people, even very young people, learn the language fast,  I know some ECL educators that will swear that xTalk is the best thing for teaching basic concepts. It is certainly what got me hooked as a kid. I also have a theory that straight readability reduces the need for as many code comments. HyperCard 2.0 had some JIT precompiling that helped speed things up, but these days it seems CPUs are fast enough to handle any extra bit of interpretation without much slowdown. 

" C library might be helpful in some situation it would invariably need to be ported to and maintained as JS as well (or vice versa)"
There is the possibility of there being already ported / WASM compiled, small versions of various libraries (ImageMagick for example), but I do understand that you want/need to keep its engine small and as self-contained as possible. But then it also seems a bit pointless to maintain a Desktop app/exe versions at all, since it is still subjected to the same limitations as running sandboxed in a browser.

I think you should at least consider using 'native' file APIs for file stuff. It seems like more work to implement a System 6 file dialog from scratch then to just call out to the OS or HTML5 api. Bug report: in the built in file dialog there's no obvious way to go back up to a parent directory, Command+ArrowUp didn't work, and there's also no way to access my computers other disk partitions.

IMO one of the main things that made HC so  insanely great was its extensibility with XCMDs/XFCNs. While HC couldn't play tracker formats like .s3m, .mod etc. there was an External that could enabled it. I even built MIDI librarian 'app' with HyperMIDI Xternals that could talk to my ancient Yamaha external synth modules back in to day. Lots of stuff most never would have thought you could do with HC. And HC had early polyglot coding, you could mix in AppleScript ( or any other OSA script language), via 'do feild "AppleSciptContainer"as AppleScript' syntax (which later would mean Shell commands too). If your main target is web/html5 then I think it would be great to be able to tap into JS/ HTML5 APIs (and maybe Node for the  desktop version) when the need arises.

Anyway is great fun to play around with,  really nice work so far!

I'll have to spend some time checking out your source later.

I also checked out your web comic. Nice, the art reminded me a bit of Cerebus the Aardvark.

(1 edit)

I'm just reading through those 'responses to responses', which helped me understand the parameters you've set for Decker targeting embedded or extremely limited  and older devices, a noble goal IMO! It then makes more sense to then limit to 16 color palette and 8bit sound samples, but it's still rather harsh constraints by todays standards, maybe even by 1990s standards. I think that limits the possibilities for creativity and may turn off some potential users.

However, THIS is exciting:
"If you know C, it’s fairly straightforward to glue custom functionality into Decker that calls native libraries. Likewise, if you know JavaScript, you could choose to hack up web-decker to expose browser APIs that aren’t normally available to Lil, like the Gamepad API or the ability to perform an XMLHttpRequest. There are lots of inherently “non-portable” features I don’t intend to add to mainline Decker which a given user might still want for a project, and letting them easily add things themselves is what open source is all about. The current version of web-decker is intentionally built without “minification” and doesn’t require anything more than a text editor to make this kind of modification. If it was shipped as an opaque wad of WASM bytecode a whole range of casual tinkering would be off the table and gated behind a complex build process and mandatory tooling."
I may just try my hand at hacking around with a non-mainline Decker, HTML5 APIs access could be a game changer, then one can call whatever WASM compiled modules.  And we can still pack that all up in an Electron app wrapper if we want to. Now I'm wondering if Decker 'Canvas' could be web canvas element, then it could be passed to external (JS) code to draw whatever into it.

And If we could just getting that interpreter to ignore a 'the' token I think that would add just a tad more xTalkishness.

One thing that might be helpful with macOS app version would be to have certain keys in it's info.plist so that it asks permission to use the microphone on newer, more locked down versions of macOS.
Also, when I map .deck files to Decker and then double-click a .deck file in the Finder, Decker opens it in its resource (Font/Res) mover dialog, instead of just opening the clicked Deck file normally. 

For anyone that IS still looking to convert ancient  HyperCard stacks to Decker decks (or any other format), there exists tools like StackImport (CLI) or HyperCardPreview.app, that can convert HC Stacks to JSON and PNG Images representation of a .stack/parts props/backgrounds/Text/Scripts, which should be very helpful compared to straight parsing a .stack (I believe stack used a RIFF like structure).  Also, believe it or not, there are still tools that can read a resource fork (or maybe it's actually the contents of the ._AppleDouble version of a ResFork?) that work on the very latest iterations of macOS (I've tested them myself on 11 BigSur).