About Materia Magica
Materia Magica is a MUD: a text-based online fantasy world that has been running continuously since 1996, back when the way you played an MMO was by typing into a telnet session. Its world runs on its own calendar, has two moons named Trigael and Marabah (one changes phase every five and a half hours, the other every three and a half), portals that open and close with those phases, a skill system whose damage types include Sonic, Necromantic and Time-Paradox, and a world map that is, topologically, a donut. People have been living in it for almost thirty years, and much of the extended team played the game long before they worked on it.
Here is the org chart, truthfully. Materia Magica has its own team and its own publisher. Its web development is handled by Rugged Software, a contracting agency, and Rugged brought in KACHOW! as subcontractors. I have shipped on this game for a year, and in that year I have never once spoken to anyone at Materia Magica! Every brief, review and huddle runs through Dan Hampton at Rugged, whose PR feedback is genuinely valuable and whose enthusiasm for the game is contagious. It is the deepest subcontract I have worked on, and one of my favorite working relationships.
The ask
The game needed "a visually interesting animation that conveys lunar data" about its two moons, since the moons affect gameplay. The brief came with homework attached: in-game lore files on the two moons, Trigael and Marabah, as well as information about portals, known as worldgates, that can teleport you to other realms, and an adventuring guide about the general world of Alyria.
In the game, you check the moons by typing TIME, but in the effort to modernize the game's website, the team expressed a desire for the same information as an interactive instrument on the homepage.
The process
In Materia Magica the moons are mechanics: waxing and full phases speed up spell regeneration, and specific phase pairings open worldgates at specific stone circles. That is not just flavor text; it is scheduling information players plan around. In fact, a player clan published their own lunar predictor that renders the next dozen gate openings as a table of rows:

So the centerpiece became an instrument: a brass astrolabe that tells Alyrian time, tracks both moons through their phases, opens little shuttered windows onto wherever the worldgates currently stand, and counts spell regeneration underneath.
Sketches
Dan came in with some ideas of his own. One was the game's cosmology in three dimensions: a digital version of an orrery. The other was a gnomish contraption I likened to an atompunk device, with multiple panels for primary information, effect intensity, a lunar orbit diagram, and a forecast list.
| The cosmology | The dashboard |
|---|---|
![]() | ![]() |
The question became: do we want this to be a cool digital representation of what's in the game or for it to feel like a physical artifact a character might have in the world?
Personally, I loved the idea of making an artifact. If part of the purpose of the clock was to develop the visual narrative of the world, why not lean into the lore building?
The reference I kept coming back to was Prague's Orloj, which has been telling a medieval city the hour (in four types of calendars), the zodiac, and the phase of the moon on a single dial since 1410. Alongside it sat a seventeenth-century French manuscript of the twelve lunar phases, gold and blue in a ring, which is where the palette came from. I was also inspired by moon phase watches, the complication where a disc with two painted moons turns behind a little window in the dial, so the moon you see is always in the right phase. You can easily use this mechanism with two overlapping moons.

So with these inspirations in mind, I went to sketching. First I had to work out what we had and how everything relates.
Turns out with a system like this there's actually a lot of arithmetic to go through: how many phases there are and where the moons sit in relation to each other (eight phases, one every 5.5 hours for Trigael and 3.5 for Marabah), whether the moons should sit in apertures or ride the dial, whether it should be a clock at all or rather a device like an orrery.

The ones we liked the most were the orrery, where the moons ride their orbits and the phases sit along the path, and a town clock similar to the Orloj with a moon phase dial. So then I made medium-fidelity Figma versions of them:
| The orrery | The orrery, with a slider | The clock |
|---|---|---|
![]() | ![]() | ![]() |
After seeing them more sketched out, we decided to go full force on the town clock idea.
As an intellectual exercise, I tried iterating on the layout with ChatGPT.
I fed it the medium-fidelity option on the far right above and a description a clockmaker could have built from: numerals I to XII around the border, two moon apertures with waxing, full and waning inscribed around each, two little map globes with a star on a landmark, and a curved "Spell regeneration at" band over an odometer reading 125%. (I still thought the phases were six and four hours at that point.) It really did not understand the concept! Every render came back with the numerals out of order, the hands crooked, and the apertures somewhere new.
After a few passes it diagnosed the problem itself: the image tool "wants to pretty it up" and fights any precise mechanical layout. It offered to draw me an SVG blueprint instead, and the file link said "file not found." Which is how the blueprint ended up on paper, and then in PixiJS, where nothing gets prettied up unless I say so.

Safe to say I gave up on ChatGPT rather quickly (and rather annoyed).
And a good thing too, because the client was exceedingly clear that they didn't want any AI art!
Preparing the game data
So far we've only talked about design, but I was also hired for my software engineering know-how to hook up my own design to the game data.
The game's world data lives in decades-old area files and C tables, and the marketing site is built in PHP and Laravel. As a non-game dev, I had read access to the game codebase but no write access, so any work I had to do was simply fetching from what exists and transforming it rather than changing how the game code works at all. So the first month of my work was dusting off my computer science degree to:
- read C code with more linked lists than I had ever seen in a production codebase before
- take said linked lists of map data and write scripts we can run to transform changes to the map into arrays of JSON for frontend consumption
- write parsers and collections for reading in said JSON map data
- write parsers and collections for reading in game data in an arbitrarily defined format in
.datfiles - write CLI commands for operations, such as finding the coordinates of a location from within the greater map and generating thumbnails of what that looks like on the map (for the worldgate tiles)
- write scripts that generate constant files of worldgate coordinates and moon phase tables found in the C game codebase to be used for the Laravel web app
- write utils for Alyrian time conversion (time is spat out of the game codebase as a string that needs to be parsed)
- write a database seeder that creates believable mock data based on real game data information so the clock can be run locally
- write a cron job that grabs the current game state on a ticker and writes it to the web app's DB
- write an API endpoint intended to be polled for new game state data
- write tests against fixtures cut from the real game files
And this was all largely done without the assistance of AI coding agents. I hadn't written PHP for nearly two decades and had certainly never written anything in Laravel. I hadn't adopted AI into my coding workflow yet, and generally I was so fascinated with this project I wanted to write it myself anyway and understand what I was writing.
Once I had wired up the backend to my liking, it was time to start figuring out how the clock I had designed would react to all these different parts.
Designing the structure
Every part of the clock started as a vector outline: the numeral ring, the aperture, the label plates, the gears, the hands, the moons. Shapes first, so each one could be judged on its own before any of it looked like a real material.
Hooking it up to data
Before going into high-fidelity designs, I needed to make sure the design was grokkable and animated as well with the data as I had imagined. It's like having low-fidelity UI user testing before letting the users have the chance to complain about colors or font.
So the plain vector shapes were used first as a test.
This of course meant I now had to add to the frontend and:
- write PixiJS code that renders all the clock elements and animates them based on current game state
- write polling functions to listen to changes in game state from the previously created API
- maintain state and update the clock elements accordingly
- (later) introduce slider functionality that fetches a prediction table for the next 24 IRL hours
| This is the first version that ran.PixiJS's default blue background, two flat discs for moons, stick hands, and two debug buttons that randomize the spell regeneration counter and the portal drums so I could test the animations without needing to wait for a change in game state. Game time runs at a minute per second here so the hands visibly move.Ugly on purpose, getting the form down before the chrome. Every moving part could be checked before any of it was drawn properly. |
Those outlines then became clipping masks for material images in Photoshop: a brass texture clipped to the numeral ring, marbled blue and green to the face behind it. All material images were found on stock photo sites, but heavily edited and filtered in Photoshop.
Photoshop's blending modes and layer blending options did the rest, with inner shadows, drop shadows and color overlays turning flat shapes into parts that look like they have thickness and catch light. Because the game didn't have much visual language yet for objects (but had some concept art for characters), I went ham on it, leaning heavily into my inspiration pieces.
Since the moons would overlap each other, we were trying to figure out ways to make both as visible as possible, and landed on the idea that they should be semi-transparent. That's when stained glass came to mind.
Experimenting until we get it right
There were a few aspects we weren't quite sure about yet. For example, how to have a mechanical device transition between wildly different map locations.
The portal windows themselves show map tiles of where each gate leads. I auditioned transitions for the tile swap the way the sketches audition everything (fog, crossfade, mechanical shutter, a wipe we described as "windshield wiper, Brazilian bbq"). Ultimately we went with a fan-out shutter.
Similarly, we were racking our brains on how to give users a way to see future predictions for the moon. We didn't want it to be searchable and we concluded that we wanted it to be part of this magical device we'd created. We were convinced that a slider was the best way, but the clock is circular so any horizontal or vertical slider just didn't look good.
| Here's a montage of the iterations it took to get the clock right, from figuring out the art to figuring out the code. Eight stops along the way, each a screen recording from the day it happened. The very first one I had to resurrect from its commit, since nobody records the ugly version.Flat blue in October. Brass by November. Then barrels, a bug worth keeping, portal windows, fan shutters, and in January the slider bending into a circular dial. |
Try it
Here is the instrument itself, the component lifted out of the game's codebase and running on this page. The reading is real: a snapshot of the game state taken one evening in September 2026, with Trigael a waning crescent, Marabah full, and worldgates standing at Xaventry and Irda. Alyrian time keeps advancing from that moment, because the clock computes it rather than being told it. Drag the dial and it walks forward through the next 24 hours of gate openings, the same forty-eight states the server hands the homepage on every load.
The outcome
The clock merged on Valentine's Day 2026 and is now the first thing every visitor to materiamagica.com sees.
A year in, I still have never met Materia Magica. I just keep shipping through Rugged, and the work keeps coming back. So does the trust: Rugged now includes KACHOW! in its own proposals, in slides Dan built that introduce the extended team by name and school.
Modernizing this game is a monumental and extremely fulfilling project. It has all the work one can imagine from web development to old-school game development, animation work to pixel art and sound design, with interesting, unique problems like translating ASCII art to pixel art, building telnet relays, and parsing mysterious messages and data files. It's a greenfield project with lots of opportunity for trying out new ideas.
I hope I will get to continue to be a part of it!











