Collecting Some Thoughts

In progress right now is the industry management and work orders. Each feature at this point is taking a longer time than previous ones since they are larger pieces. For industry management there are several components before an alpha version is complete:

• Goods Tree Screen
• Labour Dialog, Industrial Structures Dialog and Work Order Dialog

Those UI components are completed and functionality for the work order dialog is also complete. The other component that would be necessary for the alpha version of Cultura is the full functionality of Labour Dialog. Each of these dialogs are different ways to handle industry. Labour dialog allows you to assign a number of people to work in a particular industry to produce as much as they can. It also handles tool selection and non-ideal labour assignments (for the alpha it means people who have a house that is designed for a different type of good and in the future it will also mean people who are not using their best skill). The Industrial Structures dialog allows you to easily upgrade industrial structures and/or view what type of households exist. Each house can have only one type of industrial upgrade (dedicated industrial structures don't exist in the alpha and not likely until you reach neolithic age technology). The work order dialog allows you to order up specific amounts of a good to be collected/crafted using a material selection.

Currently, the work order functionality (you set a work order and then the game automatically begins to assign people to complete the task) is code complete but not fully tested (and debugged and so on). So that'll be finished soon enough. The difficulty in getting this to completion is the rather large number of edge cases and UI design issues that come up. Cultura is a complex game and that means a complex UI. But, ideally the game offers a simple UI to the user but holds easily accessible advanced options for them to micromanage to their heart's content. Additionally, outside of the management UI, there will be a limited number of buttons when units are selected to craft items and possibly other options in the future. Much of the complexity arises from how the code should intelligently react to user input (what should a unit harvest, when should a unit stop, should a unit queue up actions or throw away actions, etc)

Collecting all the tasks together what does Cultura need? Let's ignore UI issues for now. Those will be fleshed out when a feature complete alpha is done (since it's hard to say what might be clunky before actually playing the game).

• Managing Work Orders
• Managing Labour Assignments
• Managing Industrial Structures/Households
• Tracking wealth by household
• Family Spawning/Reproduction
• Random Level Generation for new games
• Data-driven tech tree and goods tree
• Data-driven graphic resource/mesh creation

And nice to have for alpha:

• Event-driven system
• Graphics component with event-driven system

There are a few open design questions that haven't been fully settled upon:

There might be a UI for seasonally created work orders. For example, it might be "Hunt up to 150 gazelle meat in Summer". This is useful if you don't want to accidentally damage the ecosystem. That currently doesn't exist. There are only work orders and labour assignment.

For now, each household may have any number of bedrooms, living rooms, dining rooms and other such residential rooms but only one industrial structure. Estates are composed of different houses, each with up to one industrial room. This is to simplify gameplay and reflect the cottage-style industrial of earlier ancient times.

Reproduction is currently going to be progress based and dependent on health. Poor health leads to slow reproduction rates. After a set amount of time, children become adults. A set amount of time after that they couple with someone else and start a new family. This new family moves out immediately and requires additional housing. Insufficient housing leads to homelessness (I'm unsure whether people can just randomly build houses or whether land property is controlled). I'm also unsure if I wish to implement cultural rules (such as a daughter moves into the son's estate). I'm also unsure of how to do estate spawning or estate joining. For example, let's say a son grows up and then gets married. Does he build his house in his family estate and combined his labour with that of his extended family or does he break off and start a new estate? Estates share the fruits of their labour but not personal property.

I'm still open as to the random level design. Mostly I gravitate towards having a balanced world where each land region is of a specific type and that type determines the kind of resources it may contain but is "balanced". For example, all land regions have 5 common resources and 2 rare resources. Additionally, I'll design the goods tree to be balanced. Each type of good leads to an equal number of industries except precious metal and precious stone which lead to extra industries (and thus drives up their value in a soft manner).

Lastly, my current set of "raw item categories" is: grain, fruit/vegetable, dairy, meat, wood, stone, earth, fur/skin, fibre, filler, bone, herb, precious metal, precious stone. Each has 4 mundane and 4 fantasy style goods. Steampunk theme means they may encounter either resource. Eventually I'd like to rank the material types by rarity. An item's appearance is determined by the most rare material used in its construction. I'd like that more rare materials give a greater bonus when used. The resources are paleolithic themed and that is why there aren't apples, pears or strawberries. Although I'm not clear on whether strawberries existed back then, it got rather difficult to be too authentic so the following list is only somewhat accurate to stone age:

• Grain: wheat, oats, rye, barley, stone grass, green brome, silk rye, bluestem
• Fruit/Vegetable: juniper berries, radish, dates, almonds, glowing mushroom, blue leek, yellow berry, tiger nut
• Dairy: none for now
• Meat: gazelle, seal, mammoth, sabertooth cat, unicorn, ice crab, dragon, direwolf
• Stone: granite, limestone, flint, chert, stonewood, rune rock, aquaferra, dark granite
• Wood: pine, oak, cypress, sycamore, silverleaf, ironwood, amberbark, goldwood
• Earth: clay, sand, kaolin, silt, bright clay, dark shale, fire sand, frost silt
• Metal: tin, iron, nickel, zinc, viper stone, cold iron, frost ore, amber nickel
• Bone: gazelle, seal, mammoth, sabertooth cat, unicorn, ice crab, dragon, direwolf
• Fur/Skin: gazelle, seal, mammoth, sabertooth cat, unicorn, ice crab, dragon, direwolf
• Fibre: silk, cotton, ramie, hemp, giant spider silk, thread mushroom, rock string, yarn bush
• Filler: papyrus, ryegrass, leadtree, burclover, hollow weed, elf blade, grey shrub, goldclover
• Herb: tea, ginger, basil, cinnamon, glowing nettle, ember flowers, comfrey root, mandrake
• Precious Metal: gold, silver, copper, platinum, mithril, adamantium, snow silver, null iron
• Precious Stone: turquoise, diamond, jade, sapphire, mana crystal, moonstone, sky pearl, power stone

Technology Management

Tech

Cultura begins in the stone age and is meant to eventually go to the Early Modern age. However, for the first iteration it'll just be the paleolithic age. And for right now, let's take a look at the test UI for the technology management.

In a somewhat Diablo style interface, a list of technologies is shown and rather than be like Civilization where you have research points accumulating to a specific technology you instead receive tech points. Technologies which you can research have a "+" button next to them. I may have technologies which cost more than one point or alternatively give you less benefit per point making some technologies strictly superior to others.

I'd like to add arrows to show prerequisites more clearly and also technologies have "level" requirements not just specific tech requirements. For instance, pottery may require Level 5+ in scraper tool. For now, this screen works. When you add a tech point to tents you are then able to build tents. Once you exit from the screen and go back to the game and then go to the context menu you will see that tent indeed shows up.

Yay

Building Construction

In order to finish off building construction to the alpha stage several pieces were needed:

• Context Menu
• Placement UI
• Material Selection
• Wealth tracking
• Technologies

There were a few bug fixes involved: getting the wealth tracking working right, fixing the graphic for updating trees and so on. The wealth tracking revealed that my quadtree accidentally double inserted items. When I added silverleaf trees, I discovered I had a typo in my code that accidentally changed all trees to the graphic of the one that was just cut down. Imagine my surprise when all my silverleaf trees became pine trees!

Context Menu

The context menu interface has changed to be a keyboard based interface. I left the right-click to show functionality but the primary way to show it is to press the "B" key on your keyboard. The reason? I kept having units selected and then I would right-click only to order the units to do something I did not want instead of showing the right-click menu. Durr!

Basically the context menu shows the base options (which will eventually become icons) and then the sub-categories and then finally the final options. It will also let you quickly open up the faction management screen. I think there will also be a single keyboard shortcut to just go straight into the management screen but that will be for when I create those screens. For now just the context menu!

Opening up the context menu shows this:

We select build

We select Cultural buildings:

Finally, we select Inukshuk

Now we see we can place the building anywhere and also select the materials with which we can construct it.

After we place buildings we can see that there is a bunch of rocks that mark the construction site:

So we can see a preview when we move the mouse around where the building will be and in the lower right corner we see what materials we will be using to construct it. Eventually I will add a resource overlay in the top right corner so that you can see your wealth - liability. You can spend into debt and the display will show negative (indicating that you should get more resources).

Wealth Tracking

Wealth tracking is accurate to the game tick. In actions that affect faction wealth it updates it on the fly. This is a bit dangerous (if I miss a spot in the code then the wealth is incorrect). To make up for this, I have a debug assert that does a resource wealth audit every 100 game ticks. If there is a mismatch between calculation at that moment and the current cached value of wealth then an exception is thrown. This will help me debug any place I have missed proper wealth tracking.

Wealth is defined by having resources stored in structures (therefore units carrying items do not constitute as part of wealth). Liability is defined by structures placed and how much more resources they need. Once industry is added, liabilities will also include work orders and item requests.

Technologies

The technology UI will be next but for now, factions record their technology in a std::unordered_map where it is technology ID to tech level. Many techs are repeatable and so int to int is a reasonable structure. Technology limits how many materials you can select and what buildings you can construct. Right now the two test structures a inukshuks (which the faction begins with) and tents (which the faction does not have). So when you open up the menu, only buildings for which you have the technology show up. Additionally, attempting to select materials beyond the limit results in nothing happening (there will be an error message added in the future). I will also probably have to add information in the material selection on technology limits such as "You may select up 1 material per item type".

Diplomacy

Let's take a look at Cultura's AI engine and focus on the diplomacy section.  When you trade or make deals how do they figure out how to react, how to figure out whether it's a good deal?

We start with a way rate to all items equally.  Any item is thought of in terms of how much it increases a faction's score.  What is score?  It is the health/happiness/administration provided by the deal item.

Value = health + happiness + administration

It might be possible for a faction to value these scores differently.  If health is low, health is more valuable.  Administration points are more difficult to obtain so they are more valuable.

Value = health * bias1 + happiness * bias2 + administration * bias3

Okay, but how do we calculate the score?  We can define a set of "primitive" functions that we can use:

A) Direct Function

Trade item directly represents goods that have a score rating that can be estimated.  For instance, each unit of Pine Cupboard provides +1 health, +1 happiness.  You are offered 200.  We have no bias.  Therefore it is worth 200 * 1 + 200 * 1 + 0 * 1 = 400.

(Considering existing stocks)
We already have 100 Pine Cupboards and we have 200 people.  Each person gets full benefit from 1 Pine Cupboard.  Additional pine cupboards only provide 1/10 the score.  Now the value is 100 * 1 + 100 * 1 + 0 * 1 = 200 and for the surplus amount is worth (100 * 1 + 100 * 1 + 0 * 1) / 10 = 20.  The value is 220.

B) Trade Opportunity Cost Function

The value of a particular good is the best trade you can get for it.  If there are no previous trades this value is unknown.  Thus the value is the HIGHEST score of all the goods you have traded it for.

For instance, say you have 50 oranges.  They can be traded for 1 pear (+1 health) or 1 mango (+2 health).  In the first trade it is worth 50 health.  The second trade is worth 100 health.  Therefore the trade opportunity cost is 100 value.  We are simply applying A (the direct function) to each set of goods it can be traded for.

Alright, so there's two primitives.

That's pretty good if we're exchange goods.  We calculate the value of what we are trading away.  Let's take a look at an example:

Goguryeo Offers:
200 mangoes

Asks:
50 silk

Direction Calculation
Okay, 1 mango = 2 health.  We have no existing mangoes.  Therefore it is worth 200.
Silk = 2 happiness.  We have lots of silk, overwhelming our people.  So it is worth 100 / 10 = 10.  It is worth 10.

Trade Calculation
We are being offered the mangoes.  We ignore this calculation.
The best other offer is durians which are 3 health each.  Therefore, 50 durians are 150 health.  Trade value is 150.

Using these scores we determine this deal is:

Goguryeo offers 200 and asks 150.  Deal is +50 from our perspective.  Therefore we should accept at a high percentage chance.

Alright but what about more complex deals?  War, threat and raiding.  The situation here is more difficult.  But we could try to break it down to this:

C) Threat Cost

The value of a change in relationship is the threat cost difference.  This can be both negative and positive for when relationship deteriorates or improves.  We figure out the power of an enemy military.  For now we might make a simple calculation:

Military = sum of unit power values * bias

The bias is affected by real data points.  If we fought a war previously and strength was underestimated we can push the bias value to a higher one.

We figure the amount of military needed to counter another faction to be:

MilitaryPowerNeeded = MilitaryPower * Threat

The value for threat can simply be the value of relationship score between the two factions normalized over a value range (between 0 and 1).  So for any change in relationship then the threat value will change and change the MilitaryPowerNeeded.  The difference between the new and old value is the MilitaryPowerNeededChange.  We then estimate how many goods are needed per point of MilitaryPower.  How?

ValuePerMilitaryPower = MilitaryPower / Value of Military Goods

We take the total military goods use calculations A (direct) and B (trade) to get the value of the goods, divide our military power by that and figure out the value per military point.  Let's look at an example:

Song Dynasty demands:
Submission

Okay, if we refuse then we expect -10 relationship which in threat terms means +0.1 threat.

Song Dynasty has 5000 militaryPower.  Current threat is 0.2 and we might expect +0.1 threat if we refuse or -0.1 threat if we accept.  So if we refuse, we need 500 militaryPower, if we accept then we need 500 military power less.

Currently military power of your faction is 2000, with goods valued at 4000.  Therefore each military power is worth 2 value.

So the trade deal is:

Accept: +1000
Refuse: -1000

Are we done?  Military calculations are more complicated than this, so no.

B2) Opportunity Cost of Labour

The reality is that military goods are a drag on an economy.  So we need a new calculation.  Things we could have built if we didn't make the military goods.  Let's call that calculation B2, the opportunity cost of a good in terms of production rather than trade.  If we freed up the labour used to make the military goods what could we have made and use the calculation of A and B to determine the value of those goods.

Total Good Production / Total Labour Used = labour cost of good

This cost is chained.  For instance, a Flour Mill = Gear + Spoke.  Gear = 10 stone.  Spoke = 5 wood.  Therefore Flour Mill = labour cost of each flour mill + 1 * labour cost of gear + 1 * labour cost of spoke + 10 * labour cost of stone + 5 * labour cost of wood.

Knowing that 1 unit of military power = goods whose labour cost is say 50, then we see the best highest value good we could have made instead.

We'll say that each military power could have been 3 honey bread which is worth 6 value.


D) Raid Value

We might want to attack someone for their goods.  In this case, we estimate loss of military power for goods gained.  We might simply come up with a random starting value and then shift it up/down according to actual raids conducted.  Militant powers would estimate higher at first, pacifist powers would estimate lower.  Real raids give real numbers.

As an example: We raided Song Dynasty and gained 300 rice.  Each rice is +1 health.  We lost 20 military power (calculation is the same as discussed in C).  Let's say each military power is 2 value.  We gained 300 value and lost 40 value.  The gain is 260 value.  What is the raid value?  The value is 260/20 which means each military power is worth 13 points.

Like trading, we take the opportunity cost calculation.  The best raid value is the one used.  We pretend for now that Song Dynasty is the best place to raid.  What's second best?  We'll say it is a nation called Silla.  With Silla, each lost military power results in 8 value.

Notice that a tougher target means higher losses and will lower Raid Value, so it inherently takes into account both the prosperity of a target and its defences.

That's great we have a way of figuring out military power expended and the value we get out of it.  But the problem is, how much military power are we going to expend?

Now we can combine the two calculations of C and D.

Song Dynasty demands submission.  We can submit and free up 500 military power.  Therefore submitting is valued at 3000 by calculation C (military goods no longer needed and we value it by A, B and B2).  Therefore the final value is 3000.

Or we can reject.  By calculation C that is valued at -3000.  But it means our raids continue.  In order to break even we must expend at least 3000 / 13 = 230 military power.  So the question now is whether we are willing to risk that much military power.  A faction can set a military power risk threshold.  Let's say Gogoryeo is willing to risk 300 military power.  A -3000 value is not enough to justify the stop to border attacks against Song Dynasty.  If instead Gogoryeo is only willing to risk 100 military power then it is no longer justified to reject submission.

So finally we have a faction's thresholds.  This isn't a primitive calculation.

E) Military Deployment Perceptions

Factions have two values against one another.  The first is the threshold of military they wish to deploy against someone and feel it is still reasonable as a percentage of their military power.  The second is how much military they believe an enemy nation is deploying against them.

Say you are aggravating Song Dynasty.  You injure your relations with them but you know they are already fighting a conflict with Jin Empire.  So around 70% of the Song military is deployed against Jin and of the 30% left they are deployed in various ways.  You notice that only 5% of their military is deployed against you (Gogoryeo).

Song Dynasty has 5000 military power.  Only 250 military power is deployed against you.  According to previous conflicts you trade losses at a ratio of 2:1.  For every military power you lose, they lose 2.  That means you need 125 military power to take care of this threat.

If the actual threat value is higher than this, this means they are temporarily weakly deployed against you for whatever reason.  So if threat value says you need 250 military power but military deployment perception says 125 military power, take a value in-between.  We can keep it simple and just say the half-way point.

You combine D and E and figure out that the requirement of troops is 187.5 and furthermore, increases in threat value are not as significant because if military deployment has not changed then you perceive the military threat to be less than it could be.

What else is important about E?  Shifts in military deployment from your actions.  If you sign a deal to aid someone else in their war against an enemy, you see benefit from decreased enemy deployment along your border.  You might also incite war between two factions, using this calculation to see the benefit versus the cost of goods needed to convince the others to go to war.

Alright well that was quite a bit.

With these we can compile more complicated formulas by putting them together.  For instance:

1) Damage Infliction

Song Dynasty dislikes the Gogoryeo and denounces them.  They believe this will cause the Silla to take a more aggressive stance against the Gogoryeo because then the Gorgoryeo kingdom must redeploy military against Song.

For Song Dynasty it sees by D (threat value) a value of -200 due to increased military required against Gogoryeo.  However, it looks at E (military deployment) between Gogoryeo and its neighbours.  It figures that this begins to draw military away from its other borders and invite attack because their deployment levels drop below some of the military thresholds of its neighbours, such as Silla.

So, it calculates that military losses from such conflict will drop the total size of the Gogoryeo kingdom and as such then lower their troops along the Song-Gogoryeo border.  This freed up military in the long-term is calculated by D (threat value) and is then seen to be +300.

Threatening Gogoryeo is then worth +100.

2) Accepting Roman Protectorate Status

The Romans promise military protection but then we (the Gauls) must pay tax.  By calculations A and B of the non-military goods sent we figure out that the value is -500.  In return the Romans promise protection.

Between the Gauls and the Romans, we see a threat level drop.  Using calculation D we figure out that the freed up military is than valued at +300.

The Romans also post a garrison in our lands.  Depending on our trust of the Romans we may view this as completely not a threat (100% trust) or an insidious invasion plan (0% trust).  It's likely somewhere in-between.  We calculate via D and/or E that this lowers our military deployment and so is worth +700 but due to our trust level (70%), it is lowered to +490.

The total deal is worth +290.

Radial Right-Click

With a RTS interface well known, the hope is that there is no need for any menu system at all for basic RTS commands. Move, harvest, attack, follow and drop-off are all just a matter of right click when you have a unit selected. Selection is through a left click. Scrolling is by holding your mouse to the edge of the screen or using WASD.
In keeping with the same theme the right-click menu will be just as minimal. It'll consist of icons that appear in the same manner as a context menu and will be designed radially. For the prototype version, it'll just be simply arranged box-shaped buttons but the idea is shown below:

Once the player has selected something to build then the UI shifts into building placement mode. Originally I had designed it to be a simple click and if you wanted to place multiple buildings then it was a shift click.
The shift in mentality is to have a more city-building friendly UI. In that light, placing just one building is more rare than placing multiple buildings. So shift is not required. After you place a building, the mode persists in order to allow you to place more buildings. Instead, you need to right-click in order to exit building placement mode.
Building structures in Cultura is a bit complicated versus most city-building games. Because my concept of "wood" is actually a category of goods you can collect (pine, oak etc) and I want the interface to be more friendly, I opted to follow something that is a combination of Sim City 2000 and Capitalism 2 interfaces. Basically, you go through the radial menu. First you select build. Then you select housing. Then you select tent. Now you are in building placement mode. A tent requires wood and fur/skins. In the bottom right corner a window would show up to show the various options and persists as you place buildings. Those settings are used per building placed. This allows for a quick way to build a lot of "common" structures using cheaper materials and then splurge on a select few "elite" structures in a quick and easy manner.

Sim City would have a large left panel with lots of building categories which would open into small sub-categories. Capitalism would let you place a building and then go into a settings menu. For Cultura, the large left panel is replaced by a radial context menu. The settings screen is replaced with a temporary settings panel at the bottom right of the screen. The real estate used in the UI is then temporary and once you are finished it immediately goes away.
I'll work on tweaks to make the UI experience faster/smoother once I have more of a game to play around with and see what is good and what needs to change.

Context Menu

Context Menu

Rather than have a full-on RTS style button grid at the bottom of the screen, Cultura will have a minimal menu presence. The game will rely on intuitive RTS control scheme (left click selection, right-click action) and a small tutorial to teach it. So it relies on established gamer knowledge and standard UI implementation. For everything else it will be done by a context menu. You right click anywhere and the context menu shows up.

In Cultura, it uses CEGUI and it uses Ogre3d and those two combined means they must communicate with each other. The actual context menu exists in CEGUI. The effects it has on the game and the RTS interface exists in Cultura code (which uses Ogre3d). That means I need the CEGUI component to communicate with the Cultura component. Now, since I have yet to implement an event system it entails a bit of tight coupling.

The Cultura component handles when to show the context menu and then "gives up" handling mouse events. The CEGUI component is informed that it should show the context menu and properly attaches listeners to various mouse events to buttons pressed. When a left click occurs that is outside the context menu, the menu is hidden and control is returned to the Cultura component. By control is returned, I mean the Cultura component now understands that the context menu is closed and therefore goes back to its original handling of mouse events. This means that on the first left click outside the context menu, the context menu is hidden, but no unit selection occurs. I think that is actually somewhat expected. The primary issue with making it any more complex is that because I cannot guarantee order, in a reasonable manner, of how an event is handled, the CEGUI component simply either handles the mouse click or it does not through all its possible listeners and the Cultura component can be blind as to what happened and simply waits for control to return.

The context menu currently only allows the construction of buildings, it will eventually include empire management options. Also it will probably become a radial menu and at the very least, use icons instead of text (but have text tooltips). If a build is selected, the menu then shifts into possible buildings that can be built (based on faction technology) and then if a building is selected, it then returns control to the Cultura component which then handles the placement of the new structure.

In the Cultura component, it will have a transparent version of the structure sitting at the mouse cursor locked to the closest game grid square. Left click means to place. Right click is to cancel everything. There is shift-click to place multiple buildings. Each placement of a building queues a faction-level action in the faction's action queue. In the faction class' updateTick() method, it will attempt to assign jobs to idle civilians (who work for the government directly). That can be more complex later in the game when there are more complex government options.

Eventually you will need a way to cancel actions and also to requeue actions if civilians are interrupted and stop doing a job, that job needs to be requeued.

I will finish "factionActions" in the next post!

SaveGood and LoadGood

SaveGood

Saving is the "easier" part in the Cultura project. What's being used is the simplest thing that can be done for now which is serialization into a bytestream and then writing this to a file. Difficult to debug and difficult to maintain but extremely fast. Essentially, each class that needs to have data save implements the serialize function, deriving from a class I called GameEntity (for you Java folks just pretend it's like Object). From here you can do whatever you please.

For primitives I simply cast their address to a char* and then save bytes into a byte buffer equal to their sizeof(). For objects that are not pointers, I call their serialize function. For objects that are pointers I can do the same. For arrays and other objects with size, I serialize their size and then serialize each individual object. The resultant byte stream is then directly written into a .sav file on disk.

Key notes here are that dependencies are not serialized (for instance, someone with a reference to AppStateManager will not serialize the AppStateManager and cause an infinite loop of serialization). Serialization is strictly "downstream" in the class hierarchy. Second, the graphics components are not serialized. I call createScene after I'm done deserializing when I load in order to recreate all the graphic entities.

LoadGood

Loading is the trickier part of deserialization although all of the problems are of course because you didn't serialize properly :). A file is loaded up, the contents are read and then put into a bytestream. This buffer is used for deserialization.

For primitives I can simply read a number of bytes and then assign the value I get to a primitive. For instance, read sizeof(int) bytes and put it into an int. Whatever value you get is what it is. Yay!

Objects are somewhat trickier. The constructor for all my classes that are serializable have a default constructor to make it easier to do this. In the default constructor, non-pointer member objects are constructed with their respective default constructors. When deserialization occurs, those objects can simply call .serialize(ByteBuffer) and for pointer objects then we create a new instance (using the default constructor) and then call ->serialize(ByteBuffer).

For arrays and the like we have to get the size, which we saved, and then resize arrays or unordered_maps and such and then begin to deserialize objects or primitives and then add them. For certain containers, we don't serialize the container, we merely serialize the contents. For instance, we can serialize the list of units in a faction and then create a new QuadTree and then add them to the QuadTree (so upon loading it is a fresh QuadTree with the saved units).

Dependency injection is terribad. After creating new objects you must then inject dependencies again since you cannot save pointers in serialization (what would it point to?). This creates very strange and complicated deserialization call trees. The worst of it in Cultura were actions which require pointer to objects to allow it to manipulate the game world. Poop.

And here is the result of loading, the unit is still carrying out the action that was queued, a harvest node action.

Menu Upgrade

The menu automatically generates the file name. I'll leave it in automatic generation even to release to avoid problems with bad user input. Both the save/load menu refresh each time you go back, looking at the files that exist in the save directory. It is also capable of stripping the .sav from the file name to show the user a nicer looking name (although right now it's just numbered from 0 to whatever). There are no loading screens but in the work needed to perform loading, quitting the game, going back in, creating a new game, saving the game or loading the game all work as expected (game is cleared, there's no accidental double deletes, there may be a little bit of memory leakage but I haven't checked yet).

Now you can SaveGood and LoadGood