Today it's Friday and--following Madrid's tech schedule--my intention to work until lunch time. I've worked intensely five days straight, and the inertia wants me to keep on moving, but it's better to develop sustainable habits early rather than to pay the price later.

I've decided to work on the bézier game. I'll go through the things which I have thought would be cool to add/modify, and see how feasible it is:

Add support for different app keyboard conventions

The original game uses Adobe Illustrator's keyboard conventions for the bézier tool. I've received requests to add support for Inkscape (which I have never used), so I would need to install it to check out how it works. I'd also like to add support for Sketch and Figma. What other vector apps are out there? The challenge here is not to much to remap the functions to different keys, but the subtle interaction paradigms that each app has. In Sketch, for example, you don't hold the alt key in quasimode but you switch node type modes through pressing numbers between 1 and 4. I'll have to rearchitect this part of the application.

Recently I helped proof-reading the readme of keyboardist by fellow Mexican designer/developer Armando Sosa, I looked at the API and it was a really intuitive. I'll use this to get it done. This last point takes me to...

Add a credits section

In one of my first attempts at project Arete I decided to deliberately attempt to do it without the use of any third-party libraries or frameworks. I knew this would be doomed form the start, but I just wanted to see how far I could go reinventing the wheel, in part so that I could understand how wheels actually work. The experience left me more appreciative of open source work.

Add levels which introduce concepts progressively

I've received a lot of emails from frustrated users not knowing how to complete a level. The problem lies in that the progression is too harsh, the tutorial levels skim over fundamental concepts which, if not understood, impede completing stages further ahead. Instead of a complete tutorial at the beginning, the solution implies to have levels that introduce new concepts: how to draw lines more efficiently through constraining axis (shift key), where and how to use different node types (one for each level) and such. For this I need new vector illustrations, which takes me to the next point:

Add new stages

The bézier game supports a subset of the SVG line commands, so if I use a random vector illustration, I need to manually convert any unsupported command into a supported one. I need to look into the codebase, but I think the reason for this is because I need to convert SVG path commands into canvas ones. There are libraries that support this, but at the time I created the game they were too bloated. The situation might have changed, so I'll revisit my decision. This would allow me to add any vector illustration easily, which I could take from the noun project and give credit.

Save progression

A frequent request I receive is to save progression, so that I can close the browser window and come back where I started. At the time I created this, I thought the game was too short to merit this feature (which is not trivial, because it needs to save your solution and scores, and then if you repeat the stage and have a worse score, keep the better solution and such). With added levels this becomes a must have.

Nice to have: add graphics tablet support

Another common complaint is that the game does not support graphics tablets. I don't own one, and I never have. It would be interesting to look into this, as I intuit that it the solution is trivial, as graphics tablets are meant to emulate the mouse and part of the keyboard on a single device. Where this might get complicated is in the interaction with with the different keyboard conventions. When the time comes, I'll ask around to see if anyone has a graphics tablet that I can borrow.

--

It's 10:20 and being realistic I only have time for one long work session. Perhaps the best place to start is to swap my home brewed SVG to canvas path translation code to a proper library.

Work session 1 (2h)

Hmmm, it turns out I had already put a library in place to convert from SVG to canvas. Instead I remembered some pending bugs and got acquainted with the codebase again. It turns out that, at the time I made it, I couldn't find a way of centering elements and also center the coordinates of the mouse to account for the offset of the translated element, so I chose to translate the path coordinates instead, so that the mouse and path coordinates would match. This was a poor architectural choice, because further down the road it impeded me from centering elements upon resize because of all the hackery that was underneath.

I now know better, and the task is removing all the hackery. It felt nice deleting so much ugly code but at the same time it has to be done with care as to not cause problems elsewhere.

I was reading that modern cities have separate storm and sewage drains. I know, from experience, that most (if not all) cities in Mexico don't separate them. This makes it almost impossible to treat the water before releasing it back into nature, because you can't treat that volume of diluted sewage. The solution would be to replace the sewage lines of the entire city. The cost would be astounding and it would take decades. This is the importance of architectural decisions.

But, at the same time, if we worried about the implications down the road of everything we do, we'd become paralyzed. It is simply not possible to foresee all outcomes. I prefer prototyping and then throwing away when I have seen the implications, rather than to getting the plan right from the beginning, for perfect plans are only possible after endless previous mistakes.

Work day is done, I'll enjoy the weekend.

Debt

  • Blog: Serve everything on https
  • Blog: Give some decency to that ugly footer
  • Redirect duopixel.com and duopixel.ca to method.ac