Les dialogues doivent arriver petit à petit, avec un VFX associé à des dialogues de science fiction #149

New issue

Closed

opened 2026-08-29 11:59:32 +00:00 by metaheavens · 2 comments

metaheavens commented

2026-08-29 11:59:32 +00:00

Owner

No description provided.

metaheavens commented

2026-08-29 12:13:02 +00:00

Author

Owner

English translation (as asked, before starting):

Dialogs should arrive bit by bit, with a VFX associated with science-fiction dialogs.

So two things: the line should be revealed progressively rather than appearing whole - typed out, the way a transmission decodes - and the banner should carry an effect that reads as science fiction while it does it, rather than plain text simply becoming visible.

**English translation** (as asked, before starting): > Dialogs should arrive bit by bit, with a VFX associated with science-fiction dialogs. So two things: the line should be revealed progressively rather than appearing whole - typed out, the way a transmission decodes - and the banner should carry an effect that reads as science fiction while it does it, rather than plain text simply becoming visible.

metaheavens commented

2026-08-29 12:39:58 +00:00

Author

Owner

Done in b721760.

Arriving bit by bit. A line is typed out at about 42 characters a second - three and a half words - rather than appearing whole.

The sci-fi part. A scan sweep runs down the panel while it decodes, with a short trail behind its head so it reads as travelling; faint rules sit across the whole panel always, the way a screen has a raster; the frame carries the sweep's charge while it works and settles when the line lands; and the caret is a solid write-head during the decode, only starting to blink once it is waiting on the reader.

Two implementation notes worth keeping:

The full text is set and then revealed with visible_characters, rather than the string being grown. A growing string re-wraps on nearly every frame, so words jump between rows as they are typed.
A press on a line still arriving finishes it instead of dismissing it. That is not a flourish: without it a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. The second press dismisses, as before.

One consequence you will notice: the banner types while the game is stopped, because it is the one node still running under #128's pause. That is right - it is the thing the pause exists for.

Done in `b721760`. **Arriving bit by bit.** A line is typed out at about 42 characters a second - three and a half words - rather than appearing whole. **The sci-fi part.** A scan sweep runs down the panel while it decodes, with a short trail behind its head so it reads as travelling; faint rules sit across the whole panel always, the way a screen has a raster; the frame carries the sweep's charge while it works and settles when the line lands; and the caret is a solid write-head during the decode, only starting to blink once it is waiting on the reader. Two implementation notes worth keeping: - The full text is set and then **revealed** with `visible_characters`, rather than the string being grown. A growing string re-wraps on nearly every frame, so words jump between rows as they are typed. - A press on a line still arriving **finishes** it instead of dismissing it. That is not a flourish: without it a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. The second press dismisses, as before. One consequence you will notice: the banner types while the game is stopped, because it is the one node still running under #128's pause. That is right - it is the thing the pause exists for.