Print

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

[NW_Kohaku]

It seems to me that a compromise may be to define large scale building types and uses and let the hard code fill the out. So one could say "this civ uses [BUILDING_PLAN:TEMPLE] buildings that have [BUILDING_SPHERE:METAL] and [BUILDING_SPHERE:BY_CIV_PREFRENCE], and it uses them to [BUILDING_USE:MEETING_AREA:ALL], [BUILDING_USE:WORKSHOP:METALWORKING], and [BUILDING_USE:RELIGION:ALL]. Perhaps you might also say [SELECT_CONSTRUCTION_MAT:FLOOR:LOCAL_STONE] and [SELECT_CONSTRUCTION_MAT:WALLS:ANY_METAL].

With enough basic Building plans- they could be anything from sphere-sensitive temples to generic hovels or a variety of workshop plans or castle designs. Then you're free to do anything from making a civ that builds everything with low, adobe buildings to a techie civ with everything made of metal and glass in shiny towers.

Well, that's where I tried to go with a follow-up question:

Spoiler: Long quote (click to show/hide)

Will you code in the ability to create our own raw-defined building types for worldgen?  [...]

I'm not eager to get into this right now, since I'm not sure what the overall specs need to be and I don't want to tie myself to a raw format early.[...]

[limegreen]What if raw-definable buildings were definable in a simpler way?  I see two major ways of handling this, the simple but crude and raw-folder-bloating way, and the elegant but complex way:[/color]

I already think the simplest way to do this is to simply let the raws define functions for each building we create, (so that we have multiple entries that fill the role of "peasant house") and generate probability weights the way that we already can do for castes, so that we can make random-looking buildings by just making 50 different buildings, and giving them varying weights to occur, so that, unweighted, each individual building would only occur 2% of the time.  You could largely copy-paste the same overall building shape, and just re-arrange the furniture if you saw fit to make something that would seem different to the player who walked into town.  Temples to different spheres, then, would just be a copy-paste of other temples with certain parts changed to fit whatever idiom that sphere had.  (For the "purpose" of the temple, it might be [PURPOSE:TEMPLE_OF_SPHERE_NAME] as opposed to just [PURPOSE:TEMPLE] (where each "purpose" is a string where the entity city-building list of commands can be instructed to build so many of each) so that different spheres would cause different sets of buildings to be called up, with some/most buildings just being of "ANY" sphere.)

This wouldn't really be very procedural, of course, but it would be functionally similar to a more comlex and possibly more buggy solution, at the cost of probably forcing a new raws subfolder just to deal with having to organize the potentially huge number of variations on basic themes to make the idea work properly.  (This may be a stopgap for a more complex solution, although I know you're not much for stopgaps.)

The alternative (although not really an "alternative", there's no reason not to do this in conjunction with the previous) would be to make raw-editable procedural parts.  This would mean that you define a base of building, and then, on certain parts, you designate a special zone that actually calls on a procedural function that will look for sub-building pieces.  Sub-pieces may call for further sub-pieces, so that you could define a noble's estate by having a grand hallway with additoinal pieces being rooms that are branches off the hallways.

For example, you could have a set of "ground floor" plans for a farmer's house, and a seperate set of "second story" plans for a farmer's house.  Not all ground floors would have a second story, but ones that did would make a call to add onto a certain anchor point (specifically, in this case, the stairs) upon potential sub-sections of the house.  The function that calls for the additional sub-section of the house could be a weighted list of potential building floorplans, rather than simply something defined to fill a particular function, so that you could know the exact dimensions of the building pieces you are calling in beforehand.

As a sanity check, this would probably require some kind of arbitrary limit on recursions (say, no building segment tree with more than 100 nodes), so that some player who wants to test the limits doesn't blow up the world by making a building that is infinitely recursive by, for example, making a tower (Tower of Babel?) where each floor calls upon making another version of itself on the floor above, or some set pattern of floors so that it could extend infinitely high into the sky... not that such a thing wouldn't be cool, but infinite recursions tend to be bad.

For the purposes of fulfilling the needs of a sphere-based temple, these areas, then, you could either do the same copy-pasting solution I talked about, above, where each temple has a slightly different floorplan, but the bulk of it is repeated each time.  Alternately, it might be possible to build it "tricky", and make a set of TEMPLE_OF_SPHERE_NAME, with only the changing parts that filled in, which calls a default temple set of pews or the like, possibly including the door to enter the temple proper.  (Making "buildings from the top down" may require some special sets of sanity checks be added to make sure that all buildings have at least one door to the outside, and that it can link to the "main throughway" at some point.)

Similarly, the building could have the same floor plan, but have areas that are designated "furniture zones", where the game is simply given a list of furniture that needs to be in the house, and the game will just mix-and-match ways of placing that furniture... although this would need to be somewhat complex if you wanted to make sure tables always had chairs next to them, (calling up mini-floor plans that only deploy furniture in some pre-set raw-defined arrangements for particular floor spaces) and outright randomized furniture placement may likely be best for "abandoned" houses or outright ruins, where the stuff is supposed to be randomly strewn about.

You can make a fairly flexible system by having the furniture procedurally placeable inside of the buildings as a separate chunk of code, having the wall and furniture materials be a separate chunk of code, making the amount of space around the building or ways to access it be another chunk of code, and then making the actual shape of one or more chunks of a building be a chunk of code.

For example, you can make a "downstairs" zone of 4x8, and have a stairwell somewhere in that building, which allows you to stick any raw-defined "upstairs" that fits into the 4x8 area allotted to it, and maybe a basement in the same area.  If it's supposed to be a really crowded city, you could force only 4x8 or at least only 4xwhatever building shapes to take up the space in the upstairs. 

You can make a temple's each room, or even portions of rooms, be defined in different pieces of the raws if you want to.

Having 30 different versions of just one building will only lead to 30 different buildings, but having 5 different versions of 6 different assembleable pieces of a building will lead to 15,625 different buildings (albiet potentially only "different" in minor ways).

[Neonivek]

I mean... meat eating societies existed and have been quite dangerous (The Mongols)

Ohh well... odd.

I guess they are going to be like Trolls in the Majesty Universe where they are born from slime.

[Mel_Vixen]

Hey the not eating goblins will not turn into our new cliffs i bet at some point they are back to eating meat which will be when proper herding job assignments etc. are in.

[Dradym]

well, in most folklore, goblins are faeries of a sort...and thus, nature spirits...i could see this idea as what goblins are more like in dwarf fortress...though, then, they couldnt reproduce...except by "assimilating" others, without technology, more like pod-people, which would explain why they need to abduct people

[NW_Kohaku]

well, in most folklore, goblins are faeries of a sort...and thus, nature spirits...i could see this idea as what goblins are more like in dwarf fortress...though, then, they couldnt reproduce...except by "assimilating" others, without technology, more like pod-people, which would explain why they need to abduct people

In most folklore, dwarves and elves are just as much fae creatures as goblins are.  In fact, much of folklore uses "elves" and "dwarves" and "gnomes" pretty much interchangably, and only refers to goblins in terms of being a malicious elf.  (And they are all Keebler Elf-sized elves, at that.)  So it's not like we're being particularly faithful to the source material, here.

I'm pretty sure that whatever choice Toady is making regarding goblins, it's something he's come up with, himself.

[Neonivek]

Well right now we are just asking for clarification Kohaku.

Because it is a rather large jump for how we understand Dwarf Fortress now.

[Rexfelum]

Because it is a rather large jump for how we understand Dwarf Fortress now.

I dunno, actually.  I wonder if that "Goblins are not going to need to eat" thing relates to how goblins already function: if you capture a goblin, you don't need to feed it.  Sure, sure, the same holds true for other sentient creatures on your map (except for your dwarves), and we know that the Toady One intends for (say) human civilizations off your map to need food.  But maybe he's thinking of a similar dynamic.

--Rexfelum

[nil]

in my opinion there's absolutely nothing wrong with citing folklore and tolkien and the like.  it's almost never done in a "we must do things in X way because Y did" manner--which obviously would be problematic, DF is its own thing after all.  instead, usually folks just draw on other sources for examples and to show the limits of what it possible or plausible.  there's literally no reason goblins couldn't be somewhat supernatural (it would certainly explain the demon thing).

[zwei]

While we are talking about composites and content generation: http://designfestival.com/the-cicada-principle-and-why-it-matters-to-web-designers/

Prime numbers beat fractals!

[Knigel]

interresting city you have there, would be cool if it weas built on a hill.

Sounds like Ba Sing Se.

[NW_Kohaku]

While we are talking about composites and content generation: http://designfestival.com/the-cicada-principle-and-why-it-matters-to-web-designers/

Prime numbers beat fractals!

That's a neat idea... Once I digest that, I'll have to start using it.

[Miuramir]

While we are talking about composites and content generation: http://designfestival.com/the-cicada-principle-and-why-it-matters-to-web-designers/

Prime numbers beat fractals!

While that's a decent summary of an interesting technique for creating "stupid" designs, DF is generally using far better procedural designs that are at least partly "smart".  In general, prime-tiled systems are good for making repetitive, unimportant background info look slightly less repetitive; in situations where the material actually matters for gameplay, content-aware procedural generation will give vastly superior results. 

The main improvement I'd like to see in the city generator is a focus around what the city is actually *there* for.  Historically, the majority of early cities (DF is nominally pre-1400 IIRC) were located around a trade-related location; natural harbor, river ford, river portage, trade route crossing, mountain pass, etc.  Of the ones that aren't, the majority of the remainder were organized around defensible locations (mostly hills, islands, or peninsulas).  There are a very few that were located around unusually rich sources of food or mineral wealth (effectively also a trade location, as they became a source node in the network), or in dry climates sources of fresh water.  Offhand I'm having difficulty coming up with any significant cities pre-1400 that didn't form around at least one of the above; the possible exception might be religious sites in the middle of nowhere, and I'm not aware of any that were cities pre-1400 that weren't also trade hubs or the like. 

In other words, the city generator shouldn't generate a city and plunk a river or caravan route through it; the vast majority of cities should pick a location based on one of the above reasons, and then generate the city out from the fortress, river, etc.  The generator can "cheat" a little in some cases; picking a spot along a river that it wants a city, and then putting in a ford / rapids / bridge / island as part of city generation to retroactively explain why the city ended up in that particular spot on the river.  (The default DF river generation doesn't do well at generating mid-river islands, which historically were a popular choice for a citadel around which a city grew.) 

Another useful city-generation trick is that, as several folks have noted, earlier inner city walls tend to get "mined" for stone for buildings or newer, outer walls; this tends to end up with a pattern of roughly ring-shaped larger roads along where the old walls were.  This is why many old-world cities end up with a radial plan; the original major roads were radial from the keep / crossing (or it was placed on existing roads), and as it grew larger, circumferential main roads took the place of successive generations of walls.  If you have a generator for a small city, generate that, then replace the wall with a main road and generate a medium city around that; repeat again to get a large one.  In addition to some of the maps already linked, the early map of Moscow is a pretty clear illustration of how that works out. 

[NW_Kohaku]

While we are talking about composites and content generation: http://designfestival.com/the-cicada-principle-and-why-it-matters-to-web-designers/

Prime numbers beat fractals!

While that's a decent summary of an interesting technique for creating "stupid" designs, DF is generally using far better procedural designs that are at least partly "smart".  In general, prime-tiled systems are good for making repetitive, unimportant background info look slightly less repetitive; in situations where the material actually matters for gameplay, content-aware procedural generation will give vastly superior results. 

It depends upon what you are going for... To a certain extent, if we have a set of 3x3 rooms for various villagers inside of buildings, and each room has a bed, a box, a cabinet, a table, and a chair, and all we want is to have those five items arranged in different ways so that each and every villager bedroom isn't identical, then you could essentially use a more "random" procedural placement code, where all that is important is that there is an empty tile near the door, and the chair is next to the table.

The main improvement I'd like to see in the city generator is a focus around what the city is actually *there* for. [...]

I'm not 100% on this one, but given what Toady said about these cities, the cities are just towns and villages that were started for the purpose of farming, and as they become more populous, they become more urbanized.

In other words, they're there for having some open fields to farm.  But when the city grows, the fields are replaced with ever-more densly packed buildings until all the fields are gone when the city hits its maximum population size. Meaning that the reason they are there is no longer there.

And yes, that's a bit of a problem.

[Asmageddon]

EDIT: Sorry, these were all asked and answered. Sorry for asking them.

[Jiri Petru]

The towns in the new post are exciting!
But also a bit disappointing at the same time.

It's now clearly visible that all towns simply plop down a circular web of roads on the map and then start filling it up with buildings. All towns are perfectly circular and look all the same. Moreover this system results in illogical outcomes like here:

Spoiler (click to show/hide)

There is a sharp line on the north where city blocks suddenly give to landscape... one would expect it would gradually fade into homesteads, and that the cottages would spread further north instead of doing this weird semicircle on the other side of the river.

The village parts on the maps look like American suburbia, but not like a medieval village. Historical villages didn't spread out in a circular cobweb pattern.

Basically, my beef is that the maps seem to lack any logical "simulation" of growth and spreading patterns. It doesn't resemble historical examples of towns and villages. Plopping a circle on the map and filling it with streets and houses feels too unreal and arbitrary. As a result, they don't look believable and they also lack character because they're virtually identical.

(Now, I realise these are all testing towns not implemented in the actual game world yet, so here's hoping it changes! Toady is most probably just testing the street algorithms before going on with more complex shapes. Also, this is a whining of an ungrateful person who has grown accustomed to Toady's high standards and expects him to do better. Even in this phase the generation is better than in any other game.)