Print

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

[Jiri Petru]

...

and

[[ Include a option to save custom uniforms and schedules.

...

And stockpiles. Everyone makes special stockpiles to hold cookable/brewable items, over and over again.

Instead of allowing their export/import, it would be much better to have all the useful stockpiles in the game by default. If 90 % people need to customise their stockpile settings to make specialised "seed stockpiles" or whatever, why not have them pre-packed in the game? This rule could be applied to most parts of DF interface.

Of course I have nothing against export/import, it's very useful as a complementary tool. But it shouldn't replace good default settings.

[Ullallulloo]

For the interface, if Toady would let 3rd-party apps send basic commands, it'd do for the general interface to let everybody be happy.

[zwei]

...

and

[[ Include a option to save custom uniforms and schedules.

...

And stockpiles. Everyone makes special stockpiles to hold cookable/brewable items, over and over again.

Instead of allowing their export/import, it would be much better to have all the useful stockpiles in the game by default. If 90 % people need to customise their stockpile settings to make specialised "seed stockpiles" or whatever, why not have them pre-packed in the game? This rule could be applied to most parts of DF interface.

Of course I have nothing against export/import, it's very useful as a complementary tool. But it shouldn't replace good default settings.

Better defaults would be more than welcome, but this kind of thing could become very cluttering (still better than checking wiki whether valley herb can be cooked or not, of course.)

Another take on this would be to select reaction as template for stockpile: "Mill plants" reaction applied on stockpile would result in stockpile that takes apropriate plants and bags.

[therahedwig]

Okay, I don't have fancy graphics to show but how about this:

dynamic hud that can be modified to the player's content, and of which the layout will be able to be put into profiles similar to the embark profile, with a text file to go with it. When you start a new fortress, you can pick a profile to play with.(I'm mostly thinking allowing the player to sort the game commands. If one should want to get to the construction menu, one should be able to press whatever key they assigned to it and get to it quickly. With the command and relevant key showing up on the list)

Advantages: People will be able to customise the interface to their own taste AND share it with eachother.
New items should be easy to integrate into a well-designed system.
Could allow for newbie interfaces which have dig, chop, and build still and similar vitals on the top menu, which'll help them with starting out(I'm thinking of my own experience where I was confused over why the game didn't let me build anything and why I couldn't find the dig-command even though everyone said this game was about digging).

Disadvantages: Probly a hell to code.
If the system is badly designed, we will get the 'depend on third party'  problem that Toady dislikes so much.(badly designed being 'so intricate that only the modders actually know what they are doing' and 'each release will break the previous release's profiles)

- Someone who, ironically, got these ideas from screwing with programs like Maya and Photoshop.

[Jiri Petru]

therahedwig: while not a bad idea, it would most probably end ind this scenario: "modders" start to release their own interfaces, and soon one or two will become dominant and the others get discontinued. One year down the line, there are two UI packs and everyone is dependent on their creators, Modder A and Modder B. Whenever Toady releases a new game version, there are hundreds of people lobbying A and B to release an update.... A and B eventually burn out, and since no one else bothered to keep niché UI packs updated, players suddenly have to go back to the default game...

...which of course has as user unfriendly UI as ever, and for most of the audience it remains unplayable without external tools.

Basically, what I'm saying is that I think usability should go before customisability, not the other way around.

EDIT: But I don't mean to argue about it because don't think it really matters for the purposes of this thread. The goal is to gather some ideas and suggestions for a better interface, whether it'll be coded by Toady or my modders.

[Lord Shonus]

Actually, it should be power>Usablilty>customizability, but your point stil stands.

[therahedwig]

therahedwig: while not a bad idea, it would most probably end ind this scenario: "modders" start to release their own interfaces, and soon one or two will become dominant and the others get discontinued. One year down the line, there are two UI packs and everyone is dependent on their creators, Modder A and Modder B. Whenever Toady releases a new game version, there are hundreds of people lobbying A and B to release an update.... A and B eventually burn out, and since no one else bothered to keep niché UI packs updated, players suddenly have to go back to the default game...

...which of course has as user unfriendly UI as ever, and for most of the audience it remains unplayable without external tools.

Basically, what I'm saying is that I think usability should go before customisability, not the other way around.

EDIT: But I don't mean to argue about it because don't think it really matters for the purposes of this thread. The goal is to gather some ideas and suggestions for a better interface, whether it'll be coded by Toady or my modders.

That's why I said that'll only work if it's well-designed.

A well designed system would think ahead about future implements, and WON'T break whenever a new item is added.
So that, if such a system is made in 0.4, then interfaces made with it should still work in 1.0 and backwards.

Ideally the program would check if it recognises the commands, and if not just removes them. If new items are missing, it'll try to add them with default configuration, as long as the default configuration doesn't clash with the existing customised configuration(And then, ideally, the game would try to modify the configuration till it doesn't clash). Finally, the configurations should be able to be edited both in-game and out-game. This way, it'll be the domain of the people who play the game, instead of people who mod the game.

Come to think fo it, when doing this, it might also be best to consider 'protected' interface, like, for example the interface configuration menus themselves. Afterall, you wouldn't want to lock someone out of reaching those. So it's best that those kind of things can't be edited.

This way people won't have to wait for updated versions, they just can go into the game, think to themselves 'I don't like how the new interface items are placed' then just hit whatever key is hardcoded into opening the interface config menu, and edits it themselves.

So in the end it's usability makes customisabillity inceases usability.
My main reasoning with why this would work is similar to my inspiration(image editing software)'s reasoning: because hugely different players play DF differently. One is a trapsperson, the other a militarist, the next one a pacifist, a butcher, an architect... Each of them would have a different ideal interface and should be able to atain one by themselves without much knowledge.

[Jiri Petru]

An interesting article on obscure interfaces:

A Battle Lost through Attrition by peterb

It discusses wargames but I think we can safely say DF is at least as complex as a typical wargame. Many interface lessons from that article apply to DF.

EDIT: Plus adding a quote from one of his other articles (the rest of which isn't that much relevant).

Richness is Good, Complexity is Bad

If you’ve ever been involved in designing and implementing software, you’ve participated in the following conversation. Two engineers will disagree about some aspect of how the product should work. Implementing either behavior is easy. Both engineers will present their arguments, and are convinced of the rightness of their position. Neither can convince the other. Eventually — perhaps to avoid further conflict, perhaps just to get the issue behind them — someone will suggest “I’ve got an idea. How about we just put a knob on the product, and let the user decide which behavior they get.”

This is almost always the wrong decision. But often, if all of the engineers are young and inexperienced, and there’s no one around to issue a smackdown, knobs like this make it into the final product. The product is made uglier and more complex, the end user is presented with choices that she doesn’t care about, and you sell fewer units.

A game is rich when it presents you with a lot of interesting choices to make. A game is complex when it presents you with choices that you don’t care about, or when the mechanics of making those choices are intrusive. (...)

[NW_Kohaku]

Heh, I remember once purchasing a game called "The Operational Art of War", and getting kind of excited by the really thick manual.  It had about thirty pages of just charts on the stats of the different tanks that took place in World War 2 era battles, and different upgrades and variants that were put on the tanks.

Then you start playing the game, and realize that all you control are little tokens that represent collections of 200 tanks at a time, and all you can really do is take your giant stack of tokens, and mash them into the stack of tokens of your opponent.  All that supposed detail in the units, but you can't even separate the infantry from the tanks or tell one tank apart from another.

It wasn't very good.  It was so focused on being historically accurate that I couldn't find many real ways to seriously alter the outcomes of the battle other than just not fighting.

[Jiri Petru]

While I appreciate you popping in and sharing your experience with wargames, Kohaku, I'm a bit confused.  Was this supposed to be a part of the interface argument, or just a side story? (I'm fine with the latter, I just want to be sure I'm not missing something.)

[NW_Kohaku]

Side story, mostly, although I'm sure you can infer something from the mistakes of others, which would have been the point of those articles you posted earlier.

I'm thinking about the way in which the "army arc" interface will be implimented, among other things, and drumming up my own argument on the matter, and this thread went and brought that back up.

[Lord Shonus]

Heh, I remember once purchasing a game called "The Operational Art of War", and getting kind of excited by the really thick manual.  It had about thirty pages of just charts on the stats of the different tanks that took place in World War 2 era battles, and different upgrades and variants that were put on the tanks.

Then you start playing the game, and realize that all you control are little tokens that represent collections of 200 tanks at a time, and all you can really do is take your giant stack of tokens, and mash them into the stack of tokens of your opponent.  All that supposed detail in the units, but you can't even separate the infantry from the tanks or tell one tank apart from another.

It wasn't very good.  It was so focused on being historically accurate that I couldn't find many real ways to seriously alter the outcomes of the battle other than just not fighting.

If you like that kind of detail, try WinSPWW2 (Windows Steel Panthers - WWII edition). It's a free individual-vehicle/squad wargame. There's also a "modern" variant.

[NW_Kohaku]

Thanks, but I have too many games I'm already leaving to rot in my "to play" pile because of DF.

[Draco18s]

Thanks, but I have too many games I'm already leaving to rot in my "to play" pile because of DF.

DF is in my "to play" pile rotting. >.>
'tis a shame, but I'm sure when the new animals come out I'll pick it up again.
Last version didn't really have anything "new" for me to play with.

[NW_Kohaku]

I kind of hate waiting on new versions, though.  When the new version comes out, you're going to have to wait for the bugfixes for whatever new wacky crash will be put in with the new stuff.  I actually kind of like just going back to my big 40d fortress, and watching the little antfarm run more than trying to have to keep up with all these updates, and having to reset all the init files every few weeks.

Trying to keep all my mods current to the new version makes me cry, so I often just play the older, buggier versions (or 40d), rather than update.

Pottery will be too irresistable for me, though.  I'll have to do it, but I'll wait for a week or so after it comes out for the inevitable bugfix version that comes afterwards.