Prototypes shouldn't look too nice. They should look like a work-in-progress. They should show their joints.
This keeps discussion at the right level of abstraction. You want to be talking about the capability, not the color scheme.
I've always liked building systems where the joints are visible: legos, Minecraft. Lately I've been thinking about the process of learning how to find the joints in systems where they're less visible. Of 'carving at the joints'.
Apparently Plato talked about "carving nature at the joints". I think my recent reference is the show Delicious in Dungeon, where they explain how to cut and prepare dungeon monsters into unlikely meals. The show has a lot of fun with the instructions reveal, where something that looks inedible is made appetizing through a precise set of steps.
Compared to digital constructions, there is a higher cost to starting over with physical work. But there are materials you can choose where it's much lower-stakes, and I've been having fun assembling a set of them:
Pokemon took the combat formula from traditional turn-based RPGs and turned it inside-out.
In traditional RPGs you have a few characters who learn more and more attacks and spells.
In Pokemon you capture more and more characters (pokemon) who can only have four moves each.
Edit: There are credible reports that suckless/folks-involved-with-suckless engage with right-wing/neo-facist/nazi views. Views I completely reject. I've never been involved in the community, and tracking down what has happened is difficult from the outside, this seems like a good collection, albeit with link rot. But I've definitely seen a neo-fascist streak (often positioned as trolling) on linux youtube content and want to be clear I do not support any of that, and advise anyone entering into the linux community to stay away from that ideology, there's lots of folks (by far the majority) interested in software customization without those views.
suckless is a set of opinionated Linux software focused on simplicity and targeted towards experienced users. The most interesting part of the project to me is the attempt to break down the most common programs into a set of shareable primitives.
Their main programs and tools:
The new wave of generative text models is impressive. It's also an opportunity to think about the purpose of reading (or listening to) information. Can generative models satisfy what I want from these activities? What do I want, really?
I like interviews. I like reading and listening to interviews with authors or thinkers I like. When I listen, I think I'm generally looking for ways to understand their ideas better. If I've read their writing, then I've probably heard the distilled version of the argument. The cleanest and the best they could come up with. That's great, but sometimes it can be so clean it's hard to find a way in. Informal interviews, clumsier and with more digressions, can provide another way in, the messiness can be welcoming. It also helps remind me the author is a person, lessening the gulf between us. We're all just people trying to figure things out I think, there's comfort and closeness in that for me.
Tailwind gives you a bunch of utility classNames to write CSS with. I've been loving prototyping with it, and I'm interested in why, because it's ideas often feel counterintuitive.
Get a storefront, split it into a front half and a back half. Put six computers in each half. The front half is free for anyone to come and use. The catch is that the free-to-use computers only run the software made in the lab by the in-residence developers that work in the back half.
I take a lot of inspiration from video games but I want to make creative tools. What's the difference between a game and a creative tool?
One big difference seems to be the end goal: with a creative tool you make something you want to share outside of the tool. You export something, often an image or a text document. In a game, you're normally working within the game world. Often you're completing quests. For more creation-oriented games like Minecraft, you're building something and you may even share your creation in the form of screenshots or recordings, but still there's a sense that what you made belongs in the game world and is best experienced there.
Another big difference is primitives. In drawing and painting applications, you're often working at a pretty low-level, defining shapes and colors and paths. In games, you're often acting within a world using an avatar. It's more like making scenes with dolls and action figures (or in Minecraft's case, legos) than it is painting or drawing. The distinction seems to carry over pretty cleanly from the physical world. 3D graphics programs or game development tools like Unity possibly make things a little fuzzier, but even there I think the distinction between playing and creating can mostly be classified according to what level you're intervening at.
I meant to write about this quote last time but got sidetracked:
okay, to start, an analogy: long ago, a single person could build the best video game that existed. Adventure didn't require 200 developers and 18 months to get out the door. as technology improved, so did expectations. Adventure was my goal. Today's kids' goal is fortnite. —@steveklabnik
okay, to start, an analogy: long ago, a sing le person could build the best video game that existed. Adventure didn't require 200 developers and 18 months to get out the door. as technology improved, so did expectations. Adventure was my goal. Today's kids' goal is fortnite. —@steveklabnik
One of the things I keep coming back to is the value of visible seams. The idea that you can look at something and develop a mental model of how it works or how it is made.
I'm working on recreating some graphics editing programs in WebGL. To be able to zoom in on images, I've implemented a pretty standard 3D camera with projection and view matrices. I've found really understanding projection to be difficult. It's one thing to get some cubes placed and rendering in the world, it's another thing to enable mouse interactions, where you have to project and unproject between screen space, view space and world space.
Figuring out the steps for transitioning between the spaces has been difficult, but a nice consequence is that I'm developing a mental model of what is happening on screen that I can reason about. The idea is that the screen reperesents a flat window onto 3D space that extends behind it. I'm starting to be able to intuitively reason about when I can keep something in screen space (the cursor), and when I want to project it into world space (creating a bounding box on an image). Mouse-directed zoom (as movement along a ray projected from the mouse), took me a while to get right, but now I feel like I have a better handle on what it is doing then when I've implemented it in a non-3D camera set-up.
When I have done image editors with zoom in the past, things have always gotten messy while dealing with translation and zoom. Now I feel like maybe that is because I was mixing 2D and 3D concepts. Placing images in 3D perspective space with a camera has required a lot of set-up, but I'm now starting to believe it will really pay off.
In my Linux set-up, I use dmenu as an application launcher. dmenu is basically autocomplete for applications and scripts. In many ways, it's not so different from launching things using Spotlight on a Mac.
Opening 750words.com with dmenu and a launcher script.
Since I started using it, dmenu has been a convenient way to launch apps. But I've only recently started to realize some of the interesting things it makes possible. A lot of the possibilities come down to the limitations of the interface, and how agnostic it is about what it launches.
I've been thinking a lot about Joseph White's talk on his motivations for making the PICO-8 fantasy console. There's so much in the talk that resonates with what I've been thinking about for Constraint Systems: about how carefully selected constraints change the feel of working, making it feel more focused, and even cozy.
Since viewing the talk I've been thinking a lot about how he frames PICO-8 with the idea of a fantasy console and cartridges, and what I could do for framing Constraint Systems. I've toyed with the idea of making the Constraint Systems homepage into a simulation of a fantasy operating system with each experiment as an application. Part of the feeling I want to capture is going to the middle school computer lab in the mid 90s and trying out the strange collection of software the school had preloaded (even though the variety of the internet is great, there is something comforting and cozy in the idea of a finite number of programs to explore).
I had been thinking of the operating system metaphor as a fun, possibly attention-attracting, thing, that I should get around to sometime. After viewing White's talk, however, I think it's something I should prioritize. Framing Constraint Systems as a fantasy computer/operating system could (done well) communicate my vision of the project, and communicate it not in a long text somebody has to read, but as a general vibe. In the best case, they would "get" the project just by looking at the homepage. This is what "branding" is, I suppose, it just feels more tied to the core of the project here than I'm used to thinking of it.
Bushido Blade 2 was a Playstation game I played a lot in high school. It was a fighting game with swords, and its main hook was that instead of health bars, damage was based on where you struck your opponent. You could injure limbs or finish the an opponent with one strike if you hit the right spot.
A kill in Bushido Blade 2
Design-wise, Bushido Blade rethought the premise of a fighting game from first principles. I love what this approach allowed them to do in terms of immersion: during a fight, nothing is visible on the screen except the two characters.
Switching between light and dark colorschemes in all terminals using a hotkey.
I recently got instant light and dark color scheme toggle working for all open terminals, including those running Vim. I used a combination of techniques from Pywal and Base16 shell, and learned some things about scripting in Linux and escape sequences along the way.
This thread, by Zach Gage, on how genre conventions serve as interaction shortcuts, got me thinking about how I use Vim conventions in my creative tools at Constraint Systems.
7/ A big part of making games involves working with genre literacy. In game design a key concept is the idea of weight: Every rule you add has a cognitive load on the player, and you must balance the weight of your rules against how meaningful they are to the play experience.
8/ An idea might be great, but if it makes the game unwieldy, ditch it. But genre-conventions are different -- they're weightless. They allow for an increased complexity and nuance in games, because they let designers include a huge number of rules without adding any weight.