Crash Course Economics

We seem to have completely omitted units from the mining concept. Mining seems like one of the few things your population could actually do for the player other than invisibly generating points.

Also, since the game generates organisms procedurally, it decides whether an organism's code has fur/wool/both/neither, so by definition, if we include them, it must know whether they are present on an organism, so the only one with the problem of ‘working out’ whether something has or has not got a feature is the player. From the game's perspective, there is as much of a difference between fur and wool as there is between a dorsal fin and a pancreas, so I really don't understand what the problem is.

The problem is that somewhere in the game, we will have to decide whether a creature has hair, wool or whathever. And unless creatures evolve fur and wool like if they are evolving bones or exoskeleton, we can´t differenciate them.

@Nick: If we are going the stockpile route, a noise map is not necessary (it actually would make things harder). Just plain old RNG (random number generator).

Edit: @Nick: Yes, thats about it. However, i dont think mineral ocurrence will vary too much with biomes, they wont need much work. Somethings could be affected, maybe a geologist could help here.

i have an idea about the fur and wool

in the creature creator you have a choice of skin right?
just put wool or fur or both as a option of skin choice
problem solved because the game can just read the skin type.

@The Uteen: Mining is included in the post I mentioned. However, it the case of mining, the compound is always necessarily mined right away. Most often there is first earth or stone in the way that must be mined/dug out to collect the compounds (ores). To address this we would simply need an algorithm that deals with figuring out how much to dig out.

@Dani: Oh ok no noise map then.

@Rorsten: Primarily, feathers/fur/hair are painted on with a brush. The level of distinguishing between them I don't know. Further, the computer controlled species evolve without an editor, so how would the computer identify wool/fur on them? That solution would only work on the player's species.

Btw, I have been quite quiet recently. I will be coming back full force tomorrow. I also have a lot of stuff I want to post!

What about scrapping the whole wool/fur distinction and rather going for a generic category hide that has hair of a certain length and is possibly water-resistant and has a certain resistance to temperature conductivity?

NickTheNick wrote:

@The Uteen: Mining is included in the post I mentioned. However, it the case of mining, the compound is always necessarily mined right away. Most often there is first earth or stone in the way that must be mined/dug out to collect the compounds (ores). To address this we would simply need an algorithm that deals with figuring out how much to dig out.

@Dani: Oh ok no noise map then.

@Rorsten: Primarily, feathers/fur/hair are painted on with a brush. The level of distinguishing between them I don't know. Further, the computer controlled species evolve without an editor, so how would the computer identify wool/fur on them? That solution would only work on the player's species.

Btw, I have been quite quiet recently. I will be coming back full force tomorrow. I also have a lot of stuff I want to post!

Yes i know that they evolve without the editor but they still have a skin type correct?

Yes, they can have its own skin type, but we have no way of choosing which one they have.

Either we come up with a way of deciding it or we scrap the distinction, as darkgamma said. I always though that such distinction is not necessary.

Okay so can someone get the complete list of biomes? If possible PM it to me or post it here.

So I originally intended to suspend this thread until Microbe Stage was more substantially finished. However, I will be reviving this thread because it addresses the compound system, which ties into the Microbe Stage as well. From what I can remember, last time we were here we were discussing where compounds come from. So after we wrap that up, the next sub-episode, aka part II, is "Where Compounds Go", will be posted.

Lastly, after part II of episode II is done, we will finally move on to episode III, which will be all about "Compound Properties". This will be the step that I see as most contributing towards microbe development, or even the whole game at large. I have a basic list of some properties for now, but I'll save that for later.

Now, until I get my next chance to post here again, take this opportunity to revive any discussions you were having before or raise any new and relevant points. How is the chart doing, Holomanga?

If you're new to this thread, don't worry, just take a skim of the past episode and jump right into the conversation. Ideas and participation are welcome!

Okay, so just to summarize the last part...

1. Compounds naturally stockpile in nature, based off of a Random Number Generator, with fluctuating abundancy.
   
2. To collect these compounds, the player must build appropriate buildings within the vicinity of the compounds stockpiled in nature. A building is identified as "appropriate" for collecting a certain compound if it contains a certain Function Part, or if it equips its workers with a certain Function Part, that is identified to be able to collect that compound.
   
3. Compounds can also be collected with units equipped with the appropriate FP, with appropriate being defined above.
   
4. The rate at which a building collects the compounds is determined based off of how many people it employs and the technology (i.e. the Function Parts it uses).
   
5. Buildings stockpile the compounds they collect.
   
6. Energy cannot be stockpiled, but must be used immediately upon collection or is lost.
   

So that is mostly everything. However, there are two issues I still see left for us to confront.

First, how many types of compounds there should be for different variations of food. Here is my list of compounds to cover food, but its just a rough draft, so give me your suggestions.

Grain
Fruit
Plant Matter
Meat
Seafood

And the second, more important issue. We need to go through the list of FP's and decide which ones allow the collection of which compounds and at what rates

Feel free to discuss the above, or just what has been covered so far, until I get the complete list of Function Parts put up.

I'd base different foods off of different parts in the OE, since those will already be defined by compounds. A refined, OE-based list would include:
Woody Plant matter
soft plant matter
fruits
grains
plant fluids
---
fungal matter
---
animal flesh
animal bone/connective tissue
animal fluids
There you'd have all of our food groups: grain, fruit & vegetable, dairy*, protein, and fats and oils.
*interestingly, dairy is only a recent addition to the human diet. The first humans able to metabolize lactose appeared sometime on the European continent some time ago, but the lactose-processing gene did not flourish until cattle farming became commonplace, at which point it was advantageous to have it. This is why non-European populations have a high incidence of lactose intolerance.

Perfect! Interesting tidbit too. I would suggest we maybe change the compound names of some of those foods to more simple and less technical names. What do you think?

Animal Flesh -> Meat
Animal Bone/Connective Tissue -> Bone
Woody Plant Matter -> Wood
Soft Plant Matter -> Vegetable? Plant Matter? (I can't think of one)

-----------------------------------------------------------------------

So here is the list of Function Parts, as promised.

Spoiler:

As you might notice, the list is in the order that they are unlocked (based off the Research Web). Now I wouldn't consider this a finished list. I have many suggestions of my own. If you have any, post them.

Basket, bag, and bucket seem redundant.
What's the difference between a fish trap and a water-organism trap?
Single-Edged Blade being separate from Double-Edged seems strange. I would rather put them both under "Blade", and make it an option to make it single or double bladed.
Projectile? That's not very specific.
A coffin doesn't seem very necessary.
All the pulleys, winches, triggers, and axles make sense to a limited extent, but the TE won't be a full physics simulator, and the player won't be expected to have to be an engineer to design the machinery of a wind-mill from scratch. Some of those aren't very necessary.
I would rename baking oven to just oven, so that it could be more broadly applicable.
Lectern, chain, and clock also seem unnecessary.
Bullet?

I also have some FP's I would like to add. Most of the FP's on here can't even be attributed with collecting compounds, as I mentioned earlier. However, I will wait to hear what you guys think first before I give my ideas.

Rename that how you like.
That FP list will take a lot of recategorization and refining. I say we simplify it as much as possible, focusing on simple FPs, then expand on each FP as a category. In the instance of blades, condense into a blade category, then include axe, knife, spearpoint. I like your idea of just making blades customizable from then on and not having separate FPs for double vs single edged blades.

Great. So I'll start with the revision of this list. To all of you guys out there, all your ideas are both welcome and necessary, so contribute if you can.

So first, I think we should come up with FP Categories, like you mentioned. Once we have a set list of those we come up with the FP's themselves. Based off of the list above, that gives us:

Tools (Merged with Blades)
Ex. Spearhead, Axe, Blade, Handle

Containers
Ex. Bucket, Bag, Basket

Machinery
Ex. Wheel, Ballista Mechanism, Steering Oars

Structures
Ex. Courtroom, Organic Lab, Classroom

What else? Are any of these too general?

I've just come up with a good idea. For structures, Instead of placing a physical object into the model, you instead designate an area of the model as that structure by dragging in a little beacon, around which, in a given radius, that structure functions. For instance, I can make a courtroom by building four walls, then going into the structures FPs and selecting courtroom. I drag out the "courtroom" designator, and place it in the model. Around it, it shows a cylindrical area that designates where the "courtroom" is. The size of the cylinder indicates how big the structure is, which affects resource consumption, and the efficacy of that structure in playing its societal role.

Great idea! I had actually thought of that a while back, but I never mentioned it, and it really made looking at the whole TE/Building concept a whole lot easier. However, don't let me dampen your epiphany.

However, my idea was with cubes/rectangular prisms. Which do you think would work better?

NickTheNick wrote:

Great idea! I had actually thought of that a while back, but I never mentioned it, and it really made looking at the whole TE/Building concept a whole lot easier. However, don't let me dampen your epiphany.

However, my idea was with cubes/rectangular prisms. Which do you think would work better?

Doesn't really matter, prisms are probably better, since they are more modular and their volume is just a tiny bit easier to calculate. It is a fairly elegant solution, isn't it? I'm glad we think alike. I'd also say that, for an area to be legitimate, it must hold all of the FPs/TOs that would be required for it. This means that each structure comes with a list of other TOs that it must contain. If you build it in an area without one of those, It will populate it in automatically. Does that sound good?

I love the solution. This way the player aesthetically designs the buildings exterior, and then just places the shapes on the inside. It is meant to correlate to the OE, in which the player fits organs into the space inside the organism.

~sciocont wrote:

I'd also say that, for an area to be legitimate, it must hold all of the FPs/TOs that would be required for it. This means that each structure comes with a list of other TOs that it must contain. If you build it in an area without one of those, It will populate it in automatically. Does that sound good?

I'm only kind of understanding you here. Could you elaborate?

NickTheNick wrote:

~sciocont wrote:

I'd also say that, for an area to be legitimate, it must hold all of the FPs/TOs that would be required for it. This means that each structure comes with a list of other TOs that it must contain. If you build it in an area without one of those, It will populate it in automatically. Does that sound good?

I'm only kind of understanding you here. Could you elaborate?

Each (or most) of these structures has prerequisite TOs, I would imagine. When the structure is placed, it must have within its volume, all of the TOs needed to function.

Just to clear up any miscommunication, my understandings of the definitions of the words are (correct me if I'm wrong)...

Function Part means a preset item/part that the player unlocks through technology, and can add to their creation to enable it to do certain things.

Tech Object means a saved creation of the player from the Tech Editor.

If you mean placing the finished creation, ie the structure, onto the map, then the whole thing is treated as one entity, aka Tech Object. The individual Function Parts within it are not distinguishable.

If you mean Function Parts requiring further Function Parts, that would be an interesting idea. For example, if I wanted to place a Library Function Part (i.e. a big cube) inside my creation in the Tech editor, then that Library FP would require X number of books (also another FP) to be placed inside it. If the player just directly placed the Library FP, the X number of Book FP's would automatically be placed with it.

If you didn't mean either of these, then my brain is just busted from all my math homework.

I think what Scio meant is roughly your second suggestion: if you place a particular room in a building, that room will require various TO's inside it to be valid. e.g.: a library would requires bookshelves, a courtroom would require seating and a lectern/gable etc.

Depending on whether we have accessible interiors or not, these required TO's may need to be placed, or otherwise simply add to the resource cost of the building. To complicate things slightly, we may allow additional TO's placed in a room to increase its efficiency, though this would need to be limited by available space in that room.

Also, rather than simply having rectangular rooms, we have a few other options. None of these are simple, but all are feasible, both programming and cpu wise:
- Design the interior space of the building first, probably by cutting up the available space by placing walls, rooms can then be designated and FP rooms can then be made to fill each physical room.
- The above in reverse, place FP rooms (probably rectangular) and then link them with corridors and doors to form the physical interior.
...though unless we decide on having interiors neither of these is relavent.

p.s. - I know I haven't posted in weeks. I'm still reading almost every post, but have found very little time for writing any replies recently.

Seregon wrote:

I think what Scio meant is roughly your second suggestion: if you place a particular room in a building, that room will require various TO's inside it to be valid. e.g.: a library would requires bookshelves, a courtroom would require seating and a lectern/gable etc.

Depending on whether we have accessible interiors or not, these required TO's may need to be placed, or otherwise simply add to the resource cost of the building. To complicate things slightly, we may allow additional TO's placed in a room to increase its efficiency, though this would need to be limited by available space in that room.

Also, rather than simply having rectangular rooms, we have a few other options. None of these are simple, but all are feasible, both programming and cpu wise:
- Design the interior space of the building first, probably by cutting up the available space by placing walls, rooms can then be designated and FP rooms can then be made to fill each physical room.
- The above in reverse, place FP rooms (probably rectangular) and then link them with corridors and doors to form the physical interior.
...though unless we decide on having interiors neither of these is relavent.

p.s. - I know I haven't posted in weeks. I'm still reading almost every post, but have found very little time for writing any replies recently.

The second is what I meant. Because of the many different geometries that could be possible for a structure, I suggest that we stick to The original idea of including structures as drag-in FPs of a distinct geometry- let's just say they can be any prism, since that way volume is easy to calculate and they can easily fit most spaces that players will try to fill up. I know that calculating the volume of irregular solids quickly becomes a very complex problem as one moves away from simple polyhedra, cones, spheres, etc.

Ah okay. The second one would add more in-depth customization, and would give use to FP's like books and lecterns, but I feel like it is too much. Also, if we use it to too great of an extent, such as Libraries requiring bookshelves and chairs and tables and books, etc., then that actually has quite a negative effect on the economy. The player only has a limited number of people in their population working in buildings/factories that produce such FP's, and to increase the number of FP's the player needs to produce just to build a single building would put a huge strain on the player.

I would prefer with going with, as scio just suggested, simply placing the shapes, which represent the FP's (for structures only, like classroom, courtroom, etc). However, what I had orginally intended was that each FP has a predetermined size, and that a player would place multiple of the FP if they wanted to increase the resource consumption and processing rates, instead of just placing one FP and enlarging it.

To give an example, the "Forge" FP can undergo one process. "Forge" FP's convert any metal in their ore form to their pure metal form. When you place the Forge, you select which specific process it undergoes. I pick "iron ore --> iron". My building will now intake 1 iron ore to produce 1 iron every x time interval. The Forge would also have a predetermined number of people needed to operate it. For the Forge FP, it is 3. That means that my building would intake 1 iron ore to produce 1 iron every x time interval, and employ 3 people. Lastly, this building matches the requirement of "either in-taking or producing raw materials (the iron ore in the case)", and so it employs labourers, as opposed to artisans. So finally, my building intakes 1 iron ore to produce 1 iron every x time interval, and employs 3 labourers.

However, if I added a second Forge, I could choose what process that second Forge would undergo. I could pick "iron ore --> iron" for it, and the new details of the building, with 2 forges now instead of 1, would be:
Intakes 2 iron ore to produce 2 iron every x time interval, and employs 6 labourers.
If I chose "copper ore --> copper" for the second forge, then it would look like:
Intakes 1 iron ore to produce 1 iron, and 1 copper to produce 1 copper ore, every x time interval, and employs 6 labourers.

I think this method is easier, but if we were to use the other method, where the player just places one of the FP and then increases the size to increase its processing power, then we would have to both put equations such as "Employs X people for Y m^3 of volume", as well as a minimum volume, so they couldn't just make it tiny. Actually, scratch that last part, you would have to put minimum dimensions, because the player could make the FP a pancake, very wide and long, barely high, and still meet the minimum volume requirement.

I like more having each FP having variable size. The units for the resources can have decimals, so we dont have a minimum input/output. A tiny FP would take a very small space, but it will produce a lot less resources.

(This only applies to FP that represent buildings, or places where creatures work. For any other FP, the other this doesen't apply)
If you think about it, when you look at buildings, factories ot similar things, the thing that matters is area. The volume is not important. If you double the height on an office room, you will have double the volume, but in practice the working space is the same. At most, you won some space for storing.

However, height is also of some importance. If a building is not tall enough, the creatures won't fit inside, and won't be able to work inside. So a minimum height is needed.

That way, when you place a space for the FP, it checks if the height is enough. If it is, then it calculates the area and stores it (to save further calculations). Each production cycle, the FP will only multiply its intakes and outputs by its area (or have them precalculed) and add/substract them from the stockpile as needed. Double the area, double the production.

Other than that, i also wanted to say what i think about the computer placing the required FP when the player places an area requiring them. If it only "virtually" places them, adding its costs to the total cost it is possible. However, what it cannot do is placing them "physically", unless we have a template on how to place them.

I was just worried that decimals would strain the programming. I read on a different forum that adding decimal places makes it harder to code and calculate. Is that true?

Nonetheless, I like your idea of multiplying the base number by the new calculated size. There would have to be some basic restrictions, such as the number of people needed to employ must be rounded to a whole number. Also, that's a good point considering height. I think that covers everything.

By the way, for the sake of simplicity, when we talk about FP's that are specifically used for buildings, like we have been talking about this whole time, just call them Structure FP's, or Structures.

If we take the approach of just using prisms for the Structures, then it would be a great, simple solution. Plus, it would make it easy for modders or even ourselves if we ever come back to implement the insides of buildings.