Presenting USG:Rerolled

Despite the hardships, I’ve been able to at least occasionally dedicate some time for the continued development of this year’s Finnish Game Jam / Global Game Jam game. Worked alone this time, and still made a nice game. With TypeScript :o
Now, with the continued effort, it’s starting to look pretty good! The game itself is a mix of Dicey Dungeons, Slay the Spire and maybe even FTL - Faster than Light. It’s about dice-rolling and loot in a turn-based combat, from encounter to encounter. Originally it was to have gameplay that would have emulated Cultist Simulator in at least some questionable way, and hence got the name SDC: Slay Dicey Cultists. But then it occurred to me that this could be an excellent chance of carrying on the torch from the project that is my unicorn, The Peli – or as more recently known, USG. So let’s give it up for USG:Rerolled!
The main focus of the game is the equipment, and the many effects the pieces can have. This made me to choose to implement the effects with straight up code, instead of trying to codify all the effects in some kind of standardized structural form. It's been a good choice for productivity. But I dread the day I need to make some kind of breaking chance. I also did some snooping, and found that this is how other games have chosen to approach this problem, too. As the game will have (and already has) quite an assortment of equipment, it only made sense to also create and editor for the items. And the editor. Well… I guess I’ve spent as much time on it as the game, or something `:D
The editor has some standard fields for the most basic attributes of the equipment. It also has an integrated code editor with syntax highlighting and auto-completion. This is achieved by embedding the very same text editor component (add diff viewer) that powers Visual Studio Code, the Monaco Editor. The changes made via the editor are versioned separately from the rest of the game, and the editor has an ASP.NET Core backend for implementing the filesystem and code generation functionalities. Upon saving the data, the game itself is automatically reloaded with the new equipment data. I’m rather pleased of the setup. I’m planning on extending the editor for also creating random encounters for the game to balance out all the combat. Then there’s always some quality-of-life improvements to be done… But overall, it’s already in a surprisingly good shape! The editor even has a graph of the saved versions and their relations...
The latest addition to the game was an encounter map, which brings some structure to the game. Compared to the work already put to the game, this was a relatively small addition, but it did take a few days to get the SVG-based drawing and random generation to work in a satisfactory way. Evening out the randomness would be the next step. Speaking of next steps, I’m kinda testing out if I could bring ships with limited hardpoints to the mix, without everything getting too confusing. Then I’d be quite close to the dream that is USG. See you next time!


Everything I planned for. Crumbling before my very eyes. And I’m not even talking about the pandemic.

I kinda thought that now that I got my studies finished, I’d get a chance to focus on what is important and make time to do things. But that didn’t quite plan out, as there surfaced some things that’ll be requiring my attention. And not just for a little while, but for several years :( And some things that directly contradict everything.

Though it (mostly, not completely) depends on whether I think about those things or not (: It would be wise to give some thought to one of them, but thinking about it doesn’t really help it at the moment… Was this vague enough? :s

But, as they say: it is important to try to keep sense of normality in a time of crisis. Remains to be seen how well that'll pan out.

Nuget package creation addentum

A short and informational blog text for once!

In preparation to some big plans™ I changed the way I generate my Nuget packages. The old way where all the metadata was specified in the .nuspec file was otherwise good, but it didn't specify version metadata for the actual DLL.

I've now changed the process so that version is specified in the .csproj file, via the VersionPrefix element. I've also defined a VersionSuffix element with a value of dev. This way when the project is built "locally" the assembly version ProductInfo field reads for example 0.1.0-dev. Whereas when the Nuget package is built I pass the option -Properties VersionSuffix=, resulting in 0.1.0. And as a side effect of moving the version element away from nuspec, I also had to also specify -Version $version, where $version is a PowerShell variable parsed from the csproj file and include a placeholder version in the nuspec file.

While slighly complex, this now allows me to fetch the version programmatically and know whether the library is an "official" release version via Nuget, or a locally compiled version with unversioned changes. I've also considered to just inject the version together with the prefix as a build step, but for now I'll try my luck with this thing that needs the assembly to reside on disk:

PS: there's a ton of unresolved issues with the Nuget CLI program, many of them several years old. When investigating the above, I also noticed that my Nuget packages don't include external libraries as dependencies even when using the option -IncludeReferencedProjects. It is a reported bug, but hasn't been fixed. One alternative might be to use dotnet pack instead of nuget pack, but I'm not sure what other changes that would entail.

InfluxDB broke, again

It is not a long time ago that I blogged about how I experienced my first fault with InfluxDB. And now it has happened again. This time a bit different, though. And much worse.

It all started with the familiar NATS alert, so I tried rebuilding the indexes again with buildtsi and thought that would be it. I was wrong.

This time there was an invalid CRC on one data block, which caused segfaults(lol) within the InfluxDB executable. Speaking of error checking... the verify command in influx_inspect has a bug. It erroneusly reports a block as healthy, because the right counter is never incremented. But anyway... The block is faulty. What now? Where is the option to fix it, or remove the block? Removing the offending file manually doesn't help.

So in the end this made me abandon the data, and start from scratch :'( And for some reason docker-compose kept doing some weird caching with the data (even when it was a filesystem mount), even after downing and removing the old container, and emptying the old data directory, and it was an effort to get everything working again...

I should probably consider upgrading the hardware. If that is the real problem. For the lulz I also asked for a quote of InfluxDB enterprise. If I cluster it, then one node can fail and it recovers, right? Right?? But I don't expect the quote to be realistic. And even if it was, it's probably still too much. One alternative might be Apache Druid. But it, too, seems a bit too young a product.