Wiley Wiggins

pac mode

Sat, 05 Sep 2026 17:34:36 +0000

(occasionally I will repost a journal entry from the DMK repo here if I think they might be of some general interest. This is one)

I took a break from my task list to try something silly— making pac-man in DMK. As a result some bugs got fixed related to the player actor inheriting stats it shouldn’t, and some new features got added. Actors without any inventory won’t pick stuff up (treasure doesn’t take up inventory space so they could still get that before). There’s now a melee immunity attribute that came in handy for a power-pill invincibility state. The actor random color attribute that used to just be used for color-matched doors and keys etc. can now also just randomly color actors for variety. There are also now some new win conditions, like killing all actors of a type or collecting all items of a type.

I am always torn between trying to make it so the project can make “any” kind of turn based game and avoiding making it too complex (it already is too complex!) and wanting to sort of stretch and flex it as much as I can and see where it breaks and see what assumptions I have about the code are actually wrong.

One thing this prototype surfaced was how hard it was to add another animated sprite to the small collection that exist (fire, mist, liquid) since I didn’t want to have a lot of animated sprites initially, but some felt important from the start. Instead of having these be data driven by sprites, they were hard coded in a bunch of places that made adding more a chore. I don’t know if I want to encourage adding a bunch of custom animated sprites to prototypes but I see no reason why I shouldn’t make it possible and relatively easy. So there you go. One day there may be a database of common assets that designers can upload assets to for custom animations and prototype-level listings will facilitate this. For the forseeable future though I really like providing a lego-box of assets and letting designers experiment within those constraints, keeping a unifying look and feel to prototypes, but with a big space for variation within that.

Another pain-point that the prototype exposed (even though I knew it was there already) was the fact that the state actor tints (when you are in a bleeding state you turn red, etc) was only turned on for dark levels. Tinting had initially been used to blend together lights on dark levels, but then I used it to also add state effects that could blend, as well as blend together the tints of adjacent liquids over time (something that is still the biggest performance suck in the project, and which needs to be attended to). On light levels every turn tint calculations needed for blending didn’t occur, so state tints were skipped. Those work now (via updateEntityStateTints()) while the darkness level tint blending remains unchanged. They also use a different blending mode so they’re more effective than the multiply blending that works best for tinted lights.

Finally I found one behavior that was pretty intrinsic to DMK prototypes that I had to override, that a collision between two one-hit-to-kill actors would be decided by who moves first, which seems like a perfectly good default assuming games like checkers are our starting place. But what Pac-Man, where a weak piece always loses except in a special state? Or how about a game like Animals Chess (Jungle) where there is a hierarchy of pieces that takes precidence? Animals chess also has an even more exotic exception- instead of a item/time based state of imperviousness, it has an area on the board where hierarchy is suspended and we return to first-to-attack wins rules.

Both of these turned out to be variations of the same fix. The engine already had melee_immune, which says “this actor can’t be hurt in melee” — the power pill grants it. What was missing was melee_harmless, checked on the attacker instead of the target, now Pac has it as a base state. Ghosts always win the exchange, and the impervious state suppresses it while granting melee_immune, flipping who eats whom for twenty turns and flipping back cleanly when it lapses. That needed one more small thing: states could only ever add attributes via grants_attribute, so I added suppresses_attribute as its counterpart. It wins over any granted state, which felt like the right precedence.

Animals Chess was a surprisingly easy extra get while doing this work. A prototype can now declare rank_order, an array of actor ids weakest to strongest, and captures follow it: higher takes lower, equal ranks trade, and the first entry takes the last. Rank is membership in that list rather than a number stapled to each actor, which I like better than integers scattered across files — inserting a piece mid-hierarchy is a one-line edit, and because the ends of the list are derived rather than hardcoded, the rat-takes-elephant wrap-around isn’t a special case at all. It’s just “first beats last,” and a prototype gets it wherever it decides to put the boundaries. None of it does anything unless rank_order is declared, and unranked actors are exempt, so a rank game can still have ordinary monsters wandering around in it.

What I didn’t build is the half that’s actually specific to Jungle: the trap squares where hierarchy is suspended, the water only the rat may enter, the dens. Those are all tile rules rather than actor rules, and they’re the bigger share of that game and would require their own work sprint. The trap square is interesting though, because it’s the same shape as the power pill from the other direction — a temporary suspension of the normal rule, except triggered by position instead of by an item. If I ever build it I suspect it wants to be a state applied on entering a tile, which would make the two mechanics literally the same machinery. This could be pretty useful in a roguelike, say where anyone in a web or quicksand gets instakilled by an attacker (maybe that’s not a good comparison since those actors also put you in a helpless stuck state, which makes the “who moves first” part moot since you can’t move at all for a while.)

The other thing worth noting: this only gates damage, not what the AI decides to do. Target selection goes through isEnemyOf, which is flat faction membership and knows nothing about rank, so a ranked AI will happily throw its cat at your elephant every turn and bounce off. Making that smart is behavior-library work. It’s a good reminder that “can I hurt this” and “should I attack this” are genuinely different questions and I’ve only answered one of them. Some reusable chunk that lets npc actors know when they are outmatched would be really useful to add to personalities, and could even reuse the player-controlled actor attribute tactician and give it a meaning for npc’s.

guardian.com waking life

Fri, 04 Sep 2026 23:52:24 +0000

link

public posts?

Tue, 01 Sep 2026 09:38:58 +0000

In just a few days I’ll be starting work on an interdisciplinary humanities PhD at Concordia University in Montreal. I’ve spent the last two weeks getting settled in here. It’s lovely here but moving was hard. I thought that when I moved to California and back for my MFA work, that would be the last move I had in me. Naturally I would have to stay in Texas to be near my mother. When I got back I found, like a lot of my friends had, that Austin had become pretty uninhabitable to me outside the bubble of my own house. Outrageous prices, political hostility, ecological precarity, and most of all a lack of meaningful, stable work. I started compacting down with the rest of the sediment at the bottom of a deep lake of depression that was only allievated by continuing the work that I had started at UCLA— mainly three large writing projects, one expanding from each of the chapters of the thesis I had written. Small game prototypes supported each project. I had a little survey show of some of these early projects at The Museum of Human Achievement in 2024, and one of those prototypes has now ballooned up into a toolkit for making dungeon games that I hope to develop into a sort of Bitsy for roguelikes. I also gave a talk to my friend and past advisor Danny Snelson’s electronic literature class about interactive fiction and uses of the text parser. Danny and I also had a productive prototyping sprint on a strange narrative documentary soccer game(?) And finally, I spent this summer deep in researching and writing a long essay about future imaginaries and The Tower of Babel for a new outlet of the UCLA Game Lab in development.

Looking back I’ve kept almost feverishly busy! But I let this feed wither and die into impersonal software development changelogs that were better kept in git repos than posted online. I think the main reason for this has been a sort of depression about the state of the web, where the only engagement you seem to get any more is having your work scraped for content by bots, or “bad actors” actively looking for personal information to outright attack you with. It’s sad because the web is still the place where I want to make things. There’s something generative to me about the idea that a stranger may stumble on something I make and have a connection with it without my ever interacting with them directly. One of the projects I had looked at but wasn’t able to pursue over the summer was archiving and restoring the early flash works of my friend Divya Srinivasan, who was an animator on Waking Life and is now a successful children’s picture book author. Her personal site circa 2000 was a very intimate web of photography, minimal animations and sparse writing, and I remember really loving exploring it during that time, and feel like it should be part of the canon of Net Art. Divya agreed to have the work archived and restored but became reluctant whenever any sort of promotion of the work was brought up. For her what activated the work was the encounter a person would have finding it and interacting with it as an anonymous thing discovered. I really understand that, that was what made Net Art interesting to me, especially projects like JODI, while they were still totally mysterious.

My first class at Concordia is called “Materializing Design,” and it’s a course designed by Dr. Rilla Khaled, adapted and taught by my advisor Dr. Pippin Barr. Part of the course is developing an approach to “Annotated Portfolios” in a software context. In practice this means adopting a set of versioning habits, and incorporating journals into git repos as opposed to just dry changelogs, surfacing design thinking. This is actually sort of like what I was doing for a while with this feed. I’ve pre-emptively started journaling inside the repo for Dungeon Mode Kit, after having copied early posts and changelogs there. I’ve stopped posting changelogs here.

That leaves me with what to do with this feed? I could use it to announce released things, but for all of the work I do, how often does anything ever actually come out? I keep a personal journal in obsidian now with sense memories of each day to try to keep me connected to my body and the world rather than just rattling around inside the prision of my own skull, but I would never share that on a site called “WILEYWIGGINS.COM”… a relic of an earlier thirstier and chattier internet.

I’m going to play it by ear and try to remember what feels correct to share with that invisible person who stumbles into a space I’ve created.

Hello from Montreal, I love it here so far but miss my family and cats. I got a somewhat fancy camera and as soon as I become bold enough to walk around with it hanging off my neck I’ll post some photos to /photos/ (especially when it starts snowing, which as a Texan terrifies me)

Slowing Down

Mon, 10 Aug 2026 00:00:00 +0000

Slowing down

“We build our computers the way we build our cities—over time, without a plan, on top of ruins.” ― Ellen Ullman, Life in Code: A Personal History of Technology

Dungeon Mode Kit is a tileset, sound fx sprite (of sounds mostly made by recording and manipulating one real instrument), and scripts that sit on top of some existing javascript libraries (ROT.js, PIXI.js Tween.js and Howler.js) to allow for the quick prototyping of games (primarily turn-based roguelikes) using the free tilemap editor Tiled and human-readable data files that are separate from code. The ultimate goal would be an online suite of tools with their own tilemap editor, similar to Bitsy. Where DMK diverges from Bitsy is that it allows the creation of games with mixed procedurally generated maps and authored maps. ZZT is also an inspiration.

This project is intended to help me make small game prototypes that would play embedded in a piece of writing about dungeons as part of my doctoral research at Concordia University in Montreal. I would love if it was useful to other game designers, too, and I hope to find people to collaborate with on its development.

I’m an amateur programmer with a little bit of Unity C#, python, and javascript experience, but I’m primarily interested in recombining a handful of elements lego-style to get different results. I don’t like the brittleness of programming itself and would prefer to play with building blocks rather than spend all my time tooling them. Remembering how absolutely crushed I was for time during my MFA work, I rushed a lot of this project ahead of time so I could avoid programming rabbit holes going forward and focus on design. I’ve decided to slow down now that I’ve reached a point where the basic functionality is all there. I’ve included some changelogs and blog posts from the prior development in the repo itself, in an attempt to gradually adopt methods for my first coursework at Concordia— “Materializing Design.” I’ll continue to develop this practice of documentation as I go. Going forward the bland and overstuffed changelog posts I was doing previously will be replaced with more granular reflections of the process, git commits will contain the changelog info which will continue to roughly stick to it’s existing format. My version numbers have always been pretty arbitrary at this experimental stage, but once I declare a “1.0” I’ll start organizing features and bugs into major, minor, and patch releases.

All that being said, here is my design struggle for DMK v 1.17b, which was entirely an under-the-hood data organizational structure naming sprint, starting with the idea (I keep features, tweaks and bugs to work on in a messy document called IDEAS.md) and moving through my reasoning and the resulting work. This was a big refactor but I tried to be intentional and talk through what happened here instead of just leaving a sus changelog.

applyState() revisit

Right now the applyState method only works on sentient or controlled actors, but that is not good design for something just called applyState. there should be an additional method for sentient controlled actors that uses applyState so we can still make up new states for inanimate actors.

this suggests:

Actor types

A type would be a set of actor defaults that individual actors could apply through an attribute, which would set a lot of things that would be tedious to apply to each actor. For instance ‘beast’ could be a type that would add things like state immunities, a personality, stats and attributes. A ‘dog’ actor could have type: “beast” and then any actor data would supplement or override “beast.”
Would there be a types.json or would this be additional information in actors.json?

Here’s where this gets hard

The word ‘type’ was very overloaded in the codebase. I’m getting into one of the big design problems that always happens in codebases that start to scale up: an overabundance of generic sounding names. ‘Type’, ‘group’, ‘collection’, ‘category’, ‘container’ etc, etc. Both visual design and information design are problems of juggling quantities and finding distinct and appropriate containers for them. I come from a css background and this is one of the first problems you learn to tackle. What are containers called, how do they communicate things like hierarchy and containership visually (if they are visible.) What do they mean and how do they keep their contents manageable

In DMK we have Entities, which are a root class that both Actors and Items inherit from, and Entities already had a type — except it didn’t mean “what kind of thing is this,” it meant “which entry in the data file is this.” actor.type was 'goblin'. item.type was 'health_potion'. Prototypes (another generic sounding classification) have an item_catalog which calls potion and scroll categories (another generic container word, it can’t be avoided), adjectives.json and attacks.json (word lists that themselves have questionable names) sort their words into categories too, and Object.keys(prototypeActors) gets called prototypeActorTypes — the ids again. So three different jobs, two words, no agreement about which was which.

I went looking for a free word and didn’t much like what was available. kind was taken by the targeting system. nature, stock and mold all turn up inside the word lists that generate item names, which is exactly the kind of collision that produces a “mold potion of mold.” archetype was the one word that wasn’t used anywhere in the repo, but it felt heavy, didn’t communicate much other than add some Jung vibes that I don’t want to inherit. I also didn’t want to call something one thing in the data files and something else in the code.

My solution was to reorder some of the naming conventions rather than keep adding to the pile. The category concept got the word type, because that’s the word a designer reaches for when they write "type": "beast" in a JSON file, and the data files are the surface I care first about keeping legible. The id keeps Entity.type for now, and the type is resolved away before an Actor is ever constructed — merged into a flat definition, so nothing downstream has to know types exist (if I had to use archetype as another word I would probably add it here—meaning “a more primitive type than type”). That leaves exactly one awkward phrase in the engine, actor.data.type, and accomplishes the main feature without a bigger refactor (for now).

The naming mess had already made one decision for me. I’d wondered whether types should just live in actors.json as specially marked entries, which would mean one less file. They can’t, because prototypeActorTypes collects every key in that file and the spawner drops one to three of each into the level. Type definitions would have wandered around the dungeon as monsters. So a badly named variable turned out to be load bearing in a way I didn’t expect, and types got their own file.

Once it worked I could see what the tedium had been costing me. Skeletons were flammable and could be poisoned, which is silly for a bag of dry bones. states.json has had a poison_immune flag the whole time and not one actor ever declared it, because setting it by hand on every skeleton and ghast and wraith was more bother than the effect was worth. Now undead says it once. That’s the whole argument for types in a single example, and it’s the kind of thing I only notice after the tedious version stops being the only option.

Currently there are generic items that serve as containers for random individual items— randomized potions, food, staffs etc. The category knows its members but no member knows its category. Extending types to items could cut down on the amount of redundant item data and still support the random item placement code.

types.json already has a domain field sitting unused, and the merge code doesn’t care whether it’s handed an actor or an item. What I don’t know yet is whether an item type and an actor type are really the same idea or just two things that happen to merge the same way, and I’d rather find that out by trying it on items than by reasoning about it in advance. My thought is that you might place a random beast the same way you place a random potion, but that you’d want to define that placing pool in the prototype not in the types of all beasts or all potions. So maybe the random placement pool is a separate thing from types, but types are the same idea for both items and actors.

Also Entity.type still holds the id, so an actor’s type has to be read as actor.data.type. Need to make it Entity.id and give type back to the category.

DMK 1.16b

Fri, 31 Jul 2026 18:35:58 +0000

[1.16b]

Added

“Infrastructure sight” folded into magic mapping
degrading/breaking items (mattock is the test case)
new “palladian” map generator for boss/artifact areas
Biome editor (editors/biome-editor.html) and a shared biome library. Biomes are now data files like actors and items: defaults in data/biomes.json, per-prototype additions/overrides in prototypes/<name>/biomes.json. prototype.json only names them in its floor_plan. See docs/BIOMES.md.
data/prototypes.json, an index of the prototype folders. Static HTTP can’t list a directory, so the editors read it to fill their prototype dropdowns — previously four editors each carried a hardcoded list, all of them out of date. Add a line here when you add a prototype.

Fixed

Exploration (map memory) is no longer lost when you revisit a floor
Item colors are named in text feedback
treasure_room now reads the resolved floor mechanics, so a biome or floor override can set its own rate — previously only the prototype-level value applied.

Changed

Moved biome editing to its own devoted editor, just apply them in the floorplan section of prototype-editor
Torch fuel amount can be set from item data, which sets a precedent for other timed consumable items.
“walk_description” attribute is extended to Actors as well as Entities

DMK 1.15b

Wed, 22 Jul 2026 18:35:58 +0000

Added

Biomes (depth-ramping): a multi-floor prototype can now define a biome — a themed bundle of depth-ranged spawn/item/hazard catalogs — and assign it to floor ranges via floor_plan.
Drink-at-self potions: a new use_at_self item attribute lets a potion that normally only does something when thrown (e.g. the potion of incineration) be drunk anyway — it triggers its own break/explosion effect on the drinker’s tile.

Changed

Prototype editor cleanup sweep: a pass over the whole prototype editor to cut clutter and make implicit settings implicit.

Fixed

More corridors
Better room distribution

DMK 1.13b

Thu, 02 Jul 2026 11:00:56 +0000

Added

Goblin ambushers + reach weapons: a new goblin_spearman actor (with the goblin_ambusher personality) lies in wait just inside a room beside its entryway and only springs when the player comes into view — otherwise it seeks out the nearest ambush spot rather than wandering.
Opt-in auto-wear on pickup: a new auto_wear item attribute makes specific wearables (e.g. the crown) equip automatically when picked up, while everything else stays manual.
render_layer actor attribute: an actor can declare render_layer: "bottom" (or "top") to control how its sprite stack orders against other actors sharing its tile, instead of relying on sprite insertion order.
tiled-key visual reference of tiles that spawn actors or generate random dungeons in map.tmj

Fixed

Fire trap instant-kill: stepping on a fire trap could instantly kill a full-health player instead of dealing ~8 damage. Two separate causes: fire damage now caps at once per victim per turn (overlapping/spawning/adjacent fires can no longer stack many 8-damage hits in a single turn), and — the actual killer — the ignites spawn logic no longer instantly incinerates living creatures (actors with a health stat) as if they were flammable scenery; creatures burn for damage over time, only inert flammables (trees, webs, bridges) are consumed into fire. Fire also dedupes to one actor per tile.
Flying actors & ground hazards: a flying actor hovering over a collapsible floor no longer collapses it
Dart turret only fired once and couldn’t be attacked
Monsters ignoring or freezing near the player: melee monsters (goblins, rats, jackals, etc.) now retaliate against an attacker they can’t currently see (added the defend_self behavior to the melee personalities), instead of only chasing by line-of-sight.
Hallucination/confusion cleared on level change: falling or taking stairs to another floor while hallucinating (or confused) no longer drops the full-scene visual effect.

DMK 1.11b

Fri, 12 Jun 2026 17:34:36 +0000

Added

Prototype win screen: a prototype can declare a top-level win_state (distinct from per-floor win_conditions) that ends the game when met. The win screen fills the canvas with white full-block tiles running the new gradient_wave color-cycle effect (horizontal red/gold/blue bands scrolling upward) and writes the completion message in letter tiles over it. Terminal — input and turns lock. Demoed on the Combat Arena (arena.html): defeat the Minotaur to win. Designed to display tracked stats (kills, gold, etc.) on the screen later.
Reusable gradient_wave effect: a new data-driven effect primitive (in effects.js + data/effects.json) that tints sprites with scrolling horizontal color bands from an arbitrary colors palette (cycled as a ring). Available to any prototype or actor like the other named effects.
Roguelike amulet-escape win: the dungeon prototype now has the classic win condition. The Amulet of Yendor spawns on the last floor; carry it back to floor 1 and use the sealed exit to win (“You have escaped with the Amulet of Yendor”). The floor-1 up-stairway is the locked escape exit — bumping it without the amulet rejects you (“The exit is sealed. You need the Amulet of Yendor.”), and an authored up_stairway placed on the map is automatically converted to the sealed exit (locked, solid, and re-skinned to the Sealed Stairs sprite), so designers can position it freely. Implemented as an escape-style win_state (via: "escape"), an extension of the win-screen system above — the escape is triggered deliberately by using the exit, not the instant the amulet is picked up. The dungeon’s old caverns transition is removed; the amulet is now the only way out.

Fixed

Silent loading events: events that fire while a level is loading (before the player clicks to start play) no longer leak sounds or messages — fixes the spurious “The Sealed Stairs opens.” that printed at game start for levels with authored locked stairways.
Escape exit no longer unlocked by floor win conditions: the dungeon’s floor-1 escape exit is gated solely by the amulet (the prototype win_state), so it is now exempt from the per-floor win-condition lock/unlock system — previously, satisfying floor 1’s (empty) win_conditions by, e.g., killing a monster would wrongly open it. The sealed look and lock also persist correctly when returning to floor 1 after descending.

DMK 1.10b

Sat, 06 Jun 2026 14:26:46 +0000

Added

Overlay layer transparency: tiles on the authored overlay map layer (used for outdoor levels with tall structures) now go translucent when an actor passes behind them, the same way actor “height” tiles already did. Reveals the actor’s full two-tile footprint; applies to controlled actors, NPCs, doors, stairways, and gateways.
Locked stairways are a locked pair: when a level’s down-stairway is sealed by an unmet win condition, the matching up-stairway on the level below is now locked too. Previously a player who fell between levels (bypassing the stairs) could simply walk back up through a stairway that should still be sealed. The pair stays in sync — meeting or re-breaking the win condition unlocks/re-locks both halves, including on levels visited earlier or not yet visited.
Generic (any-key) locked doors: designers can author a simple, unpaired lock. A locked door with lockable but no color_locked (or the new generic_locked_door actor) is opened by any key, and any key can open any generic locked door — alongside the existing color-paired key/door system. Stairways and gates remain key-proof.
Per-object default_items override: an actor object placed in a Tiled actors layer can set a default_items custom property to override the starting inventory for that one placement (JSON array, comma-separated list, or empty to hold nothing). For example, a pedestal can be made to hold a crown instead of its default key — no new actor type needed. See docs/MAP.md.

Fixed

Deep water submersion: restored the missing deep attribute on the deep_water actor, so traversing deep water once again submerges the player (a regression that left submersion working only for deep sewage, while the float-items behavior still worked for both).
Input during collapsing-floor fall: player input is now blocked during the pause when a collapsable floor activates, so the character can no longer move again before falling to the next level.
Stairway naming: unlocking a stairway no longer mislabels it “Stairs Down” regardless of direction; up-stairways are now correctly named.
Keys open doors, not stairways or gates: a key bumped against a locked actor now only unlocks doors — either the color-matched locked_door it’s paired to, or any generic locked door. Previously a carried key would silently unlock any openable+locked actor on contact — including win-condition-sealed stairways and switch-driven gates — which let complex levels (key → door → crown → win condition → stairway) be short-circuited.
Key/door colors pair regardless of spawn order: a key and its color-locked door now always share a color, even when the key is authored before its door on the map (e.g. a pedestal key listed ahead of the door). Previously the key’s color was assigned at spawn time from a not-yet-populated queue, so a key placed before its door got a mismatched random color and couldn’t open it. Pairing is now reconciled once after all doors and keys are placed.

DMK 1.8b

Wed, 20 May 2026 15:54:56 +0000

[1.8b] 2026-05-20

Added

Switches There’s now a switchable actor attribute that we are using for levers and trap-style pressure plates. These use either proximity or a “machine-id” attribute to activate actors like gates. switch_effects picks what target attributes are effected and switch_message sets the text feedback. The default lever and pressure plate actors are used by architect for some treasure room variation but this needs lots of testing.
New Maze Generator (see in progress) Trying a more Brogue-like approach than the previous “digger” type, needs testing.
Collapsable Floor actor lots of work around the platform actor attribute, which was just a stub before

Fixed

bug where dead actors became visible again after leaving and reentering the viewport
blinking to an invalid spot goes as far as it can now instead of failing in an ugly way
torch light appears same turn they are lit
burning condition displays correctly now
when confused you are no longer only warned when you are actually about to step on a hazard
invisible playable characters are translucent, npcs are invisible and hidden from sidebar

Wiley Wiggins

pac mode

guardian.com waking life

public posts?

Slowing Down

Slowing down

applyState() revisit

Actor types

Here’s where this gets hard

Next

DMK 1.16b

[1.16b]

Added

Fixed

Changed

DMK 1.15b

Added

Changed

Fixed

DMK 1.13b

Added

Fixed

DMK 1.11b

Added

Fixed

DMK 1.10b

Added

Fixed

DMK 1.8b

[1.8b] 2026-05-20

Added

Fixed