This week, I put a ton of work into all three aspects of Antorum: The Server, the Client, and the World Editor (introduced in my last post). Because of that, I'm going to post two blog posts detailing the work. I'll release this one quietly on Sunday night, as usual, then release the next one in a couple days.

Here's a list of the major Editor tasks that I finished:

• New water shader
• Terrain smooth tool
• Entity placement tool
• Entity edit tool
• Native file dialog for saving/loading world files
• Refactored terrain library into a unity package

With this work, the editor is finally shaping up into something that can be used for the game. It's lacking a few important things, such as varying tile types, tile masks, and trees. I'll add those features as the game evolves and starts to require them. The core of the editor, however, is in place. Designers can create new islands, modify the terrain, place entities, and easily bring it all into the game. I'll discuss more about how the Server handles this in my next post.

Compared to my previous post, you'll probably notice that the island pictured here is flatter. That's because I realized that this style of terrain handles gentle slopes way better than it handles big hills and mountains. Since the game operates entirely on a 2D plane, and is seen from a top-down viewpoint anyway, keeping elevation low will keep things simpler. However, there will be a few areas in the final game that have a higher elevation.

The entity tools are primitive right now. As I mentioned back in dev-log 4, entities are defined Server-side in .toml files. This system has basically stayed the same, with a few additions for new component types. I decided the quickest way to get entity placement working was to continue leveraging this. Designers working in the editor just input the resource name of a specific entity, then click to place them. Obviously this isn't too flexible because it doesn't allow fine-tuned customizations (like the Unity inspector does), but the route forward will be simple: More .toml! When the game is getting complex enough that we need to tweak values per-entity from within the editor, I'll modify this system so that designers can directly modify the .toml for a specific entity instance. I'm sure it won't be as clear-cut as that, but I've got to move onto other features so I'll circle back around on this.

Here's what the layout of an Antorum .wrld file looks like:

The format will evolve as time goes on, and it has some issues now. For one, the terrain is chunk based, but it all get saved in one monolithic file. That's fine, but it eliminates the possibility of having more than one person working on a world file at the same time. It also means that the entire world has to be loaded into memory on the Server. That's also fine, since the world is not that large. Even at the size I am predicting the full game world to be, it will still be manageable. For the next game, I'll work on a more flexible world/chunking format. I may have already shouted it out, but I'm using bincode for all my serialization needs, on the Server-side at least. I have written my own C# bincode implementation for the Client & World Editor - Maybe I'll publish it to GitHub at some point.

As a bonus, here's a screenshot of one of the first iterations of the terrain engine, circa May 2018. I've probably rewritten it twice since then, but it's really cool to finally get to use it, and the concepts I've learned, for a real project.