Bay 12 Games Forum

Caverns can be quite safe if you prepare well for it. My current fort I am working on caverns, and to my luck, this segment of the cavern is an island, so I don't have any hostile spawns, aside from anything that might come from the water itself (Which I am in the process of walling off). Still need to build a few wells eventually.

Beware flying cavern creatures, if you're just relying on walkable (and now amphibious) isolation.

I had a Pterodactyl-based FB in one of my caverns (discovered through a stairwell into the top, as is usual with my explorations, which was promptly sealed off) and the subsequent well-shaft digging was equipped with various lever-operated hatches.  Terry the Terrible Tearaway Pterodactyl (or whatever it was called) still flew some way up the well-shaft (approx 50Z levels, so easy to react to, when I happened to notice it).

Hmmm, makes me wonder.  Near the bottom of the shaft (probably in the escape-level, just next to where the caverns get breached through by the final channelling after the well-digger has made sure he can wander away from that square) if I make it a fortification, instead of a wall, put a non-grazing watch-beast the other side of it on a 1x1 pasture defined over a pressure plate attached to one or more of the series of hatches, with room for it to retreat if it saw anything nasty, could anything that scared it push it off of the plate, into the (sealed off) rear of its guard-burrow, and cause the hatches to close automatically?  Would that cause issues if the well's bucket was currently lowered to the bottom and in danger of being severed by the closing hatches, or would it just stop the rope/chain and prevent movement until the hatch(es) opened again?

Must try that, sometime.

I don't understand why method 1 would be significantly preferable to just passing around a world and making sequential fortresses for the benefit of future adventurers.  It would be a lot of work, just to keep your adventurer in year 1075 instead of year 2000.

Simultaneous cooperation or competition, according to taste.

In the former case, one player can be saying to themselves "I know if this fortress fails, it won't be for the lack of booze and food!" while another is confident about his defensive architecture, and yet another is doing their best to get those in the military into shape for when that architecture needs breaching for the resource gathering that another player is desperate to start upon, but is holding back and odd-jobbing until such time as it's safe to do so...

In the latter: "I can make my dwarf more self-sufficient than yours" "Oh yeah, even if I drain the water away from your well?" "Ph34r m`/ M46M4!!111!!!111oneoneone"  Or perhaps something less clichéd, BYGTI.

I like the idea of multi-fort sort of control within the same site.

Not sure you got the sentiment I was trying to convey (in a post that was meant to reply to the original (or at least second) post, even though I'd read everything that came after before I did), as a "seven hermits site" was just a logical extension of the "they don't even have to interact" idea, and "seven hermits at war" just a further extension, but not a default position.

The absolute original basis to the above is that each player would be responsible for a sub-set of the population, a truly "cooperative game".  Rather than a current succession fortress where you get "Oh, I see you haven't done much with the defences, I'll add a trading airlock" or "food stocks were low when I started, so I've produced a whole lot of roasts that should keep us going a few more years", that sort of action would be (could be, should be) undertaken simultaneously across the whole board by the players controlling (ideally) the best mason or food producer, or even (much as in a single-player management of a fort) the player who has a legendary woodcrafter who has more spare time and very little spare wood to whittle away.

DF barely moddable?  Ok, I know you mean "in multiplayer ways", but the original Method 2 called for a coordinating server that collates everyone's moves, and that's the thing that works out who is allowed what action.  (Change your own dwarf's nickname?  No problem.  Not so for that of others, though!)  I've maybe been a bit free-and-easy with the fact that everything is visible to everyone else (in a truly "multiplayer deathmatch" situation, the server could even be set to impose a "fog of war" on each player), but certainly each player has natural control limited to their own agent-characters in the game, and perhaps resources that they have established.  Although, even then, a "permissions interface" in the client and server could over-ride this and leave the core DF program none-the-wiser.  (Indeed, it never need know that there were multiple people even trying to play with it, so the fact that an action by one player had been authorised by another wouldn't come into that part of the equation.)

Another problem is the stocks. We could feasibly store which items were in which borough upon creation, and manually store fort ownership, but this would be unpredictably difficult, I believe.

I skimmed over this, myself.  Either it's a free-for-all (when it comes to snaffling any particular item) or the server imposes some sort of restrictions on what each client can display in the list of thrones they can emplace in the room they are furnishing.

For food, it's probably a free-for-all.  Although maybe with a server option to "lock" the likes of dump or forbid options so that only the client of the player controlling the dwarf that is the producer of that item can normally do so.  Perhaps other clients are given a "request permission?" button/key-press which alerts the producer-client program so that the player gets a yay-or-nay answer (if not setting an auto-permission, or auto-deny, for this sort of interaction with that particular requesting player).  I foresee the default setting to be "require permission, unless rotten".  There are other ways to adversely affect stocks (setting up the food stock-pile entirely the other side of the map, and potentially cause the whole stock to be in motion), but that can be worked upon.  But food is a largely "get it when you need it" commodity, hauling excepted.  Kitchen controls (cookable/brewable settings) might or might not be considered something that a single player (designated from the start, or going by skill-levels) can control.

Furniture is directly selected, and so when attempting to place a chair you just pare-down the selection screen to items for which the player has (natural or granted) permission to use.  Or list them all as normal but with the same "get permission" schema for such sub-items as need it.

Quote

There are finer details to be worked out that might be necessary with regard to the potential for griefing players.

I believe a portion of my post stated that griefing players are not a concern.

Indeed.  I was merely suggesting ways in which, firstly, this kind of simultaneously cooperative play might be allowed to selectively restrict certain actions to certain players in accordance with "This is Player X's dwarf" and then secondly, by extension, extend to a feeling of "This is Player X's dwarf's stuff".  Whatever was implemented would be really about focussing each player on playing their own part in the Grand Scheme, with a general trust that the others were doing so, but it's so close to providing a system in which griefing (by anyone but a designated authority, such as the mayor-player or the squad-leader player, within the domain of automatic trust that they necessarily need to be granted) already has checks and balances against it that it's not much more effort to attain.

Quote

And the deliberate version of this might be a mini-competition.

I will refer you to what Carnes stated in his post above yours. I don't view multiplayer DF as anything more than a vehicle to social gameplay, and therefore, competitive gameplay is not desirable to me.

It may not be, but whether (say, frexample) Halo/Doom/Duke Nuke'Em 3D/whatever in its multiplayer mode is a deathmatch game which can also be set to be played cooperatively, or a cooperative game in which there is a deathmatch possibility, players will always want to try the other side of the coin.  And (however it is done) the whole range of actions (from locking down 'aggressive actions' between players up to it being the prime intention to actively pursue internecine hostilities) are going to be demanded as options by any player-base.

I'm not sure if I'm even the right kind of person to partake as player in whatever the end result is (far too altruistic for a deathmatch, far too micromanaging to keep up with the "get it done, whatever way" set of players), and this is not a call for what I want, just putting it out there.  Like I said, at least to be disagreed with.

While I'm not particularly sure about certain aspects of "Going Multiplayer", can I put forward a variation on Method 2 for at least general disagreement with.

Each player is given domain over a subset of the dwarven population.  The client's interface with the "master game controller" program will only let the player alter (say, if the player is allocated just one character) a single dwarf's job allocations, only allow that dwarf to be added/removed from burrows by that player, and similar restrictions when it comes to joining a free military-unit slot, or moving into a new one in a different (existing) unit.

Squad leadership excepted... as mentioned far below.  And there is another exception of compartmentalisation when it comes to military units, in that the squad leader's controlling player has control over training/patrolling schedules and full-squad order designation (although this latter can be over-ridden by per-dwarf redesignation by the controller(s) of the subordinate members of the unit), but that's mostly due to the dependencies of actions involved when military needs are at the forefront, and there's always resignation/unit-shuffling available in the event of a disagreement by the subordinate.

Assignments such as to-be-dug tiles, furniture emplacement, etc, are free actions, as other players who have mining/furniture hauling/whatever enabled for their character(s) should be able to prevent them wandering off through burrow assignment.  To this end, there should maybe be two different styles of burrows...  "Public Domain" ones open to change (excepting dwarf membership) by anyone and "Personal" ones that once created by a given player are solely their own to change (though not to view).  This way there can be a combined effort to maintain a "This is inside"-style burrow or a "This is where the food and refectory is" one (at least as long as no-one takes the urine and forces the others to maintain their own private versions of it), but "Player2's Mining Operation" cannot be messed about with by any-one (at least not programmatically, there's always various forms of sabotage by otherwise-controlled characters).  This does not mean two different types of burrow to the "core DF program", merely that the coordinating server program is told of the distinction by the client programs, and keeps track of all that like it does everything else.  Burrow removal follows the same rules insofar as who is allowed to enact them.

A further server option could be that a pre-defined area (or, indeed, volume) of the map can be set to be dug/modified by each respective game character's player, with perhaps a form of horse-trading/mutual-consent allowing the shifting/sharing of various areas.

Other than the aforementioned tracking and partitioning of control, there's very little difference between this concept and the original Method 2.  Minimap (or other representative) tracking of each player's views and actions upon the world, basic chat (aside from the obvious idea of scrawling messages in the rock with as yet unfulfilled digging designations, to various ends from shout-outs to out-right insults, I foresee) for task coordination purposes, handling the pausing situation and a whole lot of peeking/poking by the DFHack-inspired game coordination server are the order of the day.


There are finer details to be worked out that might be necessary with regard to the potential for griefing players.  e.g. should there be a free-for-all when it comes to furniture emplacement (also forbidding, dumping or even melt-designating of items)?  Or some restriction (perhaps permission to use, by the player whose character created the artefact throne) to prevent someone claiming all the marble statues intended by another to decorate the noble's bedroom (the noble possibly being being 'controlled' by a third-party, profoundly apologetic for the demands it just made)?  Although I do wish to see it having the more optomistic approach of each player keeping an eye on their character(s) and the stock situation and asking "Has anyone been making booze recently, I've got a carpenter here who's feeling withdrawal symptoms".  Perhaps eliciting the reply "Whoops, I forgot to ask you for more barrels!"

Ditto some thought to be put into whether one player's built forge should need permissions (again applied through the client to the coordinator process, and still invisible to the main DF engine) for another player to designate the likes of metal bucket manufacture, or shuffling the jobs around within it.  "Job Manager" jobs might be interesting, and perhaps at least have some kind of pre-emptive yay-or-nay job management function assigned to the player who controls the Manager dwarf character.  Noble assignments themselves are restricted to the current expedition leader/mayor/equivalent (according to level, or indeed who is considered nominally the first in line to command of a fortress where !FUN! may have done for the obvious candidate) for all the non-military and primary military appointment, this latter then having domain over creation of new squad-leaders.  This of course requires thought as to the cooperative (or otherwise) play required at the point that the single-player version is browsing through the embark scheme.  Perhaps this would normally involve chat-style discussions of who has the best miner/military/woodworker/leader types, and then individual point assignments however each player thinks (with the ability to review, but not change, other-player-characters) although of course changes to the goods to be carried (also affecting the points available to the embarkees) would have to be negotiated in some way.  Whether that ends up with "I'm vetoing all booze until one of you two stops trying to hog the social skills!" or something a lot more civilised might indicate what kind of game this ends up starting as.

I could also foresee a "seven hermit site" being either deliberately or inadvertently pursued from the start.  And the deliberate version of this might be a mini-competition.  Such as "dig your own hole [having arranged for at least one pick each?], get your own resources, the aim is to be the first one to have ten goblin invaders on their kill-list".  The less amiable (perhaps unplanned) version might involve becoming the sole surviving dwarf after creating problems for the other hermits anywhere from 'accidental' magma-flooding of their fields to sabotage/by-passing the various defences to allow the siege to incapacitate all others.  But don't forget that the 'winner' would also have had to keep themselves fed and boozed-up sufficiently, and avoid the machinations of everyone else at the same time.


Also, at some point between appearance on the edge of the map and the point at which they lose their "flashing-X" status (usually in the meeting area), immigrants could either be shared out randomly to existing players or given out to watching-and-waiting players who until now have not been able to acquire a "controlling share" of the population.  (There's a potential for the aforementioned leader-player to dish them out, but I think random, or perhaps 'levelling', distribution would work best.)  The death of a player's last (or, indeed, only) dwarf might (by game settings and/or player consent) mean either the acquisition of the next newly available (or donated?) dwarf or Game Over, and leaving the remainder of the interested parties to deal with the future development of the fortress alone.


And, again, this is meant to use the same mechanisms (with the various stated restrictions) as Method 2, which seems to me as largely (although not completely) attainable, given a little effort.

On another note, a racoon just stole a silver greataxe.  o.O

I predict that, some years hence, you shall be revisited by... Racoon The Barbarian!

*Hums a tune to self that is a peculiar mix between the Conan theme and the title music for the late 80s animation "The Raccoons"*

Quote from: BigD145 on July 31, 2011, 09:31:57 pm

Quote from: Starver on July 31, 2011, 04:30:35 pm

Quote from: Jurph on July 30, 2011, 08:11:56 am

Wrong -- diagonal movement costs 1.4 squares of movement.

I've previously quoted that information, but others have said that there's no basis for this, so I don't throw this fact around any more and go with the apparently more provable "Modified Manhattan" distance.  Still, we can deal with it being otherwise.

a squared + b squared = c squared

Basic geometry of a right triangle.

He's reffering to that info needing verification in DF movement costs.

Also, 4N and 3W would be a total distance of 5 IRL (good old Pythagoras), but:
distance 7 by Manhattan[1], which it definitely isn't
distance 4 by Modified Manhattan[2], which most people work with
distance 5.243... by Manhattan With Diagonals[3], which is the possible (but unproven) alternative where only exact orthagonals and diagonals are strictly an analogue to RL[4].

[1] (|x|+|y|)
[2] (max(|x|,|y|)
[3] (min(|x|,|y|)*sqrt(2))+|(|x|-|y|)|
[4] At short distances, this is more than absorbed in the tile-to-tile measurement discontinuity, but a radius 100 circle would have the point 60x80 from the centre 4..5 tiles 'wrong' from true equidistance with its more accurate cousins, depending on how accurate the diagonalising factor is[5]...
[5] And if you did the calculations based on centre-to-centre or edge-to-edge (both inner or both outer!).
[X] I can't blame the above footnote storm on too little sleep, I only just woke up!

First order of business on embark:  get access to mud so we can grow plump helments and make wine.  We are dwarves!  We are strong!  We do not drink Water!  But Water is a necessity for non-drinking purposes, including this one.

Can't comment specifically about this, because my Glacial embarks have had soil beneath the glacier (even if it's just in one tile off in one corner, out of the 16 or so embark tiles that my fortress spreads across) and I've found that works nicely.

BUG: the "cannot dig stairs from the bottom of glacier into the rock" issue.

While I can't build a stairwell into the layer of ice, and have usually dug ramps to bring myself into the ice-levels, if you designate down-stairs and it 'just' digs out the tile, I can then designate down-stairs upon the now air-filled tile and get back down.  (Also, if digging from below, up into the ice, the downstair 'top' of the stairwell column again acts like a standard (d)esignate (d)ig, but can be reesignated as downstair and... no problem.)  So while there's a degree of strangeness (possibly for the physical reason you give), it's not a deal-breaker.

Your masons could also build up/down stairs with ice, if you really want them to.  Interesting material, ice.

Also, never had a problem with obtaining Water.  Dig a stairwell down, hit the caverns (maybe not the first), discover where the water is and set up a well or twenty.  Thus I don't have experience with some of your other BUGs.

BTW, Yetis are interesting wildlife dangers.  Topple your workshops.  (If you don't build ice walls, and/or ice bridges over channels in the ice to keep them out.  A pity I couldn't also make ice levers and connect to the ice bridges with ice mechanisms.  Now that would be rather consistent.)  I've got some in a fortress that I haven't yet gotten around to seeing if are tameable.

HILARIOUS NEWTONIAN ISSUE: if I'm not very, very careful when breaching the caverns, then the miner who does it will dig out the floor under his or her own feet and fall 50 or 60 Z-levels before hitting the cavern floor so hard that body parts are thrown to a distance of seven or eight squares from the point of impact.

Sounds like you're doing it wrong.  I've never had a miner fall into the caverns he is breaching (knowingly or unknowingly, by myself).  Stairwell exploration from Z-1 (or wherever you're starting) to the lowest possible layer?  When cavern breaches: if from top then dig out a tile to one side, of where the stairwell breaches and then build an up-stair on that lowest stairwell to prevent inadvertent flying cavern beasts/FBs from wandering in, then plan next breaches (for wells etc) accordingly; if in a side-wall, then stop downwards digging immediately, set to build isolating walls, etc, or retreat upwards in order to sort out the previous trip.  The only way I could ever drop a miner into the cavenrs is to make an unplanned and unsurveyed 1x1 channel-stacker.  And falling 50 to 60 Z-levels?  I only ever modify my caverns for greater separation, and I'm not sure what you've done to create 50-60 Z-high cavern spaces...

Maybe I just haven't lived.

Maybe I want to dig a shaft from the main fortress straight down to the cavern level, so I can have a well.  Wells seem to be suboptimal, though.  First of all, I seem to lose roughly one miner per shaft (though a shaft may be wide enough to support more than one well) on this kind of project.

The trick is to dig your channel-shafts down to the layer before breaching the caverns, then dig sideways.  Optionally dump the stones accumulated, then send in a miner to channel the last floor-separation away from the side.  Contaminated?  Well, if you're dropping dead (or soon-to-be-dead) miners in them, I could see how, but not otherwise.  However, wells make universally drinkable (if not actually unsalty/non-contaminated/whatever) any water they dip into, so your experience sounds consistent in that respect.

I'd also put the wellhead(s) close (within a Z or two) of the cavern breach.  Perhaps for safety add a hatch in on the bottom layer of each and every well you have (and wall the shafts back in on the bottom level) connected to a lever, so that you can close the shaft off if randomly flying stuff wanders into close proximity with the shaft.  Water gets drawn up half a dozen Z-levels at most, and across maybe half a dozen wellheads, so plenty of supply if necessary.

Later on, tap into the side of a cavern lake with a pool that can floodgate-isolated and either drawn from from an even larger number of wells or pumped up as necessary.


Again, a lot of the later items you mention have not happened to me, and/or have not needed to be sorted out in the ways you apparently tried, so I can't answer everything you say, but maybe the above makes sense?  Maybe it doesn't.  Caveat diggor?

[...] I recommend building a wall. most things can't pass walls. Maybe a roof as well.

Not knowing if this applies to those modded creatures, but they might have been flyers.

In which case permanently (or at least until the caravans/migrants are to be allowed in) isolating the innards from the outside might stop them from attempting to path over the walls, but as long as there is a ground path they'll take whatever route they can, inclusive of airborne if capable, as I understand it.

(Again, can be made into a baited trap if you understand how it all works.  Eat the Fortress.  Drink the Fortress.  Live the Fortress.  Be the Fortress.  Be one with it.  [CarryOn]Oooh, you are a one, aren't you..?[/CarryOn])