Notes

Collected bits and pieces I've noticed this month.

Terminal bonsai

John Allbritten created this little thingumbob that lets you grow a bonsai tree in a terminal window.

The difficulty of doors in video games.

I don't think I've ever given much though to doors in video games, unless they act real weird - badly designed doors are just as annoying in video games as they are in real life. Well designed doors on the other hand should be forgettable and achieving this in a video game is harder than you might think.
"Why game developers can’t get a handle on doors", The Verge

The booze shader

Another thing that's hard to get right in video games is liquids and still stay within a reasonable performance budget. Vfx developer Matt Wild nailed it for Half-Life: Alyx, I especially loved this clever bit of performance optimisation:

“When I shake a bottle, [the liquid] kind of wobbles around a bit. So we make it wobble around a bit, inasmuch as the wobble looks about right.”
It’s this wobble that initially delayed the shader, as there wasn’t an efficient way to get the information into the game. In the end, the performance cost was negligible, because Wilde’s colleagues at Valve realized they could store data in the shader’s vertex color.

"Why the bottles in Half-Life: Alyx look so dang good" Polygon

Pictures of apps and websites

I've long been of the opinion that modern design tools are lacking or perhaps even misguided. While I admit that big strides have been made in reducing the amount of work designers have to do to get an idea to a working product, we are still largely making pictures of apps and websites. It's much easier these days to link these pictures to quickly prototype an idea and describing specs for developers has largely been automated, but at the end of the day it's still pictures of apps and websites.

I was reminded of this again when I came across this article by Carol Chan on how to construct complex variants in Figma. I mean, 288 card header variations? Sure, a card header may very well have this many variations and the design should be robust enough to handle them elegantly, but there must be a more effective way to go about this. Working closer to actual code and trying to break the component while testing and then iterating on it perhaps, not making 288 pictures of the component.