Created for PROCJAM 2020

Background

Obviously I'm interested in procedural generation for games -- DragonMail has procedurally generated terrain, terrain details, structures, NPCs and all their names. Even UIBA is kind-of procedurally generated (even if it's just filling out templates with random picks). And again from the principles of DragonMail, I'm interested in non-competitive stuff. So PROCJAM seemed like a really obvious first game jam for me to join.

Then a week before the start of the jam I was hospitalised, and had emergency surgery under general anaesthetic. Recovery from GA is never a fun thing, and with my underlying health conditions it really wipes me out. Then the week of the jam coincided with a three day (virtual, in 2020) planning meeting for my work, and that also takes it out of me. More so than ever this time, it turned out, for reasons I won't go into here. Which made the chances of me delivering anything really new for the jam were approximately zero.

So I went with the principle of "Make something that makes something" and decided to extract the name generator from DragonMail into a self-contained library and/or application for anyone to use. To be honest, it's the only bit of procedural generation in DragonMail that's 100% my code and also more interesting than filling out weighted templates. Which I guess means I didn't even write any procedural generation code during the jam, just rewrapped and tweaked something I already had. Oh well.

That said, I have produced some original content for the jam. And had some learning experiences along the way.

Development

The first thing I tried, once I'd got the code pulled out of DragonMail into its own project, was to build a command line application. Not something I'd done with C# before, but I've written so many command line programs in so many languages over the years, that I thought it couldn't be that difficult, could it? Well, it turns out yes and no. I quickly got it building and running, but only in the build environment. I've not been able to get a standalone application built. I've not even been able to work out how to build it in a relocatable form so that it could be installed anywhere and run from a .NET environment. I lost over a day to that, before just giving up. If someone with more understanding of getting a standalone application built from C# can work out how to do it, that would be great.

At this point, I hadn't retrofitted the new project to DragonMail. Which wasn't completely trivial, as the DragonMail version had support for multiple parallel name sources and place names embedded in the random name generator, rather than layering those on top. Which would have been more sensible design from the start, but at least it's doing that now.

I never wanted DMRNG to be just a Unity package, and after my failure to build a command line app, the next thing for me to try was to see if I could integrate it with a Godot project. Using C# in Godot is officially "experimental" and requires a special build, plus having an external C# build environment, but my experience of using GDScript to glue game objects and logic to a C# library doing nothing but providing a self-contained class with methods taking and returning only integers and strings was pretty positive. There were problems: Godot acknowledges that you can't use the system clipboard with a web app, but on top of that you can't copy text unless it's in a edit box, no matter the platform, and formatting the text in an edit box for output is way more difficult than I can be bothered with understanding for this. So the cute little demo you can run here (a) doesn't let you paste your own data in and (b) doesn't let you copy the results out. In fact, even if you download a desktop version, you can't copy the results out. I wouldn't let this stand if the demo were the goal, but it really is just a demo. If you care, clone the source and figure out your own solution. And speaking of the desktop builds, I found a bug in Godot which prevents you from building for Windows from Linux if you're using the git version control plugin.

And producing the demo in Godot after a lot of UI work to DragonMail really brought it home how painful this aspect of working in Unity is.

Summary

The obvious question is: Have I achieved what I set out to? I'd say at least 80%. I've released a working DMRNG module for use with Unity and Godot, and created a standalone app to demonstrate its operation, learning some more about Godot along the way. I've also turned it into a command line tool, which should have been a way for developers not working Unity or Godot to make use of it. Unfortunately, being unable to create a standalone version of this tool makes this goal a partial success at best.

The other question to ask myself is: Have I enjoyed being part of the jam? Having a goal with a deadline, but no pressure to complete or compete, is absolutely the best way to get me to do something, so that's great. Being part of the community on Discord has been pretty positive, even if work and health demands on meant I couldn't engage and collaborate as much as I'd have liked. It has, however, again brought home that I'm coming at game dev from a fairly unusual angle: that of decades of programming experience but none of it related to games, or even graphics. And, of course, those decades put me at the extreme upper end of the age demographic, without the authority of experience when it comes to games. So I still feel like a bit of a fish out of water.

Where next?

DMRNG is done. End of. Now I go back to development of DragonMail itself. Over the last few weeks, I've had a serious rethink about what features I really want in a full release, and decided to descope a couple of the trickier goals. This means that I'm now on course for full release in early 2021. After that, those descoped features will be top priority for DragonMail2 (or maybe they'll just be major upgrades). I might take a break and go for another little game in Godot though. Procedurally generated, of course. And then there's PROCJAM 2021...