19 November 2025 - Tools, Gameplay, and Universe Generation

You're on the latest post!

Hello again! This is going to be a very long and drawn out blog post. Saddle up.

Tools and Gameplay (and Inventories!)

Just recently I finished a utility type designed to preview 3D assets in menus. This isn't anything really remarkable, a lot of games have it now, but it's nice. The important detail is that it also marks the completion of another part of the game that was left in a "do this later" state for way too long, which is inventories and item equipping.

I mentioned this in September where I defined the idea of an inventory hub, but never had an implementation beyond the bare minimum. Now that I have designed gameplay around it(!), inventories have been formally defined! If you didn't read the September post, don't worry, I'll recap here.

The Inventory Hub

So to get started, inventories in The Conservatory work based on a "hub". Every entity is given an InventoryHub instance in the code. So what the h e c c does it do?

The inventory hub contains at least one Inventory instance.
Picking up an item like a backpack mounts the backpack to your inventory. In the inventory menu, you'll see a new backpack button added to a list on the side. If you select it, you can see the inventory for that backpack. It can be accessed from this tab.
- Picking up multiple backpacks adds each one as its own tab.
- This isn't limited to just backpacks, it's just that backpacks are the most obvious example.
Similarly, dropping it dismounts it, and removes it from the list. Items in the backpack stay in it, but are no longer accessible to your inventory menu.

And of course, this begs a question: "Won't I have to get items out of the backpack to use them in crafting or to equip them?", you ask, to which I can proudly answer no! Crafting recipes, item checks ("is X in inventory"), and even equipping items can be done from any mounted inventory. Backpack or otherwise. This brings me to the next thing.

Inventory Proxies, and How Your Hotbar Works

The other quirk with the inventory system is that things like your hotbar and armor slots are not actually slots. They never store any items, and in fact they can't. This may lead you to ask, "How do I equip stuff if my hotbar can't actually hold an item?"

This may be a bit confusing at first, but the way it works is through a type called ProxyInventory - the hotbar is a ProxyInventory. When you move an item into your hotbar, think of it more like a link. When you do that, the hotbar slot you put it into receives notice from the hub system: "Hi hotbar. The player just dropped the mining laser from their red backpack, slot (4,2), into you. When they press your button, equip that item, okay?" - and the hotbar does just that. This is what it means to link an item, and that's the fundamental principle behind ProxyInventory.

This has some interesting bonuses too:

You can assign the same item to more than one hotbar slot simultaneously.
Mods can add new kinds of equippable slots (new wearables, additional cosmetics, augments, literally anything) and they don't have to worry about storage logic or managing the items. It's just part of the inventory!

Also another note, if you are worried about "how do I know which stack of things I put in the slot", hovering your cursor over a hotbar slot (or selecting it, if you are using a controller) will draw a red line pointing to where in the inventory it's getting that stack from. Likewise, hovering over / selecting a slot that has been added to your hotbar will draw that same red line. Basically, you'll never "lose" a stack with this system, I've designed with that in mind.

The final note is that proxy inventories can be created on demand. This is useful mostly for modders, who may want to add custom types of equippables. The game does this already, with armor/cosmetics both being their own proxies, same with the tool slots you see in the video above.

Character Models

As gameplay continues to develop, I've started seriously thinking about the look I want for my character models. I am experimenting with three types of rigs right now, the first being blocky like Minecraft, the second being skinned lowpoly (think PSX models, but a lot more polygons), or rigid lowpoly (same as the skinned kind, but geometry never "bends", it's more like a doll). Each technique has pros and cons, and a different aesthetic, and I'm not sure which one I want to use yet.

While this is a big endeavor, something else is on my mind too: Armor and clothes. See, different species in The Conservatory have different body shapes. So how do I account for this in a way that minimizes work for the modders? Originally, I had a long list here explaining some of my ideas, but as I was writing it, I had a bit of a brain blast, and I mean this idea is freakin' genius. So I'm going to save it for later and keep it all to myself for now. Sorry not sorry. I just need to make sure it works before I hype it up and show it off, you know?

Universe Generation and the "wide as an ocean, deep as a puddle" Problem

Look at the negative reviews for games like Elite: Dangerous or No Man's Sky and you'll notice a recurring theme: Yes it's cool, but it's empty. There's this whole universe of ... nothing. It's as wide as ocean, but as deep as a puddle. You'll see this phrase used a lot, and frankly it's a good one. The greater meaning of this claim points out the fact that having a whole universe sets up a lot of potential. It feels like something that could be, but isn't, and that doesn't feel good.

Unfortunately, as I have it designed now, The Conservatory will suffer this exact same fate. Originally I mentioned ways that I planned on at least sort of fixing that, which was to have special, hand-chosen planets that have unique, one-off buildings or locations as part of their generated world. This helps a huge amount because it actually adds special stuff to the universe, but all it does is delay the problem.

A Double-Edged Sword

So the intuitive solution to this is a theoretical "perfect algorithm", one that can employ unique procedural generation down to a level of individual people and dialogue. Planets would have unique cultures, unique architecture, history, people, they would be authentic in every way. Some of you more modernist tech folks look at this and are probably thinking "that sounds like AI", and as much as it bothers me to say it, you're right. But you forget, only second to being a developer, I am an artist, and so the slop grinder is off limits. It's unethical to use in its current state, and I cannot in good conscience for myself nor my community ever use it. It's fundamentally and morally wrong to do so. But there's more... this solution sucks. Not the AI thing. I mean even if I could do this without AI, it still sucks.

"It sucks?!", someone screams. "I mean, come on Xan, imagine every world having a living, breathing civilization with history and traditions, it's every trekkie's wet dream!"

But that idea ignores the fact of the matter: We don't find stuff special for what it is, we find it special because of novelty. Surely seeing a whole entire civilization down to historical details is definitely going to be as cool the 137th time as it was the 136th. Yay. It's a new alien species. ...Just like last time.

It. Sucks. It stops being new, and it becomes boring. Advanced civilization or barren rock, it's the same thing over and over again, and it throws us back to square one.

The Real Solution

With that realization, the real solution to the problem shows itself, and rather ironically, this one sounds like it sucks. In practice I am willing to bet it'll be good, though: Make space travel hard. It's definitely antithetical to the design of the game up to this point, but I think I can make it work. In lieu of this, my idea is to have all of the homeworlds for the playable species, homeworlds for some cameo species maybe, and then a select handful of special, preset worlds. Some of these worlds will have life, others will not.

This is actually quite useful as a writing tool. By isolating most of the game down to only a handful of star systems, I can name them and their worlds. This makes the world feel more believable, makes the community of the universe feel more coherent, and less haphazard. It breathes a new life into the universe that would not be possible otherwise, and I can feel it: This idea has a lot of potential to it!

Of course, let's not forget the original idea, which now shines in gilded platinum above the other options: Having some exoplanets out there that have civilizations, or ancient ruins, becomes special once again. These are hidden diamonds in the rough, things to be excited for! Modders can add these and add mystery to the universe, add a sense of discovery and novelty at will! What was once a stopgap to an unavoidable problem has now become one of the greatest benefits of the new design. Yes, the universe will be empty, but that's okay, because it will be made in a way where it makes sense for it to be.

Of course, some of you are inevitably reading this wondering "will I still be able to travel the galaxy freely?" to which I answer yes. You will. But it will be very resource intensive, finding new worlds, having personal ships that are warp capable, these will be promoted from a base feature into a luxury which only the most accomplished players can afford. Most of the game's content will be centered in the few worlds near the "spawn" of the game, and I think this will help the game to feel significantly better than if I had just made it completely procedural like No Man's Sky or Starbound.

Closing Thoughts

That was a long post, with a lot of words, that's at least like what, 8 words? 9 maybe? A lot of words. Anyway, now that most of my core systems are done or nearly done, the implementation of the game is getting the love and attention it needs. I now have the tools and the platform on which to create these things. Coupled with my original design all the way from the start of the project, these new ideas and new directions have shaped the path needed to get the game to its completion. This marks the beginning of a new era of the game's development, and I think this moment, right here, is the start of where you will begin to see more gameplay and pictures in future blog posts.

Though, on a bit of a more pessimistic note, I see that it's been almost 3 years in development now. I guess something I want to say is that I have been behind schedule and working too slow these last years, I think. But maybe I'm just being too much of a critic to myself. This is the first game I have ever developed entirely on my own, after all, and I'd be lying to you if I didn't say I was stumbling around and getting lost in feature creep all this time. Choosing to make a mod-centered game has kind of enabled that plaguing "over-modularization" you'll see a lot of aspiring new developers fall into, and it's only my long-time experience of being a general software developer that has saved me from that pit. But despite this, I can't shake the feeling that I have been slacking. You don't see pictures because there's nothing to show. I have tens of thousands of lines of code for things in the game yet I can't sit down and record myself playing it because it doesn't exist. It's all systems, the means to the end, and no substance on top of it. Still, as ashamed as I am, I'm not here to beat myself up. I am going to try something new, something different. I am going to go from a general "get X done" to making myself a task list at the start of some interval of time, and I am going to complete those tasks with precision. I need to do a better job of setting goals for myself, and plan to do just that. I will get out of this!

And that about wraps this post up. Thank you all for being here for so long. I know there's a tiny amount of you (less than 10) that religiously read these blog posts, and it's the people like you who just want to see where this thing goes that make it worth it for me. So thank you, and here's to more months of making this passion project into a reality!