Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Draco18s]

Farming becoming more difficult because the demands on farming change as your fortress grows, that's an excellent balancing method.

Agreed.  The problem is that my (last used) method of farming was to create a 5x10 plot, set it to produce 4 different crops throughout the year: sweet pots, cave wheat, quarry bushes, and plump helmets.

Done.

I never had to touch it again.  Once in a while I had to turn brewing and milling back on because I ran out of input material and the jobs auto-canceled, but that was about it.  I was producing food at a much higher rate than I could ever consume it.  My fortresses would die to FPS before starvation (my popmax is 100).

This means that in order to have difficulty through scale something else needs to change so that there's something to scale up as you get more dwarves.

[NW_Kohaku]

I would hope that with crop rotational methods, we could have a system that is not so much based upon scaling, but upon time.

Soil could start fairly rich, and require little more than muddying and it would be ready to go, but as the years go on, you need to either put more care into preserving the soil, and improving its productivity to meet the demands of your populace, or would have to simply start slash-and-burn agriculture over larger areas.

It would be important, however, to ensure that as much as possible be controlled by setting routine tasks for dwarves, rather than micromanagement-dependant.  I don't currently fertilize my fields, not only because I get plenty enough crops from a pair of 5 x 10 fields (above and below ground), or because I can save wood that way, but because I have to do it manually.

If dwarves are capable of taking rotting chunks of carcases, putting them into worm and fungal farms, then picking up the resultant "fertilizer", and seeding the farm with it, all on the basis of a preset command, then there would be little reason not to use such a system, nor would it be as intimidating.

(That said, making the density of farming increase the likelyhood of pests is a very good idea.  A similar problem with ranching animals becoming a target for swine flu disease outbreaks would be wonderful.)

[NW_Kohaku]

Oh, something I forgot to mention earlier:

I completely agree and I'd like larger numbers, but I'm restraining myself because memory space for the map seems to be a limited resource, if not for the memory then for the processing of it all and ultimately FPS. But that's a technical matter, and a simple model can always be given more precise numbers in any case.

I'm fairly sure the smallest unit Toady can code is an unsigned byte, which, I'm fairly sure is 2^8, or from 0 to 255.  At the very least, we should be able to have 255, unless this was used alongside a mask or something to split it into even smaller parts between variables.  (Although such a thing would be such micromanagment I would hardly see most programmers going to such lengths to save a shred of memory.)

[Draco18s]

I'm fairly sure the smallest unit Toady can code is an unsigned byte, which, I'm fairly sure is 2^8, or from 0 to 255.

Except that this is wrong.  It is entirely possible to assign 1 bit variables, and if you are creating your own datatypes (e.g. classes) you can define your own variable sizes too.

Example:

Code: [Select]

class TileWaterLevel {
   boolean One;
   boolean Two;
   boolean Four;

   function setWater(int amount) {
      if(amount > 7) {
         amount = 7;
      }
      if(amount % 2 == 1) {
         One = true;
      }
      if(amount % 4 - amount % 2 > 0) {
         Two = true;
      }
      if(amount > 3) {
         Four = true;
      }
   }

   function getWater() {
      return One + (2*Two) + (4*Four);
   }
}
Note: % is the modulo operation

That class effectively creates a 3 bit variable type, as it uses 3 booleans to store a value between 0 and 7 (and a boolean is 1 bit).

There's a bit of overhead for the class (those functions have to exist in memory) but the overhead is only required once.

[NW_Kohaku]

I'm fairly sure the smallest unit Toady can code is an unsigned byte, which, I'm fairly sure is 2^8, or from 0 to 255.

Except that this is wrong.  It is entirely possible to assign 1 bit variables, and if you are creating your own datatypes (e.g. classes) you can define your own variable sizes too.

Example:

Code: [Select]

class TileWaterLevel {
   boolean One;
   boolean Two;
   boolean Four;

   function setWater(int amount) {
      if(amount > 7) {
         amount = 7;
      }
      if(amount % 2 == 1) {
         One = true;
      }
      if(amount % 4 - amount % 2 > 0) {
         Two = true;
      }
      if(amount > 3) {
         Four = true;
      }
   }

   function getWater() {
      return One + (2*Two) + (4*Four);
   }
}
Note: % is the modulo operation

That class effectively creates a 3 bit variable type, as it uses 3 booleans to store a value between 0 and 7 (and a boolean is 1 bit).

There's a bit of overhead for the class (those functions have to exist in memory) but the overhead is only required once.

Umm... correct me if I'm wrong, but DF is a game coded in C, and C uses small integers for booleans, meaning three booleans would actually take up MORE memory.

[Draco18s]

Umm... correct me if I'm wrong, but DF is a game coded in C, and C uses small integers for booleans, meaning three booleans would actually take up MORE memory.

Ah, you are correct.  Because of the way computers access locations in memory.  You can, however, still define your own memory structure for large datatypes (such as map data) which I know Toady has done.

[Silverionmox]

If i'm not mistaken even the bytes are chopped up in bits that have some meaning assigned. 0-7 would require 3 bits in that case.

[Draco18s]

If i'm not mistaken even the bytes are chopped up in bits that have some meaning assigned. 0-7 would require 3 bits in that case.

Correct.  I don't know how DF tracks the map data, I just know that it's pretty crammed; every bit assigned to something.  And water is actually 4 bits:

abcd

a = water/magma

bcd = 0-7 level.

[RCIX]

If the game keeps getting more complex, you'll need to turn it into a turn-based game with single steps at a time...

[NW_Kohaku]

Of course, I have to wonder if farms are treated in the same manner as whether there is water or walls in a tile right now, or if they need to be in the future.  Currently, there is only need for about 100 tiles of farm.  Unless we go for one of those extreme suggestions of 20,000 tiles, which is amazingly unlikely for Toady to impliment, we shouldn't be having so many tiles that it would actually start becoming worthwhile to track every single tile on the map for soil nutrient data.

It might mean that someone could deconstruct farms and then reconstruct them in order to reset mineral data (although maybe you could hold onto that data until a season change or just make someone re-irrigate the tiles or just take long enough to deconstruct then reconstruct a farm that it doesn't become too attractive an exploit), but if nutrient data were focused in on only farm tiles, it would reduce overall memory use.

[G-Flex]

I don't really think a couple megabytes of rarely-used data would make much of a difference to the map, though. I mean, it's not as if a byte is very large.

[NW_Kohaku]

I don't really think a couple megabytes of rarely-used data would make much of a difference to the map, though. I mean, it's not as if a byte is very large.

It depends on how many there are...

Assuming a standard 4x4 embark, with 48x48 tiles per embark tile, times the number of z-levels (which is something like 150 to 200 in the standard settings of the recent version), we are talking ballpark 6.5 million tiles to keep track of.  (This is, of course, completely expansible by making deeper caves/taller overall maps/embarking on the full 16x16 embark tiles.)

Hence, anything that is tracked per individual tile, even tiles that are air or wall or in the middle of a magma sea, will be fairly expensive.

Anything where it only tracks specific tiles, where there should be, at most, only about a thousand or so farm tiles, even if we crank up the land use for farming, we could store litterally a thousand times as much data without taking up as much space in memory.

[Draco18s]

What really should happen is that some of the map data isn't tracked per tile, but that each tile has 1 byte with which to reference "other data about this tile."  It'll increase the overall memory useage of a map by that 6.5 MB, but you could offload the fluid bits and a few other "rare to have in every tile" bits into a separate memory location.  Then only the tiles for which this data needs to be stores is stored.  1 byte for a tile to track soil quality?  With 1000 farm tiles?  Why that's only another kb of map info!  Eight new fluid types?  Why that's only 3 more bits per tile (and only for the tiles that have any--non-zero--fluid amount!)

Any tile without any "extra info" would simply have a null address, still using 8 bits of space, but it allows far greater expansion of increasing map data without significantly altering the overall map data size.

[NW_Kohaku]

What really should happen is that some of the map data isn't tracked per tile, but that each tile has 1 byte with which to reference "other data about this tile."  It'll increase the overall memory useage of a map by that 6.5 MB, but you could offload the fluid bits and a few other "rare to have in every tile" bits into a separate memory location.  Then only the tiles for which this data needs to be stores is stored.  1 byte for a tile to track soil quality?  With 1000 farm tiles?  Why that's only another kb of map info!  Eight new fluid types?  Why that's only 3 more bits per tile (and only for the tiles that have any--non-zero--fluid amount!)

Any tile without any "extra info" would simply have a null address, still using 8 bits of space, but it allows far greater expansion of increasing map data without significantly altering the overall map data size.

Keep in mind we are dealing with multiple variables.  I would say three as an absolute minimum for soil quality if we are to have the sort of system where crop rotation would make sense, plus water, and each of these would need around a byte for the sort of things we'd like to do with them.

Also, I did some research of my own, and to get back to the number of tiles it takes to feed a dwarf, based upon my own estimates of the size of a tile, came up with some numbers of my own.

Apparently, the minimum idealized amount of land that a purely vegan average-sized human needs to feed himself for a year is 3,000 square feet.  (This is according to some random dude named Jason Bradford, who is, incidentally, one of those guys who says we should go vegan because it involves less land use, so he may just have some goods to sell on this account.  Take my lazy Internet research with a grain of salt.)  I calculated out the size of a tile at 100 square feet.  There are other factors to play in, like the winter growing season of DF, but we can use this as a quick-and-dirty calculation to arrive at the idea that humans take 30 tiles of farm per person.  (Dwarves are 6/7ths the mass of humans, and, assuming equivalent metabolisms, would presumably eat 6/7ths as much.  That reduces it down to roughly 26 for dwarves.)  Mutiplied by the number of dwarves in a fort, and you get 2,600 to 5,200 tiles per dwarf if we wanted to be completely realistic.  This is also talking about farms which are always in the same, presumably close-to-ideal conditions, meaning that drops in soil quality would require a matching increase in land to compensate.  This is also not taking the skill of the farmers into account, when farmer skill makes a MASSIVE difference in crop yield in the current version.  (I honestly don't want to be that realistic... especially since, realistically, cities or fortresses IMPORTED their food from a very large, open, and completely undefended countriside where most peasants lived at barely above subsistance agriculture.  We simply wouldn't have a self-sufficient fortress if we were being that completely realistic.)

Now, we could theoretically start talking about the numbers that would be required to be jammed into the machine for it to spit out our target.  If we want 26 tiles to feed 1 dwarf, who eats 8 times a year, we are talking about 1 tile producing roughly 0.31 food per year (this is assuming we are making 1 food = what a dwarf eats per sitting, which is something I've been arguing against in things like the reasonable foods and volume and mass threads).  We should presume that, even with longer growing seasons, we should be at least theoretically able to harvest twice a year, and considering as it is theoretically possible in the real world to harvest some crops three times a year, even without winter farming, it really should be something higher, anyway.  This brings us to about 0.16 food per tile per harvest (or 1 food per 6 tiles), in "normal" soil conditions, with "normal" farmers, with a "normal" 2 harvests per year.

Again, I don't particularly support that, but those are the numbers. 

[NW_Kohaku]

OK, since someone tried to start another thread just on helping Toady impliment this stuff, I'd like to go back to talking about what Toady said recently in the Future of the Fortress thread:

Regarding the "farming improvements" goals, how much detail is currently planned for tracking soil quality?

A completely accurate model would probably be a lot of effort/information with little to gain from it, though enough detail to properly encourage crop rotation seems like something that should make it in eventually.

We haven't made any final decisions.  I think a NPK+pH model does give you something back, because you'd get some really great varied local landscapes and it would take care of crop rotation, composting, naturally poor soil, or whatever else, but it introduces a farming interface problem to dwarf mode in terms of conveying the information in wholesome terms and allowing you to solve problems that come up.

First off, I'd like to go back to talking about what Toady seems to be having the most stated trouble with, which is "How do players see the data".

Again, even if we ARE tracking NPK+pH, the notion of seperate elements like Nitrogen are essentially unkown to people of the timeline, although I think "acidic" would be fairly understandable even from a medieval mindset.  It was something Silverionmox and I discussed earlier, but didn't get too deep into, where Medieval farmers would know what their soil needed, even if they didn't have much knowledge of real chemsitry.

I'm doing my typical google searches, and all I'm coming up with are cycles of letting fields fallow, and a knowledge that legumes in fallow fields help produce more crops overall, even if they don't understand nitrogen fixation, so I'd like to ask if people have ideas on how to represent NPK in a medieval-understandable manner.  (N as "Legumes have not grown here in quite some time"?)

edit: Oh, and in one of these things that I was reading, http://www.hyw.com/books/history/agricult.htm , they basically said that it took 1.25 acres of land to just barely feed a medieval peasant, plus they would have to forrage some.  So instead of 30 tiles per dwarf, think more 500 tiles per dwarf.  Or 50,000 to 100,000 tiles per fort.  Obviously, in a probability spectrum, that's somewhere in the "LOL NOT HAPPENING" range.  At least, not without off-board farming and large tracts of rural land around the fortress.