So it feels a bit odd to do a postmortem on something so small, but I went away for a few weeks right after I submitted this entry, and it's good to get a bit of retrospection on things you've made so you can make your stuff better in the future.

Normally for my solo projects I just have some basic bullet points in a file called postmortem.txt in the root directory that I'll put some thoughts into, but I figured others might wanna know what was going on in the background too.

I had a few ideas I would've been interested in working on for the tech jam. Some of them I've worked on before for different projects but was only just able to scratch the surface of what I wanted to do before it was "good enough" and we moved on.

I put everything in a list, thought about what I'd do in a couple weeks for them, and gave it a few days of thought; if I wasn't thinking about an idea after a couple days I crossed it off.

The one I picked in the end was inspired by some GDC talks on Horizon: Zero Dawn's runtime placement of vegetation and Far Cry 5's procedural generation of vegetation and other assets. In the end the final submission skewed more towards the FC5 version than Horizon's, mainly because I didn't want to deal with GPU shit.

Here are just a few things I thought stood out really well in the editor, especially compared to trying to do the equivalent in other engines.

From the existing tools for other games I knew how I wanted the tool to work pretty much from the get go, so I was gonna need something that'd let the user paint the biomes directly onto the terrain to add biomes to it.

Thankfully, setting up editor tooling that interacted with the scene view was dead simple (and with a bunch of existing terrain tools so I could see how they worked.) I've made a lot of editor tooling over the years for games, mainly in Unity where any sort of interaction into the scene is painful and full of edge cases. 

I made all of the tooling in a standard game project first and then moved all the code before submission into a library. I was expecting to have to fix up some things once I did this, but it all moved over without incident and was nice and smooth.

Creating custom inspectors and being able to modify the asset preview, add a toolbar, etc. was all a breeze too. Especially nice was being able to render gizmos in the preview space, since I used this for the Ecotope Assets to draw the areas of influence around the models without having to create a separate editor for them.

I'd like for a couple more options for the Asset Preview toolbar like being able to make the toolbar always on instead of only showing up on hover. I'm sure I can get this working if I wrote a different kind of preview or inspector, but I was on a deadline.

I added the "live regeneration" feature pretty late on, up until then after painting you had to press a button to regenerate everything on the terrain. Once it was in though, I was very impressed with how well the editor handled lots of game objects being destroyed and recreated constantly to regenerate the biomes. Especially since some of my test biomes would create several thousand objects in a relatively small area.

These are some bits that got cut, or I had to work around to make them work. Some of the editor stuff could be fixed already since it's been a month, which is great if it has.

Early on I was starting to build out a node graph base to build the ecotopes and biomes, like shader graph but for placing trees. This started getting out of hand and complicating things too fast though. I wasn't happy with the way the graphs were looking so complex and obscuring what was going on (in my mind anyway) with lines and big sections. So I canned the graph and simplified things down into the hierarchical system instead.

I had a bunch of dev buttons like clear biomes, and regenerate biomes that at some point lived in the component inspector. You can see them below from an in-dev screenshot. They're just functions on the component with the [Button] attribute.

These were causing issues with the generation where half the objects placed would "fall" through the terrain as if it wasn't there, but with no rhyme or reason as to which objects or when.
I was able to get around this by specifically using the PhysicsWorld for the traces instead, and then the generation code was moved out of "game" code and into tools and the buttons became a tool window. All these changes seemed to make everything 100% consistent in the end, so I kept them in.

In the final submission, ecotopes have an editor window that pops up when you double click them. You edit the ecotope, you save it, and then you can regenerate the biomes to see the changes. But if you don't save it, then you won't see the changes because the editor window creates a clone of the ecotope when it opens and only overwrites the one in the project when you save. I didn't like shipping it this way, but I was running low on time and this was the quickest solution to the problem below.

At first, the ecotopes were edited via an inspector implemented using the IAssetInspector interface. But I started having issues where they would "rollback" to before you saved the asset. I eventually tracked this down to occurring only every second save, and only if it was saving any rules with properties in them.

This piece of code that saves the rules array was what I eventually tracked down as to causing it, specifically the Json.Serialize line (more on that later but for minor bitching instead of anything major.) 

writer.WriteStartArray("rules");
foreach(var rule in layerRules.Rules)
{
    writer.WriteStartObject();
    writer.WriteString("type", rule.GetType().Name);
    writer.WriteString("data", Sandbox.Json.Serialize(rule));
    writer.WriteEndObject();
}
writer.WriteEndArray();

Without the json serialize, it saved normally, but obviously didn't actually save your changes. In the end I found the simplest solution was to put it in its own editor that worked like I described above. I'd have liked to fix this up proper, but I flat out ran out of time to mess with it.

The asset preview for the Ecotope Assets has gizmos in it. When the asset preview icon is rendered, it also rendered the gizmos into it and made them look ugly as hell.

This is working exactly as it should though, it just surprised me. You can check out EcotopeAssetResourcePreview.cs for the full details, but to keep the gizmos and prevent them from ruining the preview icon I do this:

public override Task RenderToPixmap(Pixmap pixmap)
{
    // @note: when rendering the preview icon then remove the gizmos world first so that the gizmos don't get rendered into the icon
    Camera.Worlds.Remove(gizmoSceneInstance.World);
    Camera.RenderToPixmap(pixmap);
    Camera.Worlds.Add(gizmoSceneInstance.World);
    return Task.CompletedTask;
}

Here's a bunch of stuff that I would've liked to have done better, or differently, or just fix up in the future if I feel like it.

Get rid of the need for the separate editor with the cloning and saving like I put above. It works, but it's clunky and annoying.

Right now the hierarchical system says that all the layers run their generation rules first, then the global ones run afterwards. I'd like to put each layer in the global rules list so that they can run in any order.

This would let me more easily add preprocessor rules, like a rule that added a density fade to the edges of each biome so forests would have a thinner density at the edges.

In order to speed up the generation and allow it to work in "real time" when repainting biomes I split the terrain up into tiles (or chunks.) That way if we paint something on the western side of the terrain it doesn't need to regenerate the entire eastern side.

This works fine for the most part but some of the code didn't get updated to support it fully so around the edges of the tiles, you can get models within each others footprint radius when they shouldn't be allowed.

I wanted to add a better preview image to the Ecotopes rather than just the green forest icon. Preferably it should show a small patch of what that Ecotope is, like a forest or field or desert. At the size they show up in the editor though, it wasn't worth the time and effort to generate those previews.

Since I was making this to add on to the terrain component, the ecotopes list on the Biomes component got based off of the terrain materials list.

Really though this just made things more complicated for no real gain. A list of them would've done the job and probably made it more clear you can replace them. If I'd made actual previews then this might've been nicer to look at, but as is it's just a bunch of tree icons.

The terrains save a "storage" asset to the project so that you can reuse the terrain in multiple scenes. I was originally doing something similar, but since I only had the one biome texture map I wasn't sure how useful this would actually be, and as it was complicating the code for no immediate gain I got rid of it. Still not sure if it was the right call, but it hopefully wouldn't be too difficult to put back in later.

If you read all that then thanks and I hope you gained something from it. It's good to cast a critical eye on our own work, but getting things shipped rather than perfect is the name of the game.

The Tech Jam was a lot of fun, and it was great to see so much cool stuff getting worked on and submitted. Good on ya's to everyone who gave it a go, and I hope everyone continues to make and share more cool stuff in the future.