July 7, 2019.
So I’m trying something new in the format here.
In the past I was all about bullets and terse drive-by information dumps. But that’s not at all pleasant to read (even for me). And on re-reading those notes I found there was so much context that had been lost.
Advice for indie gamedevs
Cliff Harris (Cliffski) advises indie game devs how to not fail. It’s a harsher tone than most writing in the love & light indie gamedev community. Yet another way the dominant cultures of AAA and indie diverge!
The central themes I picked out were “remove every activity that isn’t literally ‘producing your game’“, and “don’t fool yourself”. The first one is tricky because there are some very fruitful activities that aren’t ‘producing your game’ that you probably should be do quite a bit of. For instance, building a following and marketing your game. But outside of those activities, I totally agree with Cliff’s assessment.
Paul Graham shows and tells us how to write a good essay
Paul Graham’s essay about writing essays got me thinking about trying the writing style he recommends. It’s a pretty wonderful essay - liberating even. I wish I had read it much earlier in life.
I struggled with the same problems Paul mentioned, in high school AP English class: Why indeed is the conclusion just restating the thesis statement from the introduction, just in different words, and so on. I just thought I was a terrible writer. Indeed I was a terrible writer in high school – but the strange “thesis, 3 paragraphs, conclusion” essay format certainly didn’t do me any favors.
Luckily, by the end of college I figured out some hacks to get consistently A’s in that format:
- Search for the most interesting / surprising thesis. This should be 80% of the work. Writing the essay is a cinch once you’ve nailed the thesis.
- Find supporting points for your thesis in the work, but don’t force it
- Massage the overall narrative of your essay until everything fits cleanly - don’t leave any ‘conceptual sharp edges’
- Make the essay ‘interesting’ to read - both at a low level (vary terms, rhythm, style) and a high level (have a few surprises, nail the prose in your conclusion, etc.)
I was satisfied with those A’s - I earned them the honest way under the given constraints. But in retrospect, I wish I had just done it Paul’s way.
Actually, I sort of did. I managed to discover a couple strategies that Paul’s recommends - especially to find the surprising. My best essays surprised me in what they found in a text.
For example, I came up with a fairly standard thesis for “All the Pretty Horses”: the main characters are quintessential Texans, driven by nostalgia to live in denial, acting out a bygone era of cowboys that ended long ago. But I supported that thesis with surprising events from the book that seemed to be throwaways: little moments that most readers ignore, yet point right back at this thesis. That essay worked because when you focused on these subtle moments – and their timing – they not only supported the thesis, they underlined Cormac McCarthy’s mastery of writing. It helped that the prof was a McCarthy fanatic who ate these sorts of things up!
The high school / college essay format is basically useless. Primarily because you don’t see anything good written in that format in adult life. It’s one of those “school-skills” that teaches you half a solution, leaving you adrift to figure out the actually useful part for yourself. (Aside: I think that useless format persists because it makes a class full of essays legible for teachers, and thus easy to grade quickly.)
Besides all that, I find Paul’s writing style very nice. I didn’t use to. Maybe it’s getting older, but there’s something very cozy about a well-presented argument that isn’t shoved down your throat. It’s like having a pleasant conversation with someone instead of a monologue. Even if that ‘conversation’ is only in each of your respective heads!
Thread: Bennett Foddy and others discuss what is a “puzzle” game.
Having now looked at basically every arcade, console and computer puzzle game of the 80s and 90s, I can no longer honestly say I know what a ’puzzle’ is— Bennett (@bfod) July 3, 2019
I love these sort of ‘research hunting expedition’ tweets that pop up on experts’ timelines. It’s this sort of work that helps newbies intermediate folks stretch our understanding and develop skills faster.
Haven’t played much yet, so these aren’t recs, just seemed interesting or different (some have time pressure):— Bennett (@bfod) July 3, 2019
крест (DOS, RU)
Kret (‘mole’) (DOS, PL)
Brainies (SNES, FR)
Builderland (AMI, FR)
Confused? (MSX, NL)
Door Door (FDS, JP)
Hypnotic Lights (INTV, US)
Xi (WSC, JP)
Ilmari Heikkinen sketches an architecture for (cached!) 20ns web browser queries
Some intriguing work by Ilmari Heikkinen on hardcore data-backed website optimization, from the backend to the frontend:
“Turn complex query into view, turn view into manually materialized view, with triggers for incremental updates, cache results in Redis, cache results in Service Worker IndexedDB, make SW continuously access a 256 kB chunk per thread to keep the data in $L2”
Some of that was jargon to me, so I had to unpack it to understand better:
- a complex SQL query
- …wrapped in a view of that same query
- …which is manually materialized - i.e., persisted to disk
- …with triggers for incremental updates to efficiently keep the materialized view in sync
- …with the view cached in Redis to take load off the database
- client-side Service Worker IndexedDB to cache the server-side data in the client
- …continuous reads of 256K chunks to try to force the data to stay resident in the CPU’s L2 cache
- …intending to keep the data in the CPU’s L2 cache to avoid fetching from RAM, and (I’m guessing) as a tradeoff b/c L1 will be thrashed anyways
It’s basically a way to achieve the fastest caching at each level, subject to realistic constraints. As Ilmari states, the goal is ambitious but do-able with this design:
“Query results in 20ns or bust.”
…Assuming the data is already cached in the client and up-to-date, that is.
When I see a design like this, I always think: “how could you create this from first principles?”. You could arrive at this design by working backwards from the L2 cache to the SQL query.
If your app allows for eventual consistency in the frontend, this design will give you instant data after the first round-trip fetch from the server.
A clean architecture for invalidating the cache is another problem altogether, though…
qframe - a tiny, feature-filled API server sandbox
It’s surprisingly full-featured for such a small program.
I can imagine this would be useful as a study of the components that make up an intermediate API server: authentication, users, etc.
Add Lotus Agenda to the list of long-dead-beloved software (alongside HyperCard, Google Reader, etc.). The novel bits (for 1988, mind you!), as I can tease out:
- collect & organize ideas and notes, alongside more structured data: contacts, appointments, etc.
- “promiscuous” (for lack of a better term) categorization - a bit like tags, but with different mechanisms
- automatic, smart categorization - parses dates, so you can just enter a date in a note and it’ll show up on your calendar automatically
- smart tag handling - e.g., establish synonyms: “mod”, “modification”, “enhancement”, etc.
- rules for automatically assigning categories & priorities
According to Mitch Kapor:
“Agenda was all about managing ideas.”
One of my side projects is a micro-PIM. In researching the field, I’ve noticed that whenever journalists use a tool it’s usually a good sign of the tool’s utility 1. As stated by James Fallows so many years ago:
“A significant number of journalists use [Agenda]”.
Mr. Fallows – a journalist – is no slouch in the PIM department. He has written for multiple decades about his evolving use of PIM software on numerous occasions (spanning several generations of computing: DOS, Windows, Web): Agenda (PDF version) (1992), Zoot (1997), Personal Brain, by The Brain (2009), Scapple (2012)
DoodleLens, by Aidan Wolf:
You can now copy full color digital art into doodlelens, coming in the next update! pic.twitter.com/TQNss0H9mi— Aidan Wolf (@Aidan_Wolf) July 6, 2019
Very cool, and completely adorable. When I get some time (and a good use for it), I’d like to recreate the AR bit in Blender (sans the restrictive smartphone & app) and film some more dynamic / interactive scenes.
@darkwark is developing a voxelization script for Aseprite that voxelizes 2D pixel art. 3D sprite in a voxel world:
Working on another script for @aseprite. This one generates 3D voxels based on your current sprite— Kamil (@darkwark) June 29, 2019
There are a few different modes, but the most exciting one is using a height map to generate extrusion:
(MagicaVoxel + Aseprite = 🧡)#screenshotsaturday #MagicaVoxel #gamedev pic.twitter.com/bCsYtoya4n
SpriteStack is a new pixel-oriented voxel editor.
Several suggestions of IF engines, from folks in the IF community:
- Twine (obvs)
- Choicescript - Introduction to Choicescript, a bunch of Choicescript-based games to try online, a CS tutorial written in CS!
- Texture - @TextureWriter
- AXMA -
- Windrift 1/2 -
- ink, from @inkleStudios
These engines appear on the much more comprehensive engine list at the IF Wiki.
There’s overlap between IF, text-based adventures, and scripted / narrative-heavy games (like Night in the Woods). At some point I wanna deconstruct these a bit, and see if there’s a nice simple kernel that could be implemented & reused for other projects. There’s possibly also some insights for the UX of round-trip user-feedback flows on the web (like signup forms, etc.).
Why write the rollup?
If you’ve read this far, thank you!
While writing this, the question of “why?” came up. My motivations:
- to digest the bits that I found interesting enough to want to remember later
- to get better at filtering material that’s relevant to my work
- to share interesting bits (mostly from Twitter) that would go overlooked by others
but not necessarily quality. A tool can be extremely useful but not polished. ↩