Morningstar Update January 2023

January 2023 is what you'd refer to as, "a month."

It had its ups and downs with really amazing and necessary progress, but good god, the punches have just kept coming. 

To end the month, everyone is either recovering from Covid-19, or currently has it. My fiance has it, so it's just a matter of time until me and my toddler daughter do. Allegra is recovering. Curtis currently has it. Kent didn't get it thankfully but is suffering a neurological issue. The last man standing is James.

This has obviously impacted all of our performance the last few weeks. 

The good news is, a lot of the essential tools that have been a long long time in the making are at a point of maturation. 

The Terrain System
The Map Editor
The Building System
The Sprite Editor (Characters, Doodads {what we call static objects} Buildings)
The In-game Character Editor
The Animation Framework
The Character Controller

Are all coming together this February in their production phase state and merging together into the master.

One of the biggest lessons game devs need to learn is that no tool, no matter how powerful, fits every use case out of the box. As your game matures, you will often outgrown a tool because it doesn't handle your scope in a performant way, or it simply is fundamentally incompatible with your feature sets demands. 

We knew this in advance. It's why Morningstar spent a good 3 years in pre-production establishing little prototypes to test those theories and identify the core risks that our cases would challenge, and we began listing out the utilities we absolutely have to build from the ground up. That list up there is our answer to the questions the design document posed regarding the foundations of the game we are making: how best to create the world, simulate its terrain and objects, how to sort them, and how to make those as performant as possible to fit our scope.

First among them is a tiling grid system that handles isometric 2d of our specifications, with a grid and sub-grid system. 

We began with using the Unity 2d Extras kit, just to help me establish the art style and test our theories.

That it turns out was trash for our purposes. So we built a custom tile grid for out case that layered sprites based on the Z-depth buffer in orthographic space. Which worked, BUT, the scalability of our prototype was limited, and the code was not ideal.

We also began an experiment with Tile Map Accelerator, which again was very very cool, really smart implementation, and inspired us quite heavily in how we could optimize the 2d terrain in a performant way, quickly, and handle the associated data in way our game can handle. But it has lots of flaws and hangups, lest of all a lack of data storage for each tile, like fertility, walk speed, if it's one fire, etc. It also struggled with out very large resolution art assets -- we're not making a pixel art game.

We knew we needed to hire someone with the skillsets we were missing, and luckily back in April we found Curtis, who previously worked on a game called Rogue Invader. He found our pitch on Reddit, and jumped at the opportunity to join us in May 2022. 

Six months later and Curtis has matured a new isometric grid system that utilizes our Symbol system to store terrain kits, cliffs, buildings, and its driven by a GPU & Shader focused tilemapping system that moves all our procgen and tile rules onto the GPU, getting them off of the CPU with we need for combat and job driver tasks to keep our game super fast.

If you imagine a game like Noita, which used GPU process to simulate everything on screen so each pixel could be destructible -- our system now handles data for terrain, cliffs, and buildings, similarly to that. Morningstar represents things like dirt, dry dirt, rich dirt, grass, volcanic ash, rock, etc etc, as pixels on an image. That pixel then corresponds to a tile grid coordinate that can rapidly check its nearest neighbors and apply the tileset rules edge kits, letting kits transition to each other.

It also means we have a super fast, efficient, destructible data set in realtime. So as wildfires wipe out swaths of land, that's happening on the GPU, not the CPU and memory. That frees up all that processor time for combat and job drivers, letting us build huge cities and fill them with characters, without as many consequences as a game like RimWorld, which notoriously gets bogged down by pawns doing jobs and pathfinding, especially as buildings are constructed and combat is ongoing late in the game. 

Like every isometric game, we need to solve a lot of math problems regarding regarding the exact coordinates the mouse cursor is pointed at. 

Curtis has spent a lot of the last few weeks ensuring our solution is flexible and can scale to any size we need. We have a Chunk & Region system, similar to the way Bethesda Games operate in 3d, but for our 2D use case scenario. We also have a complex data handling structure we call The World System which saves the seed for the world, then can cast an "observer" to look at any part of that world, load all the associated data and art assets, atlas them, and ask any questions we need to ask of that particular world location, with slices of information. 

The full observer is only on for the player's camera coordinates. The lesser observers are for things like approaching bandits attacking your town in the next few hours, pathfinding to your location in an abstract way around mountains and fuzzy objects to slow them down. The next is asking if a baker has an oven in his bakery or not on the other side of the world, so the economy can poll the average price of a loaf of bread realistically.

All of this results in a complex and potentially very big save file, the states of which we have to serialize and save out in a small package.

Saving the map chunks as small or big textures really helps preserve these huge fully procedural locations with player important changes, like towns & outposts, efficiently. Symbol handles the rest for the associated minutiae. 

You can see here how fast the game is able to sort all these buildings as they are constructed instantly in dev mode, or in stages with the Construction system where characters will be doing the work, represented here with a simple dragging of the mouse for testing purposes.

What all this means is that we can have a gargantuan, realtime, procgen and hand crafted world, where every town has a simulated role in the economy (Star Sector's influence) and all that data is persistent across saves. You can build big, have big plans for a city with outposts, hundreds of characters, and not have to worry about the game bricking on you. 

You can have a HUGE city built as your capital, with lots of characters doing tons of jobs, and then CLOSE THAT MAP TO GO DO SOMETHING ELSE, and the game can still save it and churn away at those jobs, without tanking your framerate. Later you can come back to that world location and see the jobs completed, the buildings you ordered finished, and your characters living their lives. 

You can repeat this for many towns and outposts, hopefully on games you've played for 400+ hours, and not suffer significant performance losses like those we all experienced on a game like RimWorld. 

For you the player, this removes the frustrations of limits we don't like on our favorite game's growth potential. 

We still have some Depth Sorting issues to solve in a performant way across all hardware, but our current best guess is that any GPU built after 2008 should be just fine, except the ps4 or mobile gpus -- which is fine, because as a PC, Mac, Linux game, we'd never mess with that hardware anyway. We are looking at either a 16-bit or 32-bit float depth buffer solution pictured above. 

One gives us thousands of objects sorting in realtime on screen with more hardware available for other tasks, the other tens of thousands with a little bit of a future choke point in performance if we by some accident wind up with tens of thousands on screen (which we will avoid by switching to a world-map from your local camera if you zoom out to that distance.) 

We also have a lot of little issues with buildings we had to struggle with this January.

First and foremost has been codifying and simplifying the tiling rules for walls, roofs, a floors, to fit within the World System Curtis is working on. 

We had to invent a new layer of GPU-processing for the Structure->Room->Sub-Room system. This will be helping to calculate which buildings are sealed and which are unsealed. A major problem in performance we hit on Save Our Ship, with that old vacuum code. (It's a problem for any game that asks such a question anytime a wall is built or destroyed, lets be fair.)

Here you can see the RGB values of a mockup we made during a meeting. These track the main room of a building in red, and child rooms of that red room in blue or green. 

If you are playing or remote controlling the guy on the south, it would reveal the roof and south walls so you can clearly see unimpeded into the building. But the other two rooms you can't see into, because they are sealed, they would still be hidden.

There were lots of other little questions about how to handle, track, and calculate collapsing roofs, either due to damage or some other issues. 

We also had to solve for players building individual walls and whole buildings with just a click, part of the customization of our building system goals. It's a little bit Sims2-ish, or if Fallout 1 had in-game base building mechanics. Our system also lets you drag out finished buildings as well as the walls, then fill those buildings with workshops and bed and etc, for a real custom & cozy feeling. (Or a war crime room, because we know what the community is into. :p)

Slightly prematurely we've also been going back to update old assets with the final pipeline.

 The 3D to 2D art pipe accelerates the workload for new assets that rotate tremendously. The 3d artist (me) can render a base for our 2d artist (Allegra) to quickly paint over the base and get great results. 

We've also done things like add color masks to the art, so we can change colors on items however we want in game. We may even let player do so within the build & crafting UI. 

Some of the challenge of our depth-sorting and level tools we are waiting on are projectile weapons, and how we handle damage to walls, pawns, and calculating collision on both.

Supporting that I made the weapons sprites more compact and their ammo stacks. I spent most of November and December curating the art assets folders to get everything squeezed into smaller file sizes for the auto-atlas, helping move us out of pre-production into production ready asset territory. 

Next month the big overhaul should be done, and we are looking at having the merger of the above systems and the art ready to fly.

If we're lucky, that means having some in-game images to show off of all this in action! 

We'll have to see.

Despite the illnesses, and the challenges running SOS2's overhaul and Morningstar and Propaganda, we're doing a really bold sprint phase to get the game to a playable state, and begin refining mechanics instead of laying foundations. 

The next 3 months will be hugely important to having a game we can build and play by the end of the year.