Print

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

[Jiri Petru]

The "why fix it now?" philosophy then of course leads to the issue of annoying bugs and half-finished features (or call them "placeholders", if you will) that will linger for years and years because Toady will always be busy doing something else. For example, the way weapons and armour work and interact right now is quite silly and frustrating (the better metal always wins) - actually, it's working worse then before this feature has been implemented - but I guess there's no hope of Toady fixing it any time soon. No point fixing a placeholder, right, we can live with it for the next ten years until he finally gets to the "combat rewrite arc".

[Dae]

There is a significant difference between "fixing a bug" and "replacing a placeholder with the fully-feature" in a game like DF. DF is ambitious on virtually every side of it. Each placeholder is there because a whole other arc of features is missing, so before fixing it said features have to be implemented. If you consider it that way, he is actively working towards fixing your bug. It's only the sheer scale of the projet that makes it a long way.

Also, please consider what you're saying. "Basically, the better metal will win" is the common design in every other RPG and no one ever complains about it. Here it wins because its mechanical properties are more suitable for the weapon used. I don't see why you're complaining.

[Zared]

Also, please consider what you're saying. "Basically, the better metal will win" is the common design in every other RPG and no one ever complains about it. Here it wins because its mechanical properties are more suitable for the weapon used. I don't see why you're complaining.

"The better metal wins" doesn't mean if you put 50 dwarfs in iron, and 50 in steel, the steel dwarfs will edge out the iron dwarfs.  It means if you do that it will be 50 to 0 in favor of steel, since they are completely invincible (ok, not entirely, occasionally a shield bash might shatter a skull).  The iron battle axes will hit the steel armor and they will deflect harmlessly, while the steel battle axe will be hacking limbs off like no tomorrow.  Of course, give them blunt weapons instead of axes and now iron wins with its heavier weaponry that ignores armor. 

This is, of course, pretty much how it actually works.  But RPGs never do it that way, as opposed to always doing it that way.  Because it's not fun, and it's not what's in books and on TV.  Unarmored dude chops anonymous knights in full plate armor into ribbons, sword slicing through solid steel as though it were butter.  It's never "knights bonk each other around a bit until one is too tired and bruised to keep up his guard, and the other stabs him in the armpit with a dagger". 

[monk12]

Same here.

On an unrelated note, one problem I can see with automated edibles could arise when the game has you eat some dragon steaks you were saving to sell at the market when you got back to town instead of your rations of badger haggis.

I imagine an interface similar to the Kitchen screen in Dwarf Mode would be easy to implement and use.

Also, please consider what you're saying. "Basically, the better metal will win" is the common design in every other RPG and no one ever complains about it. Here it wins because its mechanical properties are more suitable for the weapon used. I don't see why you're complaining.

"The better metal wins" doesn't mean if you put 50 dwarfs in iron, and 50 in steel, the steel dwarfs will edge out the iron dwarfs.  It means if you do that it will be 50 to 0 in favor of steel, since they are completely invincible (ok, not entirely, occasionally a shield bash might shatter a skull).  The iron battle axes will hit the steel armor and they will deflect harmlessly, while the steel battle axe will be hacking limbs off like no tomorrow.  Of course, give them blunt weapons instead of axes and now iron wins with its heavier weaponry that ignores armor. 

This is, of course, pretty much how it actually works.  But RPGs never do it that way, as opposed to always doing it that way.  Because it's not fun, and it's not what's in books and on TV.  Unarmored dude chops anonymous knights in full plate armor into ribbons, sword slicing through solid steel as though it were butter.  It's never "knights bonk each other around a bit until one is too tired and bruised to keep up his guard, and the other stabs him in the armpit with a dagger". 

The reason why we like stories where the unarmored swordsman cuts the knight to ribbons is because of how unlikely it is- it speaks to superior skill trumping superior armament. And you know what? Toady already has plans for that- stances, more tactically interesting combat, etc. As far as the "sword slicing through steel" bit, the only time that happens with any shred of plausability is when the material or magic of the sword is sufficient to handle it. Which, as you've pointed out, is how things work now.

There is a significant difference between "fixing a bug" and "replacing a placeholder with the fully-feature" in a game like DF. DF is ambitious on virtually every side of it. Each placeholder is there because a whole other arc of features is missing, so before fixing it said features have to be implemented. If you consider it that way, he is actively working towards fixing your bug. It's only the sheer scale of the projet that makes it a long way.

Y'know, what he said. DF isn't the greatest Heroic Fantasy RPG right now, but it will be. Until then, I'll settle for having the most accurate Medieval Combat simulator around.



Unrelated: GAH SMF 2.0

[piecewise]

Also, please consider what you're saying. "Basically, the better metal will win" is the common design in every other RPG and no one ever complains about it. Here it wins because its mechanical properties are more suitable for the weapon used. I don't see why you're complaining.

"The better metal wins" doesn't mean if you put 50 dwarfs in iron, and 50 in steel, the steel dwarfs will edge out the iron dwarfs.  It means if you do that it will be 50 to 0 in favor of steel, since they are completely invincible (ok, not entirely, occasionally a shield bash might shatter a skull).  The iron battle axes will hit the steel armor and they will deflect harmlessly, while the steel battle axe will be hacking limbs off like no tomorrow.  Of course, give them blunt weapons instead of axes and now iron wins with its heavier weaponry that ignores armor. 

This is, of course, pretty much how it actually works.  But RPGs never do it that way, as opposed to always doing it that way.  Because it's not fun, and it's not what's in books and on TV.  Unarmored dude chops anonymous knights in full plate armor into ribbons, sword slicing through solid steel as though it were butter.  It's never "knights bonk each other around a bit until one is too tired and bruised to keep up his guard, and the other stabs him in the armpit with a dagger".

I'm not sure if you're saying that thats a bad thing or a  good thing. Personally, I love that it stays as close to reality as possible because it gives a real sense of progression. If unarmored people could just go around hacking through chestplates like nothing then it would make armor entirely meaningless. As it is, good quality armor and weapons are very valuable because of their ability to defend and destroy better then anything below them. If we remove those properties that makes it like that, then all metals just become pseudo-equal and boring.

And here's the thing, iron does  not beat steel every time. I've got an adventurer with close to 600 kills who uses nothing but a average copper sword. I've fought men in plate steel armor and won without having to strip off a single piece, and you know why? First, rarely are people completely armored. Hands and feet are often prime ground for amputation, and doing so can end a battle quickly. But even if an opponent is fully armored, I can still strike with the pommel of my sword, or slap with the blade. Nearly every weapon has a blunt attack, and thats what will kill armored men. Admittedly, in fortress mode all this is random, so the odds are stacked in steel's favor simply because the iron wielding ai isn't smart enough to fight tactically; but the point is that there are other factors in play beyond simply "steel beats iron".

As per the add vs fix debate, you have to remember that for every update he's doing 2 bug fix releases, so he's literally doing twice as much bug fixing as updating and you want him to do more? The problem with that is that df is already relatively slow to add new content (or at least release this new content) and adding more bug fixing would only delay that. Bug fixing is important but it can't arrest development in favor of infinitely bogging the project down in fixing systems that might not even exist in a few more updates. Right now the important thing is keeping the game fixed enough to be playable and fun while moving toward the future.

[YetAnotherStupidDorf]

Toady's schedule: new features release, "new bugs" bugfixing release, "old bugs" bugfixing release. It is perfecct - it advances this alpha stage game while letting it to be playable.

you have to remember that for every update he's doing 2 bug fix releases, so he's literally doing twice as much bug fixing as updating and you want him to do more?

Yes. Feature creep (like whole undead&werewhatevers mini-arc) does not get its own release and bugfix release, rendering whole "release, bugfix, release, bugfix" business menaningless.

[Kilroy the Grand]

I wonder with the new interaction system, if I could mod in an item to give my adventurer temporary stone skin?

[Miuramir]

I cut out breeding vampires since I didn't want to deal with it for this release, but I know it's a popular thing to have mixed-breed vampire slayers and that sort of thing, so it'll probably happen at some point.

Sir, I'd be eternally grateful if you pushed the half-vampire vamp slayers to sometime post version 1.00
No, really.
It's not dorfy.
Please don't.
Sir.

I don't see why the South Slavic / Balkan traditions of how vampires function and behave are any less relevant than other historical regional beliefs on vampires.  The dhampir is technically the child of a vampire father and a human mother, but the term has become more general to include various other half-breed combinations.  Originally they were most commonly the result of a vampire returning to a woman they were attracted to in life; this is a classic folklore motif and is a good starting point for interesting plots; it should fit well into DF's Night Creature framework.  The belief that they have many of the powers of the vampire without some of the limitations makes for both dangerous foes and interesting adventure PC possibilities.  Given DF's procedural framework, the mix of bonuses and penalties they cross-inherit may be at least somewhat randomized, making them potentially tricky foes as well. 

[TheSlimeGod]

I'd by worried that the game would make auto-eat either dangerous foods or things that you want to keep, such as seeds.  In fact, I'm pretty sure that the game will never be smart enough to avoid auto-eating the foods the players want to keep, especially if you consider all the weird stuff people could mod (would the player prefer to eat the root that makes them go berserk, or the berries that make them turn into a ghost for an hour?).  I'm hoping there's some sort of interface so that we can forbid things... I'd hate to learn my character ran out of water and auto-drank some vampire blood...

Could certain basic foods be fitted with some kind of tag that identifies them as safe to automatically consume while other edibles that may be valuable could be eaten manually?  That way, if you ran out of basic foods to eat while fast-travelling the game could alert you to the fact and you would have to decide to eat part (or all) of your precious cargo until you could restock.  Or you could greedily press on and potentially die of starvation ...


This game and Toady's continuing vision for it still make my jaw drop.  Thanks Toady!

[G-Flex]

There is a significant difference between "fixing a bug" and "replacing a placeholder with the fully-feature" in a game like DF.

That's true. There are still plenty of bugs and issues that fall into either category, and a lot of "placeholders" could be replaced with a fleshed-out, less-problematic version with not much cost now or in the future.

I do not personally believe in implementing features that do not work properly, and then leaving them working improperly for years.

As per the add vs fix debate, you have to remember that for every update he's doing 2 bug fix releases, so he's literally doing twice as much bug fixing as updating and you want him to do more? The problem with that is that df is already relatively slow to add new content (or at least release this new content) and adding more bug fixing would only delay that. Bug fixing is important but it can't arrest development in favor of infinitely bogging the project down in fixing systems that might not even exist in a few more updates. Right now the important thing is keeping the game fixed enough to be playable and fun while moving toward the future.

You can't measure effort in number of releases; that's just silly and absurd. You also can't measure need that way.

You're also making the fairly typical excuses. Yes, it's true that sometimes it's not worth fixing something up past a certain degree because those systems may be replaced. This is not an excuse you can use against any suggestion that more bugfixing or polishing be done. The fact remains that there are plenty of changes and fixes that could be done now, wouldn't really take much time (such as simple raw value problems, to provide the most obvious example), and involve systems that were just implemented and wouldn't likely be replaced any time soon at all.

In my opinion, what would "infinitely bog the project down" is the continuous implementation of new features on top of new features when the previous "new features" don't actually work right, or have too many problems to reliably produce the correct results.

[Neonivek]

It'll have to be balanced out, whatever it is, or else the world gen has to stop some short period before a known date sensitive calamity is going to happen.  Then I think I mentioned before that heading toward an apocalypse is fine, and non-date sensitive ones are fine as well.  It just has to be fun.  If world gen ends up with too many rejects after doing several hundred years, that would be horrible.  If a post-apocalypse world is playable and not all that common, then that's okay as well.  It should be difficult to kill absolutely everybody without blowing up the world, and worlds with small isolated groups of humans clinging to life are cool, if a bit limited

Thank you for your answer Toady

Though I meant more about not removing a creature's (or situation's) inherant world ending potential because people will have means to prevent that from ever happening.

For example a Vampire who infects people with a touch (or something) could end the world because he is relatively unharmed by the populous at large. If the game however gave a form of consciousness to the people so that they could counter such a uprising by that vampire then maybe you wouldn't have to nerf it. Even if that means a town may end up being populated entirely by vampires.

Or a civilisation of super expansionists with great technology and powerful patrons looking over them possibly forcing everyone else to team up on that power.

Or rather the ability for others to recognise a threat and manuver against it.

Not sure how I translate that into a question though to reask Toady.

[piecewise]

There is a significant difference between "fixing a bug" and "replacing a placeholder with the fully-feature" in a game like DF.

That's true. There are still plenty of bugs and issues that fall into either category, and a lot of "placeholders" could be replaced with a fleshed-out, less-problematic version with not much cost now or in the future.

I do not personally believe in implementing features that do not work properly, and then leaving them working improperly for years.

As per the add vs fix debate, you have to remember that for every update he's doing 2 bug fix releases, so he's literally doing twice as much bug fixing as updating and you want him to do more? The problem with that is that df is already relatively slow to add new content (or at least release this new content) and adding more bug fixing would only delay that. Bug fixing is important but it can't arrest development in favor of infinitely bogging the project down in fixing systems that might not even exist in a few more updates. Right now the important thing is keeping the game fixed enough to be playable and fun while moving toward the future.

You can't measure effort in number of releases; that's just silly and absurd. You also can't measure need that way.

You're also making the fairly typical excuses. Yes, it's true that sometimes it's not worth fixing something up past a certain degree because those systems may be replaced. This is not an excuse you can use against any suggestion that more bugfixing or polishing be done. The fact remains that there are plenty of changes and fixes that could be done now, wouldn't really take much time (such as simple raw value problems, to provide the most obvious example), and involve systems that were just implemented and wouldn't likely be replaced any time soon at all.

In my opinion, what would "infinitely bog the project down" is the continuous implementation of new features on top of new features when the previous "new features" don't actually work right, or have too many problems to reliably produce the correct results.

1. If there are easy, raw based fixes that you really want to be done, then go do them yourself.
2. I did not say that no bug fixing or polishing should be done, just that there is a great deal being done already and that calling for a halt in development in favor of pure bug fixing isn't the best idea. New features keep people interested, keep donations coming and expand the game as a whole. The important thing is to not do too much of either. Personally, it all seems to be going right for now.
3.In the end, because neither of us really know about how the inner workings of the game, so it's probably better to trust toady's scheduling.

[Nivim]

Could certain basic foods be fitted with some kind of tag that identifies them as safe to automatically consume while other edibles that may be valuable could be eaten manually?

You could go a step further and give adventurers more general forbid or use options, similar in system to fortress mode, that will apply to everything normally happening automatically. Such as auto-burning torch/lamp oil or not when travelling at night, or auto-changing wound dressings and applying herbs at every meal.

[Kay12]

3.In the end, because neither of us really know about how the inner workings of the game, so it's probably better to trust toady's scheduling.

I find this one a fair argument. However, I still consider that requesting bugs to be fixed is just as fair as requesting certain new features. Toady may accept, Toady may decline, Toady may not even notice, but heck, at least I got to have my voice heard.

[G-Flex]

1. If there are easy, raw based fixes that you really want to be done, then go do them yourself.

Er, that kind of misses the point. Yeah, there are some things that modders can fix, but why should they have do? Easy fixes should be incorporated into the game itself. There are also a lot of things that are doubtless trivial but that aren't reparable by modders, like the mishaps with grazing animal metabolism.

2. I did not say that no bug fixing or polishing should be done, just that there is a great deal being done already and that calling for a halt in development in favor of pure bug fixing isn't the best idea. New features keep people interested, keep donations coming and expand the game as a whole. The important thing is to not do too much of either. Personally, it all seems to be going right for now.

I would agree, but there are enough significant problems with enough of the newer systems that I find the current model unsustainable, as it doesn't give me much hope that those problems will actually be fixed. The ratio of problems fixed to new problems created seems too low to me. Maybe Toady's just thinking more long-term, and these things will be sorted out as part of a much more significant fixer-upper release cycle a little while from now, but I don't want to assume that, nor do I think it's necessarily the smartest way to go.

3.In the end, because neither of us really know about how the inner workings of the game, so it's probably better to trust toady's scheduling.

Why? I mean, there's a bit of a point here, but I'm talking about fairly fundamental development practices that don't have a whole lot to do with particular implementations of things, and some of the stuff I mentioned is fairly easy to fix. At any rate, I can only judge based on what I see, and I see a lot of recently-implemented subsystems with flaws ranging from trivial to bizarre to fundamental and important, and I get a little discouraged when those things linger for what is very many months now. There's really no other way to feel when you see bug tracker reports (my own or otherwise) relating to a new feature sit for a year or more without further comment.