Although a different context, I always find the writeups of cybersecurity CTFs that go through the "What I was thinking, what surprises I encountered, how I pivoted" process both more enjoyable and more enlightening than writeups that simply explain the solution as if it was known from the beginning.

At the same time there might be some editing since there might have been approaches tried that didn't go anywhere, and whether that's interesting/relevant to the reader is probably a judgement call from someone who knows the domain and whether those dead ends might have been natural things to try in that specific context.

Maybe a "why it works" post would be useful, as in "this part of the demo does x because I was trying to do y but ran into this issue, which caused me to experiment with z and then a side effect inspired me to switch abc to def", etc. Personally I think explaining the creative process is more interesting than explaining the end result.

> Personally I think explaining the creative process is more interesting than explaining the end result.

Thanks, I think this is right, to focus on the process instead (and commenters indigochill and lawn) which I think are describing the same type of writeup.

Perhaps my error was starting with "how it works", whereas I probably should focus on the story of the process and add the "how it works" where it makes sense in the story. I also don't really try to record the process at the moment, it's just from memory.

High-quality 64k intros usually need a film-like production process nowadays, except it is harder because you have to fit it into 64k later, it typically means procedurally generating everything as well as using the appropriate tools (runtime packers, compiler options, etc...). It is, I think, the most demanding demoscene category.

There is much less commitment in a tiny intro. You don't have days of preparation, storytelling, art direction, etc... to stick to. If, when optimizing your intro, you stumble on something better, you are better off throwing everything away and build on that instead, "everything" is just 192 bytes after all. I didn't know 192b was a thing BTW, I am more accustomed to powers of two, like 256b.

It's 194 bytes I keep getting it wrong :D yeah it's a strange size, the short version is SMS (140 bytes) => twitter => dwitter => unicode packing of ascii with JS decoder (which could not be undone because the limit was defined as unicode points) yields 194 bytes.

> If, when optimizing your intro, you stumble on something better, you are better off throwing everything away and build on that instead,

Exactly this, but because of the extreme size limitations you often end up forced to iterate out of frustration trying to fit something, and then something else weird but interesting will often pop out of that process that you wouldn't have directly thought of.

I straddle the tech/art gap as a tech artist in 3D VFX & Animation. I've done work as visual as branding and identity, and as technical as network performance and a back-end web development. I'm also a technical writer for a commercial rendering engine, which is pretty different, but I've some experience reading and writing about these things.

Technical folks often approach process write-ups as they would an incident report, or a tutorial. Rarely a pleasant read! A little prep before you start yields major improvement: First, decide exactly what you're saying, and to whom. For a big one, having a "story" part, a prosaic technical write-up, and a reference section can fit multiple people's needs. Then, consider exactly what your audience wants and needs to know about your message: try not to be overly broad. Make that into a simple narrative and story arc, and expand it into an outline. It sounds like boilerplate, but it's more like scaffolding. Correctly applied, it steers you towards a concise, compelling piece without endless dickering and waffling about what to say next. Start with the broadest, least specialized audience-- adding details is easier than editing them out.

This is the same for any creative process. Any painter could describe how they’re reasoning about a composition and what-not. But ultimately each individual needs to digest technique and make it their own.

Writeups like this are great though because it can at least share the tools used and give folks some place to start.

I know nothing about the subject but an idea is to use a "let's make a demo" story to, as you say, capture the important journey instead of the end result.

It takes more effort than a simple "how it works" explanation but if done correctly I think it should explain how the demo works while also capturing the magic of the creation process.

> the explanation of how it works is often severely departed from the process of creating it

This description rings true for a whole swath of creative endeavors, including ones like demos that appear technical on the surface: optimizing an algorithm, conducting scientific research, building an engine, constructing a mathematical proof, and so on.

How long does it take you to make a demo? Might be cool to do a live streaming, or just record the process even if not live.

Sometimes I do it in one sitting, sometimes that's quite long, like 12 hours or more! Other times I will revisit it over days or months - You'd be surprised how much thought and transformation can go into 192 characters. It depends how much potential room for improvement it "feels" like there is left, you get a sense for it, sometimes you just know it's done, others you're never quite sure when to stop trying to push harder.

I've commented in a sibling my experience live streaming which was interesting. Another Demoscener who has given this far more concerted effort on Twitch is KilledByAPixel, I think they are recorded somewhere maybe on youtube. My two attempts are lost to time.

As an example (yes shameless plug) I wrote this one recently over a couple of long evenings, I'd estimate 8 hours maybe:

https://www.dwitter.net/d/31805 (runs fastest in Firefox)

But there are some familiar micro-raymarching techniques I've already developed and reused in this. The bit that took most of the time in this one was figuring out how to fit binary search marching that was required to support large differences in marching distances and textures without producing excessive moire effects.

If you write your demo in a recording editor, then when you're done, you can go back and watch the playback of all your edits and add commentary.

Interesting idea, thanks!

Would be cool to see a full video of the process from start to finish, if you’re up for it.

That way people can get a better impression of it.

I've actually tried that on Twitch, it was fun for another reason: viewer involvement. But as a format I found it didn't really work well because for my most impressive demos 90% of the time I'm just staring intensely at tiny fragments of code and trying to rearrange and run it in my brain - this is not interesting to watch believe me, I suppose one could condense the video to only show the ends of those segments and just talk out-loud about the concrete thought that has coalesced at the end of it and the actions that are now being taken.

> I suppose one could condense the video to only show the ends of those segments and just talk out-loud about the concrete thought that has coalesced at the end of it and the actions that are now being taken.

I like that idea.