This is the second in a series of blogs about how we developed Stenciletto
The first thing we had to solve was how to handle the UI graphics. If you’ve looked at Stencilletto you’ll see it is built up from many crisply edged shapes of many colours. They need to be crisp and precise as anti-aliasing artefacts would break the game. The shapes render at different sizes on the same device, depending on the context, big on some pages, smaller on others. If you’ve played it on different devices you’ll see the UI adapt to the device size. All this means that the shape size is indeterminate. We could handle this with bitmaps, but you would either need bucket-loads of bitmaps of different sizes and colours or you’d have to work with a limited number bitmaps. Stenciletto uses a lot of different shapes, so your bucket of bitmaps is really, really big. And there is the issue that animations that resize bitmaps look really fuzzy compared to the sharpness of the basic shapes. You see the problems we faced?
So vector graphics and drawing everything on the fly it is. Now all we needed to find was a really-fast dynamic 2D vector rendering library to do the job for us. And so we looked and looked and looked. Nope. None. Nada.
“Jane, we need to add writing a really-fast dynamic 2D vector rendering engine to the TODO list.”
“K, how long is that going to take?”
“Just a few days. Not many. Well, maybe a bit more than that. AGES!”
The first design decision for this was to use SVG as the output from the design process. At the time, Jane was using Illustrator. It was difficult to get the precision we needed for the shapes in Illustrator and the SVG output was gross, really hard to parse. We tried other common affordable packages, but they weren’t up to our required design quality. Then by magic, Serif launched the beta of Affinity Designer. They could have designed it for us. It did the job perfectly.
Now we had the design parameters set, now on to coding stuff.