Thinking out Bézier Game

Prelude to the workday

I'll set my intention towards releasing the new Bézier Game on Monday of next week, so I have four workdays to complete the work. It should be enough, but perfectionism would probably drag the release a day or two, this is fine.

I feel certain hesitance towards implementing more stages without having finished what needs to be programmed, because events up ahead might mean that the stages I created need to be reworked. I know this to be an untrue idea, because now I can use any SVG path as a stage, though I have not accounted for the MOVE command.

I'm not sure I want/need to implement this command, for it changes the mechanics a lot. It becomes a composite path, so the stage ends not when you are able to connect A to B, but when you connect A to B in all paths that compose the composite path.

(I am writing as a tool for thinking here)

It is not all that difficult to implement, but it changes many assumptions that I made programming the original game. I could split the composite path by virtue of their M commands, and then iterate over the segments until they are completed. But then I would need to have a start and endpoint for each segment. Yes, it is quite straightforward, but it will require many changes to the current code.

Allow us to reason of this feature is worth it. What does it allow?

To punch holes into paths
To have unconnected overlapping strokes
To have a closer experience to a vector drawing app

It seems worth it indeed, I shall explore this feature in a work session and see where it takes me.

Work session 1 (1h)

I came to "Pedro Salinas" library next to Puerta de Toledo. It is a nice pleasant library. I worked on Project Arete, since it is an unveiled project I shall not write about it. What shall I write about instead? I will just drink smuggled tea and observe the kind of people who attend the library at this time of the day. Nothing needs to be written.

Work session 2 (1h, 15m)

I begun the work required to support composite paths on a single stage. It's going easier than I expected, but the code is very knotty. I had much pleasure in deleting substantial amounts of code regarding gradients and bevel effects, it took me so much work at the time but now it feels a naïve place where to put effort, and there was no value in it (except for the questionable aesthetic experience).

I'm actually surprised I don't think this code stinks. I've been able to be productive on the codebase I have and I generally know where things are, though it is structured in a very idiosyncratic way. I wish I could swap the GSAP dependency for something more lightweight, but that's very down on the list of priorities.

I'll put a "bookmark" of sorts for the last place of work: a stage has a startpoint and an endpoint.

⬤──────────────◯

Now, I have not multiple startpoints or endpoints, but they change position as you complete each segment:

⬤──────────────◯ ────────────────── ──────────────────

And then:

────────────────── ⬤──────────────◯ ──────────────────

And so forth. When you finish drawing all the segments, the stage is completed.

Work session 3 (1h)

I came to the pool for lunch. I worked a while without much focus, there's just too many distractions for the kind of work I'm currently trying to do, but I did advance. I know when a composite path segment has been finished drawing, now I need to reposition the pulsator and to begin a new stage within the stage, so to speak.

Afterword