Home Artists Posts Import Register
Join the new SimpleX Chat Group!

Content

November has been a very productive month, preparing for the largest merge of assets and code the game has experienced yet. 

We have 4 major landmasses rising out of the depths of the development ocean, and they are all starting to mature simultaneously.

#1 -- Curtis's Terrain Editor, Layer Sorting Algorithm/Binning for buildings and objects, the Shader Based Tilemap Accelerator, Procedural Generator, Dynamic Sprite Atlas, Tile Ruleset System, and the Sprite Editor & Titleset Editor.

This is all work that began after Curtis joined us in May of 2022 and came onboard, and began an independent project to take our initial prototype terrain system and fully scope it out, implementing the core features in the most performant ways possible vs the naive initial implementation for proof of concept. 

Most of these systems need to mature together, as they all depend intrinsically on one another. 

This month has been all about taking the old Unity serialization out of our terrain system and migrating to the core of our game's engine, Symbol.

Symbol is such a powerful tool. 

Inspired by games like StarSector and RimWorld, we learned lessons in how those games define objects, inherit abstract classes from different definitions, and brought those lessons together with problems we faced on Save Our Ship or Beyond the Sector. Kent built a serializer which scrapes all the human readable XML files on load, turns them into a super fast binary, and packs them using Ceres (formerly MessagePack) to read and write to these binaries during runtime. James has contributes significantly to its performance yet again, and added many more robust features.

Symbol lets us collect game updates and mod files together and not sacrifice multi-minute long load times like in similar games, something we absolutely needed to solve before full production on our game even began, years before the first mods is ever added to the game. 

Our whole architecture needed to be based on it, so a feature years later can be possible. 

For our terrain editor, which has been developing independently as Symbol mature under James and Kent's work, that caused a little bit of a split which Curtis spent this month curing.

This has meant assigning all of our various terrain tiles and cliff assets their symbols. Migrating from those hard coded assets to these more abstract and public ones has been a major shift, and will establish all our work on terrain going forward. 

We're no longer hard coding assets for testing & iteration purposes. Now we can make new asset packs and deploy them all externally via XML, and the terrain system will add them to the brush pallet and generator rules.

Curtis has also been establishing the seeds which allow our terrain to generate only once, instead of rebuilding every time a tile is updated, something our radical optimizations in shader-based terrain needs to save terrain and remain persistent across saves. Moving to that system in symbol means we have an internal solution to that most major of problems plaguing any tile based game: save file bloat, and limited map sizes.

He's also been redoing the prototype building and cliff system from scratch, which means finding a much more performant way of layering the sprites that move through our environment. 

All of this is building up to the final result of being able to both Procedurally and Manually edit terrain, and save out map data to a persistent file loadable by the game. This way our game can have both hand crafted maps made intentionally by designers, and vast, infinite maps to explore, made by the algorithm. 

The mix of hand crafted and procgen will ensure Morningstar's world can be as rich as any cRPG, while still being as free and open as RimWorld's planet was. Instead of being stuck with the trope of MineCraft villages being a nonsensical hodgepodge of buildings in random environments, our world will have the best of both.

With a host of toolsets available to us as devs to rapidly iterate on biomes and tie them into the generator for the World Map's details, we're going to be able to deliver a core game that is lush with detail, and give those tool to modders to expand even further. 

This has been six months of daily progress by Curtis, and watching it mature and emerge from the mist of design documents to reality has been super exciting. 

Creating such a complex system from scratch, which will also be open for modders to add to, is a gargantuan challenge. 

Merging the local map module with James's 3d colliders and pathfinding will be the moment Morningstar leaves the earliest stages of development, and finally begins focusing on our gameplay, as characters explore the real world outside their test room and we can edit the map as they do work using Kent's Expectations Job Driver.

#2 -- James has been working on our Combat System since joining us back in May.

The first tool we needed was the Animation Framework, which itself was a number of tools and unique challenges in rendering our sprites in a pseudo-3d system of bones, which rotates the sprite art as the character turns in the world. Then came animating those bones. 

If you remember from past updates, James had to rip out Unity's Playables.API and completely write a new API from scratch, allowing us to bypass several show stopping problems with firing Events during an animation -- animations that might be interrupted, such as when a sword swing is stopped mid swing.

James then created a collision and first pass pathfinding system, so characters can explore their environment and swing weapons at each other, registering whether a strike is blocked by immovable forces, or if it did damage.

After that major hurdle was vaulted, our characters can now do damage to each other and react to getting hit. We merged that with our existing User Interface so now we can register wounds and show health events.

Wound Man, the system we use to display injuries and lost/modified limbs, has been migrated to Symbol and given a new Sprite Atlas that will still be open to modders to change out the parts, and a new display system.

#3 -- Kent has been very occupied this month with our funding ventures that keep the company running, but he's found time to merge together James's progress on his implementation of "Skin Symbols," which is how we render character sprites in layered groups, with his latest build of the Character Generation system. 

Now that we can correctly layer sprites, and put them in the correct location on a character's body, and save and load those as Symbols, we can, finally, design a character in our fancy UI, and place those sprites into our Animation Framework, where the character is visually unique from the test dummies we've been staring at since May.

The Character Art was given a major overhaul by Allegra and I prior to this implementation which slashed texture memory down tremendously. It did introduce the need for offsetting sprites manually relative to their origin, however, and that was quite a task to clear.

Merging that UI and the Animation Layers with James's prototype, has been Kent's main occupation when he hasn't been working on Expectations and the Supply Manager, two systems that allow us to assign jobs to characters and show the player how jobs are being taken care of in their towns.

We need this first merge before we can look at the next wave, merging the local maps from Curtis. 

As you can tell, this has been a lot of shifting thing around and redoing older work to accommodate new work.

#4 -- Allegra and I have been busy working on an art assets overhaul, reducing file sizes and cutting out alphas, renaming the oldest files to fit our new system that automatically finds and classifies files by name into symbols, and cropping images down with excessive alphas. 

There are a couple hundred items so far. Everything from food to crafting materials.

There are also many hundreds of facilities and building parts to look after.

There will likely be at least a hundred more before vertical slice is done. 

We've also worked on some really powerful new tools with Curtis's new terrain system, developing the Sand Dunes and Snow Drifts, as well as a new Sub Grid based set of tiling assets, which we plan to use to speed up performance of decals. 

Basically, as sand and snow begin to blow in, these little drifts will appear and tile over the terrain. Blood and ashes, building debris, etc, can also tile this way.

In addition to that upgrade of old assets, we're looking at making another tool to quickly edit sprites and assign their symbols: The Sprite Editor.

This will piggyback off of the existing character editor and allow us to edit how sprites are layered, and set their "offsets."

Basically, the problem is that the sprites are all different sizes now, part of cutting down overdraw and saving file sizes & atlas space. That means, when you import a sprite, it is dead center on its "anchor point," the place the game thinks is the center of the art.

Obviously that's not intended, so we need to manually define how these pieces stack up.

This new system will help us define those values, instead of having to guesstimate where they should be, or load the symbols, check, and try again re-loading symbols. 

November overall was a good month for the project! There's much more to do and a lot of ground to cover before we reach that long awaited vertical slice, but we're getting there! 

See you again next month.


Files

Comments

No comments found for this post.