Mark Rogers

UniverseGenerator came out for .NET and Unity in October. Version 1.0.0 of the TypeScript port is now on npm as universe-generator and on JSR as @m4bwav/universe-generator. A seed gives the same galaxy in a browser as it does in C#, down to the names.

The map below is made by the npm package in your browser while the page loads. Type a seed, pick a preset and click a star.

import {generateGalaxy} from 'universe-generator';

const galaxy = generateGalaxy('my-seed');
console.log(galaxy.shape, galaxy.regions[0].name); // Ring Musca Drift

Same seed, same galaxy

The C# library promised that a seed produces the same output on every platform. The port had to keep that promise across languages, so the C# repository's golden files are the test suite. Each one records what a seed made in C#, and the TypeScript output has to match it exactly. No golden was edited to make a test pass.

UniverseGenerator 1.0.0 is out on NuGet and OpenUPM. Give it a seed and it builds a universe, galaxy clusters, galaxies, star systems, planets and moons as plain C# records. The same seed gives the same output on Windows, Linux and macOS, on .NET 10 and .NET Framework 4.8, and in Unity under both Mono and IL2CPP.

using UniverseGeneration;

var galaxy = Galaxy.Generate("my-seed");
foreach (var system in galaxy.Systems)
    Console.WriteLine($"{system.Name}: {system.Star.Class} star, {system.Planets.Count} planets, danger {system.Danger}");

HD 147927: K star, 6 planets, danger 9
HD 165595: M star, 1 planets, danger 6
HD 28101: K star, 6 planets, danger 6
...

Where it came from

My game SpaceDeckBuilder2 has a galaxy generator of about 1,400 lines. On October 2 I asked how many other projects generate game worlds like it, and whether it should be a library. The answer became an extraction plan, and the library shipped two days later.

Most of what I've built since late August comes from one annoyance. A coding agent learns something on Monday (a port, a quirk in a build tool, why a test fails on Windows) and on Tuesday a fresh session learns it all over again. Everything below is an attempt to make that stop, or a side effect of trying.

Write it down where any tool can read it

Everlast gives each project an ai-docs/ folder: a short handoff, an append-only log, decisions, dead ends and plans. Facts about me and my machines go in a private vault instead of a repository. The record lives on disk as plain markdown. A session in Claude Code, Copilot or Codex can pick up the work from it without relying on any one tool's memory. It reached 0.6.1 today.

Evergreen is the same idea applied to skills. An agent skill is a set of instructions, and instructions about fast-moving tools go stale. An evergreen skill carries its research notes, a changelog, a learnings file and an eval suite, plus a schedule for checking its claims against primary sources again. Version 0.15.0 (October 2) added setup checks, so a skill can say what it needs (a tool, an API key, a local server, access to a database) and walk you through getting it.

Recently I had the great fortune to read Schismatrix Plus by Bruce Sterling and I was truly impressed. This is another of those gems like the Culture series by Ian M. Banks or the Xeelee sequence by Stephen Baxter, that for some reason never won the highest honors of written Sci-fi. I would like to think that if Schismatrix Plus was published for the first time today, it might get more accolades than it did during its original publication, because cyberpunk and space-operas are more well-understood and accepted serious genres today, than they were in general in the early 80s. Schismatrix Plus is essentially an omnibus edition that contains the original novel Schismatrix and the other short stories that take place within the Schismatrix universe.

NodeJS and npm are among the fastest growing development platforms and communities. This is primarliy because NodeJs as its name implies is a javascript-based development ecosystem, which takes advantage of the fact that javascript is one of the most widely used languages today. While I don't have any links, I wouldn't be surprised if some metrics show javascript as the most widely understood programming language. Almost every developer learns javascript because almost every developer at least attempts to build a javascript-enhanced webpage at some point. For this reason, I thought it would be a good idea to make some npm packages so that I could gain some mastery over the NodeJS ecosystem. I had worked with NodeJS in the past to setup a integration test system and to use various common or custom command line tools, but I had never created a package.

Recently I decided to check out F# and make a nuget package with it to sample the language. I've heard a lot about F# over the years, so why not take the language for a test drive and see what all the fuss is about. To me creating a semi-useful NuGet (or npm, or whatever) package is a proof-positive way to demonstrate basic skills in a language, framework, or platform.

Wikipedia says that F# is a "is a strongly typed, multi-paradigm programming language that encompasses functional, imperative, and object-oriented programming techniques", which is a both a helpful and unhelpful description that sounds like the language could have almost any feature. To some extent that's true, like C#, F# borrows from other 'paradigms' so that its has a wide mixture of language features. While F# supports "functional, imperative, and object-oriented programming techniques", its is intended as a "functional-first language" language, meaning that while you can use it like in an imperative or object-oriented way like C#, its intended usage style is as a functional language. Functional Programming is paradigm where most of the code is broken down into a series of function evaluations rather than focusing on state as in object-oriented programming.

I've been meaning to replace my old blog for a long time now, but I was dreading getting my hands dirty with it. I made the original blog more than 5 years ago back when Asp.net MVC was still being developed and my blog had been based on an early example of a blog called oxite.

My primary motivation in using the oxite blog was to prove to myself and others that I at least understood how to modify and deploy an asp.net MVC website, which the exercise more or less did. The problem was that the oxite sample was not particularly rigorous, as it was intended more as an example, and to make matters worse eventually later versions of Asp.net MVC made the blog sample more or less obsolete. Also, I later learned there was some sort of security hole, probably sql injection, in the comments section or perhaps elsewhere, and I had to make the comments readonly, further declining the utility of the blog. To add to all of that, its base design was not particularly pretty compared with the responsive mobile designs of today. I decided that I needed to scrap the site and start over with a new system, preferably a CMS, but there are so many, which one to choose?

One thing in particular I found missing, was that when you are implementing searching you have to be able to translate the search operator codes sent by the grid to the server into something you can use on the server side. One mildly frustrating problem was that the documentation only lists 9 of the 14 total search operator codes that you have to translate.

I'll list the rest of the codes here:

bn - not begins with ( !(LIKE val%) )
in - is in ( checks if the searchField is in the searchString )
ni - is not in (checks if the searchField is not in the searchString )
en - does not end with (!(LIKE %val) )
nc - does not contain (!(LIKE %val%))

While I was working on my current project, I found I needed the ability to generate a name randomly. Pretty simple task, but I have been unable to google a free .net random name generating library that I could use. After reading this question, I came to the conclusion that no such library exists. So I decided to make one myself, and give it out for free in the hopes that it might generate a few hits.

You can try it on the tools page, which runs the current version of the library.

You can get the library using nuget (Nuget Project Page), or you can download a zip file containing the DLL here.

One of the main reasons I setup my own custom site, was to begin experimenting with SEO. Search engine optimization is one of the primary ways to get new surfers to your website.

What does that mean in practice?

Trying to figure out ways to get your website listed higher in google search results.

Usually this is done by getting people to link to you, as well as creating content for your website. Preferably content that is actually useful to someone other than yourself. Part of the motivation for this very post, in fact :p.

Other than creating content, I have also signed up for google's Web Master Tools, and Analytics. I don't know if I've ever come across a serious web page that did not use google analytics, and I figured that google might rank me higher simply by having more information about my website. Also I added a robots.txt to help the robots crawl the website, and soon I'll be adding a site map.

I was looking into how SchemaExport and SchemaUpdate work for NHibernate.Tool.hbm2ddl. I'm about to put another website up and I wanted to be able to generate the database schema for the new site, instead of creating the tables by hand. I've done this for a couple applications before, but I have to admit to only vaguely understanding how hbm2ddl works. This is probably do to the almost total lack of documentation on these features, outside of a quick run-down in the nhibernate docs .

At first glance it looks like Export generates SQL create table statements, and SchemaUpdate generates a bunch of update statements. But one thing I was curious about was whether or not SchemaUpdate would create new tables if they didn't exist. After looking at the current nhibernate source code, it appears that SchemaUpdate iterates through each table and if the table exists in the destination database then it generates an update script, otherwise it generates a create script.

Currently I'm trying to create a single-sign on solution, and I was having trouble because sometimes (but not always) the encrypted text would fail to decrypt. I found out that the later .net versions have stricter checking for valid characters. So when the encrypted byte array was converted to a string, the encoding process would create characters that the stricter decoding process did not like. This article on msdn's .net security blog finally helped me out.

In the current project I'm working on, I need to create a lot of configuration/data files for when the application builds the database (Fluent-Nhibernate). This appears necessary because the application must populate the database with some default mostly static domain objects that are required for the application to begin working normally.

The two main .net json Beautifiers were Jayrock, and the C# source code of a "quick and dirty" json pretty printer by Raymond Glover. I actually like Raymond's a little better, because Jayrock is more of a general purpose Json library rather than being focused on pretty printing.

Raymond's was cool, but I wanted one that would conform exactly to a specific json beautifier JsonLint. Seeing how short and easy it was for Raymond, I decided to write my own json beautifier/pretty printer and wire it up to my blog. I think I mostly wanted an excuse to use the strategy pattern in a situation where it appeared to be needed.