Bay 12 Games Forum

The OP brings up some very valid points and people "used" to the gameplay of DF (those who have devised strategies to circumvent the game's problems) really shouldn't criticize those points too much.

Here's a few suggestions which would alleviate some of these issues:

1. Passive animals shouldn't scare off dwarves.

2. When more dangerous animals scare dwarves, perhaps the warning message should be reworded to something like, "Dwarf B was intimidated by a Wolf".  Might make it feel more like a gameplay mechanic and less like a programmatic error message (which is what it is, but the point here is that games need to feel like games, not like software    ).  If a new player wishes to set this threshold high enough to ignore wolves, and consequently gets his dwarves killed, then that was his choice and he paid for it.

Then again, adding yet another option buried inside a menu isn't exactly the best way to help new players.  New players are already going to be overwhelmed by depth combined with the lack of explanation of how things work.

3. Perhaps there should be global orders of whether dwarves should completely ignore wildlife.  Or to give players even more control, rate each animal on a scale of 1 (harmless) to 4 (dangerous and aggressive) and let players choose what threshold of animal to ignore.

4. It might also be nice to let players "Look" (K) at creatures and determine their vague strength, so that players get more of a feel for how powerful the wildlife actually is.  Again, a simple scale of 1-4 or so; you won't be sure exactly how powerful an animal is, but you'll know not to touch that pack of wolves til a bit later.

5. Maybe consider some way of forcing an early attack upon the player (and on easy maps have it be very easy).  A disgruntled hermit, a band of wolves, or a weak goblin would slowly march towards the fortress and fight, with a little pre-fight notification that the attack is incoming, and perhaps a little advice on which workshop is most likely to yield some early weapons to help stave off the attack.  Just something to help smooth out gameplay flow and gradually introduce the player to the combat/equipment aspects of the game.

quote:

---

Originally posted by mickel:
<STRONG>"Katana" is a fun, exciting name? </STRONG>

---

Yes, the proper name for any weapon is far more interesting sounding than using some bland description as a name.

quote:

---

Originally posted by mickel:
<STRONG>Frankly I don't see why the dwarves would mysteriously aquire the japanese name for the weapon the instant they picked one up rather than make up a name of their own if they didn't already have one.</STRONG>

---

As I stated in my first post of the thread, all of the variant names could exist in the game (as many as Toady wants to add.)  The descriptions and gameplay would be the same, but the names would be varied for flavor purposes.

Because you'll fight all of these various opponents and they'll be unique and varied because of the different names - first you'll fight a middle eastern warrior wielding a scimitar, then you'll fight a samurai wielding a katana, then you'll fight some other variant from another culture.

Point being: it's more interesting to fight varied, interesting opponents whose weaponry seems unique, than to fight a bunch of cloned opponents who all wield the exact same poorly-named weaponry.

Sure, the dwarves themselves wouldn't produce scimitars or katanas - they'd produce their own unique blend of one-edged sword that would be called something else.  But that doesn't mean scimitars or katanas can't exist somewhere within the world to give it more variety.

So when you loot a sword and equip it, what name are you seeing?  A fun, exciting name like "Katana"? Or an entirely uninteresting description like "Gimli equips long single-edged sword."

Providing a description for items is an excellent idea.  Renaming them all to descriptive names is boring.

In the case of multiple real-world countries having two separate names for the same type of sword, both names could still exist - giving the player an impression of the unique visual appearance associated with the weapon in each real-world countries - but the description of the item and its gameplay functionality would be identical.

Specifically regarding the "What's a Yumi?" comment made earlier in the thread, I just finished up work on a game involving Yumis.  Apparently it's simply the Japanese term for bow (http://en.wikipedia.org/wiki/Yumi).

Using the Yumi as an example of my previous suggestion it would coexist alongside standard Bows, being functionally identical and described but perhaps noting the unique trait of Yumis in that the place where the bow is held is slightly different; this would just be flavor text and have no impact on gameplay.

Although if bows are divided into longbows and shortbows, you'd use the Japanese equivalents which according to the wiki page would be daikyu and hankyu.

Anyone who can do digital art can do sprites.  It's not a lost art because it's the same basic thing as every other form of 2D art out there.

By that definition I work about 50 feet away from 10+ people who could do such a thing.  I doubt any of them have heard of Dwarf Fortress though, and I don't really know any of them well enough to ask

quote:

---

Originally posted by Deathworks:
<STRONG>So, food and basic industry needs another 96 - 101 graphics. So, currently we have a time scale of 640 - 990 hours.
</STRONG>

---

6-10 hours per sprite is unreasonable without defining exactly what it is that's being accomplished by the artist.

I would put it more at 30 minutes average, for an average artist to create a simple sprite.  This would include the creative brainstorming time required to figure out how to make the sprite communicate what the unit/structure is in a very clear way.  Sprites are tiny pictures, and an average artist can churn them out extremely fast.

6-10 hours is enough for a decent 3D artist to churn out a simple 3D model and texture.  (animations would perhaps take longer, but would also be shared among many units.)

quote:

---

Originally posted by Eagle of Fire:
<STRONG>
Yes, I know. But some players think that's a good thing because it keeps the player population mature and with a decent behavior. I'm one of those players. Anyways, those same persons who shun this game because there is no graphics are, in the biggest part, people who think that a game must first and foremost have good graphic, and everything else is bonus. I'd really hate to see DF go that road, it would totaly kill the game appeal. At least to me</STRONG>

---

Actually the community's maturity is more the fault of the game's usability being horrible.  So only relatively intelligent players figure it out and stick with the game.

I've seen other communities form up around poor-usability games much the same way; like attempting to hook up for a multiplayer game of Total Annihilation via a chatroom in mIRC.  It was a fairly arcane process, which filtered out all but the more intelligent players, which resulted in a smart community.

But if the intention of the game is to provide fun to players, then poor usability is a bad thing and should be addressed.

Usability in this case is defined as the ease of use; how easy it is to learn the game's concepts and play the game.  I think the OP misused the term a bit in relation to his comments about being able to change video resolution (a suggestion which would certainly make the game better; if you could see a larger breadth of stuff at once.)

The only concern is that the different workshops were presumably shaped differently for a reason (making them slightly more interesting to place since they're not all the same.)  If we were able to rotate them that'd make it even less important and possibly call into question why the buildings are different at all (the only reason left would be so that they can be told apart visually; which is actually yet another reason rotating workshops might not be a great idea - it might make it that much more difficult to tell what is what.)

quote:

---

Originally posted by Aquillion:
<STRONG>At most, we need exactly one hard-and-fast rule:

1.  Don't be stupid.</STRONG>

---

The problem with this methodology is:

1. Everyone who isn't stupid already isn't stupid, so the advice is useless.
2. Everyone who is stupid doesn't know how not to be stupid...because they're stupid.

As for "Dealing with massive posts", in most cases you can spend time simplifying your post down to its core concepts.  When presenting an idea, too much information is often a bad thing.  Keep it short, allow people to respond, and then develop the idea further if you have more to add (it's good to have thought of such details ahead of time.)  Or at least have a single summary paragraph before launching into the longwinded description.

If a design concept can't be described in a concise manner, then it's unnecessarily complex.  Gameplay depth should come from the interaction of a lot of simple-to-understand systems, rather than making things inordinately complicated.

The only exceptions are things which are invisible to the user. For example, it's okay for pathfinding routines to be complex because from the user's standpoint all they see is "Dwarves move from Point A to Point B."

I suppose most ideas involve some of both.  For example if I suggested "Dwarf Fortress should have rogues which sneak into the player's fortress and steal things"  I could easily go into a longwinded explanation of exactly how these rogues handle locked doors, circumvent traps, how they choose what treasures to steal, how to handle evasion of authorities, where to drag the bodies, etc, etc.  But most of these things are invisible to the player, who only knows there's some bastard ascii "R" sneaking around his fortress stealing crap (which is a simple concept.)

[ August 09, 2007: Message edited by: Axehilt_VuP ]