Print

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

[praguepride]

Why do we need to split up skills based on human historical point of view? Can't we let the dwarves have their own history where carpenters just did all the woodworking?

Speciliazation is for gobbos, humies, and treehuggers

[G-Flex]

Specialization makes sense for dwarves, since they (presumably) take great pride in the quality of their work. Hell, it makes sense for any highly-industrious race/culture.


Also, coopers aren't distinct from other woodworkers simply for historical reasons. Take a look at the arguments in this thread; the skills, techniques, and knowledge involved is different for making something like a watertight barrel than it is for making, say, a bed. This is true independent of history.

[LegoLord]

I don't know, I think I'd have more pride in my work if I could do awesome stuff and only be specialized to the level the game currently presents.

[Silverionmox]

You could do effectively the same thing just having a "score card" like a kill count, tallying

Yep, that's about the same, but it's just a statistic. What matters is how it impacts the dwarves; I couldn't care less about the high score table.

I'm sorry, we're relying upon a wildcard search field for our dwarves, now?  Again, get this interface implimented FIRST, then suggest the sort of things that would require that interface.

Design the interface around the systems, rather than the other way around. By Armok, I hope Toady never considered to leave the unit list like the unwieldy mess it is now.
Still, even without that tool it would still be fun to see Urist benefit from his interim job as a mason after the siege of 212.

Regardless, this is, again, just trying to find a way to force more micromanagement on players,

No rhetorical tricks, please: either it's enforced micromanagement, or it doesn't necessitate a change in player strategy so it's superfluous. You can't take both positions at once.

who would probably rather just say "you are a carpenter.  Make stuff in the carpentry workshop forever." and be done with it.

Nothing would stop them.

Again, this sounds more like an interface suggestion than a skill system suggestion.  They're totally seperate things

Killing two birds with one stone!

It doesn't matter if you don't micromanage it "all the time"... with potentially hundreds of dwarves, people will have trouble doing anything more than simply setting a single dwarf to "make wood things forever".

As in my example, that just setting "wood" as allowed material and leaving the two other columns on "any". Right now, it means activating woodcutting, carpentry, bowyer, woodcrafting and wood hauling while scrolling through that endless list.

In fact, aside from looking for peasants, it's virtually impossible to find a dwarf [...] manage which dwarves have which hauling jobs to adjust how much time is spent in any given workshop.

That's an interface issue. How did that get here?

[...] they will eventually get better, and that's all I can really do, anyway.

... They still will; what's the problem?

an increase in complexity, which necessarily leads to an increase in data

So?

without proposing a way that the complexity shapes anything being handled for the player,

?

without any improvment in dwarf behavior

The dwarf AI needs work, but I didn't get an idea to include it in this skill suggestion. My bad.

, and without any way for the player to actually manually shape the actions of dwarves in any way.

I thought you didn't want micromanagement? Anyway, you can, by specifying the materials they use, to the point of allowing alder but forbidding beech, if you choose to do so.

- We already have job permissions, that's what the labor screen is.

And they absolutely don't need any improvement? Hah.

- Material permissions only really matter in terms of which particular rocks or the like are used, unless you want to have overlapping systems on both the workshops and dwarf labor screen for what jobs are going to be performed.

It's just another approach: I care which dwarves use what materials because their skill matters; which workshop only matters now because you can't control material acces other than by spatial proximity. We'll see whether permissions remain tied to the workshop or will be tied to dwarves.

If it is for determining who uses what specific types of minerals, then you are honestly proposing a rediculous amount of data being put on a screen because now we have to see a chart showing us every single stone on it for every single dwarf that we can individually checkmark or x out.

Again, like the stockpile interface it's just general categories, which you don't expand unless you want to.

- Job priority is an ENTIRELY seperate proposal from this one AND interface.

Not anymore now Two birds in one stone. I'm rather proud of that, since we don't need a different interface for every system.

- How does adding more complexity hide complexity?  Wouldn't the simple solution be to simply make the thing less complex?  In fact, the real way to hide complexity from players who don't want to view it is to simply let them do what I've been saying all along - let them just put a dwarf on carpentry forever, and never worry about it again.  That exact goal is already achieved with the current system.

And why should that stop us from proposing systems that keep or improve the current simplicity while expanding the possibilities?

[NW_Kohaku]

You're making way too many assumptions here. The game won't necessarily stay the way it is now forever, nor will quality/value modifiers, necessarily, or skill caps, or anything like that. You're right to say that some of that would probably need to change/be more developed in order for this sort of thing to ever matter, but we're already discussing serious changes to game systems. It's foolish to state that a hypothetical idea is bad just because it depends on other hypothetical ideas.

For instance, say we were talking about attributes instead of skills, and we didn't know about the current in-development version; you might make some argument about attribute caps or some-such as if they're set in stone, even though they're actually changing now, never mind in the future.

The question we should be asking is "what would the game need to do in order to achieve the effect we're aiming for?", not "can this effect be implemented properly without changing any other systems?".

Actually, I consider you to be the one making far too many assumptions, it is an assumption to make plans upon anything you haven't seen yet.  There aren't any attribute caps right now (they can be gained well beyond the 5 levels they appear on the game screen right now, and who knows how high they can ultimately go before they hit some kind of data-type limitation or cause an overflow bug).  To plan upon something you haven't really seen, and hasn't been thoroughly tested yet is, as they say, counting your chickens before they hatch.

However, you're right, we should be talking about what people will want to play, which is why I've been saying this whole time that people really aren't going to want to play with worrying about if dwarves are micro-specialized in certain things or not.  They're going to want to simply look and see if they have a good carpenter or not, and if they are working on making the things they need at the moment.  I don't see this sub-skill system adding anything that people really will use.

There's no value added for the cost.

As an example, I just shake my head at the notion that the new version had raws for things like eye pupil size added in, just to add to a description, even though it has no forseeable effect on any sane player's gameplay.  (It also has disturbing equivalencies to FATAL's system of making you roll for head circumference.)  Where is the gameplay value of a system like this?  If it adds no value, why is it there?

Which is why I come back to the same thing I keep saying: this is either going to be extra data I'm not going to care about, or you're going to do something that will FORCE me to care about it, in which case it will, by necessity of the way this is set up, be nothing but annoying micromanagement that makes understanding large fortresses even less wieldy than it already is.

[LegoLord]

Here's what I don't get.  The suggestion is to add in something that adds a new layer of complexity to skills, but in a way that is subtle enough that people can just keep doing what they do now (i.e., set a dwarf to just do carpentry and leave it at that).  So what, precisely, is the point of it aside from eating up programming time?

Also:  wall of text made of responses spliced in the middle of quotes - not a good thing.

[Kilo24]

As an example, I just shake my head at the notion that the new version had raws for things like eye pupil size added in, just to add to a description, even though it has no forseeable effect on any sane player's gameplay.  (It also has disturbing equivalencies to FATAL's system of making you roll for head circumference.)  Where is the gameplay value of a system like this?  If it adds no value, why is it there?

Which is why I come back to the same thing I keep saying: this is either going to be extra data I'm not going to care about, or you're going to do something that will FORCE me to care about it, in which case it will, by necessity of the way this is set up, be nothing but annoying micromanagement that makes understanding large fortresses even less wieldy than it already is.

To contrast the FATAL reference, the main difference is that this is done automatically by a computer with no input from the player.  There is no gameplay value to it, but there may be a very slight value added to the description quality, which makes dwarves (imperceptibly) more unique.  It's almost certainly completely unimportant, but it comes at a negligible cost to the programmer's time and to the player's time, so it's a decent but irrelevant tweak in my book.

I'm mostly in agreement with the idea that coopering might be a historically accurate divide, but adds nothing to the game.  Very few fantasy stories involve coopers who are distinct from carpenters.  It's also the case that as the number and specificity of skills increase, dwarves in the current system become less dynamic and able to do multiple things (since the vast majority of the time, focusing a single legendary dwarf on a single type of production job his skill matches is leaps and bounds ahead of any other skill setup in terms of efficiency.)

[NW_Kohaku]

Sorry, Legolord...

(Also, Silverionmox, could you put some linebreaks after those [/quote] things?  It's easier to respond when you can find where the quoted quotes end.

Still, even without that tool it would still be fun to see Urist benefit from his interim job as a mason after the siege of 212.

Once again, I think the root of these arguments we have is rooted in extremely divergent ideas of what "fun" means. 

No rhetorical tricks, please: either it's enforced micromanagement, or it doesn't necessitate a change in player strategy so it's superfluous. You can't take both positions at once.

Actually, I have to wonder if you're reading what I'm writing, here.  I've been saying time and time again that these changes force one of two things: EITHER superfluous data, OR enforced micromanagement of a greater amount of data.

who would probably rather just say "you are a carpenter.  Make stuff in the carpentry workshop forever." and be done with it.

Nothing would stop them.

And if you don't stop them, it tilts towards the "superfluous data" side.

Again, this sounds more like an interface suggestion than a skill system suggestion.  They're totally seperate things

Killing two birds with one stone!

No, it's proposing that the problem isn't that your car has no wheels, it's that you haven't flipped it over, dug a pit, filled it with water, and called it a "boat" to make it work.  What you're doing has gone completely and totally beyond the ken of this thread's purpose.

some stuff taken out of context, and responses with fractions of a sentence

This has gotten tedious enough already, since this conversation has just been going in circles, with you not even apparently acknowledging my points, so I'm not even going to bother trying to figure out what kind of conversation you were trying to have, and sleep instead.  I need sleep.

[G-Flex]

Actually, I consider you to be the one making far too many assumptions, it is an assumption to make plans upon anything you haven't seen yet.  There aren't any attribute caps right now (they can be gained well beyond the 5 levels they appear on the game screen right now, and who knows how high they can ultimately go before they hit some kind of data-type limitation or cause an overflow bug).

I know. My point was that attribute caps/growth are changing; right now, there aren't any caps and dwarves are all more-or-less identical, whereas in the next version there's a sense of maximum potential that varies between individuals. It was an example of how systems like this can, do, and will change drastically.

To plan upon something you haven't really seen, and hasn't been thoroughly tested yet is, as they say, counting your chickens before they hatch.

The problem is that a lot of serious suggestions require other suggestions or features to be implemented. If features A, B, and C are all mutually dependent, that doesn't mean we shouldn't be able to say we want any particular one of them; it just means you have to discuss the rest as well. It's similar to comments about the interface above: You have to know what people want in order to know what the interface should be. If you have mutually-dependent features A, B, and C, you need to know what's expected of each of them before you try to figure out how they'd work together.

However, you're right, we should be talking about what people will want to play, which is why I've been saying this whole time that people really aren't going to want to play with worrying about if dwarves are micro-specialized in certain things or not.  They're going to want to simply look and see if they have a good carpenter or not, and if they are working on making the things they need at the moment.  I don't see this sub-skill system adding anything that people really will use.

Speak for yourself, please. This is a game where creature personalities and relationships are fairly detailed and will continue to get more detailed. What makes you think Toady would want to implement hair and iris color yet not want to implement more significant details like skill specialization? It's perfectly fitting with the development of the game, and judging by the posts in this thread, there are people who would like to see it.

As an example, I just shake my head at the notion that the new version had raws for things like eye pupil size added in, just to add to a description, even though it has no forseeable effect on any sane player's gameplay.  (It also has disturbing equivalencies to FATAL's system of making you roll for head circumference.)  Where is the gameplay value of a system like this?  If it adds no value, why is it there?

Aesthetic details like that, even when they don't impact gameplay mechanically, still help to individualize creatures and endear them to the player. This will matter more, if anything, when creature randomization comes into play more, and hell, look at the descriptions/raws given for some of the sample randomized creatures in the next version. If you read a fantasy novel or watch a movie, things get visually described for a reason. It helps with the experience, as a whole, to associate visual descriptions/features with an entity, even if those features don't directly impact what that entity does/can do. Otherwise, you might as well argue that saying a person has red hair shouldn't be done in novels, because after all, that's irrelevant.

Of course, in real life, people sometimes do care about the physical traits of others, which is another reason why they're being implemented; it can have social ramifications even when it doesn't have obvious physical or mental ones.

Which is why I come back to the same thing I keep saying: this is either going to be extra data I'm not going to care about, or you're going to do something that will FORCE me to care about it, in which case it will, by necessity of the way this is set up, be nothing but annoying micromanagement that makes understanding large fortresses even less wieldy than it already is.

Nobody's asking you to care about the exact same things as everyone else. The game isn't made just for you. If you don't care about it, that's great, that's your prerogative, but it's perfectly in line with the game's design principles and with what has endeared people to the game in the past (and present).

Of course, I don't think anybody's saying you should be forced to care about it, either. Your carpenter being a little better at making certain items than others isn't something that's going to make or break your gameplay. It's just an added bonus for people who don't want dwarves to be faceless and nameless.

Again, if you look at anything Toady says about any of this, it's obvious that it's intended for the game to represent highly individualized creatures with meaningful goals and relationships, with impact across all game modes. This is much, much harder to do in a way that people easily care about if they're not physically, mentally, or socially distinguishable from each other, and right now, they barely are at all.

[neek]

The issue that I'm finding is that a). some old players will have a problem with a new system that doesn't perceptually improve on the old (not so much in the interface design, but also in how it works.), b). new players won't know any better and need to be able to approach the skill system with the same or less effort than the old system would have required.

I'm going to posit a challenge; NW_Kohaku, you have stated earlier that these suggestions (as made thus far): How would you approach the idea of 1). changing skill interface setup, and 2). adding subskills? (Neither of those should be related). I ask this because thus far, you have been vehemently opposed to the idea. Reading some of your suggestions, you have an excellent imagination, and you state what you desire quite clearly. You MAY not agree with what I'm asking (that is, option 2), but your input on how to handle this might steer the conversation into something more... productive?

[Hyndis]

How would these proposed changes improve gameplay?

It sounds like a huge amount of micromanagement for no gain, because if I have 200 dwarves in my fortress I'm only going to care about very generalized skills.

So this system could invoke months of work and balance just so it can...be ignored? Because it will be ignored. It adds nothing to gameplay. Its just a whole lot of work that adds nothing except for tedium.

That is not fun, and it should not be included in a game.

[G-Flex]

I (and other people, I think) have already addressed the "huge amount of micromanagement" problem. It's not the kind of thing that needs to (or should) make the game more tedious or frustrating to deal with.

You could say the same about wounds or anything else: Why care about which finger is broken on a dwarf if you have 200, or what their personalities are?

You're also ignoring the fact that Fortress Mode isn't the only mode of play, and that non-player-controlled dwarves in general would be affected by these things.

[Andeerz]

I agree with G-flex on a lot of points.  I know I'm going to be sounding hand-wavy here, but the suggested skill synergy stuff that would operate behind the scenes (and therefore seem useless to some people if I am understanding the situation correctly) would make for the skill system to be more robust as other features of the game make it in. 

Agh... it's hard for me to explain at this hour and I need to think about it more.  But analogous features to the general suggestion include personalities and world history.  These features are pretty much useless to gameplay and add a seemingly useless level of complexity, but at a later date, they may prove to be useful for making smooth interfaces between future features and already existing ones.  In essence, they provide places for other systems to plug into the equation in a meaningful, believable way.  I can totally see how some of the suggestions made here involving changing how crafting skills are set up could be later exploited with a future system of knowledge transfer if it ever happens.

[G-Flex]

The thing about skill synergy itself is that, in part, it's meant to make skill management less irritating, especially when you have a lot of skills involved that seem to be related. This could even apply to some of the skills we already have. For instance, a guy who's been fighting with axes his entire life will certainly fight with a hammer or club a lot better than someone who's never fought with either, because the skillsets have a fair bit of overlap.

Of course, an alternative to this is to break skills up to the point where that overlap is actually explicitly represented instead of abstracted into "these skills just happen to be similar", but that would be an extremely tall order to fill.

[Silverionmox]

Here's what I don't get.  The suggestion is to add in something that adds a new layer of complexity to skills, but in a way that is subtle enough that people can just keep doing what they do now (i.e., set a dwarf to just do carpentry and leave it at that).  So what, precisely, is the point of it aside from eating up programming time?

New skills will inevitably be needed. If we have a system that's flexible enough to accommodate many new skills, that will save us the trouble of working with a skill list that's slowly inflated to 100+.

People can do what they do now, but they also can go the extra mile to specialize and be rewarded with higher quality (depending on their whim or the fortress location: if there's a lot of gold and zinc ore, the player might specialize smiths of those two metals, for example, while using just the general approach for woodworking and everything else). For non-player entities in adventure mode, regional specialization adds variety to the villages and towns.

I've been saying time and time again that these changes force one of two things: EITHER superfluous data, OR enforced micromanagement of a greater amount of data.

This has gotten tedious enough already, since this conversation has just been going in circles, with you not even apparently acknowledging my points, [...]

I am acknowledging your points, just not conceding mine. Anyway, since you set conditions that are impossible to satisfy, why would anyone try to? Some features may be unimportant to you: that's fine. Stating that you consider that wasted programming time for your taste would have sufficed, rather than trying to suppress features other people like.