What I've been doing between updates

I've wrapped up adding a significant amount of procedural generated content. It's at a pretty good state, but I want to add more content before releasing it. My plan is to add more content as I work on the next phase of the game. Longer-term, I want to use a variety of procedural generation techniques in different parts of the game, both because procedural generation is a lot of fun and to learn more about it myself.

Since (mostly) wrapping up this round of procedural generation, I've been working behind the scenes to integrate the Encompass library. Encompass is like an Entity Component System, but it adds messages to better separate different parts of your game. (If you're not familiar with ECS, it's a way of organizing your game to make it easy to add or change behavior. See the aside below) It's a well-crafted library, and the documentation, while somewhat brief and incomplete, is solid. My main issues with Encompass are really outside of its control:

• Integrating ImGui, which ties together input and rendering in a way that makes it awkward to use with Encompass, which emphasizes separating the two.
• Creating classes and adding attributes in C#, which you have to do for each component, message,  engine, and renderer, is pretty verbose. I'm used to the concise syntax of dynamic languages like Python and Clojure (although some static languages, including F#, are similarly concise).

After this stage is done, I'll be ready to add more gameplay. While I haven't been talking about design decisions quite as much in these devlogs, I think I'll have more to say once actual gameplay is integrated. I've laid a lot of groundwork, so hopefully I'll be able to add more gameplay, faster.

I've also been working on the art. I created a faux game box, which you can see above. I've also been working on creating images that can be used when events happen.

The technical wanderlust continues. I experimented with integrating IronPython as an alternative way to write the logic. There are a couple of downsides:

• IronPython is limited to Python 2. (IronPython 3 is a work in progress.) It's still maintained, so it doesn't quite have the same downsides as using CPython 2. Still, I'd rather not write any Python 2 anymore. It also means that if I want to include third party Python libraries, I will likely have to use an unmaintained or legacy version.
• I can't figure out how to use IronPython code from C# without manually creating C# variables for each Python function or object I want to use on the C# side. In other words, I can't figure out how to simply say using SomePythonModule; and then use the functions like it was a C# library . (You can create assemblies from IronPython code and maybe that would allow you to do this, but it's not well-documented.)
• Ensuring the dependency is included and working on every platform will take time. This is true of most new dependencies in my experience and raises the bar for any dependency. 

Ultimately, it's not worth it for this project. If I were starting from scratch and IronPython 3 were ready, I'd consider going the other way around: creating a mostly Python project with some parts written in C# and C# .Net libraries. I may still use IronPython for writing helper scripts or playing around with things, since it can call C# code straightforwardly.

Aside on ECS

To illustrate, I'm actually going to start with explaining a common problem and an alternative way it's often solved. Games typically have a lot of entities, like players, enemies, NPCs, and abstract things like factions or teams, which have behaviors, like falling, picking up items or, again, abstract things like gaining reputation or losing money. One way is to bundle up everything for each kind of entity into classes (a primary unit of code in C# and other object-oriented languages). You might have a player class that contains stats like health and behaviors like "swing sword". It may even contain the code for drawing the player on screen. Organizing code this way is intuitive but tends to get messy as games expand. This is not only because central parts of the game like the player have a lot going on but also because the information and behaviors tends to overlap between them. For example, if things can be set on fire in your game, you probably want to different kinds of enemies to take burning damage in a similar way and to play a similar burning animation. You may be forced to copy a lot of code to make them all flammable, which can then get out of sync.

Rather than using large siloed classes, an ECS like Encompass separates information about the different entities into components and their behavior is separated into systems (engines in Encompass). In addition to keeping the size of classes manageable, it also enables mixing and matching components and makes systemic changes easier. For example, if you had one kind of enemy that shocks the player on contact and another that chases after the player, you could add the shocking and following components to an entity to create a new kind of enemy that does both. Then, if you wanted to create a cloaking object that keeps enemies from following the player, you could change whichever system is responsible for the following of all enemies behavior. (These kinds of arcade examples are commonly used to illustrate ECS, but it's also useful for simulations like Isometric Park.)