Unity and the Black Star Ruler

For some time now I've been working on Cultura as a purely C++ project. My reasons were two-fold; I wanted to get a lot more comfortable building an incredibly complex C++ project and second, I love programming.

But, the issue is that building out Cultura using nothing but raw C++ has been taking a long time and at this point I have a greater desire to push out a game. That's why I've recently switched to building out a game in Unity. It felt like a good choice (my other was the Unreal engine). These days, Unity itself is free and unless I make over 200k revenue, then there's no fees to pay.

My first idea I'll be implementing in Unity will be a 4X Space Empire that I've tentatively called Black Star Ruler. It takes place in a post-apocalypse galaxy where the major species have just been reduced to a single colony ship each by the enigmatic Black Star Ruler. From this humble restart of civilization, you grow your people into a new empire. Along the way you may explore ruins, accidentally trigger defences of ancient starbases and colonize planets cleaned of sentient life in the previous war. It's in the vein of Master of Magic (but in SPAAAAAAAAACE) and Master of Orion. I liked those games and it's my take if you just rammed those together into a chimera beast.

As a side note, I've also made that game a public repo on Github, unlike Cultura which is a private repo on my own server.

I can has pottery

The latest update now includes basic industry! The test industry was the manufacture of earthenware. Earthenware is a tier-2 good, meaning it requires at least one level of intermediate goods to construct.

Earth (raw item) => Sherd (intermediate item) => Earthenware (final item)

Using my amazingly hand drawn graphic of a single blue pottery, you can see it stored inside the "cave" which is nothing more than a square border of rocks on a yellow savannah landscape.

Following this, work will begin on ensuring good consumption works fine. So people will pick up pottery and smash it into their faces to consume it for happiness and health.

The Continuing Quest of Alpha

Instead of blabbing about stuff here is a list of various bugs that were fixed...

• Added isInterruptible to actions to make certain system initiated actions non interruptible such as eating food
• Added a back-off to worker assignment in build structure if materials required aren't available to prevent infinite reassignment
• Fixed incorrect insufficient material detection in IndustryAction
• Fixed missing superclass constructor call in BuyItemAction
• Added exit condition for BuyItemAction if none of that item is found to buy
• Added exit condition for IndustryAction to cancel if no materials are available
• Added isInterruptible and it is passed down to stacked actions
• Fixed IndustryAction distance to factory calculation to use FirstFloorSquare instead of location for better accuracy
• Fixed BuyItemAction determine whether to buy something if the id of the good to buy is zero
• Restructured IndustryAction to either perform labour or gather materials, whichever is possible and to end action if nothing is possible
• Fixed UseConsumableAction to ignore inventory limit otherwise it can stuck in a cycle of failed attempts at PickUpAction
• Fixed UnitInputManager building material selection to choose first material type off chosen materials
• Fixed infinite buy loop in BuyItemAction because quantity purchased was not incremented
• Fixed setPlayerInitiatedAction to properly check the size of the action stack while popping from it to prevent an NPE
• Fixed IndustryAction stacking of CSpendItemAction which had incorrect parameter values
• Fixed new estate creation and using the id in BuildStructureAction
• Switched pathfinder to do start to destination to see if it can early exit for units that are stuck
• Fixed GraphicsEngine missing dispatch of remove building message
• Fixed BuildStructureAction to exit once building is complete

Of course, here is a picture of a successfully built inukshuk. By successful I mean it didn't crash while doing it.

Game Design - Property

There's currently two game cycles designed: food consumption and goods consumption. They're really the same thing except every person in your empire must eat at least one food per day, while they may go on without consuming any goods. The next game cycle to be designed is property items. There will eventually be a number of different kinds of property items but for now it'll just be goods.

In general everything in the Cultura economy is designed with these principles:

• Each person wants to consume exactly a single unit of it per cycle. Any additional consumption has reduced or no benefits.
• The optimal amount to produce/store of an item is your population size. For example if your population is 10 then you want to produce 10 items per cycle. This means family size or other factors mostly out of the control of the player do not affect the production amount.
• All goods are designed such that trade is encouraged.
• Make this as simple as possible for the player to calculate production requirements and bonuses.

So how does this work for the existing cycles?

Food Consumption

At the end of each day, a person tries to consume food that gets them the highest bonus. Each time a person consumes food the bonus stays with them for a cycle (this cycle is currently 7 days but that might change based on balancing). But, they MUST consume food every day. So even if the highest bonus for the food is zero they still will eat it.

Health and happiness bonuses are cumulative over a season. So at the start of each season every person starts at 0 health and 0 happiness. You have a goal to reach by the end of the season to avoid problems. This gives some leeway for having "bad" days and "good" days to catch up.

Good Consumption

Good consumption is similar to food consumption except that a person only consumes good if the bonus is more than zero.

Property

At the end of each day a family calculates the bonus it receives from the property it owns and adds up the cumulative health/happiness bonus for a season (which gets reset at the end of the season). The property also degrades over time and eventually requires repair.

During the bonus calculation, the family tries to maximize its score. The formula is intended to be simple. The property they own is added up. Each person's consumption of property is separate. So the first person consumes as many unique property as possible, then the next person and so on. In the end the formula would then be: You get full bonus for the first n of each property and half bonus beyond that. The number n is the size of the family.

So What is Property?

The current concept for Property goods increase health or happiness. Housing can only store a maximum amount of property; if a family wants to own more property then they must expand their housing. Housing can be expanded infinitely but requires land area.

There are some possible simplifications depending on game balancing and understanding difficulty:

• Will repairing property be necessary?
• Will there be storage limits of property?

Anyway, we will see!

Graphics and Events

The graphics engine is underway. There's three pieces to it. First is the graphics component that does the actual rendering, scene management and all the fancy stuff you heard about. Then there is the game-side of the engine where events are generated and processed before being sent off to the actual renderer. The third is the UI. This part sits separate from the game and rendering portions so that user input can be taken in at any time and then processed by the game (to take in commands) and to the rendering (to update the what the user sees).

Currently, the game engine is built to produce events from a unit moving to a tree being chopped down. That's sent off to the test-engine for now, until the rendering engine is built, and then you get to see some magical updates. People carrying rocks, balls of water, shiny rocks, heavy rocks, dark rocks and other stuff. It's the stone age, expect lots of rocks.

With the use of events, I can then move all the graphics code into one spot, the graphics component of the game engine and thus put it into a single class. This makes it easy when I want to switch to the real graphics engine and also centralizes the graphics code. Everyone else is just producing messages to be consumed by whatever component does the listening. It also allows multiplexing!

Here's a sample of the current generated world, all random whenever you start a new game, with graphic entities built via events!

Road to the Alpha

So I'm on the long road to a first alpha right now. And by alpha I mean an actual alpha and not the "alpha" you see on Early Access these days (which means anything from an actual alpha to a finished game). That means getting the state machines bug free and reaching a point where I can start iterating on game design.

For now the features include: collecting resources, building structures, goods/food consumption, basic management of labour through work orders and labour assignment. These would constitute a game that is roughly equivalent to a Dwarf Fortress clone. After that I'll slowly introduce technological research, uprooting/planting of vegetation, AI factions and then diplomacy.

It's a short post since there's not much to talk about when you're bug squashing.

Big Cup Small Cup

A lot of the joy from an economic game is watching your industries go ahead after you've set them up. One issue that usually stands out is storage of goods. A game like Cultura is really complex, it has fifteen types of raw items and perhaps upwards to thirty finished and intermediate goods (the exact number is still in flux). This gives us two immediate questions: How many types of storage buildings for the different goods? How many sizes of storage buildings of each type?

For Cultura, the question of types of storage buildings is going to be simplified to "food" and "not food". This is mostly because in the game, the idea of useful storage is more about accessibility, space and preventing spoilage. Only food spoils, so its storage is paramount. Everything else is not really much of a concern so they're mostly for space efficiency (piles of goods would generally be less efficient than a storage pit). Then perhaps there's just two sizes of each: big and small. That leaves us with just four types of storage buildings and then upgrades for them as you progress in technology.

Algorithmically interesting is how you decided which storage site to use to drop off your goods and how you coordinate the movement of goods between storage sites. This is where you get the "sit back and watch" comfortable feeling of an economic game. The current idea is to use a "big cup small cup". A worker chooses the closest drop off site to dump goods. Then when a storage location is full, if it has a larger storage location to transfer goods into then it'll queue up a goods transfer job. This means a small cup can be poured into a larger cup. Whether or not goods should transfer between same size cups is still questionable (right now the answer is no, that way any number of storage location sizes can be coded and people simply keep transferring only "upward").