Will you code in the ability to create our own raw-defined building types for worldgen? Using the Arena Mode and Custom Workshops as a model, we already have most of the pieces to create both custom buildings and define functions for them.
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. One of the main things is that I'm not sure I'd be satisfied with static maps of buildings, rather than buildings that are a bit more adaptable. For instance, I'm not sure what raws would look like for the existing temples, which adapt portions of their architecture to the spheres associated to their deities. The raw format would inevitable restrict my ability to do things like that, unless it were really complicated. At the same time, I can see how a modder would want to be able to deviate wildly from what is currently available. It might be most simple to allow static building maps to be used by custom races, but since I won't be using that in vanilla it's difficult to prioritize.
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: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.
Author
Topic: Future of the Fortress: The Development Page (Read 1612747 times)