itch.io

The Sims 2 is real???

Amazing; 6 blinking on my cell phone out of 5 stars.

This is fantastic; an immersive point-and-click collage stuffed with puzzles. I did find ringing the bell a bit treacherous: clicking it quickly seems to make the game unwinnable. You might want to use >2 instead of =3 somewhere in your scripts. ;)

This is looking amazing. The subtle animation on the Christmas lights adds a lot, and everything has so much texture!

dd.say[] and dd.ask[] accept rich-text, so one alternative might be to represent your input options as hidden rich-text fields. You could also use rtext.cat[] to convert an image stored in a canvas into a rich-text table, or use any other method of constructing it on the fly.

Suppose you have a pair of fields named "op1" and "op2". Their "value" attribute is their rich-text, which is represented in Lil as a table of text runs and attributes. It is important to wrap each table in a list with the "list" primitive like so; otherwise the comma operator will join the rows of those tables and make all the options in the prompt "stick together":

dd.ask[
 "Some Question"
 (list op1.value),(list op2.value)
] 

To de-mystify a little, when Dialogizer is displaying a dd.say[] modal, it's doing something similar to the following:

while !pointer.down
 blink_cursor[]
 deck.card.event["animate"]
 sleep[1]
end

The "animate" event which is being sent to the current card provides the opportunity to make other things happen while the dialog box is idling and waiting for user input. Puppeteer uses this hook to animate puppets, and it can be used to give other modules and contraptions a chance to do their thing as well.

Any "blocking" scripts you write yourself can use a similar approach; a synchronous animation script becomes responsible for explicitly routing the events to everything that needs to do work on every frame, whereas an asynchronous script allows Decker to handle some of that plumbing automatically.

As Millie says, Decker uses its own font format; adapting e.g. an existing TrueType font for Decker will require some manual work, and perhaps a bit of script-wrangling. Your first stop should probably be fontedit.deck, which includes a very simple font editor. As discussed quite recently, since this editor is a deck, you can feel free to extend and customize it to suit your needs.

I wrote an article some time ago which describes how one could build their own DIY importer for pre-existing bitmapped fonts.

The structure Decker uses to represent fonts is described in The Decker Document Format, but this information is only necessary if you wanted to produce Decker fonts from some external tool. The Font Interface in the Decker Reference Manual describes the APIs for manipulating fonts on the fly from within Decker.

absolutely wild aesthetic; very creative!

Just in case it helps, the Decker reference manual has a section about scripted animation that describes "synchronous" vs. "asynchronous" approaches and the tradeoffs therein. I also recently wrote an article about making action games in Decker that talks about similar issues through a more practical/applied lens.

If you haven't seen it previously, Learn Lil in 10 Minutes is a fast-paced overview of most of Lil's features targeted at folks who already have some exposure to other programming languages.

A slightly simpler equivalent would be to use an "each" loop:

each i in range 96
 f[i]:f[i].translate[0,1 1]
end

If "f" were a list of Images, it would be possible to use ".." notation to manipulate every element in-place in the same way:

f..translate[0,1 1]

But this notation cannot be applied to an Interface type like a Font to implicitly iterate over every glyph. Alas!

I just corrected the inconsistency in how the modal fill/stroke palettes draw the first swatch while in transparency mask mode; the fix will be included in the next Decker release; probably this Friday. The behavior of the toolbar is as intended.

Well done. The nonlinear navigation structure is a visceral way of representing how all these issues and thoughts are inter-related and knotted together.

Have you considered also submitting this piece to Dec(k)-Month?

By default, Lil fragments in a Ply passage execute in an isolated scope that only has access to variables defined among passages and the variables I explicitly note in the documentation, which means no references to the widgets on the current card, the deck, etc. This is an important default, because otherwise it would not be possible to run these scripts in the stripped down "standalone" environment of the Twine Story Format where no surrounding deck exists.

You can get around this in several ways if you want to; for example you could modify the "Twine Player" example and install references to deck parts, functions, or anything else you want via the third "vars" argument to twee.render[]; you just have to explicitly opt into the things you want, and once you start doing this your stories will no longer work in Twine or the plyPlayer contraption:

# instead of this...
r:twee.render[story.value there vars.data]
# ...you could do this...
v:vars.data
v.deck :deck
v.print:print
v.pi   :pi
r:twee.render[story.value there v]

It's not a great idea to put function-calls with side effects in here, since all the fragments of a passage will be re-executed every time you revisit or refresh the passage. Beware!

From an "outside-in" perspective you could also naturally have other controls and scripts in the deck tweak or consult the flags this example stashes in the "vars" field.

Another way of making stuff happen in response to the player's actions is to add logic to the "link[]" event for the field where the rtext is rendered. In the "Twine Player" example there's some code that consults the current passage's "tags" and alters the "show" and "align" properties of the field:

# bonus: tag-based formatting cues:
p:(story.value.name dict rows story.value)[there]
output.show:if "inverted" in p.tags "invert" else "solid" end
output.align:if "center" in p.tags "center" elseif "right" in p.tags "right" else "left" end

You could have any sort of logic you want consulting the name, tags, or metadata of the just-visited passage.

If you use the plyPlayer contraption you're more limited, but it still offers a user-interceptable event if you edit the script of the contraption instance. The built-in example updates the "location" label to reflect the current passage name:

on passage name body tags meta do
 location.text:name
end

There's some other stuff I intended to work on first, but, well, once the idea started rattling around in my head...

I just completed a first pass at a utility module that's been on my mind for quite a while: a library for working with Twine's .twee story file format from within Decker:

http://beyondloom.com/decker/twee.html

The "twee" module is a more robust and general version of the code previously seen in this prototype. In addition to being able to parse and emit .twee files, it can handle Twine's HTML Output Format, it can render a simple RText-oriented story format called "Ply", and it comes packaged with a self-contained contraption for playing Ply-based stories within a deck:

Finally, there's a simple Ply Story Format available for use with Twine itself:

http://beyondloom.com/decker/ply/format.js

I hope that these will provide some interesting possibilities for using these tools in concert!

Very informative zine; I learned many things I didn't previously know about how the games industry handles localization!

Including the option to export a PDF is a great feature! One possible refinement would be to temporarily hide the navigation buttons while taking screenshots of each card, like so:

 images:each card in range deck.cards
  w:if card.index
   card.widgets@("button1","button2","button3")
  end
  w..show:"none"
  i:pdf.flatten[app.render[card] deck]
  w..show:"solid"
  i
 end

Did you read this post in the Bazaar?

I think this would be difficult in the general case without making some assumptions about the structure of passages. Hyperlinks can appear anywhere within the text of a Twine passage, so it's not simply a matter of hiding or trimming off a suffix of the output to remove the listed "verbs".

If there's demand for it (and it looks like there might be) I could look into developing a more complete and robust .twee manipulation module for Decker, and maybe even a story mode specifically designed for interoperation with Lil. I don't think I'll have time for it this month, though.

It's not quite what you're asking for, but you might be able to find some useful ideas in this thread where I discuss parser-based IF systems; my example deck features an output log which distinguishes user input from responses with bold/plain fonts.

I just wrote a new Decker tutorial which walks through three different approaches for implementing the arcade classic Breakout, and along the way touches on a range of considerations for programming action games. Note that this is targeted at an audience that is already somewhat comfortable with programming. Hopefully this will contain some useful information for our more ambitious deckbuilders and lilateers!

http://beyondloom.com/blog/breakout.html

Any follow-up questions? Was there anything you learned, or felt was missing? I'd love to hear your thoughts!

When a field is configured to display "Rich Text", it can contain text spans that are links, use different fonts, or include inline images. Rich Text is described in the reference manual here.

Rich Text is represented as a Lil table, and can be constructed like any other table so long as it has the appropriate columns. For example,

myField.value:insert text font arg with
 "Apple" "" "theAppleCard"
end

Remember, of course, that fields need to be locked for their hyperlinks to be clickable. Unless you define your own link[] handler for a field, clicking a link will call the go[] built-in function with that "arg" value, which conveniently serves either to navigate to cards by name or to prompt the user to open URLs in a new browser tab.

The "RText" utility interface (linked above) offers a number of convenience functions for creating and manipulating Rich Text tables. The "rtext.make[]" function offers a more concise alternative to the above:

myField.value:rtext.make["Apple" "" "theAppleCard"]

In the interactive docs for a variety of modules I use this sort of approach to automatically generate the index in the title card's view[] event handler:

bullet:image["%%IMG0AAYADQAAAAB49Pz8/HgAAAA="]
i:select c:key t:value..widgets.title.text where value..widgets.title from deck.cards
index.value:raze each row in rows i
 rtext.make["" "" bullet],
 rtext.make["  "],
 rtext.make[("%s\n" format row.t) "mono" row.c]
end 

Does that help?

All of the modules and examples in the Decker source repo and homepage are available under the MIT license. Any non-code assets for which the MIT license cannot be logically applied should be understood as available under the CC0.

I also formally extend the same to WigglyPaint and all of its components. If you're interested in making something wigglypaint-like, you should be sure to check out WigglyKit, a collection of contraptions that are specifically designed as more modular/reusable versions of the components in WigglyPaint.

Hope that helps!

Just to flesh out the implied details of Millie's example, I have an experimental setup with four audio clips named "sound1" through "sound4" (I used Decker to record myself saying the numbers one through 4 to make it clear), a field named "loopcounter", a button for starting the loop with a script like this:

on click do
 loopcounter.text:0
 play["sound1" "loop"]
end

and a button for stopping it like this:

on click do
 play[0 "loop"]
end

That leaves us with the loop[] event handler, which for this setup ought to be defined on the card. If you wanted the music to keep playing across many cards, defining a handler on the deck-level script could also work, but it would then be important to specify the path to the loopcounter field as e.g. "deck.cards.thatCard.widgets.loopcounter" instead of just "loopcounter".

We can simplify Millie's example in a few ways. Firstly, by indexing from 0 instead of 1, we can use the modulus operator (%) to wrap the incremented value of loopcounter between 0 and the length of the list of audio clip names, avoid the need for a "dummy" element at the beginning of the list, and save an "if" statement. We can also coerce a string like "3" to the number 3 by adding 0 to it (or any equivalent arithmetic identity operation) instead of parsing it:

music1:("sound1","sound2","sound3","sound4","sound3","sound3","sound1","sound2")
on loop do
 loopcounter.text:(count music1)%1+loopcounter.text
 music1[0+loopcounter.text]
end

We could make the script more concise still by defining the list of pattern names as a single string that we split on pipes (|) and stashing the loop index in a temporary variable so we don't have to refer to "loopcounter.text" three times or turn the string-ified index back into a number:

on loop do
 m:"|" split "sound1|sound2|sound3|sound4|sound3|sound3|sound1|sound2"
 loopcounter.text:i:(count m)%1+loopcounter.text
 m[i]
end

Since there's a very simple pattern to the names of audio clips we want to play, we could be even more concise by only building a list of the part that varies- the number at the end of the string- and formatting that at the end of the function:

on loop do
 m:1,2,3,4,3,3,1,2
 loopcounter.text:i:(count m)%1+loopcounter.text
 "sound%i" format m[i]
end

Of course, the most important thing is always to use the approach that makes sense to you! Longer code isn't necessarily worse if you find it clearer or easier to modify.

In Decker 1.52 I overhauled the brushes.deck example to make it a full interactive tutorial: All About Brushes!

I hope that this sheds some light on a feature that has remained a bit obscure and under-utilized so far. I'd love to hear your thoughts on this new tutorial. Do you find it helpful? Is anything unclear, or is it missing information you'd like to see?

As a bonus, here's an extra little Lil fragment that describes a brush which cycles through a configurable "rainbow" palette. Give it a spin:

i:image["%%IMG0AAsADQ+AP8B/wP/g/+D/4P/g/+D/4P/g/8B/gD4A"]
#c:47,44,32,37
c:39,36,32,36
n:0
brush[on rainbow do
 n:(5*count c)%n+1
 i.copy[].map[1 dict c[n/5]]
end]

What brushes can you folks dream up?

Sounds like the ImageEnum contraption might do what you have in mind, more or less. If you specifically wanted to display thumbnails of other existing cards you could write a script to populate the enum using "app.render[card]" to ask Decker to produce "screenshots" for you.

Wow! Very creative, and lots of interesting things to find. Thanks for sharing!

If you save a deck with a ".html" extension, Decker will create a standalone web page that can be opened with any browser, like this example from decker's documentation. If you then upload that document to a project page here on itch.io or someplace like neocities it might be easier to show to people.

In a few places it might also be a good idea to reset the ".scroll" property of fields when you change their text. For example,

on click do
 myField.scroll:0
 myField.text:"A lengthy piece of text, perhaps."
end

Hope that helps!

Congratulations; I'm glad you had a positive experience working with Decker!

(It looks like you may have the wrong link, though; you're pointing at the google drive root page.)

Field widgets report their scroll position through their .scroll attribute. Decker doesn't trigger any events when fields are scrolled, so we'll need to somehow poll the .scroll attribute of our field and update the visibility of the button in question.

Let's say we have a field named "f" and an associated button named "b" that we want to reveal when "f" is scrolled to the bottom.

Determining the maximum scroll position of a field is a little tricky, but here's a helper function that performs the calculation based on the contents of a supplied field:

on maxscroll field do
 c:card.add["canvas"]
 r:c.textsize[field.value field.size[0]-19][1]-field.size[1]-4
 card.remove[c]
 r
end

Given that function, we can make "f" animated (See Widgets -> Animated in the menu), which will fire a view[] event on every frame, and use that event handler to .toggle[] the visibility of the button appropriately:

on view do
 b.toggle["solid" me.scroll~maxscroll[me]]
end

Below is a complete example you can copy and paste into Decker:

%%WGT0{"w":[{"name":"f","type":"field","size":[91,151],"pos":[26,60],"locked":1,"animated":1,"script":"on maxscroll field do\n c:card.add[\"canvas\"]\n r:c.textsize[field.value field.size[0]-19][1]-field.size[1]-4\n card.remove[c]\n r\nend\n\non view do\n b.toggle[\"solid\" me.scroll~maxscroll[me]]\nend","scrollbar":1,"scroll":83,"value":"Complete newbie here, so forgive me if i look stupid right now;\n\nThe title says it all, but how would i make two (or more) buttons appear only when the player scrolls to the bottom of a field? I want to make sure the player reads all of the text in the field, but i'm not sure how to do that. Any help is appreciated :]"},{"name":"b","type":"button","size":[101,48],"pos":[26,225],"text":"THANK YOU FOR\nREADING THE\nENTIRE EULA"}],"d":{}}

Note that instead of hiding the button, you could alternatively lock and unlock it:

on view do
 b.locked:!me.scroll~maxscroll[me]
end

Does that make sense?

Don't worry- it's quite normal to stash contraption state in auxiliary hidden widgets. The contents of such widgets is distinct between contraption instances, but the background image of contraptions is shared among all instances; pasting directly onto the contraption background will cause issues if you have more than one sprite. The conventional solution would be to add a canvas widget to the contraption and draw on that instead. You'll also need to configure non-zero margins for the contraption to ensure that the canvas automatically stretches and resizes properly along with it. Both the contraption instance and the canvas will need to be set to "show transparent" if you want objects behind the sprite to show through.

Since you intend to redraw the contents of the canvas frequently, you may be able to mark it as volatile, which will ensure that having many sprite instances won't bloat deck size with unnecessary copies of sprite frames. If you aren't already doing something similar, you may find it useful to mark the canvas as "animated" so that it will automatically bubble view[] events to the contraption instance at 60fps and "locked" so that it doesn't inherit the default click-and-drag-to-scribble behavior of canvases. (Be aware that "me" will be bound to the original target of the view[] event, not necessarily the contraption itself!)

The Sokoban example deck contains a contraption called "mover" which works similarly in some ways to your "sprite" design, and the Path example deck has another variant called "follower". You might find these useful to reference.

Does any of this point you in the right direction?

I very much enjoyed the "kinetic type" presentation of your poem.

Usually stews have a higher viscosity than soups. You can try mixing a little bit of flour, cornstarch, or some potato flakes into the broth to thicken it, or even cook some bones to extract the collagen. In all cases, the thickening effect will be rather subtle while you're cooking and become more pronounced after you allow it to cool a bit. Hope that helps! :)

The DitherJam is also taking place in December. Decker's natural inclination toward a ditherpunk aesthetic could make it a great fit for participating!

You can inspect and modify the order of widgets on a card via their .index attribute, which counts from back to front, starting at 0. This is automatically clamped within the permissible range on a card, so assigning it to 0 or -1 can be a convenient shorthand for "all the way to the back" and any very large number (say, 999999) can likewise be used for "all the way to the front".

For example, you could give your draggable canvas a script like so:

on click do
 me.index:999999
end

If you have a contraption x, you can obtain the contraption's prototype as "x.def" and the name of the contraption's prototype as "x.def.name"

Update: the jam page for Dec(k)-Month The Second is now up; feel free to start spreading the word!

Extremely cute!

Just FYI, any script can attempt to open a URL by using the go[] function, like so:

go["https://beyondloom.com/decker"]

Thanks so much for writing this piece! This should be a huge help for introducing new people to Decker!

Posterized color import ended up being a remarkably simple set of changes! Easier internal linking, on the other hand, was more complicated than I expected...

That's very kind of you to say. :)

Yep!

To be precise, clicking a link in a field sends a "link[]" event to the field with the text of the link contents. If you write some custom scripting, you can make clicking links do whatever you want, much like a button. If you don't write any scripts, Decker's default behavior for the "link[]" event is to attempt to open anything which looks like a complete URL (starting with "http://" or "https://") in a new tab, and anything else is interpreted as a card name to "go[]" to. Additional details can be found in the reference manual under Events.

One possible refinement to this which would produce smaller deck sizes would be to mark the internal canvas as "volatile"; instead of saving the rendered bitmap of text, Decker would then regenerate the image at load time or the first view[] event. (This would also require you to save the pattern selection in a separate internal field.)