Saturday, January 25, 2014

Cornucopia of Consumption

Food

Let's talk about food! In Cultura, one of the big aspects is the economy: collecting resources, building goods and then consuming those goods. One of the biggest and earliest ones you have access to is food and its primary benefit is health. There are two big ratings, health and happiness. Health affects reproduction rate and also prevents sickness. Happiness affects emigration and rebellions. So how does food work?

A person consumes food once a day (rather than three meals a day plus snacks like real life). Based on their previous number of meals they get a health bonus. This is calculated at the end of each day. This goes toward reproduction if the person is a parent in a family with at least one male and one female parent. If not, then it does nothing other than add to the health score of a land region.

The health score of a land region is important because a low score below the required amount can result in sickness or worse an outbreak of plague. You don't want plague.

So what kind of food and what kind of bonus?

The health bonus is based on the total number of material types eaten. There are three item types available in Cultura during the paleolithic age: grain, fruit/vegetable and meat. Each item type has eight material types. Therefore the maximum paleolithic bonus is twenty four. The number of meals tracked is seven. Therefore a person must eat foods that contain more than three types of materials each to get the full bonus.

For example, a person eats wheat bread for six days and then eats a berry pie (blackberry and strawberry). This person ate wheat, blackberry and strawberry in the past seven days. The total bonus is three health.

How to Code

So how do we record the information in the code? Right now a Unit class contains no information about what the unit ate in the past number of days.

Let's start with this:

  • Let d be the number of days to track
  • Let m be the number of materials across all item types
  • Let n be the population

Circular Array

Blogs aren't exactly the best place to display this kind of analysis but let's run with it for now. What if we tracked what a person ate with a circular array?

Complexity

  • Add: O(d * m)
  • Check Score: O(1)
  • Memory: O(d * sizeof(Item))

During add we put in an Item into the circular array. We then have to run through all previous items to see if the item contains materials that do not exist and thus adds health. If we overwrite a previous entry, then we must do the same. We check the materials of the overwritten item, run through all items and see if it is still satisfied otherwise reduce the running count of health bonuses.

Memory usage is the size of the circular array with pointers to Item objects.

Hashmap of Counters

Alternatively we can use a simple hashmap of counters which allows us to use the readily available std::unordered_map where the key is the material id and the value is a counter. Each day the health score is checked the counter is decremented. Upon reaching zero the entry is removed.

  • Add: O(m)
  • Check Score: O(m)
  • Memory: O(d * sizeof(int))

We can see that for add, every material that exists in the food being eaten will then reset the counter in the hashmap. During check score, we must run through the whole hash map and decrement counters and count. The memory usage is a hash map of counters which are integers.

Analysis

Add: Well we do the same amount of add as check score per unit; once a day in the game. If we set d = 7 and m = 24 then Circular Array has roughly 168 operations in worst case scenario while Hashmap has 24 operations in worst case scenario.

Check Score: For circular array it keeps a running count of health bonus so it has 1 operation in worst case scenario. For hashmap, it must go through the whole hash map and thus is 24 operations.

Memory: For circular array we have to keep the Item objects around because we have to keep track of what the person ate. An Item object is far larger than an integer. With d = 7, we have 7 Item objects for a circular array. With the Hashmap we have, with m = 24, 24 integers and then the cost of a hashmap. Assuming that an Item is larger than 3 integers, it's likely the circular array takes up more memory. An Item object is most definitely larger than 3 integers if you were wondering.

Given this analysis I think I will go with a hashmap. It is quicker to implement and I'm not seeing much gain from the circular array (except that it's cool).

Sunday, January 19, 2014

Cutting the World

Land Regions

Land regions have been coded! What does this mean? The world is cut into a fabric of different land regions. The intent is for landlocked regions, mountainous regions, coastline regions, fully ocean regions (which will have no ownership possible) and more! Each land region has its own kind of resources (trees, grasses, bushes, minerals, animals). For now, animals will stay in their own land region but some future iteration may introduce migratory patterns.

Families

Families have been introduced, tracked at the faction level, but remain untested. They allow a set of parents, adult children and children. Currently, children don't exist so any new children are instantly adults (and also, there's no pregnancy so they just fire out adults from the uterus). There are some open design issues. A progress bar to the next birth is tracked at the family level but what happens if...

  • A female parent leaves? Does she take some of the progress with her to her new family?
  • A female parent dies? Does the progress bar get reset?
  • The above two questions but with polygamy (specifically, multiple female parents)

And actually historically speaking, the usual family unit was the extended family. Grandparents, parents and children. Homosexual adults were suspected to have played the role of additional parents in a family during the early stone age (ie. helping to raise the children of their siblings). Sigh!

Pathfinding Issues

I've made terrain passible or impassible. This introduced the new problem of the greedy pathfinding algorithm no longer being 100% successful. Poop! People would dance about walls as if I coded in special spells that would allow them to pass through mountain blocks. They were wrong and they dance forever. So I introduced a basic A* pathfinding algorithm for short distance (below 5 grid spaces). Is that good enough? I don't know!

For one, the A* I coded is terribly unoptimized. You can get pretty close to linear runtime complexity (for those of you who know what that means) through a few tricks (because real world use of A* is usually not that complicated). I also chose 5 grid spaces because I intend for buildings to be about 3x3 in size. However, they'll be irregularly shaped and so I may have to increase use of A* to longer distances... which implies I may need to optimize. I'll cross that bridge when I get there.

Continuing Graphical Plague

Imagine a world where things appear partially submerged in rock or soil when they should not. I have had a few graphical glitches that continue to harass me unto the night where "blocking" is not working. A mountain square from further away appearing above a mountain square closer. Items that don't appear on top of the floor but submerged in them. I've been working through these but because the game has not been feature complete I have not put them high on the list of to do. When it comes time to showcase this game to people, these will have to be fixed. Of course so would the horrible horrible UI.

Next Stuff

I'm going to add a game clock. This tells you what year the game is. And the day. Oh and the season. It'll be useful for tracking reproduction and ecological changes (trees growing, animals pooping babies). It also means I don't need to go into debug mode to figure out what day it is in my game.

Consumption of goods and a health/happiness indicator. This is the core of the game afterall. You collect poop. You punch the poop into various shapes. You consume the poop. Then because you are materialistic, fully rational, capitalist monster this makes you both happier and healthier. It ties into everything. Healthier people get faster progress on their next birth. Happier people don't stab each other.

Monday, January 6, 2014

Build All The Techs

Last caturday I managed to complete two pieces so that I can move onto my next features (stuff listed last post such as the constitutionally appropriate family class). These two things were the tech tree UI and getting the build menu to be data driven.

Tech Tree

Cultura will include technology and for the first iteration of the game it'll cover the paleolithic and neolithic age (needless to say I have a lot of work ahead of me). The general idea of technology is that each one has an id and a level. Complex technologies have prerequisites not just of particular technologies but their level as well. This allows me to make the tool technology more interesting and have it lead off to other industries slowly. For instance, you might start with the "hammer stone" and you upgrade up to level 5 before you can move onto the "biface stone", the improved stone tool. The "biface stone", upon reaching level 1, will open up several industries. This gives a way for a smoothish transition between tools.

What I'd like is for a hammerstone to provide 20% production bonus (just an example) and then 100% bonus at level 5. Then the first level of biface stone immediately gives 100% bonus and each point gives 40% bonus instead of 20%. Given that situation, I'm leaning toward putting "maximum" levels for some technologies.

There are a few caveats I encountered while making the simplistic developer friendly UI. The CEGUI VerticalLayoutContainer and similarly the HorizontalLayoutContainer have two methods that are of interest when sizing them out. There is setMinSize and then setMaxSize. It turns out that if you don't setMaxSize on a container it has a default max size and will cut off items within it! So I had to do something silly like


container->setMaxSize(CEGUI::UVector2(CEGUI::UDim(10.0f,0), CEGUI::UDim(10.0f,0)))

Build Menu

The build menu was reduced to a single menu. Bringing up the context menu will show the buttons Build/Demolish/Management. I'm still working on whether that's a good idea but UI improvements are put on hold until all game features are done. I'll start doing the UI in beta development. Anyway, when clicking on build it brings up all the buildings that I've put into the xml file. It then checks whether the player has the proper technology. Then you can build away!

Other Stuff

One interesting thing I ran into on Sunday, the day after Caturday, was trying to get my work environment set up on another laptop. It turns out that if you do not have the DirectX SDK installed on your machine (if you encounter s1023 error upon installation it means you have a VC++ dist installed and must uninstall it to allow the SDK to install it again) you get the curious error of "RenderSystem_Direct3D9_d.dll not found". The error is a bit misleading. It's right there. The problem is that it can't find something else upon loading it and one possible cause is that you don't have the DirectX SDK. Only really relevant in the debug case.

Despair at the developer friendly graphics

Wednesday, January 1, 2014

Design All The Things

Cultura is entering into an alpha state where it'll be playable on a test map. There are a few things I want to get it going:

  • Families - Children and Marriage
  • Households - Wealth tracking, management and consumption
  • Ecology - Renewable resource growth, non-renewable resource mining limitations, climate requirements for plants/animals
  • Land Regions - Splitting the map into irregular shapes

Families

Everyone in the game will belong to a family. It's defined as a set of parents, unmarried children and children not of age. It's used to track children and births.

Births are fairly simple. For Cultura, it's a compromise with a game world to give a player more direct input into affecting how fast they can get more children. A family has a single progress bar. When it fills up, the mother becomes pregnant. Then after a set amount of time a new child is born and the progress bar is reset to zero. In order to fill the progress bar, the family must be healthy. The higher the health, the faster the progress bar fills up (excess health fills into the progress bar).

Children stay children for a set amount of time. Then they become unmarried adults. I plan to have a relationship progress for these people and when they achieve it they then marry with someone else who has also filled their relationship bar. This allows the player to have direct impact on the speed of marriage. For instance, holding more festivals and events fills the progress bar faster. For now, once someone is an adult then they will immediately attempt to form a new family with another adult. These two adults are removed from their original families to form a new family as the parents.

In the future I will probably put in a baby time period where the people can do nothing. Then a child time period where they can go to school, play games or sports or apprentice and earn skills and do some amount of labour. And then finally they enter an adult period where they have full labour capacity and end their education and so on.

For now, complicated issues like divorce will not exist. Widows can remarry (they'll count as an unmarried adult).

In code, what will be done is adding a vector of family objects to a faction. Each family object tracks a vector of people for the parent(s), a vector for the unmarried children and a vector for the children. Homosexual families, polygamous families, adoption etc occur through other algorithms. The family class itself will be structured to handle it all in the future. For now though there'll just be vanilla marriage and family fission/fusion (mother/father plus the children). During update tick it would track excess health of the family and put it into the progress bar for next birth. The number of children determines the amount required for the next pregnancy. Homosexual parents would obviously just have zero progress for pregnancy. There is also intended to be future technology (likely medieval age) for contraceptives that would also stall progress. This may be useful if resources become tight.

Households

Separate from families are households. A household is defined as everyone living at the same household. There can potentially be multiple families living in the same household. Each person tracks their living space separately.

Households are important in several ways. A person who crafts any item will do so at their household and thus utilize the industrial improvement of that house. They will also store goods at their house. They also receive benefits from the housing but split across the number of people living there.

I intend to track wealth by household rather than by family. I will have to see whether that makes sense in the future.

People consume goods individually and thus acquire their health and happiness bonus from goods consumption separately.

In code, this means that each person has a reference to a building id which represents their home. When conducting unit actions, such as harvesting or item crafting, they first refer to this building id as their drop off point. If none is available or it is not suitable then they look to public buildings that are nearby.

Ecology

The game currently doesn't replenish resources which is bad news if you actually wanted to play. The update tick functionality needs to take in a game clock of some sort to determine the time of year (and thus the season). As well, plants and animals need requirements such as season of growth or climate required. Animals may have additional requirements. I haven't yet decided whether those requirements should be set in stone (a deer always require pine trees) or have them procedurally generated as the game map is formed (a deer that spawns in a land region with oak trees will have oak trees as a requirement, whereas a deer that spawns in a land region with maple trees has maple trees as a requirement).

During a growth season, a land region tracks the number of plants of a particular type, their growth rate and then adds a certain value back to the land during each update tick. This way if the player changes the number of plants then they also affect the total growth rate. For grasses and bushes (such as wheat or strawberries) each plant can regrow on its own because they are never cut down. Trees on the other hand regrow base on the number of trees still standing and then new saplings only spring up after the existing trees have all grown back to their full amount.

Non-renewable resources don't regrow and their limitation is based on the amount that can be drawn from it at any given time. For instance a single stone deposit may only have 100 stone drawn from it per hour. This can be improved with technology (such as building an open pit mine on the deposit).

Animals have requirements based on the vegetation or animals that exist in a land region. So if a deer requires 5 pine trees, there are 100 pine trees in a land region, then there can be 20 deer. Then additionally, deer are born slowly based on this amount. If you increase the number of pine trees then you also increase the number of deer. The vice versa also applies. This means that deforesting an area also impacts animal numbers.

The UI hasn't been built yet but the land management screen should be colourful and clear about the ecological implications of a player's actions. They need to know the growth rates and animal birth limits, as well as what affects them. After that the game has no restrictions. You can ecologically destroy the world if you want.

In code, the update tick needs an optional parameter for the terrain manager to take in the game clock. Well, the game also needs a game clock! While it has a clock in general it doesn't track the time of year and reset to zero each new year.

Land Regions

Land regions define an irregular shape of land for several in-game purposes. The first is the plants and animals. Each land region has its own set of plants and animals. One land region might be pine and deer. Another might be pine and rabbits. Taking different land regions means gaining access to different types of plants and animals. However, the game is designed so that you can play with an incomplete set of resources and simply trade with other players for what you don't have.

Second is that these help to define interesting borders. When you take a land region you own that area and others may not enter without eliciting some political consequences.

Third are roads. I intend to make pre-set roads between neighbouring land regions. These roads can eventually be improved with technology. They start as nothing but are coded into the game so that when people want to travel to another region or deliver goods somewhere, they take that path and not a random path.

Fourth is climate. A land region can have a custom climate. I won't make it too complicated at first. Maybe just cold, temperate and hot. Plants and animals will have climate requirements and if they are in a land region that has the wrong climate they won't grow or grow at a penalty.

In code, I will probably have the terrain manager keep track of these land regions. Being irregularly shapes makes their definition difficult. My current compromise is for a land region to be comprised of a set of rectangles. In order to test if a particular square in the game exists in a land region, it is tested against that set of rectangles. That is a relatively quick test that may take upwards to 5-10 such checks. It depends on how crazily shaped I want land regions. The rest of the data that may exist are perhaps a set of "roads" (set paths in the game for units to take), the climate and also the plants/animals that exist. I may even shove some graphic variables in there (the static geometry of the trees and so on) since I don't currently have a graphics module in my engine (woe is me).