Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: template storage  (Read 1902 times)

lucusLoC

  • Bay Watcher
    • View Profile
template storage
« on: July 24, 2009, 04:24:21 pm »

i was participating in the discussion of makeshift towns and got to thinking about what a manger ai would need to be able to successfully run a settlement. on of the requirements is the ability to build structures. in order for the ai to actually build a structure, and not have it just be placed there, the ai will need a template that will tell it in what order to build things, i.e. walls first, then the roof. and once the ai has something that tells it how to build something, it is only natural to extend that functionality to the player, in to form of templet buildings. this we all know and have discussed before. what i want to discuss is the actual format of the file that will store this data.

it seems to me that DF store most of its data in txt files, and since these are easy for the player to edit it seems that we should keep with that.

so without further ado, a text based template storage solution, code to read it to be implemented by someone else ;-)


example:

Code: [Select]

C:two story hut
Q1
...ooooo
...o>++o
...o+++0
...o+++o
...oo+oo
....r.r.
___________________
Q2
.
....x
___________________
Q3
.
....<
___________________
Q2
.
.....++
....+++
....+++
__________________
Q2
...o...o
.
.
.
...o...o
__________________
Q2
....ooo
...o...0
...o...o
...o...o
....ooo
__________________
Q3
.
.....++
....+++
....+++
__________________
E


to explain:
"C:" is the beginning of a construction, and the title follows
"Q" designates the top left boarder of the construction
"_" designates the bottom left boarder, extra are ignored, but look good
the number next the the "Q" designates on what level, relative to placement, the construction occurs on.
"E" is the explicit end of the construction
"."is a placeholder, and nothing is done there on that step
"o" is a wall
"+" is a floor
"r" is a ramp
etc.
all white space is ignored. i remember this making things easier to code, but that was a long time ago and i could be wrong.

a new step is initiated for every Q, and no step can be started without the step before being completed. a step is understood to be between the "Q" and the "_"
i relies that the top stair on Q3 and the floor on Q2 can be done at the same time, but for simplicity of the file this is not allowed, only one floor is allowed per step.

so in this example we have a 2 story 5x5 building with ramps flanking the ground door.

the interface should enumerate the steps, and ask the player what type of material to use for each step, or if one material should be used for the whole thing.

again, this could be used by players to design their own buildings (not in game of course) or by the computer ai to put together towns in real time.

(Incidentally, i hope the code tags work, since i cannot see them on this device)


Edit:
As an expansion to include diging and funiture:


Code: [Select]
c:entrance barracks
Q1:dig the room
.
.
...dddddddddd
...dddddddddd
...dddddddddd
...dddddddddd
...dd
_____________
Q1:build the supports
.
..ssssssssssss
..ssssssssssss
..ssssssssssss
..sssssoosssss
..ssssssssssss
..ssssssssssss
_____________
Q1:carve the fortifications and place doors
.
...ffffffffff
.
.
.
.
..eDDe
_____________
E

"d" is dig
"s" is smooth
"o" is build wall
"f" is carve fortification
"D" place door
"e" is engrave

i added a title for the step, so that the user will more redily know what they are assgining resources for, so the interface would prompt:

"what resources for 'build the supports' (req 0/2)
   *list of building materials to select*"
 and then would prompt
"what resources for 'carve the fortifications and place doors' (req 0/2)
   *list of doors*"

i would limit each step to only allow 1 type of resource, so each type of furniture would require its own step, and the file would have to be checked for validity.  designations would be allowed at any time. if an item is attempted to be placed a warning could be issued when the dwarves go to that step. for example, if i had one of my doors off to the left by 1 tile you would see in the announcements "dwaves cancel the construction of the door:item (or wall) blocking site"


finally edited for spelling.
« Last Edit: August 06, 2009, 08:46:59 pm by lucusLoC »
Logged
Quantum dumps are proof of "memory" being a perfectly normal dimension in DF. ~Gazz

DanielLC

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #1 on: July 24, 2009, 07:22:53 pm »

You should add a way to remove constructions. For example, if you want to build a simple one-story building with a roof, you'd build the walls and a ramp on the side of the house, then build a roof, then deconstruct the ramp.

It may be useful to add an option for floors that are only partially above ground. That way it could still be built on uneven ground.
Logged

lucusLoC

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #2 on: July 24, 2009, 07:37:48 pm »

A remove construction option fits within the framework, since it is just another designation. I dont think the framwork is powerful enough to handle terrain that the building is not desinged for, so a rudimentery site prep ai would be needed, and i do not know if the site prep ai found in world gen would be sutable. If not then a simple level terrain feture should work in most cases. I do not doubt buildings desinged to be built by the ai will need to have many more steps in them to overcome placement stupidity. For example, in the first building placing it in a corner in the hill could possible block off access to one of the buildings corners. A player would know about this and plan accordingly, but the ai will not. Since i do not want to restrict the ai from building against existing walls, the plan would have to be expanded to build the corners first, then the sides, as is done for the second floor walls. I will see if i can think of a good way to run a floor leveling algorythm to solve this problem.
Logged
Quantum dumps are proof of "memory" being a perfectly normal dimension in DF. ~Gazz

Rowanas

  • Bay Watcher
  • I must be going senile.
    • View Profile
Re: template storage
« Reply #3 on: July 24, 2009, 07:57:20 pm »

no, just have it set up like  workshop. You need open land to build everything else, so just have the exact same thing for buildings (I actually thought of using this as a digging feature to help with excavating these rooms...
Logged
I agree with Urist. Steampunk is like Darth Vader winning Holland's Next Top Model. It would be awesome but not something I'd like in this game.
Unfortunately dying involves the amputation of the entire body from the dwarf.

lucusLoC

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #4 on: July 24, 2009, 09:54:34 pm »

AS the problem here relates directly to the ai being able to build things, and thus make the world more rich and full, i will attempt to keep this framework as robust as possible. and while discussing the properties of a management ai is outside the scope of this discussion, it does have some bearing here. with that said i will give you an example of a revised framework:

Code: [Select]

(~ denotes a comment, and is not part of the framework)

C:fort seedling
R:room2;brew1;crops9;carpenty1;masonry1
Q1
.
..d.d.ddddd.ddddd
..d.d.ddddd.ddddd
..d.d.ddddd.ddddd
..d.d.dd.....dd
.<dddddddddddddddddddddddd"        ~step 1
.<dddddddddddddddddddddddd"
..dd..dd..dd...dd
..ddd.ddd.ddd.dddd
..ddd.ddd.ddd.dddd
..ddd.ddd.ddd.dddd
_______________
W1
.
........ppp
........ppp                       ~step 2
........ppp
_____
W1
.
............====
............====                    ~step 3
............====
____
W1
.
.
.
.
.                                   ~step 4
.
..............====
..............====
..............====
____________
W1
.                                  ~step 5       
..............$[pile:food]
_______
W1
.
.
.
.
.
.
................$[pile:wood]
__________
W1
.
.
.
.
.
.
.
.
.
....$[workshop:masonry]
_________
W1
.
.
.
.
.
.
.
.
.
.......$[workshop:carpenter]
__________
W1
.
.
.
.
.
.
.
.
.
...........$[workshop:brewery]
______________
Q0
.
..d.d.d.d
..d.d.d.d
..d.d.d.d
..d.d.d.d
.>ddddddd
.>ddddddd
..d.d.d.d
..d.d.d.d
..d.d.d.d
..d.d.d.d
_________
Q0
.
..B.B.B.B
.
.
.
.
.
.
.
.
..B.B.B.B
____________
Q1
.
..B.B
_______________
Q1
.
.
.
..D.D.DD.....DD
..........................D
..........................D
..DD..DD..DD...DD
___________
Q1
.
..$[define:bedroom]
_______
Q1
.
....$[define:bedroom]
_____
E



Ok, this one has a lot going on, but it defined a lot of things that the ai will need to know in order to be able to build a building in real time. i will go over he elements one at a time and discuss them, and their relation to the management ai.

first off, the title
"C:" is just the friendly, descriptive name. displayed to the player in game
"R:" tells the computer what it can expect from this building. in this case, 2 bedrooms (the other 8 are not defined, more on this later), a brewery, 9 farm plots, a carpenters shop and a masonry

this will be important for the ai as it will allow it to provide for the needs of the growing settlement intelligently. as it finds that it has units that are homeless it can build more rooms, if units are hungry it can build farms etc.

ok, so in step 1 we have:
"d" for dig
"." for keeping track of the grid
""" for defining a path-able point

that last one is important. it lets the ai know that this point in the building needs to be assessable, both before *and after* the building is complete. that is the tricky part right there. the way i figure it, each ai settlement will need to have a central point that must maintain connectivity to all other points in order for the settlement to function properly. i have no idea how to keep the ai from blocking existing  building entrances, but this should at least keep the ai from placing a new building in an inaccessible place. if the central point is placed on a road that cannot be built on, it should also keep the ai from blocking itself off from the rest of the world. this may be the hardest part to code for the entire framework, as it will have to use the pathing code extensively (not necessarily A*, but a fill at least). i will leave further discussion of this to more intelligent minds.

in the second step we started it with a "W" instead of a "Q"
this indicates to the ai (or the players template) that this step does not have to be waited on. place the designation and move on to the next step without waiting for completion.
in this step we place a 9 tile farm and move immediately to the next step. the creature job ai will complete this at its own convenience.

in steps 3 and 4 we place 2 blank stockpiles.

in step 5 we designate the top pile as a food stockpile. i am using the "$" to denote a function, not a placement.

the function acts on the item or designation that is at that cursor location. this will be important for the ai because we can use it to tell the ai where things like bedrooms and food stockpiles are, as well as where to build workshops. it is the last part of the framework that i am going to explore in this post, but it allows you to set up a nice, complete building that either you or the ai can use, and allows the "job manager" or ai to do it in real time.

for those of you who think this may be overkill, think of what it would be like to stumble across a group of dwarfs on a road, and watch them start to dig in and start a new little fort right in front of you. or watch a human settlement start a new pub, and then com back in a month to find the pub there, complete with chairs, tables and a booze stockpile. or how about just being able to tell the ai what to build in world gen, like tall narrow apartment towers for the humies, instead of whatever they build now.

that and giving the player a very powerful building templet tool, to be used and abused in new and interesting ways. . . but that is only a secondary concern.
Logged
Quantum dumps are proof of "memory" being a perfectly normal dimension in DF. ~Gazz

lucusLoC

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #5 on: July 26, 2009, 04:18:13 pm »

no one has any comments on this? or do did i just not explain it well enough?
Logged
Quantum dumps are proof of "memory" being a perfectly normal dimension in DF. ~Gazz

buman

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #6 on: July 26, 2009, 04:40:50 pm »

You will need more information on the templates. Such as how much space each takes up and maybe a category/subcategory
for example

FF 'catagory food subcatagory farm'
1010 'how much size it takes up'
DPCP ' planting cycle, dimple cup, plump helmet, cave wheat, plumb helmet'

This one wouldn't require a complicated template layout like a house, but would allow the manager to look for a food related construction:farm to complete a requirement of a village for example and ensure that it had space to place it.

I think the hardest thing is if you wanted to have this working on the same map as your dwarves you would need a framework to ensure that the two groups don't perform each others jobs, which may cause problems. It would be most useful for random generation of static sites for adventure mode.
Logged

lucusLoC

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #7 on: July 26, 2009, 06:08:40 pm »

you mean define to the ai the size of the template? i think that that can be processed from the template itself. as for the player they should be able to either see for themselvs when they place it, or simply put the dimensions in the friendly name.

the catagory thing cold be implemented esily i think, wouldn't that oly be for the players benifit though? i dont see how it would make much difference to the ai since we already tell it what the teplate contains.

the planting cycle should be easy. just define it on a farm plot like so:

$[farmplot:a;pluphelmet,b;dimplecup etc.]

of course all the  symbols will have to be worked out, but those are just details
Logged
Quantum dumps are proof of "memory" being a perfectly normal dimension in DF. ~Gazz

buman

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #8 on: July 26, 2009, 06:31:57 pm »

Unless I missunderstood, you wanted game to be able to build its own buildings and towns automatically. If it needed to calculate the size of a specific template based on the ascii paragraph then it would take forever just to find buildings that fit within the space. Similar to the world gen in the old days where you ended up with like 200 rejects before it even met the basic requirements with no modding.

If the player is manually placing these templates then in a lot of cases it may be quicker but to lay it out manually (now that you can expand constructions before designation) rather then searching an increasingly large template database. For super projects these would be very useful however.
« Last Edit: July 26, 2009, 06:33:37 pm by buman »
Logged

lucusLoC

  • Bay Watcher
    • View Profile
Re: template storage
« Reply #9 on: July 26, 2009, 07:04:05 pm »

ah yes, i see your point. plus the code to calculate the size from the ascii matrix would probably be harder to implement than simply putting the info in the template header.

as for the player manually laying out the template, i think it should be displayed like constructions are now, with everything showing at once, maybe starting off all suspended, and just have the designations unsuspended as each step is completed. but i think that is more a UI question that can be handled later.
Logged
Quantum dumps are proof of "memory" being a perfectly normal dimension in DF. ~Gazz