Post by: Jiri Petru on April 29, 2009, 05:33:18 pm
This thread is a repository of ideas and proposals for the improvement of interface. You'll find a lot of different things from different people here, the idea was to provide a fountain of inspiration for Toady to choose from. Please join us with your own proposals or at least comment on the things prepared by others.
Some of the interface ideas here require massive changes in the game (full mouse support, simple graphics, resizable menus), others are mostly little tweaks focused on quick realisation and ease of modification.
Have fun!
Disclaimer: I'd like to keep this topic focused on technical aspects of the interface itself - like what functions to include or not, where to place them, whether to have the mouse as a mandatory control, etc. If you'd like to discuss accompanying stuff like "Toady should do the interface himself/Toady should outsource it" or "The interface is/isn't a priority", please do it in a separate thread to keep this thread useful and free of flames.
Also, when the external voting gets reset I'll put Total Interface Overhaul there and ask you for your support. ;)
Suggestions repository
These are links to interface proposals by users. Please note that I'm only linking to "major" posts (basically posts with pictures). There is a lot of valuable talk and suggestions between them, and I suggest reading the whole topic.
General Interface
- by Jiri Petru: More advanced and harder to do (http://www.bay12games.com/forum/index.php?topic=34949.msg534386#msg534386) or a basic, text-based Interface (http://www.bay12forums.com/smf/index.php?topic=34949.msg1316771#msg1316771) focused only at the worst evils
- by juanoleso: the original (http://www.bay12games.com/forum/index.php?topic=34949.msg535781#msg535781), an improved version (http://www.bay12games.com/forum/index.php?topic=34949.msg554573#msg554573)
- by zwei: original (http://www.bay12games.com/forum/index.php?topic=34949.msg943176#msg943176), take two (http://www.bay12games.com/forum/index.php?topic=34949.msg944220#msg944220), take three with nothing selected (http://www.bay12games.com/forum/index.php?topic=34949.msg975763#msg975763)
- by ed boy (http://www.bay12games.com/forum/index.php?topic=34949.msg949590#msg949590)
- by robolee a grid-based interface (http://www.bay12forums.com/smf/index.php?topic=34949.msg1325694#msg1325694)
- by GenericContainer: Animation of an entirely mouse-based interface in Goblin Camp (http://www.youtube.com/watch?v=mm-dPes5NgE&feature=youtu.be) (external link but brilliant)
The Many Menus
The game menus could use some streamlining, features could be rearranged, some menus merged, items swapped, etc. The are suggestions about the menus:
- Rearranging items in menus (http://www.bay12games.com/forum/index.php?topic=34949.msg534390#msg534390) by Jiri Petru
- Rearranging items in menus (http://www.bay12games.com/forum/index.php?topic=34949.msg535252#msg535252),by Silverionmox
- Workshop menu (http://www.bay12games.com/forum/index.php?topic=34949.msg944220#msg944220) by zwei
- Building stuff (http://www.bay12games.com/forum/index.php?topic=34949.msg962483#msg962483) by zwei
Other Screens
Dwarf Fortress has a lot of other screens aside from the main game windows. These are suggestions for these:
- Embark screen and Dwarf details (http://www.bay12games.com/forum/index.php?topic=34949.msg944288#msg944288) by zwei; another Embark screen (http://www.bay12games.com/forum/index.php?topic=34949.msg945868#msg945868) by zwei
- Minimap (http://www.bay12games.com/forum/index.php?topic=34949.msg975763#msg975763) by zwei
- Military screen (http://www.bay12forums.com/smf/index.php?topic=34949.msg1144846#msg1144846) by zwei
- Job management (http://www.bay12forums.com/smf/index.php?topic=53113.0) (aka Dwarf Foreman) by Valdemar (separate thread)
- Standing Production Orders in Goblin Camp (http://www.goblincamp.com/2010/06/feature-preview-the-stockmanager/) (external link)
- How to handle workshop material selection (http://www.bay12forums.com/smf/index.php?topic=34949.msg1383575#msg1383575) by Jiri Petru (read the following comments too)
Misc
- Screenflow (http://www.youtube.com/watch?v=rVhsIGGg3QE) (Youtube) - showing several Z-levels at once
Post by: Jiri Petru on April 29, 2009, 05:33:37 pm
For me, the single biggest problem with the original interface is that it's too chaotic. The main menu has no (apparent) system and I can't use it at all. I had to remember the shortcuts at which point the menu became useless... not a good sign. I guess the reason for the chaos is that the options aren't visually sorted. Having a visual memory, I need to have the buttons divided in differently looking groups according to functions. Important functions need to be bigger. Unimportant need to be smaller and positioned somewhere in the corner.
With this in mind, I tried to draw a simple design. My main principles were:
1. No graphics
I want the suggestion to by usable by Toady, who said he doesn't want to do graphics. Very well. I used only text and some very simple icons anyone can draw in MS Paint. Although you can't see it on my mockup below (I'm not that good at computer graphics), I imagine the game interface - the buttons, the tabs, etc. - to be in the default OS style. Eg. the game menus would look like this (http://www.jbeckj.dk/silenthunter/Docs/Guides/Sh1/Xp/SilentHunter_WindowsXP_files/VDMSoundAdvCompatibilitytab.gif) in Windows XP, like this (http://www.askdavetaylor.com/0-blog-pics/windows-vista-taskbar-start-menu-properties.png) in Vista or like this (http://dev.mysql.com/doc/refman/5.0/en/images/myodbc-macosx-odbcadmin-tracing.png) on Mac OS.
I hope it would be easy to make the interface “skinable” by fans.
2. Interface needs to be separated from the game grid
Obviously, for this to be possible, the interface needs to be separated from the game grid. It uses it's own fonts, not the game's tileset. You could for example use 16x16 tiles for the game, but Verdana size 10-12 for the interface.
3. Mouse-based interface
My design is build for mouse - and mouse interface is above all a visual interface. That means items are visually arranged so you can remember their position and click on them easily. This means that features have to be grouped by similarity, that the interface has to use different font sizes, buttons, etc.
Keyboard users could still use hotkeys for everything, I just didn't bother to include them.
This being said, here you are. The mockup is 1024x768, which is I believe the smallest resolution a computer able to run Dwarf Fortress would have ;)
Spoiler (click to show/hide)
Mouse and Selections
The mouse eliminates the need for having “k”, “v”, “q” and “t” separately. “k” is on the right mouse button. “v” and “q” are no longer needed - use your cursor instead. And I suggest to rid of the “t” altogether - the information from this screen should be displayed in the Selection View along with the “q” information. I never understood why they aren't.
Nothing in the game should require keyboard (perhaps short of adventurer movement, but that's a different story... and game mode). When you want to place a building, or designate a zone, you can use these approaches:
- Point and click - for placing things with a fixed size - for example workshops or trade depot - or placing one piece of a thing like wall or furniture
- Click and drag - for resizable things like stockpiles or bridges, and for placing many pieces of things like furniture or constructed walls.
These two approaches should be used instead of all the current systems. From the top of my head, I remember the game currently uses: point and click (furniture...), click in a corner and then to another corner (designations...), resize by UHKM (fields...), resize by using + and - (bedrooms...). All of these should be replaced.
The Many Menus
The biggest change, though, is the menu system. As you can see, I've divided the most often used functions to two menu groups. The one on the bottom I call “Build menus” - you use these whenever you want to build something. Most of their content comes from the current “b”uild and “d”esignate menus. I felt the urge to divide them to more groups, because the “b”uild menu was so chaotic I could never find anything there. Also, it had submenus. That is a big no-no. None of my build menus have submenus - everything is max. two mouse clicks away.
Aside from the current “b”uild and “d”esignate menus, I also merged stock”p”iles, “i”zones and “create a building from a furniture” to my Build Menus. More detailed explanation follows in the next post.
When you create hotkeys for these menus, I suggest using numbers (1-7 for the tabs, 0 for Destroy), not letters.
The other big menu group are the buttons in the top right corner. I call these Fullscreen Menus, because... well, they pause the game and open in fullscreen. The biggest advantage of fullscreen is that these menus can and will have their own submenus, tabs, filters, etc. This allows us to hide a lot of functions in a single menu. My inspiration came from the current “your status” menu, but I shifted the functions indefinitely.
I haven't really thought about the different Fullscreen Menus yet, nor did I create a graphical design of any of them. If you have any ideas, feel free to post them. Mockups welcomed! One example: the Jobs menu could function similarly as the Dwarf Foreman program.
When you create hotkeys for these, I suggest using the function keys (eg. F1-F6).
What's next?
Okay that was the basic overview, thanks for reading it. What's next? In the following post, I'll describe the Build Menus in some detail. I'm also working on design for Workshop Selection View and the Stocks Fullscreen Menu with the ultimate goal to automate production and get rid of production micromanagement. You can expect the result in the near future (a week or two).
Obviously, this interface proposal is far from complete. I've tried to take all of the current game's functions and buttons and give them their own place. As far as I know, I managed to place all of them expect of these two:
- Depot Access. No idea where to place it - perhaps have it as a button in the Trade Depot Selection View?
- Squads Menu. I didn't place this for two reasons: (a) I still don't know where to, and (b) the upcoming version will probably completely change the military controls.
I'm short of ideas and hope someone else could take these and build them a nice, comfy home.
You can always post your own, completely different interface, just for the sake of variety and competition!
And if you don't feel like designing screens and menus of your own, please comment on other people's creations, write your suggestions, etd. Hopefully, we will create a big and useful topic of interface suggestions for Toady to choose from.
Post by: Jiri Petru on April 29, 2009, 05:34:24 pm
At the beginning of this interface undertaking was a desire to sort the things I can build in a different order - I am still occasionally confused by the current menus and I wholeheartedly hate the “drag a building from a piece of furniture” way of making rooms. And because complaining is much easier than actually sorting the things, I decided to give it a try and come up with my own system. I ended up with these categories:
DIGGING - I though digging deserved to be separated from other designations, because it's so important for the dwarves and also often used by players. The digging menu contains everything you can carve from solid rock (and soil, and sand...)
WORK ZONES - I was looking for a better name instead of designations, which sounded weird and alien to me as a nonnative speaker, but didn't think of anything but work zones. These allow you to order dwarves to work with the environment itself without actually building anything (can't think of a better explanation :/ ). I basically took the current designations and merged them with zones - I know they work are technically a bit different, but that shouldn't prevent them from being in the same menu. I'm sure players would prefer it this way, actually. I never understood what's the deal with (eg.) Gather Plants and Collect Sand being in different menus.
ARCHITECTURE - Renamed from current Constructions to make it less confusing (I had trouble distinguishing between Buildings and Constructions). Moreover, Constructions already have their own submenu, and I didn't want to use submenus, so I had to move them to top. These are passive features that don't need to be worked. Some are similar to features you can dig out, the difference being in that you build these on empty spaces, where the rock has already been dug out.
BUILDINGS - The most important part of the fortress. Buildings are places where dwarves perform their jobs or do other tasks (like eating, sleeping or sparring). I merged rooms into buildings, because I hate the drag-me-out-of-a-furniture system so much I wish it didn't exist. Instead, if you wanted to build, for example, a bedroom you would just select an area using the click-and-drag technique and voilá, it becomes a bedroom without a bed. So yes, you'd be able to build rooms without actually using the appropriate furniture. Now it can work in any of these two ways:
- The building isn't functional until you place the needed furniture in it. It is still there, you can select it, etc., but dwarves won't use it yet.
- The building can function even without the furniture at the cost of bad thoughts. Dwarves would sleep on bedroom floors, eat on dining room floors or work on office floors... and they would complain about it. If the room has an owner, the owner could buy furniture and move it in on his own! (this would require a furniture shop).
FURNITURE - Moved away from the buildings menu because... well... it isn't buildings. Furniture is furniture, no further explanation needed. To reduce micromanagement, I suggest you allow players to place furniture even if it isn't on stock. The manager would then automatically order the production of needed furniture (using stone if possible). The same could be applied even on other buildables...
MACHINERY - Currently the machinery is scattered all around different submenus. I thought it would be nice to have it all together. Machinery are machines, mechanisms, gears, automations and similar creations.
That's for the introduction. Here's how I divided everything up:
Spoiler (click to show/hide)
Notes
Stockpiles menu not included, because I don't have any changes for it.
Everything is sorted alphabetically, save some exceptions. When I wanted two or more thing to stick together, I gave them the same prefix (like “Stairs:” or “Workshop:”).
The colors are only for the mockup's sake, they aren't intended to be used in-game.
- Blue items are just highlighted, because I moved them from other menus and for some reason wanted to point them out.
- Red items are duplicates. Sometimes I wasn't sure where to put an item, or the item fit into two separate categories. There's no reason why single item couldn't be included in two menus, right? This is a good way how to prevent confusion and aid players in finding things.
- Green items have some special notes. See the following text.
DIGGING - “Mine” is separated from the others and not sorted alphabetically, because I wanted to have it on top. It should be selected by default when you open this menu.
WORK ZONES - The list was too cluttered, so I separated it to two lists with the “metagame” selections below. This is not a submenu! The special items should be included in the same menu as the former ones, only separated by an empty space, header or column break.
Chop Down Trees and Collect Sand and Gather Plants: could these perhaps work the same way as fishing does? Carpenters and Herbalist would automatically cut trees and gather plants anywhere, unless you tell them to use only a specified area (and if they exhaust it, they won't work outside of it). The same goes for Collect Sand, only that it wouldn't be done automatically - you'd have to order a certain number of sand bags. The reason for these changes is less micromanagement - I'm tired of designating trees to be cut.
Farm Plots are moved from Buildings. I know they are technically a building but for some reason I always looked for them in the designate menu. And farming someone associates with tree cutting and plant gathering in my head. Alternatively, farms could be duplicated both here and in the Buildings menu.
Garbage Dump is a duplicate entry of a Refuse Stockpile. I thought it would be nice to have the refuse pile duplicated here to help new users and point it out. It is a bit more “special” than other stockpiles, right?
Pits and Ponds. I seperated these to avoid submenus.
ACHITECTURE - I believe the list is self-explaining. Pillar is a suggested renaming from Support. I don't know why, I just like it better. Feel free to ignore me.
Bars are duplicates from furniture. I don't know... I was afraid players could look for them here even though they are furniture.
BUILDINGS - You can see many former “rooms” here, as I've explained above. Workshops are in two columns, because they didn't fit into the screenshot. Don't look for any ingame consequences in it.
FURNITURE - I separated Containers to Bags and Chests because I hated the former arrangement. I only wanted to place chests and bags kept interfering. The same goes for Chains and Ropes, except I didn't hate those and wouldn't mind if they are kept together :p
I suggest renaming Seat to Chair because it sounds more obvious (on the other hand, it is too similar to ”chain”, so I'm not sure). I also suggest renaming Burial Receptable to Coffin because the former always confused my.
MACHINERY - Not much to explain here. I duplicated Workshop: Millstone here, because I thought someone could look for it under Machinery.
And that's it!
The Build Menu Mockup
OK now, how would this look ingame? Taking Buildings menu as an example, I did this mockup:
(http://rpgforum.cz/temp/03_build_menu.png)
As you can see, I used some icons to ease the orientation for people with photographic memory. The icons also make the menu look cooler :) You can color-code them according to some key (never mind my colors), so related buildings would have the same color. Although this is the Buildings menu, I think you can come up with icons for digging, designations, etc. just as easily.
The icons should use the same tiles as the game display (for example Loom uses the Pig Tail tile and Trade Depot uses the Coin tile), so whenever you change tileset, the icons change too! I'm not sure how to handle tilesets of different sizes - perhaps the game could resize the tiles for icons? (I suggest defaulting the icons to 16x16 px).
The red arrow indicates there's more options hidden. When you click it, it scrolls one column to the right or vice versa.
The popup was a last minute idea to make the game easier for new players. You hold the cursor steady for a second or two, the popup pops up. These short help texts could - and perhaps should - predate full-fledged ingame Help or Dwarfopaedia.
----------------------
And that's about it from me. Thanks for your patience. I'm looking forward for your comments, suggestions and own mockups!
Cheers.
Post by: Impaler[WrG] on April 29, 2009, 06:44:13 pm
Post by: Footkerchief on April 29, 2009, 09:35:38 pm
The right-click context menu seems inherently problematic. In other games, generally the screen area of a unit/building/whatever is roughly on par with the screen area of a context menu. But in DF the menu could easily block hundreds of tiles from view. This seems like it could get really obnoxious and frustrating.
The scroll arrows in the building pane are a sign that the tabs are overloaded with options. Clicking to scroll is even more unpleasant than using keys. Workshops could probably get a tab to themselves.
Your build menu groupings are interesting in that they group items on a conceptual/goal-oriented level -- the current interface groups them more from a standpoint of game mechanics, which is less intuitive in some ways but also draws more attention to the subtle differences between, say, buildings and constructions (i.e. if it was built from the buildings menu, you know that it has actual component items). On the other hand, these structures are probably all so subject to change (on both the conceptual and mechanical levels) that we shouldn't get too caught up in the particulars of what goes where. Which raises another point:
While the particular layout of a given interface is a valid concern, the ability to modify the stock interface should come first. I think it would be really premature to break out of tile-based interfaces anytime soon.
Post by: CoyoteTheClever on April 29, 2009, 11:35:59 pm
Post by: AxelDominatoR on April 30, 2009, 02:58:56 am
Why don't you try adding pie menus in? They are *really* fast to use, easy and you can organize a lot of things: http://en.wikipedia.org/wiki/Pie_menu (http://en.wikipedia.org/wiki/Pie_menu)
Post by: Jiri Petru on April 30, 2009, 03:51:54 am
Quote
1. No graphicsFixed.
I want the suggestion to by usable by Toady, who said he doesn't want to do graphics. Very well. I used only text and some very simple icons anyone can draw in MS Paint. Although you can't see it on my mockup below (I'm not that good at computer graphics), I imagine the game interface - the buttons, the tabs, etc. - to be in the default OS style. Eg. the game menus would look like this (http://www.jbeckj.dk/silenthunter/Docs/Guides/Sh1/Xp/SilentHunter_WindowsXP_files/VDMSoundAdvCompatibilitytab.gif) in Windows XP, like this (http://www.askdavetaylor.com/0-blog-pics/windows-vista-taskbar-start-menu-properties.png) in Vista or like this (http://dev.mysql.com/doc/refman/5.0/en/images/myodbc-macosx-odbcadmin-tracing.png) on Mac OS.
I'll wait for some more comments before responding.
Post by: Tormy on April 30, 2009, 07:24:20 am
Wow, this is not your average "Make it suck less!" interface suggestion. Thanks for going to the effort of making mockups etc.
Absolutely. I really like these mockups. Good job, Jiri! 8)
Post by: Davion on April 30, 2009, 07:45:38 am
I guess at some point it might be feasible to go the submenu route.
Also, I hope Toady One makes the interface skinnable because I'd be all over that.
Post by: Silverionmox on April 30, 2009, 11:02:33 am
However, I made another version, considering some disagreements of mine and this quote from Toady:
Quote from: ToadyOne
03/16/2009: As you might want to gather and treat the wounded without the benefit of tables or beds (due to resource constraints or otherwise), I went with an activity zone for the hospital. I've added a few options to activity zone placement to make that a little easier (they can overlap now, you can flow them out like rooms, and delete a single zone regardless of overlaps). This'll also be a good test for using zones for things like dynamic workshops (way) later if things go that direction, as hospital zones will need to manage several buildings. It might also be useful for some military applications for this release.
That will radically change workshop placement, so I've tried to incorporate that. And I really like the "flow out" room definition :) .
Spoiler (click to show/hide)
So the basic menus are:
* Designation: one-time actions
* Rooms & Zones: structuring the activity of the dwarves, giving permanent localized orders
* Place furniture: ready-made items placed by unskilled labour
* Constructions: items that need a bit of extra work, or complicated constructions, all using skilled labourers.
* Map view: Changing the way of displaying information
Designation:
It starts with a toggle: do you want to add or remove tags or designations? There could be a "remove all designation and tags" option too.
It starts with the classic dig. (The two other options are for later on, when ore might be dug out carelessly and fast in smaller fragments, to load them in wheelbarrows. Quarrying would then be done by mason rather than miners, and yield blocks directly - that would then also form the basis for furniture, rather than rocks.) Channel we know, remove floor might be useful at some future point if you want to do that without channeling. Carve out stairs is used so often it should have its own option; carve out furniture would require a submenu for all the possibilities, but your dwarves would probably appreciate their living room being carved from the rock itself :) .
Smooth, engrave. Decorate is an option to let the walls or floors be decorated with rugs, totems, gems, whatever. Those could have an options panel to specify what material and which decoration/image, but that's debatable. Gather plants and chop trees likewise could have an options panel for the selective harvesters.
Deconstruct should be fitted in here also (ed.).
All the tags are for items rather than the terrain or parts of it. Trading is meant for trade goods, decoration is meant to control which items are decorated. Upgrade and removal are intended for furniture, to remove or improve those first outdated bedrooms.
Rooms & zones:
According to the quote, these will hopefully blend together in the future, giving a lot more flexibility. It starts with the selection types: flow out is like designate from furniture, except that you pick a location instead. So it's no longer necessary to wait for Urist Lazyass to install that bed. Corner to corner is the somewhat limited way, to be augmented by adding or cutting sections.
These rooms/zones will be the basic control of activity, so they'll encompass private quarters, workshops, work zones like farm plots, sand collection, fish zones, meeting halls etc. etc. The functions will be defined with the (q) tool: you'll be able to say which jobs can be done in the room/zone, which dwarves can use it or even access it, which skill level is required, whether crops are to be planted (and which, when etc), plants/trees to be cut/harvested, whether sand can be taken from there, etc. etc. (growing mushrooms and fletching arrows in the jail annex mechanisms storage would be possible for the place-constrained fortress) Large workshops that are a stockpile for their raw materials are a more common possibility.
That's only marginally constrained by the rooms basic type: stockpile and room are functionally the same, but stockpile is used so often it needs to have it's own entry. When you designate a zone along the edge, it only sticks along the edge. So no questions anymore about whether the fishing zone is placed right. Other functions that need an edge to be turned on with the (q) are: pit, pond, drinking, washing, oubliette, dump zone, etc. Whether there's a lower level, water, magma, or perilous depths beyond the edge, is the player's choice.
Cultivation would be more lenient in including trees, plant life and all kinds of mud when designated. It's also possible to constrain those functions (farming, woodcutting, etc.) to this type of room/zone if it clutters the (q) options too much.
Traffic is straightforward. Roads are hopefully culled, now that we can build floors en masse and designate high traffic over it. (ed.) Templates are user-defined or often-used configurations, which will be pleasant with all those options.
Furniture and construction are basically the same, with the distinction that furniture is placed ready-made by unskilled labour, and constructions require more work, like assembling components, or doing some masonry to make the edges fit, etc. The blueprint option plans it, to be filled in later (with possibly an option panel to specify which quality, material, value, etc.); place from stock gives you a menu with your stock to pick from.
Map options are some useful viewing tools.
Post by: Tahin on April 30, 2009, 03:27:56 pm
The only complaint I have is that it really should be playable entirely via keyboard. That would be simple enough to implement, actually. Just add a little [KEYHERE] thing on each button, and possibly keep the existing keyboard shortcuts in place.
The keyboard thing is a deal-breaker for me. I'd still play DF if it used a mouse-only interface, but I refuse to support this idea unless it can be used entirely with a keyboard as well, and I really don't see why it couldn't.
The only area where it could be difficult to allow keyboard and mouse use would be selecting and designating and such. I'd suggest making the mouse "light up" the tile it hovers over, and this "lit up" tile could be moved around via the numpad/arrow keys, as well.
Post by: Exponent on April 30, 2009, 05:13:13 pm
While the particular layout of a given interface is a valid concern, the ability to modify the stock interface should come first. I think it would be really premature to break out of tile-based interfaces anytime soon.
Personally, I've always found text-based interfaces to be harder to maintain, play around with, and improve compared to an ordinary window-based interface. Unless Toady has put together a really nice UI library, I would strongly recommend getting familiar with an existing GUI library (such as CEGUI (http://www.cegui.org.uk/wiki/index.php/Main_Page)). The upfront cost of learning a new library will always exist, but I would estimate that the payoff would be pretty significant. Again, this is largely because I think that it would in fact be easier to tweak a graphical UI when game mechanics change than it would to tweak a textual UI.
Of course, it's just my opinion, but I felt like it might be worthwhile to throw it out there, since the default assumption around here, that text GUIs are easier to adapt to game changes, strikes me as somewhat unusual.
Post by: Footkerchief on April 30, 2009, 05:56:06 pm
Of course, assumption 2 is just my intuition, not a fact. I could definitely be wrong.
Post by: juanoleso on April 30, 2009, 07:21:28 pm
No open windows, all windows slid closed, action window takes full precedence
Spoiler (click to show/hide)
As the mouse hovers over a small tab, the window expands (exposes clickable selectables as well as hotkeys)
Spoiler (click to show/hide)
Messages would be on the bottom separate, it would be expandable and shrinkable to whatever height is desired or hideable altogether, then also some kind of dropdown which separates the kinds of messages.
Spoiler (click to show/hide)
The stockpile menu can be tacked so it stays open and then the messages could be opened along bottom of it.
Spoiler (click to show/hide)
or the stockpile menu could be floating alongside the main window if desired so it would always be visible or could be put on a separate monitor.
Spoiler (click to show/hide)
In summary, pretty close to what Jiri's got laid out with everything being hideable. I think i like the right click idea, but I would have to see it in practice to know for sure.
Edit: The Action Window wouldn't squish and stretch like that, that is just me being a little lazy and I'm at work...
Post by: Lesconrads on May 01, 2009, 02:40:57 pm
I really like the way you presented your ideas. I totally agree, that the interface needs some rearranging and cleaning up.
But then, I came in here to really push the subject that I had horrible experiences with pie-menus. Do you know "neverwinter nights"? If so... you know the problem.
As a magician you needed to go through several circles with 9+ items until you got your spell done. Who ever did this without pausing first MUST be a master of hand-eye-coordination so that he took less than my 4 seconds to do so.
I am a little scared, that all this "mouse crap" will take the flow out of df.
We CAN use the mouse to designate areas for mining... do you do so? Neither do I. It just isn't working with all the other shortcuts where you need both hands on the keyboard. And I LOVE LOVE LOVE shortcuts.
The mouse HAS it's benefits though. When you need to "click" many things that are rather far away, it is handy.
A combination of shortcuts and mouse would be best. You might want to look at menus, that have icons with corresponding shortcuts.
Like a menue this way:
Code: [Select]
Item A ItemB ItemC
Item D ItemE ItemF
ItemG ItemH ItemI
with corresponding keysCode: [Select]
Q W E
A S D
Y X C
(of cause adjustable for those with other keyboard layouts)You get different menus but the items on the places always have the same shortcuts.
I hope you see what I wanted to say
Post by: ¿ on May 01, 2009, 03:13:43 pm
Post by: Impaler[WrG] on May 01, 2009, 08:02:38 pm
Post by: RAM on May 01, 2009, 08:40:55 pm
I suspect that some people go to some lengths to choose a font that they link, giving the option to select multiple fonts for different areas might be nice, but it complicates customisation. I guess that I feel that the interface should have the option of all being similar...
Bear in mind that the more space you devote to one display, the more you will have to intrude upon it to present others. If you have a dedicated information panel, and a dedicated option panel, then you won't need to obscure the playing area in order to do things...
But there are some good ideas there, congratulations!
Post by: AxelDominatoR on May 04, 2009, 07:56:06 am
But then, I came in here to really push the subject that I had horrible experiences with pie-menus. Do you know "neverwinter nights"? If so... you know the problem.
As a magician you needed to go through several circles with 9+ items until you got your spell done. Who ever did this without pausing first MUST be a master of hand-eye-coordination so that he took less than my 4 seconds to do so.
Oh, yes, I finished Neverwinter Nights with all expansion packs. It was an example of a bad-designed pie menu.
I was a bit biased in proposing the pie menu because I really like it if properly done ( it should never expand more than a depth level ). I was just curious to see how a pie menu would work into such a interface.
I am for all-text interfaces, by the way :) ( I'm a console and ascii-lover, nethack style! ), but I liked the design by Jiri Petru and didn't feel like discouraging.
Post by: ChJees on May 04, 2009, 11:45:44 am
Nothing more needed to be said.
Post by: Jiri Petru on May 05, 2009, 05:02:58 am
Just a little disclaimer: I know it's a long way to presentation arc. I didn't even hope this suggestion would be used any time soon. And I know many game functions and menus will still change. That being sad, all designs can be changed accordingly. Moreover, I wanted to post this before I forget everything, as I always do. :)
As for the keyboard, I did't intend to kill shortcuts. I just didn't include them, because I didn't want to bother. I'm sure you can easily come up with shortcuts for any menu, button or list item I used. Though if the menus are rearranged, you wouldn't be able to keep the current shortcuts and would have to re-memorise new ones.
Perhaps the cursor and selections (left/right clicking, click and drag, etc...) would have to remain mouse-only. Perhaps you could simulate mouse with arrow keys and some other buttons. I don't know. But once the interface is done, creating keyboard shortcuts shouldn't be a problem. It's just that I believe it's better to create a mouse-only interface first, and then build shortcuts on top of it - not the other way around.
The menus in mouse interface tend to be slower then in keyboard interface, indeed*. But the point of it isn't to be fast, it's to be intuitive, easy to use and easy to learn for new users. You basically can't use key interface until you memorise it, which is a terrible obstacle for newcomers. I believe keys should be competely optional. If you are power user, you can use them to play faster. But the point is that you don't have to.
(*) On the other hand, clicking on the map - selecting units, designating areas, cordering soldiers - is much faster with mouse.
----
Other comments, in order of appearance:
Impaler[WrG]: Sorry, can't help you. I can't program a thing. :-\
Quote from: Footkerchief
The right-click context menu seems inherently problematic. In other games, generally the screen area of a unit/building/whatever is roughly on par with the screen area of a context menu. But in DF the menu could easily block hundreds of tiles from view. This seems like it could get really obnoxious and frustrating.I'm not sure I understand. Are you saying that the right-click popup can obstruct view? Or that the big menu in the bottom is the problem? If (a) then please consider the popup only appears for a few seconds when you yourself open it. If (b)... well, the menu can be automaticaly hidden when you don' use it - the same way the menu in the current game. I've even included the button. ;)
AxelDominatoR: Right, pie menus can be cool. But I'm afraid I don't understand what do you want to use them for. ;) Can you please elaborate or even post a mockup of your own?
Silverionmox: Thanks for your suggestion on the arrangment of menus. Can you please describe how would these appear in the game? I mean, where would the buttons be, etc.? Are these intended to be used the same way as the "Build Menus" in my design?
One thing I don't like in your menus is that you always have to use one more click than necesarry. That's: (1st) click to open a menu, (2nd) click to select a mode - eg. blueprint or from stock? (3rd) click to select an actual item. I don't like the second click and would be happier if it could be somehow integrated to the 1st or 3rd one. But it's just a thought...
juanoleso: Thanks for your mockup! It seems similiar to mine, only that you moved the menus and buttons to different positions. I like it too, thanks. I take it that the menus on the top (File - Edit - View...) are simple placeholders until proper DF menus are placed, right? ::)
---
(If you feel I've forgotten about you, please raise a hand and I will react).
---
A question for everyone interested who didn't answer yet: what do you think of the menus rearrangement? (I mean moving items to differend menus, renaming them, etc.) Do you want to keep the original menus? Do you like my proposal? Do you like Silverionmox's proposal? Do you have a proposal of your own? ;)
Post by: Silverionmox on May 05, 2009, 05:39:14 am
The mutually exclusive option at the top of the colums will always have one selected by default (the last used would be practical), so that it won't need to be selected every time again.
Post by: Grax on May 05, 2009, 05:59:47 am
Keyboard commands takes MUCH less time than mouse clicking-clicking-clicking.
Post by: Footkerchief on May 05, 2009, 08:42:09 am
hodiernal
As a Latin student I'm appalled that I've never seen this word before.
Post by: AxelDominatoR on May 05, 2009, 10:24:10 am
AxelDominatoR: Right, pie menus can be cool. But I'm afraid I don't understand what do you want to use them for. ;) Can you please elaborate or even post a mockup of your own?
I'm at work so I cannot draw, right now. Maybe later I'll be able to sketch something.
I had in mind a contextual pie menu for every in-game object.
A few examples to follow:
- Clicking on a dwarf would result in labor, work dogs, soldiering, activate squad, etc to appear.
- A bed would result in just a "make bedroom".
- A building would have "deconstruct" along with other building-specific actions ( pull lever, operate pump, etc etc ).
A pie menu would be a little faster if implemented with an "one-click" operation:
- You press the mouse button and the menu appears.
- You move the pointer over option, selecting it.
- You release the button, at last, triggering the command.
That's only a rough idea, and would be most useful for frequent used actions ( pull lever, for example ).
Post by: Zangi on May 05, 2009, 11:42:46 am
Guys, your suggestions are cool. But i'm get used to hodiernal interface.Agreed here. I like how I can play DF with just the keyboard and not have to deal with the mouse and clicking on squares all the time. You know, sit back with the keyboard in a comfy position... and just play away.
Keyboard commands takes MUCH less time than mouse clicking-clicking-clicking.
Though, I would agree with the mouse being a more viable option then it is now...
Quote
My design depends on mouse. You can't use it without it. Sure, you can come up with hotkeys, but these were not a priority.
I can't agree with that sentiment... I want DF to still be fully playable with or without the mouse...
Not saying that change is bad. Its just that this forces players to use the mouse. Which doesn't sit well when the DF right now is playable with only the keyboard.
A lot of old DF players may not take well to forced drastic change like this, especially when it can be seen as someone/Toady saying 'This way is better so you shouldn't be playing the old way, deal with it'.
I don't believe I would take well to it myself...
Well either way, I wouldn't be saying this if the keyboard only way of playing is preserved or 'made better'.
Post by: Sowelu on May 05, 2009, 12:49:26 pm
And while working etc, I only use a mouse when strictly necessary.
Would adv mode require a mouse or would it be keyboard only? It would be weird if one mode was playable with only mouse (but not only keyboard), and the other mode was the other way around.
Post by: AxelDominatoR on May 05, 2009, 01:02:59 pm
That would make more players approach DF world using their preferred way of bringing dwarves to sure deat... *ahem* fame and glory! ::)
I made a comment here about the subject: http://www.bay12games.com/forum/index.php?topic=35050.msg542383#msg542383 (http://www.bay12games.com/forum/index.php?topic=35050.msg542383#msg542383)
Post by: Mikademus on May 05, 2009, 04:53:52 pm
I prefer DFs UI as it is now with some tweaking and a face lift. And I won't say this often, but I think that DF should look to M$ apps for UI design. Here are my ideas that may or may not have been shamelessly lifted from one of the afore mentioned apps:
No open windows, all windows slid closed, action window takes full precedenceSpoiler (click to show/hide)
As the mouse hovers over a small tab, the window expands (exposes clickable selectables as well as hotkeys)Spoiler (click to show/hide)
Messages would be on the bottom separate, it would be expandable and shrinkable to whatever height is desired or hideable altogether, then also some kind of dropdown which separates the kinds of messages.Spoiler (click to show/hide)
The stockpile menu can be tacked so it stays open and then the messages could be opened along bottom of it.Spoiler (click to show/hide)
or the stockpile menu could be floating alongside the main window if desired so it would always be visible or could be put on a separate monitor.Spoiler (click to show/hide)
In summary, pretty close to what Jiri's got laid out with everything being hideable. I think i like the right click idea, but I would have to see it in practice to know for sure.
Edit: The Action Window wouldn't squish and stretch like that, that is just me being a little lazy and I'm at work...
The mockups are good for workflow and overview. There is only two problems with them: (1) they will hide information and require you to open and close panels which can be argued to slow down interaction (but is a minor problem); and (2) they are very much in the style of applications, not games. This Visual Studio-ish interface will probably detract from the immersive experience, even if it is good UI design.
I personally prefer the original mock-ups in this thread.
Post by: Jiri Petru on May 05, 2009, 05:29:33 pm
See this post (http://www.bay12games.com/forum/index.php?topic=34949.msg542172#msg542172) for explanation.
Thanks.
Post by: RAM on May 05, 2009, 08:25:00 pm
Post by: Grax on May 06, 2009, 12:37:36 am
Heh. Now you can say you've seen it once. ;-)hodiernalAs a Latin student I'm appalled that I've never seen this word before.
I'm russian, so my english vocabulary that i learned at school/university comprises somewhat 5-6 (or maybe 10 maximum) thousands "everyday-words", so other "non-everyday" words are coming from dictionary.
Post by: juanoleso on May 14, 2009, 10:11:09 am
Spoiler (click to show/hide)
Spoiler (click to show/hide)
Tried to take into account some of the OPs thoughts and also a few of the things I saw in the thread.
1.) everything would have a hotkey or possibly even two. To get into the menus on the side the top leaf would be "1", second from top would be "q", third would be "a", and fourth would be "z" or you could hold alt and then press the first letter of the menus title, for instance engineering and construction would be alt+e
2.) I didn't have time to think about it, but the submenus would be divided so each menu would have no more than 9 items. Each item could them be assigned a hotkey q,w,e,a,s,d,z,x,c (maybe twelve including 1,2,3) (thank you, lesconrads)
3.) Pressing the hotkey would pop the chosen menu and it would then tack until cleared with space bar.
4.) where is the mini-map? Well in the future (!!!) we will be able to zoom in and out. Mouse scroll or ctrl+up/ctrl+down will zoom. (I guess this one is a suggestion of its own)
5.) left click and hold on an item/building/dwarf to bring up an interaction menu. right clicking recenters view where you clicked.
6.) Messages can be expanded and contracted to any size and then can be sorted by type of message with the dropdown. Click on message to zoom to event.
7.) the little status tabs next to menu can show a certain stat. Click to change which stat to view (up now are dwarves, prepared food, and drinks).
If these aren't any good, feel free to comment as such. I just wanted to get my ideas out of my head onto paper.
Thanks for reading!
Post by: Lap on May 14, 2009, 10:42:03 am
Using radial menus is a good idea for some things, but as sad before if you have to go through many rings to get what you're looking for it is a failed endeavor. Exactly what uses radial menus would need to be very specific. Only things that have limited options, that almost always stay the same are eligible for radial menus. The main advantage of radial menus is that players learn that moving their mouse to a certain direction should always give the same options. Having things move around on the radial or having simply massive radials means you're better off having nested drop down listed that are easier for eyes to scan.
It really saddens me at how little effort is being put into UI and graphics support. All of us at the forums obviously tolerate or like the current system. The amount of people that would be able to experience (and possibly even donate) to DF would go up immensely with even small improvements to UI or graphics. I saw a huge number of new players join just from seeing most of the characters get tile graphics.
I've gotten so many people into roguelikes by showing they TomeTik, ZangbandTK, or Dunegon Crawl Stone Soup. These people never would have joined the vanilla versions that have classic roguelike UI's. If there was something like Jiri made they'd hop on the bandwagon immediately.
Post by: vins on May 14, 2009, 11:03:45 am
When you attack, you can wrestle by choosing which part will attack which part.
To select a part, you just have to move with the arrows keys/ move the cursor on the part to select it.
I'll make a paint drawing to show you :
(http://i652.photobucket.com/albums/uu243/vins84/dessin.jpg)
EDIT : Image too small...
EDIT 2 : better now.
Post by: juanoleso on May 14, 2009, 11:45:21 am
To select a part, you just have to move with the arrows keys/ move the cursor on the part to select it.
Bring VATS to DF. Thats cool too, I guess... =-)
Post by: vins on May 14, 2009, 12:30:39 pm
Post by: BigFatDwarf on May 14, 2009, 01:50:08 pm
But then, I came in here to really push the subject that I had horrible experiences with pie-menus. Do you know "neverwinter nights"? If so... you know the problem.
As a magician you needed to go through several circles with 9+ items until you got your spell done. Who ever did this without pausing first MUST be a master of hand-eye-coordination so that he took less than my 4 seconds to do so.
Oh, yes, I finished Neverwinter Nights with all expansion packs. It was an example of a bad-designed pie menu.
I was a bit biased in proposing the pie menu because I really like it if properly done ( it should never expand more than a depth level ). I was just curious to see how a pie menu would work into such a interface.
I am for all-text interfaces, by the way :) ( I'm a console and ascii-lover, nethack style! ), but I liked the design by Jiri Petru and didn't feel like discouraging.
I must say that I didn't have those problems when I was playing NWN. Pie menu can be actually very fast and organised if properly done. Anyway, In NWN you could also used Numpad to navigate thru the menu. Once you use it for a day or two, you kinda get the hang of it and can quickly cast spells or other things. Isn't that hard.
Post by: Lap on May 14, 2009, 02:10:26 pm
Post by: Sowelu on May 14, 2009, 02:17:06 pm
You don't want to raise the bar on what's required to mod the game, and random critters would be impossible entirely...
Post by: Lap on May 14, 2009, 02:21:12 pm
There's very good reasons to not have any pictures of critters to click on. One, way more work for modders. Two, random critters are impossible.
You don't want to raise the bar on what's required to mod the game, and random critters would be impossible entirely...
Agreed completely. Back to the basic interface stuff. Jiri's design could also work well with windows being separate and resizeable like
http://www.zangband.org/common/gfx/screenshots-tk.jpg
I know a couple of the other suggestions used it as part of their design. Shouldn't really change the essense of Jiri's
Post by: vins on May 15, 2009, 11:02:48 am
And i made my drawing in 10 minutes....
Post by: zwei on December 29, 2009, 04:45:58 pm
4.) where is the mini-map? Well in the future (!!!) we will be able to zoom in and out. Mouse scroll or ctrl+up/ctrl+down will zoom. (I guess this one is a suggestion of its own)
I would not do away with minimap, zooming in and out to get overwivew of map is annoying and if minimap allows you to quickly move between points of interest with mouseclick or to scan area with drag.
Besides, DF map minimaps would be quite a eyecandy!
This is for example map rendered with 1 tile = 1 pixel:
(http://www.zweistein.cz/df/Salvevale-25-region2-219-2471.png)
Post by: Draco18s on December 29, 2009, 05:45:34 pm
By your interface using the "Destroy" feature will remove the ramp. ;)
Post by: zwei on December 29, 2009, 06:04:42 pm
Just a quick question, how do you remove a "remove ramp" designation? :)
By your interface using the "Destroy" feature will remove the ramp. ;)
Ramps could be removed by "Diging" designation, it is same labor anyway.
Post by: zwei on December 29, 2009, 06:36:33 pm
(http://www.zweistein.cz/df/map.png)
First think you will notice is minimap at bottom left, different menu panel.
Menu panel is transparent and resizable by dragging splitter. Semi-transparent menu allows to see-thorough to display more of map.
Minimap acts typically for game of this type - click to change location, drag to drag map. Main map display can also be dragged.
Main Maps can also reacts to mouse gestures: Same gesture that would send web-broswer back/forward is used for moving up/down layer. Aditional gestures to be determined by how often certain fucntionality is needed. Ideal is to use mouse for navigation and keyboard to issuing commands or fine control.
Menu. As you can see, we see menu for selected workshop: Worskhop being selected by made obvious by shape that links it to menu.
Most radical change is leaving curses behind and taking advantge of actually being able to draw instead of just printing text. This allows for best information density in menus, map and minimap, each of which has different needs.
Menu has several conventions:
1) Shortcuts are highlighted by red color, if shortcut is not simple (a letter that is part of command word), it is in brackets following text. Unless command is not avaiable: in that case it is grayed.
2) All commands (=line of text with highlighted shortcut) can also be clicked by mouse.
3) Use of dark green section separators is made.
4) Workshop in this example has "Status" text that spells out relevant info, blue items in this text are hyperlinks, when clicked they will select Creature/Item it refers to.
Player interested in looking where Urist, the sand bag thief, is would only have to click his name to select him.
In fact, anywhere game mentions creature or item in plain text, it works like hyperlink.
5) There is meta-menu on left of worshop diplay: it is used to change mode of selection and to cycle selectables.
It has nothing to do with object we are looking at, so it is set aside. Anytime game needs to have "sidebar" dedicated to navigation or metainformations, it will be rendered aside in this format.
6) Colors
I went for "flesh gold" text color as default as it is warm and inviting for newbies and more grand to look at for veterans. Dark green to separate sections and to render clutter text that needs to be there to help with dividing content. Guess shortcut red could be less intense. Blue to highlight selection in menus and to highligh hyperlink outside menus.
Post by: RAM on December 29, 2009, 08:27:52 pm
You seem to be using a fairly high resolution. It owuld be nice if people using a lower resolution would be able to collapse the menu to about alf the width and a third of the height and still find it useful without needing to scroll the whole thing.
I would keep the menu up permanently, having it come and go could be distracting, obstructive, and may even trigger seizures if many targets are scrolled over quickly. I basically want my field of view to be as consistent as possible.
I want to be able to select the job and zoom to all of the items/creatures/workshops/whatever that are involved in it. Having tasks stacked means individual tasks cannot be selected, but they could be expanded if people select the stack or something...
Adjustable transparency please. Opaque text makes parts of the background unidentifiable and similar symbols could confuse people who don't look closely. I would probably set the background to be completely obscured by the menu...
Aside from the status display I don't really see this as an improvement over the current system, but that is probably just me being sentimental...
Post by: Endek on December 29, 2009, 09:23:51 pm
"Build enormous steel cor" indeed. I'm not sure how trivial it would be to change the interface to use SDL_TTF to handle rendering of actual type instead of using the tile engine, but it would definitely be a worthwhile change.
I like zwei's mockup a lot, mainly due to the clarity of the font (what font is that? i want it!), the extra useful information alluded to in the screenie, and the notion of hyperlinking between entities.
I must admit, I don't like the wedge concept as it stands in the mockup - maybe as a faint outline only to be used to highlight the active workshop/dorf etc it would be more useful and less distracting - the wedge should not contain interface elements as I feel that the non-contextual menu in the mockup belongs elsewhere. (top of the screen, or hidden/in the right hand menu as it is now).
Post by: Draco18s on December 29, 2009, 11:42:56 pm
Just a quick question, how do you remove a "remove ramp" designation? :)
By your interface using the "Destroy" feature will remove the ramp. ;)
Ramps could be removed by "Diging" designation, it is same labor anyway.
Nonono. Remove the "Remove Ramp Designation" action. Removing a designation and designating a ramp for removal are the same command as currently listed.
Post by: sproingie on December 30, 2009, 01:48:14 am
One thing I like about the keyboard interface however is how at least for some of the modes, I don't have to precisely select the target. Viewing building info on buildings and constructions will snap to the nearest building or construction. I'd like something similar for a mouse interface -- I don't want to be forced to aim if I don't have to.
Post by: zwei on December 30, 2009, 09:49:07 am
(http://www.zweistein.cz/df/map2.png)
By popularrequest, vedge is redone to be just two transparent lines. "Target" menu is moved down to bottom left part of screen, which is to be used as message log if nothing is being targeted.
Also, added top infobar
QA:
Quote
You seem to be using a fairly high resolution. It owuld be nice if people using a lower resolution would be able to collapse the menu to about alf the width and a third of the height and still find it useful without needing to scroll the whole thing.
It certainly is resizale, border would act as spliter. Scrolling would be necesity, but as you see, information is odered by importance and as such, does not invite scrolling.
And i would not call 800x600 high resolution, it is much lower than wast majority of current desktops.
Quote
I would keep the menu up permanently, having it come and go could be distracting, obstructive, and may even trigger seizures if many targets are scrolled over quickly. I basically want my field of view to be as consistent as possible.
If you mean target menu, that one is going to stay when in targeting mode, it is not going to blink when moving around, it will stay there untill you stop targeting stuff. It is going to be consistent.
Quote
(what font is that? i want it!)
Fritz Quadrata
Post by: Endek on December 30, 2009, 10:18:48 am
With the wedge being faded out, it's not so clear which building is selected. If I were to add anything to it, it would be a border around the selected building, but otherwise, this rocks.
Post by: zwei on December 30, 2009, 11:53:44 am
Anyhow, some mockups of different screens:
(http://www.zweistein.cz/df/map4.png)
And:
(http://www.zweistein.cz/df/map3.png)
Post by: sproingie on December 30, 2009, 01:05:23 pm
Post by: Strangething on December 30, 2009, 02:33:35 pm
Toady has put so much work into this project, and clearly the interface has slipped to the bottom of the priority list. Do you think he'd let someone else have a shot at the interface, like he did with the graphics overhaul?
Also, I still want to know what "hodiernal" means.
Post by: Footkerchief on December 30, 2009, 03:20:34 pm
Also, I still want to know what "hodiernal" means.
"Today."
Post by: Draco18s on December 30, 2009, 03:23:32 pm
Also, I still want to know what "hodiernal" means.
"Today."
Sortof. "Hodie" is "today," hodiernal tense is used to refer to events that happened today, weather past or future.
Post by: Footkerchief on December 30, 2009, 03:43:57 pm
Post by: Lord Shonus on December 30, 2009, 07:49:43 pm
Post by: RAM on December 30, 2009, 10:43:40 pm
Graphics in D.F. are very dense, it would be difficult to highlight something without obscuring the meaning of the affected items. If you used an outline, it would cut through the sybols. If you changed the brightness, it would either be harder to see or you would need to reduce the brightnees for everything not highlighted. If you inverted the colours or similar, then it might freak people out and make it difficult to identify what is what. I am not trying to say that it is good or bad, just that the costs are different...
Post by: FrostGiantsDaughter on December 30, 2009, 10:45:40 pm
Post by: Lord Shonus on December 30, 2009, 11:36:44 pm
Post by: sproingie on December 31, 2009, 01:26:04 am
Post by: RAM on December 31, 2009, 03:39:28 am
Manage workers: 2 workers
Contents: See list
Items: 30
Time required: 300%
Current task: Glass Portal
Worker: Urist Glassmaker ((zoom to worker))
Item: Black Sand Bag(-Pig Tail Bag-)
Target: Custom Stockpile 13
Queue: 0 h, 11 m, 0 s, at current rate
1 item on repeat
Gather Sand: 7 repetitions currently possible
Post by: zwei on December 31, 2009, 05:13:23 am
Spoiler (click to show/hide)
Amazing original picture here: http://www.bay12games.com/forum/index.php?topic=1604.msg915833#msg915833
What about flashing the tile(s) currently selected?
If anything, game needs to generally flash much less, there are too many "flash, red arrow, flash, dwarf, flash dog, flash, dwarf, flash cow ..." moments.
You can do many things to separate selected item, see RAMs examples, but in the end you do so to find selection. Most of outlines/colors will fail here and blend with rest of the game, making it pointless.
Quote from: RAM
I would prefer a spartan list rather than a verbal description.
This is important thing to decide: I prefer verbal description where game does not expect you to be aware of what text says. I see "Status" section as more of troubleshooting area rather than another set of controls: if workshop fails to perform it will provide clues to what is happening and to fixing it in normal language and will also alert of possible problems, if everything is okay, you will want to skip it.
For example, pointing out that noone has enabled labor for current item in queue and suggesting dwarves who have experience in it/are currently idle.
Basically, i want to seaprate helpfull filler from controls.
Post by: RAM on December 31, 2009, 07:35:19 am
Then again actually depicting a dwarf might rankle some who have different conceptions of their appearance...There already are depictions of Dwarves in the games introduction movie...
Post by: BigFatDwarf on December 31, 2009, 08:57:29 am
Then again actually depicting a dwarf might rankle some who have different conceptions of their appearance...There already are depictions of Dwarves in the games introduction movie...
That's a dwarf??? MADNESS!
But really though, maybe we should just pick how the dwarves look and get on with it. I mean, everyone basically agrees that they're small, hairy and drunk.
Post by: sproingie on December 31, 2009, 11:07:50 am
Post by: Impaler[WrG] on December 31, 2009, 03:14:21 pm
Quote
Looks a little unfinished tho (namely the thing he's hammering out).
If it was finished he wouldn't be hammering on it now would he.
Post by: SirHoneyBadger on January 02, 2010, 03:40:31 am
Spoiler (click to show/hide)
Post by: sproingie on January 02, 2010, 12:40:07 pm
As it is now, DF does allow tiles for every distinctly named entity in the fortress, so coming up with unique symbols shouldn't be a problem even now. It could probably do with being more flexible, including symbols for affect, thoughts, moods, etc. Right now the state of the art is being advanced by things like Khazad and Stonesense, both of which use dfhack to peek into memory. This approach has its limits, but for the meantime it's the best thing we have for prototyping new interface ideas especially as they relate to displaying dwarf status and other output-only things.
Post by: ed boy on January 02, 2010, 01:38:38 pm
The picture:
Spoiler (click to show/hide)
Spoiler (click to show/hide)
I’m afraid I may have been a bit lengthy with the explanation, and my picture isn’t the prettiest. I do like this proposal because it is customisable, supports all screen sizes, supports fully both mouse and keyboard interfaces and sorts the various menus into what (I think) should be a much more simple layout.
Post by: CobaltKobold on January 05, 2010, 02:42:44 am
Spoiler: mouse/kbd junk (click to show/hide)
I'm going to say that these bug me mainly because the graphicstyles clash...
Post by: zwei on January 05, 2010, 07:17:56 am
As for your idea, game could be easily be made skinnable. My idea is as follows:
Have gui panels rendered by WebKit and have them be basically html documents.
Reskin could be as simple as supplying new stylesheet or as complex as complete replacement of page templates with some javascript wow factor.
you can register your own protocol and have urls like:
df://workshop/100
df://mainmenu
df://buildmenu/bed
to allow menu-to-game callbacks.
Sample simplified page for workshop:
Code: [Select]
<html>
<body>
<h1>${currentSelection.workshop.name}</h1>
<h2>Queue:</h2>
<ol>
${forEach currentSelection.workshop.queue item}
<li>${item.name}</li>
${/forEach}
</ol>
<h2>Controls:</h2>
<a href="df://terminateBuilding/${currentSelection.workshop.buildingId}"><span class="command">D</span>estroy building</span>
<a href="df://addTask/${currentSelection.workshop.buildingId}"><span class="command">A</span>dd task</span>
<h3>Info:</h3>
Permited workers:
<ul>
${forEach currentSelection.workshop.workerCandidates worker}
<li><a href="df://selectBeing/${worker.creatureId}">${worker.name}</li>
${/forEach}
</ul>
</body>
</html>
As you can imagine, once community got its little dirty hands on this, we'd be able to do pretty much anything with interface as far as look and feel is concerned.
html and css syntax would allow easy tweaking and let people make use of weatlh of information about html coding as well as wealth of features. As bonus, localization would be easier.
Post by: Rorax on January 05, 2010, 07:22:31 am
What I will say is that, it should be viable with both play styles, yes its faster with the keyboard ( in most cases), there is no reason to deny users the intuitive option of mouse use. Mouse use is visually dominated, I see a menu, so I click the menu to interact. it's the same with every action across the board; point , click, point, click, it's natural.
While the keyboard is incredibly fast for some things, it's not natural enough, you cannot say that when you first started dwarf fortress, that it didn't take your first fort forever to get /anything/ done, as you learned to navigate.
However However.
My main main main point :P is that /whatever/ happens to the Dwarf fortress UI, there are some things that need to be ruthlessly streamlined. While I cannot give examples of my own for streamlining right now. I can give an example of something which is probably going to give me RSI or carpal tunnel.
I am a huge fan of constructing buildings, but!
Such clunky short cuts as follows will be the death of me.
(left hand)
(b)uild>SHIFT-(c)onstructs>(w)all
(Right hand)
arrow keys to move it vaugly into position.
umkh to resize the wall to what you need
enter to designate.
And this needs to be done OVER and OVER for complex structures as you are incapable of "drawing" complex structures, only lines and squares.
A mouse would greatly improve this entire interaction.
and also b>shift-c>w is horrible as it is.
This is a single example of one of the many things that need to be streamlined, and hopefully my next post in here (which is hopefuly not being made at 1:30am) will include some streamlining I think will benefit several of the taxing interactions.
Post by: RAM on January 06, 2010, 01:04:30 am
Of course, mouse commands are probably more familiar to <Unmentionable> users and might make it easier for new players, though they would miss out on the pure awesomeness that keyboards will always provide...
Post by: BigFatDwarf on January 06, 2010, 08:46:43 am
Ability to draw resizable structures (walls, floor etc.)
Maybe it could be done so:
You select walls, and in a similar way to the designations menu, you'd paint where you want walls.
Then you press Accept and it would get you to the material list as usual.
Still, that would probably require much work from Toady. Or not, since the main part is already in (the designation menu)
Post by: Nadaka on January 06, 2010, 04:08:17 pm
Post by: SirHoneyBadger on January 07, 2010, 01:43:15 am
Currently, Full Screen Mood doesn't work well at all with my monitor. I'm using a 16:9 27 inch HP, and all I get when I Full Screen it is a (gigantic) corner of the game. This may simply be my ignorance of a solution that already exists, but it seems like some kind of an interface problem, especially since resizing DF is rather strange, in it's current state.
And, is there any way to cause the game to automatically follow around a specific dwarf(etc)? That seems like it would be enormously helpful, in combination with Z-levels. Also, having the ability to quickly "jump ahead" to that dwarf's destination would be great (particularly when I'm waiting for a miner to mine out visible gems, so that I can give orders to mine any invisible ones behind those, without doing any unnecessary mining). Again, might just be something I'm missing.
For that matter (although I'm pretty sure it's come up before), it would be great to be able to give a dwarf orders to only mine out a particular pocket of gems/ores/whatever, either by specific type ("only mine the regular rubies in this gem pocket. If you find any star rubies, or any other types of gems, stop and let me know"), or mine out whatever's present, other than stone ("mine all the gems you find touching this gem I've clicked on, whatever their type, but don't bother mining the surrounding marble."). Ordering miners to follow veins of ore or coal would also be great. Again, I'm pretty sure this is (atleast similar to) a common request.
Possibly more On Topic: I'd love to have the ability to easily resize (via mouse) each window in the game. That would be incredibly helpful.
The "Strange Moods" find-an-item game we have now is Fun, but it would be nice if it could have it's own screen, with an easily accessible list of the items and workshop that have already been claimed, along with the hints.
I'd also love to have the ability to click on sets of dwarfs, based on their broad skills, for job lists. In other words, to be able to click on Peasants, and bring up a list of all peasants, and then give just those peasants their work orders. Scrolling through 200 dwarfs just so that I can give turn on Fishing for my 197th, 198th, and 199th migrant peasant isn't so much Fun as it is Giant Unnecessary Hassle.
Being able to *just* access all the Antmen, or all the Horses, or all the Giant Cave Swallows, to find out where a specific one is/if one of my dwarfs has wounded it (or killed it), is even more of a hassle.
This could perhaps be fixed by adding additional screens for each division, as is currently done for the nicely laid out Military screen?
Along with this, I'd really like to be able to see which beings (atleast which dwarfs) have wounds, or which are insane, but not yet insane enough to drop them from the roster, or which are holding Artifacts, instead of having to guess.
Post by: Lord Shonus on January 07, 2010, 01:47:19 am
Post by: SirHoneyBadger on January 07, 2010, 01:51:22 am
Post by: CobaltKobold on January 07, 2010, 01:56:08 am
Post by: SirHoneyBadger on January 07, 2010, 02:40:53 am
well thanks!
Ok, so (ignoramous that I am) how do I employ this product and or service?
Particularly since I am using Windows, not Linux.
In other words, having downloaded DF itself, is this a complete version of DF, or do I stick it in a folder or something?
Yes, I know I should be making soap somewhere.
Post by: CobaltKobold on January 07, 2010, 02:44:34 am
Post by: SirHoneyBadger on January 07, 2010, 03:01:36 am
You deserve the presence of some kind of clicky thing of which I might then click on to give you some form of "very helpful forumer" medal.
Post by: CobaltKobold on January 07, 2010, 03:53:38 am
Post by: SirHoneyBadger on January 07, 2010, 04:05:02 am
"Karma record" or "whitespot/blackspot"
Something like that, only no "blackspots". I don't like the idea of negative reinforcement, and it's particularly useless when it comes to forums.
If you do something good, you should be rewarded, but the worst thing you can do to a forumer is to ignore them.
Post by: zwei on January 09, 2010, 01:52:15 pm
And, is there any way to cause the game to automatically follow around a specific dwarf(etc)? That seems like it would be enormously helpful, in combination with Z-levels. Also, having the ability to quickly "jump ahead"
Settlers 2 allowed to open new window which focused on selected unit. It was not particulary helpfull, but quite cool.
Anyhow, next part of my ideas:
Spoiler (click to show/hide)
Here is basic building menu.
First idea is to consolidate all "create" modes to single: designate construction, seccond is to front-load settings to allow uninterrupted construction designation and third is to add "drawing tools"
Typically, player does not really care about what is exactly used for construction. One of most annoying features is need to select one specific log or to hunt for stone of certain type in huge list again and again and again. Anyone who constructed building from specific stone in mature fortress where you have dug throught several layers and propably have various types of blocks and whatnot polluting list can testify that is can be very annoying.
So, each new construction will be "abstract", player will be able to set material mode to "any wood" or "any red stone". No specific item will be tasked, instead material according to given template will be picked at time of construction by worker), similary, quality can be set for certain buildings.
This is going to be also important when designating "action areas":
If player designates treecutting area, he can designate "oak wood" as its material - dwarves will only cut oak. Similary, player would be able to designate mining area as "any ore" and dwarves would leave other types of minerals alone.
As you can see, shape of construction will be also different: instead of using uhjk to resize construction, player will have several "drawing tools" avaiable - basic line, rectangle and oval. With both mouse and keyboard control. Oval tool would allow more exotic "circle farm plots" and generally easier time drawing interesting constructions.
Post by: RAM on January 09, 2010, 07:34:52 pm
I often find myself wanting to limit available materials based on their value and/or quality. Having the option to open a selection window to set multiple limitations would be nice and being able to save a few sets of limitation criteria would be handy. Maybe you could have a list of, say, 5 criteria sets, say,
Quote
1. low qualityThe rules would probably not be displayed here, and would not need to be that complicated, and even if those were possible you would probably want a simplified version for when people didn't want to bother with that level of complexity. This would allow people to have a great list of different preferences that they can swap in as the work on different aspects of their fortress. You would want to display the name of the selection criteria as you are designating to check if you pressed the wrong button...
{total value less than base value of exceptional quality base item}
2. high quality
{low quality < total value < 1000 AND not an artifact AND less than 2 masterwork decorations}
3. unique
{total value >= 1000 AND/OR multiple masterwork decorations AND/OR an artifact}
4. Megaproject level 1
{(red AND stone) OR ((teal OR lime green) AND masterwork quality)}
5. Megaproject level 2
{white AND stone}
6. Load from file
7. Replace above category from file
8. Save above category to file
9. Edit above category
I still find the transparency of the menus kind of pointless, It just doesn't seem to be practical to look at the background. Could you try upping the transparency, I don't know, 20%? and changing the text to sme brazenly obvious colour, Bright Green would work, and making it somewhat transparent also/ Or giving up on the transparency and having undiluted text.
I do prefer the light wedge to the dark wedge, but would it be possible to have a wedge that fades to completely transparent at the point it reaches its target. I figure that this would grant great visibility around the target while still giving a strong impression of what is selected, but I can't be sure unless I see it in action, and I don't really have any graphical programs that do that sort of thing. Even if it works it may be more complexity than you want in the display, it would certainly be much more number crunching then dwarf, miner = tile 018...
It occurs to me that there could be a whole siege 7 tiles away from your beds there and the minimap would stop you from seeing it. Maybe reserve some sort of warning graphic for the minimap to tell you about things that want to kill dwarves...
Post by: zwei on January 10, 2010, 04:01:53 pm
I generally like your latest ideas, though I still have some ideas about the picture.
I often find myself wanting to limit available materials based on their value and/or quality. Having the option to open a selection window to set multiple limitations would be nice and being able to save a few sets of limitation criteria would be handy. Maybe you could have a list of, say, 5 criteria sets, say,Quote1. low qualityThe rules would probably not be displayed here, and would not need to be that complicated, and even if those were possible you would probably want a simplified version for when people didn't want to bother with that level of complexity. This would allow people to have a great list of different preferences that they can swap in as the work on different aspects of their fortress. You would want to display the name of the selection criteria as you are designating to check if you pressed the wrong button...
{total value less than base value of exceptional quality base item}
2. high quality
{low quality < total value < 1000 AND not an artifact AND less than 2 masterwork decorations}
3. unique
{total value >= 1000 AND/OR multiple masterwork decorations AND/OR an artifact}
4. Megaproject level 1
{(red AND stone) OR ((teal OR lime green) AND masterwork quality)}
5. Megaproject level 2
{white AND stone}
6. Load from file
7. Replace above category from file
8. Save above category to file
9. Edit above category
I still find the transparency of the menus kind of pointless, It just doesn't seem to be practical to look at the background. Could you try upping the transparency, I don't know, 20%? and changing the text to sme brazenly obvious colour, Bright Green would work, and making it somewhat transparent also/ Or giving up on the transparency and having undiluted text.
I do prefer the light wedge to the dark wedge, but would it be possible to have a wedge that fades to completely transparent at the point it reaches its target. I figure that this would grant great visibility around the target while still giving a strong impression of what is selected, but I can't be sure unless I see it in action, and I don't really have any graphical programs that do that sort of thing. Even if it works it may be more complexity than you want in the display, it would certainly be much more number crunching then dwarf, miner = tile 018...
It occurs to me that there could be a whole siege 7 tiles away from your beds there and the minimap would stop you from seeing it. Maybe reserve some sort of warning graphic for the minimap to tell you about things that want to kill dwarves...
As for material selection goes, pressing "M" would change dialog, and there is lot of space for any kind of customization, and yep, i too envisioned this kind of compound rules.
Basicaly gui for making "select" statement from "database" of items in fortress. Experience player could simply type "where color=teal and value > 100" or anything more complicated
(note, this would be also usefull in stock screen, imagine ablity to filter stocks as "where material=any metal and size=narrow" when you want to designate post siege loot to melting)
Player could type it or just use gui to make it.
---
Transparency is there mostly for effect: it is very cheap way to add superfluous eyecandy (basically, when drawing gui background rectange, you just make aplha 0.1 instead of 0.0), do not concern yourself much with it :)
Besides, i would imagine better "eyecandy" would be 10% transaprent menus with blurred tiles under it which are trupped of colors and monochrome. Or even not that and just some kind of texture.
As you can see, i am explorign new ideas for vedge; i and still not convinced fading transaprency is good, mostly because it is so far only place in my screens without it, so it woud be kind of weird.
I thing some other way could be possible too. Slowly pulsing drop shaddow effect outside selected object or slowly pulsing from 50% to 150% brightness. Blurring/discoloring whatever is not selected, many possiblities, but none does exactly fit with rest of stuff.
---
I'd imagine minimap could have many "false color" versions. version where your allied units light up green and enemy as red, version where your construction light up or version where each tile has assigned color according to its value. Oh, and yes, minimap depicting wagon accessible areas.
There are possibly other cool maps: displayting distance from nearest food/booze stockpile, distance from closest bed, distance from closest water source, ow much have dwarves valked over certain tile.
Anything that would allow you to see flaws of your fotress setup (hmm, this area of fort is pretty far from food stockpiles but sees a lot of travel, maybe i should make mini dinner room in here somehwere)
Post by: Jiri Petru on January 13, 2010, 06:05:48 pm
EDIT: First post updated
EDIT 2: Zwei, I love your colours and the looks of that interface. I wonder - how would you imagine the basic screen, where no workshop or building is selected? Just the basic interface. In your interface, i miss for example military controls, messages, and links to fullscreen menus (stocks, units, artifacts...)
EDIT 3:
Quote from: Draco18s
Just a quick question, how do you remove a "remove ramp" designation?Well then... I guess this means there would have to be separate "Destroy" and "Cancel" buttons.
By your interface using the "Destroy" feature will remove the ramp.
Post by: zwei on January 16, 2010, 11:32:47 am
First, minimap-modes:
Spoiler (click to show/hide)
Here are few modes of operation for minimap. Generally, they are there to allow quickly troubleshoot problems (water access, wagon access ...)
Seccond, here is "nothing is selected" screen:
Spoiler (click to show/hide)
- bottom is commandline ("target mayor" command typed in), toogled by ~ key. commandline ought to allow alternate access to all commands and sometimes argumented commands
example: "designate masterpiece obsidian statue" will open construction dialog with material, material quality and building type already selected. much faster than navigating menus, even if it takes more keypresses.
or: "military activate" will activate all military squads, "military command squad bullfeathered" will open command view for that squad.
---
Above that is message log. messages are of couse linked so you can click on highlighted message to target relevant object.
---
Main menu is a bit reorganized:
Divided to sections for easier organization.
Construction section "D" is dialog i already posted: rehashed build/designate/zone/stockpile dialog, there is also target activation.
Social section is:
Military - roughly military dialog as we know it: setting up hierarchy and equipment, etc.
Jobs and Positions - nobles dialog mixed with dwarftherapist like dialog for assigning positions and activating labors en masse
Target creature: "v" function
Ecomony is:
Stocks - stocks screen. perks of this screen are global operations: you select group of items and you are able to perform operations of them (dump, melt, forbid), basically, ability to say "dump all items where material = pigtail and quality < masterpiece"
stocks screen woul also allow to flag items as "queue for trade": items flagged to be transported to trade deport when caravan appears.
livestock is basic animals menu from z screen. Of course also "sql" enabled
("select all animals where specie = cat")
Management - dialog allowing to modify bother generals orders for implicit jobs (gather outside refuse: disable), material usage in jobs (cooking menu and stone menu basically) and jobs themselves.
Diplomacy
Foreign relations are just "c" screen.
Main menu for added comfort (quicksave autosaves of command)
Quick facts so that screen is not too empty :)
Post by: sproingie on January 16, 2010, 03:37:26 pm
In messages, How about if the scrollbar only appears when it's relevant, i.e. when the mouse is over the message window, or the display is scrolled up? If someone scrolls back, you'll want a visual indicator when new input arrives: I can't tell you how many times I've been in apps where I've scrolled back and forgotten about it and missed new messages. The current game doesn't have to deal with this, since it pauses when you're looking at messages.
I've also noticed that the main display appears to be rendered on the entire window, with all the panes overlaying it being slightly transparent. I'm not sure how useful that actually is, and would probably be distracting if there was a lot of activity near the menus. I guess it depends on what's in the window, so maybe transparency could just be adjustable in-game.
Post by: DDR on January 17, 2010, 06:38:13 am
I like the game as wholly text-based. It gives it an aura of retro awesomeness that it would just not have otherwise. Trying to mix the text-based game with nice graphical menus is a bit iffy. The styles clash badly. Perhaps if it were mostly text-based, but some items opened in a new graphical window? I find dwarf therapist really, really nice. It is a separate app, so it does not futz with DF's feel. And, that table style is more or less the only way to organize 100+ dwarves.
Can we make the memory hack (I assume..?) official, so it behaves nice? What we have now works impressively well with regards to dwarf organization and aesthetics.
BTW: If I wholly change my opinion later, that means 'slept lately'. I'm rather tired now. ;)
Post by: Jiri Petru on January 17, 2010, 11:14:50 am
In other words, your menu still feels just like "a wall of text" or "a list of possible functions", not much like "interface".
BUT... (and this is a big BUT)
The greatest advantage of your approach is that is sticks very close to the present interface, and thus wouldn't require so much effort on Toady's part. Also, wall-of-texts are easy to modify and quick to redesign...
...
...I don't even know why I'm saying this. ::) Definitely not meant as a criticism of your work. Just thinking aloud, I guess.
Post by: vins on January 17, 2010, 01:40:54 pm
Nice work, but I prefer having separate groups for building than all buildings at once.
Post by: zwei on January 17, 2010, 02:24:18 pm
Zwei: Thanks for the default view. What I don't like about menus like these is that they still feel too much like keyboard only menus. Actually clicking on the lines by mouse would be IMHO quite clumsy. First, clicking lines of text isn't that good as clicking buttons (also they seem to thin, and it would be easy to misclick). Second, the functions aren't differentiated visually, there's no notion of what is more important and what less. Generally, the important or more often used functions should be bigger and positioned somewhere in the more prominent parts of the screen, whereas the less frequent features should be smaller and somewhere in the corner... perhaps even hidden in submenus. While all of this essential for mouse users, I believe even keyboard users would benefit from better visual differentiation (if you don't remember a shortcut, you at least know in what part of the screen to look for it).
In other words, your menu still feels just like "a wall of text" or "a list of possible functions", not much like "interface".
BUT... (and this is a big BUT)
The greatest advantage of your approach is that is sticks very close to the present interface, and thus wouldn't require so much effort on Toady's part. Also, wall-of-texts are easy to modify and quick to redesign...
...
...I don't even know why I'm saying this. ::) Definitely not meant as a criticism of your work. Just thinking aloud, I guess.
Oh god, he dares to criticize me, burn him! (hey, it is cool, if noone speaks their mind, sucky ideas never become "good" ideas)
1) I went by "more important is on top"/"more accessed on top".
Goal i had on mind was to structure menu (subgroup with labels) to make it easy to find whatever functionality you want: as learning curve is hard i rather have menu that is easy to navigate even if it does not follow ergonomic rules.
I would imagine players would eventually learn to access more important feature through use of keyboard and use mouse as pointing device for selections or drawing designations or as navigation tool (i would love, for example, mouse wheel changing displayed layer). Or by commandline :)
Also, for me consistency is important: hence, menu look and feel like submenus (ideally).
As you correctly note, clicking might be problem, i think that highlights of clickable items when mouse hovers can be partial solution, with that it is easy to see that you are really going to click on what you think you are.
---
And yes, you are correct, wall of text is easy to make. It is much easier to add new button if you do not have to draw icon for it, and easy to modify existing structure.
I think this is also important for our ideas: DF is game that is being developed and which is going to change a lot. Compromises allowing easy gui development/modification must be made or else develpment will show down horribly.
This is kind of why i chose to go with more of "just a facelift, essentially the same" than something more radical. As you saw at embark screen, small facelift can be quite powerfull.
I just go for good effort/result ratio, not necesarily great result :)
Post by: SirHoneyBadger on January 20, 2010, 09:01:14 am
Post by: Strangething on January 20, 2010, 05:59:18 pm
I really hope Toady opens up the interface, the same way he opened up the graphics for the 40d# revisions.
Post by: zwei on March 07, 2010, 07:26:13 am
My suggestions is that the "relevant option" to control what items can be cooked is in the wrong place. Instead of being in "Z-status", it should be in the kitchen workshop menu (or accessible from both places). In general, all the related options for some function (like cooking) should be accessible from the same place.
DUH, OF COURSE! This just makes ... sense.
Access animals menu from butchers shop
Access kitchen menu form kitchen
Access stones menu from masonry
Access stocks menu from office
Access justice menu from jail
Access autolooming option from loom
Access using_dyed_cloth from clothiers shop
Access refuse gathering setting from refuse stockpile
etc ...
Basically, game now uses too many disconected screens and hidden non-obvious setting for many items.
It make much more sense for those option for be accessible though workshops/stockpiles/rooms q menu:
* Obvious metaphor (change cooking setting in kitchens, it is simple to figure that out)
* Aviability (settings is only aviable when it is actually usefull)
Post by: CobaltKobold on March 07, 2010, 07:49:28 am
Post by: SirHoneyBadger on March 12, 2010, 11:44:48 pm
For the sake of aesthetics, though, is there anything you could do towards the interface looking a little more organic? Just slightly is fine, but in the current state, it still gives the game something of the character of a spreadsheet. I've always hated that.
Staring at drab, sharp-rectangle-enclosed menus = something I normally get underpaid for.
Useability definitely should be given preference here, I'm all for that, but the "form over function" mantra doesn't have to equate Function's total userpation and annihiliation of Form.
I realize that we're just trying to rivet together the girders here, but after all, DF is something that we're meant to spend hour upon hour staring at-possibly also to advertize-and I feel it's important to build some sense of style into the thing, even up from these foundations.
It's not like we've got graphics--the interface is almost all we visually have. It wouldn't hurt to make it look atleast a *little* stylish. Might make it slightly easier to introduce to our friends/relatives, too.
I'd rather they be mystified as I rapturously ignore them in my worship of this incomprehensible-but undoubtably beautiful-puzzlebox altar; than be repulsed by my grotesque clutching addiction to a seeming second job.
It's a question of Heaven or Hell--defined as surely as the originals are, atleast in part, cosmetically.
Skins would be a godsend.
Any thoughts on making the interface easy to skin? I really think that would be a good direction to go in.
I realize ofcourse that all of this is hypothetical, but it would be nice to do some laying of groundwork.
Post by: zwei on March 13, 2010, 08:09:48 am
For the sake of aesthetics, though, is there anything you could do towards the interface looking a little more organic? Just slightly is fine, but in the current state, it still gives the game something of the character of a spreadsheet. I've always hated that.
Staring at drab, sharp-rectangle-enclosed menus = something I normally get underpaid for.
I personally do not like curved style stuff - they are trivial to do, but also pita to do. It also looks soooo 00's :-)
And curves also have bad issue of taking too much screen space to look good. I would envision 2-3 pixel cut offs in corners of rectangles as ideal.
As for ogranics look, I definitelly agree that excell look (more like 1980s excell predecesors look) is not atractive at all.
My own idea of final interface look is "Illuminated manuscript" ( http://en.wikipedia.org/wiki/Illuminated_manuscript ) look. Embark message was for example inspired by this.
Parchment background, stylish 14th century illustrations, decorated initials, drolleries. Possibly a bit cleaned up (see df.zweistein.cz for more organic take - borders and ciration blocks are softened by drolleries while initials break up "boring" text)
It's not like we've got graphics--the interface is almost all we visually have. It wouldn't hurt to make it look atleast a *little* stylish. Might make it slightly easier to introduce to our friends/relatives, too.
Being stylish is hard :)
There are many ways. I, for example love Fallout idea of "pipboy" mascot. It is used to illustrate skills and perks. It might look like pointless waste of screen space, but it is incredible way of adding atmosphere and explaining concepts without words.
(http://images1.wikia.nocookie.net/fallout/images/9/9f/MeleeWeapons.gif)
That is why I would like to go for "1400s" manuscript look, because there little illustrations like that fel natural:
(http://upload.wikimedia.org/wikipedia/en/9/90/Monk_tasting_wine_from_a_barrel.jpg)
Skins would be a godsend.
Any thoughts on making the interface easy to skin? I really think that would be a good direction to go in.
Simple: embeed rich rendering engine (like webkit or anything that is easily hackable) and make menus into html templates. Let people go nuts with writing better templates and styling them :-)
Post by: The_Kakaze on March 13, 2010, 02:49:20 pm
Post by: Fooj on March 13, 2010, 07:08:18 pm
Post by: CobaltKobold on March 15, 2010, 01:06:41 am
My own idea of final interface look is "Illuminated manuscript" ( http://en.wikipedia.org/wiki/Illuminated_manuscript ) look. Embark message was for example inspired by this.that would be wondrous.
Post by: zwei on April 07, 2010, 02:55:52 pm
Okay, new military interface is all, but user friendly. Lets fix it.
First, we have military setup:
Spoiler (click to show/hide)
This screen worlds like previous version in terms of squad promotion and assgiment: "a"ctivate civillian, enter on line to "move" civillian in hierarchy, etc ...\
What you can see as new is squads current status: Game clearly spells out what squad is currently set up to do, a much needed feedback
(In game, dwarves that are on training duty retain military graphics instead of civillian graphics)
Drafted dwarf is "on duty" by default, ready to accept tactical orders.
Also, war animals are now part of this dialogue and player can easily assign them to dwarves now as his "squad underlings"
Civillians are sorted by applicable skills so any new skilled arrivals that you want to draft are propably on top (but again, "v" view of creature should contain "a"ctivate again).
Spoiler (click to show/hide)
In similar vein, equipment interface is also inspued by previous one.
Instead of setting up armor/weapon separatelly, player instead selects equipment sets (sworddwarf set contains sword, shield and metal armor for example, unarmed contains leather armor).
Game comes with several default equipment sets, but player is able to modify them, remove them or even add new ones is separate "custom" dialog.
Also, shift+enter on equipment set selects this equipment set for whole squad (so you can draft bunch of people under military dwarf and quickly copy his setup.)
Game has also feedback in this screen: If dwarves are underequipped, there is note of it. As bonus, game also mentions missing clothing items for civillians.
Post by: Squirrelloid on April 07, 2010, 03:19:05 pm
Post by: Atanamis on April 08, 2010, 12:15:37 pm
Post by: Jiri Petru on June 09, 2010, 09:49:10 pm
The Basic Interface
This is a proposal of an interface that should be easy(ier) to realize. I know the thing I posted in the second post is quite complicated and hard to program – with all the mouse support and buttons and skinnable interface and tabs etc – and when I've seen Zwei's ideas I decided to come up with something that could realistically be done by Toady and done quick.
So this is my idea of the necessary minimum for good interface. Granted, there's a lot of room for improvement but I think this would do nicely for version 1.0. It's still text-only, it's still keyboard based, there's no buttons or pop-ups or whatever. Very simple, basically just a reorganization of existing stuff. The only technical change is separating the tileset from the interface which I think is a prerequisite for all things interface.
What I've done is that I've cleaned up the menu to make it readable and visually helpful. I've shuffled menus and submenus according to my notion of their importance. And I would like to streamline how some functions work (like for example creating just one mode of selection instead of the current... many). This will be a bit wordy, sorry in advance.
The result is still text only and as easy to maintain as the current interface. Therefore I believe it should be put in as soon as possible :roll:.
Before I get to the wordy explanation, here's the graphical part with all menus hidden, heavily borrowed from Zwei. But don't pay much attention to the fonts and colors, they're not the point.
(http://rpgforum.cz/temp/BasicInterface-Hidden.png)
(An important note: While I've drawn these illustrative pictures to have something cool looking, bear in mind that everything I mention can be achieved in the current "graphical style" as well.)
The small line at the bottom shows commands that control the interface as opposed to controling the game. It would stay in all menus and show things like “Esc: close screen” or “< and > : Change Z-level” (which I've omitted and am too lazy to add now).
What's Wrong with Dwarf Fortress
The current problem isn't lack of graphics, it's the lack of order. Namely:
- No visual distinction whatsoever. Menus are ordered alphabetically in a wall-of-text. Instead, they should be divided into logical categories that are organized by importance. All lists need to be short to make them usable by eyes, not only be memory.
- No notion of importance/unimportance. Rarely used features like the rooms screen are sitting in the main menu, while often used features like list of all your items are hidden as sub-menus. Shuffle them around! Merge some, divide others.
- Unnecessarily many ways of doing things. Like selecting stuff. Or building stuff. Ideally, there should only be one way. It's doable and I will explain my proposal later.
- Unnecessarily many ways of representing things. So why workshops work differently than bedrooms which work differently that hospitals? This would also help to remedy the following issue:
- Toady has the tendency to group things according to their internal workings instead according to game logic. Which I believe is very, very, very confusing. For the interface and the user, it doesn't matter that hospitals work differently than barracks, they should definitely be in the same menu. Fishing zones and plant gathering “zones” in the same menu. And the other way around: why oh why are patrol routes grouped with the note taking system?
Streamlining Solutions
What always confused me the most were the many ways of building things: point and press enter, flow from furniture, UHKM, use zones. That's four ways of doing basically the same, and they should all be grouped into just two:
- Point and click for thing that have a fixed size (workshops)
- And another way for things that have modifiable size (rooms, stockpiles) or can be placed in numbers (walls, but perhaps even furniture?)
The hospitals in .31 are I think an ideal solution for everything from bedrooms to bridges. To build anything you just fill the desired area the same way you dig. (And the same way you do for stockpiles or zones.) This is both quick and flexible to allow even for irregular shapes. Coupled with the mouse for designations, I don't think you need anything else. Coincidentally, this also means the controls for building are the same as controls for digging etc. which is nice.
If the created room needs a furniture you place it after, not before. Creating rooms from furniture is the most user unfriendly idea I've ever seen in a strategy game. This also has the neat effect of allowing some rudimentary working even without furniture (“Here's your bedroom, you can sleep on the floor”) and also prepares ground for future additions such as dwarves buying and placing their own furniture.
Selecting is the other overcomplicated part but it can be solved quickly. Firstly, K and T can easily be merged into one, K should automatically tell you what's in the building you're looking at or that the Mica throne is actually a +<<-Mica throne->>+.
V and Q can I think also be merged but this is questionable. I would prefer to have one Select function, and in the case I'd select a square with both a creature and a building, it would present me with a list which I'd navigate using +, - and Enter. Keeping V and Q separate isn't that much of a big deal, but it doesn't really solve anything – when you have multiple creatures on the same tile, you still need to list between them somehow. And once need to have the list of creatures, you can pretty much add buildings to it.
Menu Reorganization
(http://rpgforum.cz/temp/BasicInterface.png)
What I've done is that I've reshuffled the menus according to game logic and similar functions instead according to the internal workings. I've merged some less often used features and divided others – most notably the Build stuff. Then I've divided them to categories and arranged these according to importance (most important on the left, obscure on the right).
Selections I've talked about above.
Work are the old designations – I've looked for a more user friendly name but couldn't find anything better. Digging is a separate option now since it's so important it needs to be in the main menu. Work area is things like cutting trees, fishing (!) and farming (!). I've thrown away things like traffic, melting etc. and put theme somewhere else because I felt they shouldn't be grouped with work. Also, they're really obscure and shouldn't be listed on an important place.
Building is the mostly just a reorganized build menu. Architecture are constructions with a new name that seemed less confusing. Furniture is furniture. Machinery is traps, mills, etc. all together. Rooms are bedrooms, barracks, hospitals, meeting areas (!) or statue gardens (!) which I think should be together. Stockpiles obviously need a massive reworking, the categories are all wrong and confusing. Workshops (furnaces included) without any change.
Some time ago I've explained these divisions in more detail in the third post (http://www.bay12forums.com/smf/index.php?topic=34949.msg534390#msg534390) (note the image in the spoiler). You'll notice it's a bit outdated (most notably it was before I decided to split the designations) but I think it's still understandable.
Military stuff nicely together. Two changes here: move alerts from military screen to burrows screen (somehow), I think it's more intuitive here since it depends on burrows and you mostly use it for civilians anyway. Setting squads to active/inactive should be a thing of schedules, not alerts (more on this some day later), which leaves alerts solely as a movement restrictor, and thus burrows. The other change is that I've split notes from patrols and moved them away.
Detailed info are all subscreens, very often with their own submenus. Some consolidation going on here, for example artifacts moved from main menu under Stocks, nobles moved under units, etc. More explanation in the second post (http://www.bay12forums.com/smf/index.php?topic=34949.msg534386#msg534386) (spoilered picture), it's old but I think I wouldn't write it much differently now.
Special are odds and ends. Item orders is an alternative name for “item prompts”. Traffic includes not only traffic but also depot access.
Minimap I'm not sure about. Zwei had some ideas here (http://www.bay12games.com/forum/index.php?topic=34949.msg975763#msg975763).
The End
While this interface would still require rewriting of every screen in the game and even some functional changes in the game itself, I think it's the bare minimum of what should be considered an “acceptable” interface. I also hope it might not take that much time, since there are no new functions (buttons, tabs, images, movable parts...) in the interface itself, it's all just about moving the text.
Please let me know what you think of it. Obviously, there's still a lot to be done – all “detailed information” screens need reworking, some of the screens like burrows or workshops would probably need changes. I hope to get to it later, but no promises. Feel free to come up with your own solutions. Of course if you dislike the whole proposal you're free to come up with your own :wink:
And here's a bit of a candy:
Mouse Support (Optional)
(http://rpgforum.cz/temp/BasicInterface-Graphics.png)
I'd really love to be able to click on everything. Also, mouse opens the possibility for useful tooltips!
Post by: dyze on June 10, 2010, 11:27:52 am
(massive post)
thank you. you just made the post i never took the time to do. i agree with it completely. especially confusing naming, menu placements etc..
great post.
Post by: Draco18s on June 10, 2010, 11:57:24 am
(massive post)
FYI:
If Architecture can have its key command indicated in such a manner, than so can Jobs.
Post by: Jiri Petru on June 10, 2010, 12:03:58 pm
FYI:
If Architecture can have its key command indicated in such a manner, than so can Jobs.
Bear in mind J requires one more keypress than j. But yeah, I've payed next to no attention to the shortcuts. I've just thrown in whatever came up. Thanks.
dyze: Happy to hear that ;)
Post by: ed boy on June 10, 2010, 12:05:58 pm
Post by: Draco18s on June 10, 2010, 12:32:14 pm
FYI:
If Architecture can have its key command indicated in such a manner, than so can Jobs.
Bear in mind J requires one more keypress than j. But yeah, I've payed next to no attention to the shortcuts. I've just thrown in whatever came up. Thanks.
True, but you did use [D]ig, and both jobs and dig currently only require one keypress, so...
Post by: Hugna on June 10, 2010, 01:05:26 pm
Lets not forget that some keys are Case-Sensitive.FYI:
If Architecture can have its key command indicated in such a manner, than so can Jobs.
Bear in mind J requires one more keypress than j. But yeah, I've payed next to no attention to the shortcuts. I've just thrown in whatever came up. Thanks.
True, but you did use [D]ig, and both jobs and dig currently only require one keypress, so...
Post by: DarthCloakedDwarf on June 10, 2010, 01:08:30 pm
Post by: Jiri Petru on June 10, 2010, 01:09:04 pm
Question: Why do you want to uglify the interface?
The graphics are irrelevant, focus on the organization.
Post by: DarthCloakedDwarf on June 10, 2010, 01:10:22 pm
The graphics are irrelevant, focus on the organization.I don't see what's wrong with the organization now (except for the military screen, which could definitely use work).
Post by: Deathworks on June 10, 2010, 01:53:56 pm
Interesting. The color-coded marking for the command keys is a good idea (and you can use that to indicate the correct case, answering concerns by people, although that may harm uniformity).
However, I am not quite sure how to interpret your entries Room and Furniture under the build heading... Non-workshop rooms that are not stockpiles or zones are always furniture spawned, so building a room is not really a meaningful concept in Dwarf Fortress.
Personally, however, this re-organization of the overview you suggest would actually run against my own preferences. You see, I keep the overview visible, not so much for the rare command keys I forget (like the one for artifacts), but rather to keep the screen layout stable. I have found that the popping up of the window for the building/material selection annoys me a lot as it disrupts the calm of the screen. You know, at one moment, I have the whole screen or 2/3 of it in the world view, and the next, a third of the screen is jumped upon by the info window, which then disappears as abruptly as it appears (visually, mind you). I know I may be weird, but that jumping of the screen layout is really jarring for me, so I keep the overview visible at all times so that only the content of the window is replaced.
Deathworks
Post by: Jiri Petru on June 10, 2010, 02:06:11 pm
The menu popping won't be an issue. It would work the same way as ever. You could still leave it open all the time. Or do you mind that I moved it in the bottom instead of the right edge? That's a matter of personal preference and can be easily adjusted. Again, it wouln't have much of an effect on the overall reorganization.
Quote from: Deathworks
However, I am not quite sure how to interpret your entries Room and Furniture under the build heading... Non-workshop rooms that are not stockpiles or zones are always furniture spawned, so building a room is not really a meaningful concept in Dwarf Fortress.
Exactly! And I suggest to say goodbye to the furniture spawning, because the game doesn't really need 4 different ways of representing/building stuff. If it can all be done the same way as hospitals now, why have it otherwise? It only server as another source of confusion.
Post by: Deathworks on June 10, 2010, 02:16:11 pm
The essential point for the popping windows for me is that the overview (or menu as you call it) and the other info tables, like the material selector when you want to construct a road, occupy the same space on the screen, so there are no new windows that appear or disappear. As I see your design, I am not quite sure how you would fit the info tables into that space at the bottom - would you go for several columns?
I hope this makes my point somewhat clearer.
As for the room thingie, you are actually going very deep into the game mechanics there. Personally, I think that the furniture rooms are actually currently the best rooms in the game - they are easily resizable and they are intelligent in that they understand a room as a single area of unobstructed space. And just as a bonus, you can actually completely remove them, a grudge I hold against stockpiles (maybe it got fixed by now, but last time I checked, you can only reduce them to 0 tiles size, but the stockpile still exists).
Ah, and furniture rooms are also the easiest to design - dig out/construct the room they are to use, place a door in the entrance, then just declare the room and increase its size until it fills the entire space - presto!
:) :) :)
I guess this underscores the different perspectives people have on these things :)
Deathworks
Post by: Jiri Petru on June 10, 2010, 03:20:49 pm
The essential point for the popping windows for me is that the overview (or menu as you call it) and the other info tables, like the material selector when you want to construct a road, occupy the same space on the screen, so there are no new windows that appear or disappear. As I see your design, I am not quite sure how you would fit the info tables into that space at the bottom - would you go for several columns?
Yup, multiple columns is the way to go. You need to use the space somehow. Just keep in mind: important things on the left, unimportant stuff and unnecessary options on the far right.
But having the menu on the bottom isn't really a thing I'd dwell on. It can as easily be on the right. It's just that this look better. ;)
I hope this makes my point somewhat clearer.
As for the room thingie, you are actually going very deep into the game mechanics there. Personally, I think that the furniture rooms are actually currently the best rooms in the game - they are easily resizable and they are intelligent in that they understand a room as a single area of unobstructed space. (...)
You have a valid point. The issue here is not that this particular system is bad. The issue is that there are 4 separate systems where there should only be one. I remember how difficult it was to me to learn and remember all the different ways of building things. We need to choose just one and stick to it, even if it means losing a bit of control.
If people really have to have the flow-out-of-the-furniture stuff, it should be as a completely optional thing. But definitely not obligatory. The obligatory part should be one system for everything, and that's it. If the user want more precise control, he can go for other controls, but these should (a) stay uneccesary (b) be hidden somewhere in the corner of the interface to show they're just a bonus, not a must.
But I would still argue against keeping flow-of-the-furniture, even if it means losing a bit of control. You can achieve the same shape of the room by point and clicking so the loss is very minor and IMHO not worth having two systems to do the same thing. This is the general problem with more options and specific systems - the more you add, the more control the user has in little details, but also the more cluttered, confusing and harder to learn the interface is.
We have a nice children story here in Czech Republic about how a Doggy and a Kitty went to cook a cake. They decided to simply put everything they love in it to make sure it'll be great. The Doggy brought some bones and meat and strawberries and stuff, the Kitty brought dead mice and grass and I don't know what else. They added dough, put it in the oven, expecting concentrated awesomeness. Instead what they got was a disgusting mess.
Sometimes I fear Dwarf Fortress (and the interface in particular) is taking the Doggy&Kitty route.
Post by: Hugna on June 10, 2010, 08:44:33 pm
Maybe Toady could add an ability to change the interface of the game. Basically this will allow players to add in their own custom interfaces. However, if it had to be coded, this might deal a spot-on hit. Perhaps an easy, yet workable involvement of text files, a readme, and images to contain the looks and everything for all interfaces. For example, one for the menu, another for... well you get it. Basically a customizable part of it all. But with how hard it might be to code it all in, it would be a good trial and error thing for people. After all, we got a lot of people working on things, right? So why not allow people to distribute their own interfaces?
In my honesty, i'd pick zwei's interface over the others. The organization with that one is wonderful, not to mention the transparent background.
So in a sense, Toady could add this stuff into an init, so people can choose if they want to use a different interface. And maybe a way to allow multiple folders in just the interface folder. Basically like the save folder, where you can use multiple folders. Like you say which folder it's in, and it will automatically load it up. Like say you have one named InterfaceExample1, and InterfaceExample2 in the Interface, and want to pick one of them to use. You type in the init's correct spot as "InterfaceExample2", then it will load that interface. And maybe when you load up the game, there is an interface folder in called "Default", that will be used mainly for the normal style of play.
If there were interfaces, i would rather choose to use them, and.. i assume others would too..
Post by: Jiri Petru on June 11, 2010, 05:44:00 am
The decision whether to have just one official interface or to open in for other to program their own interfaces, though, is on Toady One to make. I don't want to force him to do anything. This thread was meant as a repository of ideas and it doesn't really mater if it's Toady who uses them in the end or a team like Stonesense guys working on a (sanctioned) third party interface.
Post by: Sizik on June 11, 2010, 07:57:11 am
And just as a bonus, you can actually completely remove them, a grudge I hold against stockpiles (maybe it got fixed by now, but last time I checked, you can only reduce them to 0 tiles size, but the stockpile still exists).
No, they are completely removed, just check the room list. The game just numbers the next stockpile after the last created stockpile. If you create stockpiles #1, #2, and #3, then delete #1, the next stockpile will be #4, since the highest number is #3. However, if you have stockpiles #1, #2, and #3, and delete #2 and #3, the next stockpile will be #2, since the highest number stockpile is #1.
Post by: Deathworks on June 11, 2010, 08:01:48 am
No, they are completely removed, just check the room list. The game just numbers the next stockpile after the last created stockpile. If you create stockpiles #1, #2, and #3, then delete #1, the next stockpile will be #4, since the highest number is #3. However, if you have stockpiles #1, #2, and #3, and delete #2 and #3, the next stockpile will be #2, since the highest number stockpile is #1.
Interesting. I will have to investigate that, as I am currently extremely careful with my stockpiles ensuring that I only create those that I really want to have in the system later on (so my temporary finished goods stockpile needed to get all those rock crafts for the first caravans into bins usually will be converted into a food stockpile later in the game and is set up among the other food stockpiles).
Thanks for that clarification.
Deathworks (who still thinks, though, that furniture rooms are easier to create :) :) :) )
Post by: Jiri Petru on June 11, 2010, 08:17:41 am
Deathworks (who still thinks, though, that furniture rooms are easier to create :) :) :) )
They probably are. The problem here is:
1) You can't apply the same approach to everything else, say stockpiles or workshops.
2) While you can create a special system for every kind of "building" (stockpiles, workshops, rooms, zones...) that would be super powerful, you shouldn't. Having a unified system with a bit slower solution is better than having 5 different, ultra-fast ones.
Post by: Deathworks on June 11, 2010, 12:26:25 pm
By the way, I prefer to have such overviews/large menus on the side (another bonus point for the current Dwarf Fortress in my eyes, when compared to other games). While a pull-down menu belongs at the top, I feel no such rule for the thing we are talking about here. And I always felt alienated by the tendency to make everything wider and lower.
I mean, it is nice to have a screen that is 20 x 1 in its dimensions when you have a side-scroller like Giana Sisters, but for a game that is played from "above", it doesn't make sense to favor one axis over the other. Thus, I always like it when such titles use a design that makes the screen closer to 1 x 1.
Deathworks
Post by: Jiri Petru on June 11, 2010, 12:35:37 pm
I don't care that much if it is on the bottom or on the right - I think you can easily take my categories and imagine them in a right side menu. I put in on the bottom only because intuition tells me it's nicer to have a rectangular view than a square one. It's the same thing like with photographies or paintings, I think. Not that it really matters.
Post by: Deathworks on June 11, 2010, 12:38:45 pm
Thank you for the kind words.
Just so there is no misunderstanding - I was actually replying to an older comment of you hinting at that possibility to move the menus to the right. And since I never responded to that, I decided to do so now and also bump this discussion in the process.
Deathworks
Post by: Lord Shonus on June 11, 2010, 01:49:15 pm
I disagree with your second point. Unification is NOT automatically better, and some of the biggest flaws in commercial games in my experience come from assuming that it is. (The best example I can think of off the top of my head is aircraft in the first Empire Earth game or in the first two Civilization games.)Deathworks (who still thinks, though, that furniture rooms are easier to create :) :) :) )
They probably are. The problem here is:
1) You can't apply the same approach to everything else, say stockpiles or workshops.
2) While you can create a special system for every kind of "building" (stockpiles, workshops, rooms, zones...) that would be super powerful, you shouldn't. Having a unified system with a bit slower solution is better than having 5 different, ultra-fast ones.
Post by: Draco18s on June 11, 2010, 01:50:27 pm
I disagree with your second point. Unification is NOT automatically better, and some of the biggest flaws in commercial games in my experience come from assuming that it is. (The best example I can think of off the top of my head is aircraft in the first Empire Earth game or in the first two Civilization games.)
You're going to have to explain, as I never played any of those games.
Post by: Lord Shonus on June 11, 2010, 02:04:51 pm
In Civilization I and II (4x games), aircraft were controlled exactly like ground units, except that if they ran out of movement points without being in an airport or city, they exploded (fuel). This made it hard to attack targets at the far range of the aircraft, because a single mismove, easy to do in the somewhat primitive isometric of civ II, could result in your plane running out of fuel one square away from home, costing you a very expensive unit. Civ III replaced it with "missions", where you simply selected a mission and a target. If the target was in range, it would be carried out. Again, this was an interface added only for planes that was far better than the previous unified interface.
Post by: Jiri Petru on June 11, 2010, 02:05:04 pm
Post by: Lord Shonus on June 11, 2010, 02:11:08 pm
Post by: Jiri Petru on June 11, 2010, 02:28:09 pm
I know I said streamlining is a good thing but please don't take my opinions to the extreme. What you say is absolutely right. There's no simple rules like: "simplicity is always better". At the same time, complex controls aren't always an improvement. There's needs to be balance. Anyway, I believe we understand each other now, right? This philosophing leads nowhere.
Post by: Draco18s on June 11, 2010, 02:45:38 pm
It doesn't matter what the specific task is. The point is that you can't automatically assume that it's better to have the same interface for everything. The F-16 has four different ways to drop the same kind of bomb. You going to tell the Air Force to simplify it so it's cheaper to train pilots?
This reminds me of shadowrun's Matrix rules problem. Everything's situated such that the character pushes a giant red "GO!" button and thereby hacks a larger corporation's network with a single action. And it doesn't work in reverse, because there are ways of making an unhackable computer (and cheap too) that corporations (with millions of dollars) don't do.
Post by: Davion on June 12, 2010, 07:28:52 am
I disagree with your second point. Unification is NOT automatically better, and some of the biggest flaws in commercial games in my experience come from assuming that it is. (The best example I can think of off the top of my head is aircraft in the first Empire Earth game or in the first two Civilization games.)
So can you think of any instances in Dwarf Fortress where unifying the interface wouldn't be an improvement and would hinder gameplay? Or did you just want to get it off your chest that some of the interface design decisions in Empire Earth and Civilization frustrated you? Because it's looking like the latter.
Post by: RAM on June 12, 2010, 07:47:15 am
Maybe you would want one highly automated system for training domestic animals and a more dangerous system for training wild animals.
Post by: Deathworks on June 12, 2010, 10:08:25 am
So can you think of any instances in Dwarf Fortress where unifying the interface wouldn't be an improvement and would hinder gameplay? Or did you just want to get it off your chest that some of the interface design decisions in Empire Earth and Civilization frustrated you? Because it's looking like the latter.
Actually, thinking about it, stockpiles and beds are the perfect example: A bed room derives its function from its name giver, the bed. No bed, no bed room. Thus it makes sense to have the bed as an integral part of the bed room - a bed room without a bed makes no sense.
A stockpile, on the other hand, allows using bins or barrels, but they are not an essential part of it, but can leave it at a moment's notice. Even without any furniture, a stockpile is still a logic thing as it really just means the space open for it.
As I said, the bed turns into bed room is easy to use AND also quite logical. So, I think switching that to the stockpile approach would actually be making things more difficult to do and also remove a safety mechanism that prevents the meaningless possibility of a bed room without a bed.
If we wanted to unify things and say the bed->bed room stays, then we would have to make the bin/barrel spawn the stockpile, just as a bed spawns the bed room. This, however, makes changing the type of stockpile a tad more complicated AND makes one bin or barrel unmovable, thus countering the benefit of being able to move several goods combined inside a barrel or bin.
Deathworks
Post by: Jiri Petru on June 12, 2010, 10:16:53 am
Post by: RAM on June 12, 2010, 10:26:48 am
Post by: MMad on June 12, 2010, 10:33:38 am
Actually, thinking about it, stockpiles and beds are the perfect example: A bed room derives its function from its name giver, the bed. No bed, no bed room. Thus it makes sense to have the bed as an integral part of the bed room - a bed room without a bed makes no sense.
A stockpile, on the other hand, allows using bins or barrels, but they are not an essential part of it, but can leave it at a moment's notice. Even without any furniture, a stockpile is still a logic thing as it really just means the space open for it.
This sounds logical according to the way bedrooms currently works in DF. However, I agree with Jiri Petru that DF would be easier to to play and make more sense if some parts of the game (like bedrooms) worked differently.
For example, there could be many benefits from being able to assign an empty room to a dwarf. Even if they have no bed in there, they could still go there to sleep - sleeping on the floor in a private room of their own should be preferable to sleeping on the floor in a hallway somewhere. They could also store personal items in their room, with or without chests or cabinets, and conduct private meetings or discussions when that kind of things becomes more common and interesting.
Right now the bedroom is basically the home of an individual dwarf and many activities takes place there. I don't see it as necessarily obvious that it *has* to emanate from a bed. If you happen to settle somewhere without wood and can't make beds, I think it would make perfect sense to still be able to give each dwarf a room of their own.
You could argue that this kind of reworking of existing systems wanders outside of the topic of interface and presentation - but if it's impossible to make a consistent and sensible interface to describe and control the way the game works, the game should be reworked as well.
I love the Jiri Petru's idea of redesigning room construction in general to follow the hospital model - designating each room or work zone first, then placing furniture as needed. It makes a lot more intuitive sense to decide "This should be the dining room! Let's get some chairs and tables!" than to decide "Here's a table! Let's all eat our dinner in this general area". It would also improve workflow when carving new spaces - you could designate rooms of different kinds even if you haven't yet built the furniture required to make them function, making it easier to remember which was supposed to be which later on.
Anyway, awesome cool discussions in this thread so far. :) I hope Toady reads it and some of this makes it into the game.
Post by: HebaruSan on June 12, 2010, 10:39:09 am
Actually, thinking about it, stockpiles and beds are the perfect example: A bed room derives its function from its name giver, the bed. No bed, no bed room. Thus it makes sense to have the bed as an integral part of the bed room - a bed room without a bed makes no sense.
It's very easy for experienced players to forget how obtuse some parts of DF are at first. I remember commanding a bed to be created in my first map (I won't even dignify it with the term "fort"), and then wondering why no one would use it. After all, it's a bed, and it's sitting right there on the ground (in a stockpile). Surely they see it, and they obviously feel the need to sleep. Oh, you mean I have to press 'b' and place the bed somewhere else and then they'll sleep on it? This is a non-trivial conceptual hurdle to get over, given that in real life there's no observable difference between a bed that's been "constructed" and one that hasn't.
It's just as baffling in the other direction. Suppose a new player notices dwarves sleeping on the ground. "Oh, I should make them some beds." Check the menu; I need to build some beds, so 'b: Building" looks good, and hey, Bed is listed right there! (Presses B) ... "wait, 'Bed ... Needs bed'? What the hell does that mean?? I know they need beds, that's why I'm trying to build them!"
Finally, it's clear that no bed does not mean no bedroom. Dwarves can sleep on the ground! It makes perfect sense to designate a bedroom without a bed; it would mean that instead of sleeping wherever they drop at random, dwarves (or a specific assigned dwarf) would only sleep on these particular areas of ground. Once bedroom furniture gets built, it could be claimed, placed, and used in the same way that clothing and trinkets are today.
I think the most straightforward approach is to designate "quarters" in the style of zones or burrows, optionally assign them out, and then have dwarves claim beds and move them there automatically as they're built.
(Ninja'd! -- MMad is correct on all counts. :) )
Post by: Jiri Petru on June 12, 2010, 10:48:10 am
It's just as baffling in the other direction. Suppose a new player notices dwarves sleeping on the ground. "Oh, I should make them some beds." Check the menu; I need to build some beds, so 'b: Building" looks good, and hey, Bed is listed right there! (Presses B) ... "wait, 'Bed ... Needs bed'? What the hell does that mean?? I know they need beds, that's why I'm trying to build them!"
Along similar lines... and this is very important...
Notice that Bedrooms are nowhere to be found in the game menu. Nor are barracks nor dining rooms. All of these are vital gameplay elements and yet the player isn't told they exist... unless he tries to randomly build furniture and then click Q on said furniture (but why would he do that?) and then notice there's a new option there. And even if he notices this, he has no way to know what other kinds of furnire-rooms there are. There's no list! The player actually has to place every one of the insane number of furniture types and look for hidden options. It took me ages to notice I can build jails! Or zoos!
These buildings are very well hidden - which is so very, very wrong! Considering how important they are, they should be easily visible in a very prominent menu or submenu. And there's no way to do that unless you say goodbye to the "flowing-out-of-furniture" approach.
Post by: Draco18s on June 12, 2010, 10:49:51 am
This is a non-trivial conceptual hurdle to get over, given that in real life there's no observable difference between a bed that's been "constructed" and one that hasn't.
You've obviously never purchased a brand new bed, or ever moved, have you?
Having recently had my bed fall apart on me, I am very aware that an "unbuilt bed" is in fact different.
A pic or two of an unbuilt bed (http://www.bamboozled.org.uk/bedroom.htm).
Post by: HebaruSan on June 12, 2010, 11:08:00 am
This is a non-trivial conceptual hurdle to get over, given that in real life there's no observable difference between a bed that's been "constructed" and one that hasn't.
You've obviously never purchased a brand new bed, or ever moved, have you?
Having recently had my bed fall apart on me, I am very aware that an "unbuilt bed" is in fact different.
A pic or two of an unbuilt bed (http://www.bamboozled.org.uk/bedroom.htm).
So when I told my carpenter to "construct bed", he instead decided to "construct bed pieces"? I guess I wouldn't have a problem with that in principle, but that's not what the game says right now.
Post by: HideousBeing on June 12, 2010, 01:13:31 pm
So when I told my carpenter to "construct bed", he instead decided to "construct bed pieces"? I guess I wouldn't have a problem with that in principle, but that's not what the game says right now.
And simply renaming it would fix this specific problem. Interface overhaul is a good idea; especially the tool tips. Everything needs to be visible to the player and tell them a guideline of what they can do with it (wtf is a burrow! OH! TOOLTIPS FTW), otherwise it's going to take a week of looking at the wiki to do anything. Also bedrooms suck now, I can't give them a certain shape without abusing doors and walls. If they were simply designated by selecting where you want the room it would simplify everything AND allow for us to do cooler stuff with it.
While I could certainly do fine with the current interface, I want my friends to play DF to and thats only going to happen if it doesn't suck to learn how to play. I'm not asking for integrated graphics or anything silly; I'm asking for an interface that a normal human can understand.
Post by: Deathworks on June 12, 2010, 02:31:52 pm
Deathworks, if you want to keep creating bedrooms from beds, how about barracks from armor stands? And what would you do with hospitals? In my head, bedrooms, barracks and hospitals are very similar concepts that deserve a unified approach.
Let's see. Hospitals is actually an easy one for me. The most basic hospital which is what we had before 31 is a single bed allowing the patient to rest, which is the prerequisite for treatment (patients not resting can not be treated). Thus, if we wanted to unify the hospital with the furniture method, it would be a variant of the bed room, that is another room that can be spawned by the bed.
Barracks are a bit more difficult for me as I have not used them a lot in a while (no military in my fortresses as I delay invaders and then have weapon traps ready to handle any threats). The logic thing, if we wanted to unify it would be what is most significant for its function. As far as I recall, barracks have two purposes - sleeping and training. Given that the bed already has two functions, you could either argue that giving it a third possibility won't make a difference and make it kind of an easy thing to remember. However, you could also argue that actually the weapon rack or armor stand would also be logical.
HideousBeing: This is actually also an improvement I have noticed in the latest version: There is more information given when you look at things (at least rocks now tell you what you can do with them).
I agree that the documentation that comes with the game is nightmarish insufficient (I am not sure whether I mentioned that, but the newbie who got tricked by the 'b'uild menu was actually valiant enough to learn the game via the included manual).
Deathworks
Post by: RAM on June 12, 2010, 10:21:06 pm
Post by: zwei on June 13, 2010, 03:47:33 am
Let's see. Hospitals is actually an easy one for me. The most basic hospital which is what we had before 31 is a single bed allowing the patient to rest, which is the prerequisite for treatment (patients not resting can not be treated). Thus, if we wanted to unify the hospital with the furniture method, it would be a variant of the bed room, that is another room that can be spawned by the bed.
You loose some flexibility this way. For example separate storage room/operating room. Why should there be bed in room with chests full of medical supplies?
Similary, I would like to have "closet" room for my dwarves that is a bit removed from heart of fortress: Personal room to store their stuff in chests and cabinets, maybe place bin on ground and put clothing and old toys in it.
When I designate room from furniture, it would have to be bed, office, dining room or statue garden. None of them is apropriate because it makes dwarf walk there and spend time there and it always costs one tile. (I end up using one statues and designate statue garden from it. Room full of clothing with one statue is statue garden, sigh ...). And inversely, I do not want dwarves to make carpet of theri clothing in dining room/office/bedroom.
We could, of course, add Treasury/Storage room designation to chests and cabinets. But, aren't there stockpiles already?
Similary, hospital zone right now also works kind of stockpileish how it stores supplies. Curious. And dump zone ...
It seems that it just makes sense to remove stockpile designation and just have zones that can act like storage.
Post by: Deathworks on June 13, 2010, 05:30:29 am
Which would then support my original feeling that unification is not necessarily the road to take here.
For instance, a throne room without a throne or a study without a chair simply feels wrong, as does a bed room without any real bed (or straw mat, at least).
Deathworks
Post by: Jiri Petru on June 13, 2010, 06:05:16 am
Quote from: Deathworks
Which would then support my original feeling that unification is not necessarily the road to take here.Well, I could not disagree more, but you already know it :P Not only there's no unification between different building categories (workshops/constructions/rooms) in your version, there's even no unification inside what a perceive as a single category (bedrooms, hospitals, etc.). Which is IMHO very bad.
And please note what I've written about having bedrooms, barracks, etc. in the Building menus. I feel it's very crucial to have them there.
Quote from: Zwei
It seems that it just makes sense to remove stockpile designation and just have zones that can act like storage.Well... stockpiles and zones are just two names for the same thing. Even now they work basically the same way. You draw a rectangle and then set its properties. So yeah.
But I'd say zones should be removed completely. Part of them is rooms (hospital, meeting area), part of them is stockpiles (garbage dump) and part of them is designations - or "work area" how I call it (fishing zones). There's no need to have them as a separate building type.
EDIT: When I say "remove zones", I mean remove them as a separate option in the menu, not remove the principle. As I've said, I like how hospitals work, for example, and would extend it to other rooms as well.
Post by: Zalminen on June 13, 2010, 07:38:40 am
For instance, a throne room without a throne or a study without a chair simply feels wrong, as does a bed room without any real bed (or straw mat, at least).A better way to handle these kinds of required items would be that the interface would automatically ask the player which chair/bed/whatever to add to the newly defined room (and then where to place it), just like building a bridge requires you to select the used materials.
It would also be nice to be able to add more furniture through a similar system; select a room, choose to add furniture and so on.
I may be used to the DF way of defining rooms from furniture but it still feels like a strange way to do it...
Post by: HideousBeing on June 13, 2010, 02:57:03 pm
Post by: robolee on June 13, 2010, 04:57:59 pm
heres my mock-ups:
(http://www.cubeupload.com/files/caaa00dorfmockup1.png)
and a couple more in spoilers:
Spoiler (click to show/hide)
Spoiler (click to show/hide)
and some info:
Take out non gameplay related selections and put them in the bottom border (universal pause, escape etc).
Use mouse for many things treating the menu and map border panel as a button, and the menu selections like "build".
Use mouse scroll as well as +/- to scroll menus.
unify similar things (zones=stockpiles, burrows and zones, military=squad and equipment setup).
job menu replaced with a full fortress labour editor (aka dwarf therapist functionality) as shown above.
also having the help command anywhere could provide help for the screen that is currently active.
Post by: Footkerchief on June 13, 2010, 05:01:15 pm
I think all of the mock-ups so far are missing the point entirely as I don't don't believe DF will ever have non tile based text and menus. There's a possibility but I doubt it.
It's fairly likely that we'll get non-grid text: (http://bay12games.com/dwarves/dev.html)
Quote
# Core51, SIZEABLE GAME WINDOW, (Future): Allow the resizing of the game windows, and possibly the support of variable width fonts to allow more text to be displayed.
Post by: Jiri Petru on June 14, 2010, 09:19:50 am
All in all, I'd say there's no point trying to do anything with the interface until it gets separated from the game grid.
Quote
Take out non gameplay related selections and put them in the bottom border (universal pause, escape etc).I absolutely agree with these though ;)
Use mouse for many things treating the menu and map border panel as a button, and the menu selections like "build".
Use mouse scroll as well as +/- to scroll menus.
unify similar things (zones=stockpiles, burrows and zones, military=squad and equipment setup).
job menu replaced with a full fortress labour editor (aka dwarf therapist functionality) as shown above.
also having the help command anywhere could provide help for the screen that is currently active.
Post by: Atanamis on June 14, 2010, 03:27:19 pm
Post by: marcusbjol on June 14, 2010, 04:23:44 pm
Convert DF to an application to do what you really care about: running the simulation. Keep the ASCII interface and add in a back end so other programs can talk to DF properly (mebby a IP Port on the localhost).
DwarfTherapist could do queries based on a set of paramters and get the information back. It would not break at every minor version. The same for Stonesense.
Allow the backend communcition allow for input as well as output. Stonesense could become the defacto graphical interface for the game. Do not allow the back end to cheat.
This would take significant time once. After that, new code would be designed with this inmind so it should not be a problem. This would allow the end users, who really enjoy the game, do to the graphic coding for you. If these were documented properly, the graphic coders would be albe to update for new features quickly.
Benefits for Toady -
1 - Point his finger to the guys doing the graphics engine when others complain about the UI.
2 - Obsolescence is coming (it always is). How much effort would it take a group of people to remake dwarffortress in their own design?
Costs -
1 - Large upfront time cost coding the back end communicator. It would have to be albe to communicate with DF completely.
2 - Small cost making future code work with the back end.
Post by: Footkerchief on June 14, 2010, 06:06:01 pm
Post by: hermes on June 14, 2010, 09:33:20 pm
Post by: Footkerchief on June 14, 2010, 09:36:21 pm
Perhaps the month end project? (Does anyone know what that is by the way?)
Toady has said repeatedly that it's not DF-related. There's no other concrete info.
Post by: RAM on June 14, 2010, 09:49:22 pm
Pretty cool demonstration of what DF's interface could look like. (http://www.youtube.com/watch?v=mm-dPes5NgE)That is a bit too visual and imprecise for my tastes, but I can see that other people would prefer it.
Post by: Cruxador on June 14, 2010, 11:06:40 pm
Pretty cool demonstration of what DF's interface could look like. (http://www.youtube.com/watch?v=mm-dPes5NgE)It's not bad. I really can't get behind using context menus as the entirety of the menu system, but the widespread ability to place and draw using the mouse would certainly be a welcome addition.
Post by: Deathworks on June 15, 2010, 12:59:11 am
Pretty cool demonstration of what DF's interface could look like. (http://www.youtube.com/watch?v=mm-dPes5NgE)
While I personally would still prefer the current interface over such a mouse-driven one, that suggestion is actually something I would support: The thing is, the basic structure of the interface is not changed, which means that the suggested mouse-driven interface can actually co-exist peacefully with the current interface (they have the same "menu-tree").
Not my cup of tea, personally, but a very good proposal for an expansion for those who need it.
Deathworks
Post by: sadis on June 15, 2010, 01:10:50 am
Pretty cool demonstration of what DF's interface could look like. (http://www.youtube.com/watch?v=mm-dPes5NgE)
That looks quite cool. Tooltips are helpful and using mouse to placing and designations would be nice (and in some cases faster) alternative. I would rather use keyboard shortcuts to select what I'm building or placing though, as wading through mouse menus is slow and prone to misclicks.
Post by: LucasUP on June 15, 2010, 02:12:36 am
I was happy to even just see the labor menu be sorted into sub-menus.
I don't think rushing Toady will be helpful. I'm just repeating others, but the big issues/bugs should be the highest priority right now.
Of course I can play Dwarf Fortress fine as-is. A shiny new interface would be most beneficial to those who are new and learning. Seriously, figuring out something simple like how to LOOK AT THINGS is not straightforward. It took me a while to understand how you must use the k button, but sometimes the q button, but no wait, not for that, use v. or was it r? u right? :'(
Even for those competent with the current interface, as many people have said, certain things just take too much effort/digging through menus to do.
I think the FIRST thing needs to be re-organizing/designing the main game menu. It's too clustered and scary for new players. Hard to find the information you need at a glance.
I like some of the concept from that Goblin Camp interface, although I think it still looks kinda ugly. I think keyboard shortcuts /are/ faster for a lot of things in DF, but when I saw defining the shape of a zone/stockpile/wall with the mouse, it made me wish things were that simple.
Edit: Basically, Jiri's most recent (http://www.bay12forums.com/smf/index.php?topic=34949.msg1316771#msg1316771) concept is absolutely the most visually pleasing, simple, and excellently organized I've seen so far.
Post by: jeffb on June 15, 2010, 04:01:40 am
It'll be interesting to see what becomes of Goblin Camp, I'm surprised there aren't more roguelikes in the same vein as DF.
Post by: Jiri Petru on June 15, 2010, 04:10:18 am
Pretty cool demonstration of what DF's interface could look like. (http://www.youtube.com/watch?v=mm-dPes5NgE)Ladies and gentlemen, we have a winner here!
On more serious note: the mouse support is brilliant, the click and drag is brilliant. I wouldn't personally hide all the menus under a right click because I still feel things like building menus and military controls should have "buttons" somewhere in the interface where there are instantly visible. Things I would personally move under the right click are selecting units/buildings/items etc. See this post. (http://www.bay12forums.com/smf/index.php?topic=34949.msg534386#msg534386)
Also I agree with Deathworks here (for the first time I think :D). Hotkeys are crucial. While there's no reason why the Goblin Camp UI couldn't support hotkeys but there's no place where to display them. :) So if nothing else, you need some sort of visible menu that allows to to:
1) Present an organized list of the most important functions
2) Show hotkeys
But still, I'm mesmerized.
Quote from: LucasUP
Edit: Basically, Jiri's most recent concept is absolutely the most visually pleasing, simple, and excellently organized I've seen so far.Oh you make me blush. ::)
Post by: Deathworks on June 15, 2010, 07:42:15 am
Jiri Petru: Well, I am assuming that the overview over command keys is toggable, just as it is with the current system: You can have it on the screen all the time, but you can also turn it off.
Jeffb: Well, the mouse excels at other things than a keyboard as they are quite different in the handling. Thus, if you want to optimize the user interface for the mouse, you may end up with making design decisions that are not as good for the keyboard controls. The video we see is, in my eyes, mouse control used optionally for the current keyboard-designed interface.
If the pro-mouse people do think that that is a good solution for them, then I was probably too pessimistic. But then again, being wrong when you have been too pessimistic is much more fun than being wrong when you have been too optimistic :) :) :) :)
As for rogue-likes in the Dwarf Fortress way: Things like Zangband have gone quite a way towards including entire worlds, but they always remained adventurer mode types. Personally, I can understand that people are reluctant to engage in developing an equivalent for Fortress mode: 1. It is a lot of work to design. Granted, making a rogue-like from scratch is also not a piece of cake, but I still think that implementing basically a second, real time game on top of a turn-based game would take a while. 2. The combination is not as obvious. Dwarf Fortress makes simulation games meet roleplaying games. While recent RPGs and RTS have somewhat introduced that concept to the general public, I don't see much of a tradition there, thus explaining why it has not been done before. 3. Dwarf Fortress is one hell of a competitor. Nowadays, if you chose to go into that direction, you would have to expect people to compare you with Dwarf Fortress. In the most negative case, you may be seen as a rip-off. In a more positive vein, any short-comings of your title will result in people pointing to how Dwarf Fortress is superior in that aspect (even if it fails in others).
Deathworks
Post by: jeffb on June 15, 2010, 08:00:03 am
Well, the mouse excels at other things than a keyboard as they are quite different in the handling. Thus, if you want to optimize the user interface for the mouse, you may end up with making design decisions that are not as good for the keyboard controls. The video we see is, in my eyes, mouse control used optionally for the current keyboard-designed interface.I'm not sure if you've played a video game in the last 20 or so years but they have recently mastered the arcane arts of combining mouse input while maintaining keyboard shortcuts, its a truly incredible breakthrough and I'm sorry you only just learned about it from reading this post. :( :( :(
Post by: Deathworks on June 15, 2010, 08:05:21 am
The games I have encountered (e.g. SimCity 4, Tropico 3) were usually designed in such a way that you wouldn't want to rely on the keyboard input as the game was clearly designed for mouse input.
Deathworks
Post by: FatedTemp on June 15, 2010, 10:02:26 am
The games I have encountered (e.g. SimCity 4, Tropico 3) were usually designed in such a way that you wouldn't want to rely on the keyboard input as the game was clearly designed for mouse input.
In SC4 moving your mouse where you want a Residential zone and pressing the hot-key (Q,W or E) and dragging out a zone is slightly faster than clicking the menu icon, moving to where you want the zone and dragging it out. But it's not like the difference is enough to make either better than the other. But both are there so you can use which ever you're most comfortable with.
As for keyboard only, well that would be a bad idea, and that's the issue really. DF is a management game like Sim City or Dungeon Keeper and those games use the mouse (with hot-key support) for a reason, pointing devices are just better suited to that sort of task. Just like you play a flight sim with a joystick, a driving game with a wheel and an FPS with mouse & keyboard (or analogue game pad) you play management games with the mouse; best tool for the job.
Of course there are going to be players who want DF's interface to stay the same or at least similar to what it is now. I'm sure a lot of people were attracted to DF from rogue-likes and their interfaces. But DF isn't a rogue-like in any sense (it didn't even support text until Baughn added it recently), well, I suppose you could call adventure mode a rogue-like-like but the main part of the game is Dwarf Mode and that's more like the other management games already mentioned, and by those standards it has the worst interface of any management game I've ever played.
I don't know how difficult it would be to redesign the interface now, but it would definitely be worth while. It's 15, 27 and 33 on the Eternal Voting, not to mention 7, 8, 12, 26, 32, 36, 47, 50, 52, 57, 59, 67, 70, 88, 94, 96, 97 and possibly others that are in some way related to improving the interface. So the Eternal Voting and suggestion threads like this which discuss improving the interface show people do want a better interface.
I really like some of the ideas in this thread and as has been mentioned: improving the interface doesn't mean you can't keep the hot-keys or the menu with hot-key listing and it could probably be done in steps, organising it better at the game screen level and moving onto various menus such as military and trade one at a time.
tl;dr – The current interface is pretty terrible; but I play the game in spite of it. Improving it would make a huge difference and make the game more fun to play.
Post by: Deathworks on June 15, 2010, 10:15:40 am
FatedTemp: Well, with SimCity 4, that was my point: You don't play it completely with the keyboard, as it is primarily designed for mouse usage. I think it is relatively rare to have a game that is really designed for two input methods in its core (probably standard 2D RPGs are the exception as keyboard and pad seem to fully supported, although keyboard support often suffers when text is to be entered and you have to use the menu rather than the keyboard to pic the letters (^_^;; )
Personally, I my experiences with FPS indicate that game pad wins out by a big margin to the hybrid controls, at least for me.
And as you point out in your post, there are those people who do like the interface basically the way it is right now and would miss it if it was not available for those who want to use it. I belong to those people.
And as I was trying to express: As long as the old interface is not removed/made insufficient by the changes, I am not opposed to having a mouse alternative. So, if you have no problems with the approach described in the video, there is no real reason for us to argue or get angry at each other: You go for playing with the mouse, I go for playing with the keyboard, and everyone is satisfied.
Deathworks
Post by: robolee on June 15, 2010, 10:58:26 am
Pretty cool demonstration of what DF's interface could look like. (http://www.youtube.com/watch?v=mm-dPes5NgE)
This is kind of what I wanted with the mouse support in my mock-up, I was thinking about using the mouse to be able to designate anything like walls and so forth (though I think instead of the walls being L shaped it should be rectangular). However I think the keyboard commands and menu should also be kept, though as the video shows the menu could be a lot smaller with a variable width font..
I agree that the game would need a variable width fonts but it would have to be like in the above video (... in the link), not a true type font, sorry if anyone finds this insulting but the fonts in all the other mock-ups are horrible, any game font should either be custom made or follow the aesthetics of the game, just using something like arial in a game drastically reduces the quality IMO.
Post by: Footkerchief on June 15, 2010, 11:06:23 am
I agree that the game would need a variable width fonts but it would have to be like in the above video (... in the link), not a true type font, sorry if anyone finds this insulting but the fonts in all the other mock-ups are horrible, any game font should either be custom made or follow the aesthetics of the game, just using something like arial in a game drastically reduces the quality IMO.
Yeah, fonts matter and using web fonts in a fantasy game is just wrong. Fortunately they're also easy to swap out, so I didn't figure it was worth discussing.
Post by: Jiri Petru on June 15, 2010, 02:25:21 pm
Post by: LucasUP on June 15, 2010, 02:40:39 pm
Post by: SlowDog on June 15, 2010, 05:27:28 pm
Would it be possible, rather than there to be a total interface overhaul as such, for Toady to expose/create interfaces for others to hook in to?
The obvious current example would be Dwarf Therapist, which (AIUI) pokes into memory structures that it's got to find on each release. If there were an exposed interface which was "set Dwarf Id (x) with labour Mining", and "read Dwarf(x) status", etc, there could be competing manager programs which then wouldn't be broken with each release. Toady would obviously have to do work to create the interface and get the internal menu system using it himself, but if he did, it would be known to be complete and sufficient.
You could do some things by just allowing the existing menu structure to be driven by an external program; (init)->bpuukk<right><down> builds a 3x3 farm down from the current cursor position, for example. There'd need to be program feedback for workshops and the like, though.
Post by: MaDeR Levap on June 15, 2010, 05:46:43 pm
While I was happy with existence of CORE 51 (so Toady maybe will decide to decouple game world and interface), I don't think it will be implemented any time soon. At least we have resizable window now. There are still problems with it (many screens does not resize) and it needs fixed.
And about completely new interfaces, I think we should make these assumptions:
- Both mouse and keyboard should be supported. Ideally, one could play using only mouse, another only keyboard, and most will probably use both on various occassions and when more convienent.
- Project for minimum supported size (80x25), of course extendable for higher resolutions.
- Project with tile letters. We like challenges, aren't we?
In other UI-related news, I fully support getting rid of designating rooms from objects. I would like zones all the way. Hospital zone (already exists, will be mentioned here and there for comparison), bedroom zone, stockpile zone, workshop zone, etc... Place in bedroom zone cabinet and it will used to contain 50 xKitten socksx personally owned by dorf assigned to this zone. Place it in hospital zone and will be full of medical supplies. Place statue and it will do nothing except usual things (same as placed outside of any zone).
Downsides:
- Some relearning time needed from old gamers that are so used to current way that would have problem with this concept now, like Deathworks.
Upsides (some of them was mentioned earlier by other people):
- Easier to comprehend for new gamers in comparison to current system of zillion (okay, four) ways to do same thing.
- Allows to have important options in menu tree (not completely detached and hidden like now), like command "designate zone"->list of zone groups-> list of zones.
- Very elastic workshops (afaik possible now only with hospital): any size (declutter, anyone? in fact, clutter could be actually visible on map), incompleted with reduced functionality, requiring custom furniture (some of them could function as impassable tiles known from old workshops) etc.
- Modders heaven.
Post by: Jiri Petru on June 15, 2010, 07:19:03 pm
- Project for minimum supported size (80x25), of course extendable for higher resolutions.
Is there any reason for this besides Curses nostalgia? 80x25 using the default tileset is ridiculously small. And above that, why would you even measure the game screen in squares? The logical way seems to be to allow the user to set up a resolution and then fill the resolution with squares, not the other way around.
All: What do you think a sensible minimum resolution is? I went for 1024x768, allowing 800x600 might be nice but I don't think anyone actually uses it any more and the added screen space really makes a difference when designing interface.
EDIT:
Would it be possible, rather than there to be a total interface overhaul as such, for Toady to expose/create interfaces for others to hook in to?
Is has been discussed, yes. The current situation seems to be that Toady has no intention to open any part of the code, probably not even make an API for others, and I'm not going to challenge it... not in this thread because it's potentially a very flamable issue. But feel free to open a new thread. ;)
Post by: Footkerchief on June 15, 2010, 08:49:13 pm
But feel free to open a new thread. ;)
Or not. Read these quotes from Toady first, at a minimum:
Anyway, yes, this has been suggested before and Toady has made a couple direct responses. Any supporters of the idea should definitely read these:Spoiler: response (click to show/hide)Spoiler: followup (click to show/hide)
Also some earlier stuff:Spoiler: part 1 (click to show/hide)Spoiler: part 2 (click to show/hide)
. But I don't know if you see that as a relief.Made it this far? Here are previous threads we've had (and I probably missed some):
http://www.bay12forums.com/smf/index.php?topic=30070.0
http://www.bay12forums.com/smf/index.php?topic=4753.0
http://www.bay12forums.com/smf/index.php?topic=28068.0
http://www.bay12forums.com/smf/index.php?topic=21806.0
http://www.bay12forums.com/smf/index.php?topic=46189.0
http://www.bay12forums.com/smf/index.php?topic=32054.0
http://www.bay12forums.com/smf/index.php?topic=34132.0
http://www.bay12forums.com/smf/index.php?topic=56066.0
Post by: RAM on June 15, 2010, 09:24:33 pm
I haven't played much StarCraft, but I think its a great example of Mouse/Keyboard use. The really good players always go for the keyboard shortcuts because they ARE faster. The mouse is still used for certain specific things, like moving units to a precise location extremely quickly, or going to an exact location on the map.Starcraft is %100 mouse-controlled, with some keyboard alternatives to some buttons if you want them. Starcraft uses larger individual grid-points than DF, so mouse control is more precise than it would be in DF, and keyboard selection would be faster than in DF. But Starcraft is a continuous session, the mouse is faster for imprecise selection and speed is everything in Starcraft. I am happy with the way that DF pauses when I am doing something, and I don't want a mouse jerk to mess up my zone selection, I fully support a combination of control schemes, but I do not want to be forced to use a mouse. Not that my opinion matters much in the grand scheme of things...
Post by: zwei on June 16, 2010, 02:09:50 am
I haven't played much StarCraft, but I think its a great example of Mouse/Keyboard use. The really good players always go for the keyboard shortcuts because they ARE faster. The mouse is still used for certain specific things, like moving units to a precise location extremely quickly, or going to an exact location on the map.
Basically, mouse is superior for inputing positional data, keyboard for commands.
One of bad things about DF interface is that keyboard is used for navigating in game map and placing stuff, even with shift-arrows, it is just slow and inefficient.
I agree that the game would need a variable width fonts but it would have to be like in the above video (... in the link), not a true type font, sorry if anyone finds this insulting but the fonts in all the other mock-ups are horrible, any game font should either be custom made or follow the aesthetics of the game, just using something like arial in a game drastically reduces the quality IMO.
While Arial usage is dreadfull, but there is nothig wrong with using TT fonts in general. Custom made bitmap fonts are usually even more ugly (see pretty much any random tileset). Hell, you really want some features like kerning and already figured out letter spacing (which is terrible in most custom made fonts). There is no point in throwing away features ...
As far as aesthetics goes, game does not have any. I would be fond of, for example, 19th century adventure book (http://new.myfonts.com/fonts/exljbris/calluna/?testdrive=seed%3D24%26dock%3Dfalse%26size%3D76%26w%3D720%26src%3Dcustom%26text%3DDwarf%2520Fortress%26fg%3D000000%26bg%3Dfbfbfb%26goodies%3Dot.liga%252Cot.pnum) style. This one is also free to download and personal and commercial use btw.
Post by: sadis on June 16, 2010, 02:36:29 am
This is kind of what I wanted with the mouse support in my mock-up, I was thinking about using the mouse to be able to designate anything like walls and so forth (though I think instead of the walls being L shaped it should be rectangular).
Why not make it so that you can select the amount of sides (or angles) with a number key.
You start drawing a wall and it does only straight line until you press 2 (for two sides), and now you're drawing L-shape. By pressing 4 you can draw rectangle. 3 would be somewhat harder. It should draw C-shape but I'm not sure how it should select which side is left open. Maybe the side next to start point that is in clockwise direction from cursor, like this:
Code: [Select]
C = cursor, S = startpoint
Cxxxxxxxxx | x S | Sxxxxxxxxx | xxxxxxxxxC
x | x x | x | x x
x | x x | x | x x
x | x x | x | x x
xxxxxxxxxS | Cxxxxxxxxx | xxxxxxxxxC | S x
So that you would always have the open side next to where you started and would just draw depth and width from there. But this is somewhat off-topic.Post by: Jiri Petru on June 16, 2010, 05:09:15 am
Post by: robolee on June 16, 2010, 01:18:05 pm
Post by: Jiri Petru on June 28, 2010, 02:46:43 pm
Post by: sweitx on June 29, 2010, 03:30:37 pm
The point is that if its a box perimeter then you can just remove what you don't need, that's gotta be easier than predicting or designating which way the L/U will face. (and the fact that I can't remember one instance of me making an L or U shaped wall (the only use would be if you were building onto a mountain face).
I think that's a good idea, a U-shaped box just need two draws, a box with a line removal. L-shaped box is just 2-lines, etc.
One can even envision a way to handle other shapes, such as circle, ellipses, etc.
Another interesting thought! A view in different dimension! Say the ability to see/designate build in your fortress from the side.
Going to make this into a separate suggestion.
Post by: Draco18s on June 29, 2010, 04:40:22 pm
One can even envision a way to handle other shapes, such as circle, ellipses, etc.
If I recall correctly from CAD software there are something like five different ways to designate a circle.
Tangent-Tangent-Tangent
Tangent-Tangent-Radius
Center-Radius
Three points
Two-point diameter
Post by: Jiri Petru on July 08, 2010, 11:36:38 am
Now the Workshop Material Selection topped the eternal voting and was implemented to the upcoming features list, I started thinking about how to handle it in terms of interface. I wanted to draw a mockup, but the solution is so simple it doesn't even need one.
Use the uniform system for workshop items!
You could call them "recipes" instead of uniforms or whatever.
Each workshop now comes with a list of "recipes" that can be made there. But you could expand the list by defining your own recipes. You would then name them and they would appear in the menu. It's the same thing as with uniforms, except you wouldn't be able to delete the defaults.
Let's take craftsdwarves workshops, for example. The default list would look something like this (from the top of my head)
- cloth crafts
- decorate with bone
- decorate with horn/ivory
- decorate with pearl
- decorate with shell
- horn/ivory crafts
- leather crafts
- pearl crafts
- rock crafts
- rock mugs
- rock short sword
- shell leggings
- shell gauntlets
- totem
Now if I wanted to create something very specific, I would click "Add a new recipe". Which would bring up a new screen, something like the uniform definition screen. This screen would probably be very complicated, but in the end, I'd define something like "Carp bone helm" + "studded with cow horns" + "encrusted with red sapphires" + "bands of rose gold"... name my creation "horned helmet" and save.
The order list would then look:
- cloth crafts
- decorate with bone
- decorate with horn/ivory
- decorate with pearl
- decorate with shell
- horned helmet
- horn/ivory crafts
- leather crafts
- pearl crafts
- rock crafts
- rock mugs
- rock short sword
- shell leggings
- shell gauntlets
- totem
Easy peasy!
The uniform system has no cons, only pros! It remembers all your recipes (and if you don't want them remembered, simply delete them). And most important of all, it makes material selection completely optional. We definitely don't want to force the player to choose a material every time he orders something. The material selection screen should be something a player could go 100 % without, they could play the whole game without opening it once.
The uniforms/recipes could also be exportable and transferrable between games!
Post by: zwei on July 08, 2010, 12:32:58 pm
...
While we are at it, i would also like ability to "clone item" - say, i have this golden breastplate with image of lion in rubies in it and decide i want several, so i let my dwarves examine it and create recipe for it.
Also, recipe should be able to create several items: For example, "full clothing" recipe with contains leather boots, socks, trousers, etc..
Post by: Jiri Petru on July 08, 2010, 12:43:41 pm
Brilliant!...Also, recipe should be able to create several items: For example, "full clothing" recipe with contains leather boots, socks, trousers, etc..
Also, make the "full clothing" recipe a default one :) By clicking "make set of leather clothing", you would get "make any leather headwear", "make any leather bodywear", "make any leather handwear", etc. All in one click! This is something I always wanted to have in the vanilla game and now it actually seems easy to do! I would set my clothier's workshop to make full sets on repeat and never care again!
EDIT:
Quote
While we are at it, i would also like ability to "clone item" - say, i have this golden breastplate with image of lion in rubies in it and decide i want several, so i let my dwarves examine it and create recipe for it.This would, I think, be accessible from the k-z menu of an item. Amongst dump/melt/forbit there would be something like "make recipe" which would create a new recipe, name it after the item and then automatically add it to the appropriate workshop. You could later open the workshop menu to use or edit the recipe.
Post by: Lord Shonus on July 08, 2010, 04:53:03 pm
Post by: smjjames on July 08, 2010, 04:57:34 pm
I've been thinking, and I think that the announcements should be handled in a Simcity 3k/4 style news ticker.
Might be a problem if the announcements come at a high rate of speed.
Post by: Lord Shonus on July 08, 2010, 04:58:25 pm
Post by: SirHoneyBadger on September 01, 2010, 06:28:47 am
Post by: CobaltKobold on September 02, 2010, 07:19:29 pm
Of course there are going to be players who want DF's interface to stay the same or at least similar to what it is now. I'm sure a lot of people were attracted to DF from rogue-likes and their interfaces. But DF isn't a rogue-like in any sense (it didn't even support text until Baughn added it recently),
I'm pretty sure "roguelike" and "text-based output" are distinct concepts. Also, it was in there at one point.
It should be fun. The number is going to be stuck for a few days while I set up support for open gl text, 256 characters curses and 128 character curses.
allowing 800x600 might be nice but I don't think anyone actually uses it any moreI find it useful as a windowsize.
Post by: rephikul on September 22, 2010, 09:15:54 am
Spoiler (click to show/hide)
1) Remove the boundary cells, that's greatly increase workable areas
2) Stick idlers and conflict notifier together because players watch them like hawks
3) Somehow allow context menu and minimap to be displayed on the same column if df window has sufficient vertical length. In this case, the context menu has been made thinner (but the same height) and can fit in with the minimap starting from 47 cells vertically using 16x16 Phoebus
Other suggestions
Military Screen
+ Allow larger squads, maybe make squad creation gradual like how militia captains are added
+ Allow tagging individuals to fixed CIV status. tagged squad members will not listen to squad commands and schedules and otherwise treated as civilians. This help with many micromanagement headaches i.e. having to keep making new squads to keep people civved when they are unhappy with drafting and still have them wearing the same uniform.
Job Screen
+ Sort ALL "Suspended Construction" and "No Job" on top.
+ Allow managers to priotize work. Such as, priotize "Tan Hide" over "Haul Refuse" over "Haul Food" over "Cook" over "Butcher." Right now manager can queue jobs, but has no sway over the order they get carried out. In fact, game processing is carried out at the exact opposite preference as outlined above which'd leave alot of rotten waste, especially hide.
Unit Screen
+ Allow to hide deceased people
+ Allow to sort dwarves by name
z-status Screen
+ Change "Stone" submenu into "Material" and allow wood management as well... I just want to use feather woods exclusively.
+ Allow to sort animals by type or name, instead of fixed order of creation.
+ Units on health screen should be sortable as well.
+ Make CLEAR distiction on owned / not owned objects on stock menu. Maybe just dont display stuff not owned by the fortress all together. It causes alot of issue when unknown cavern or caravan objects show up on it.
Post by: Jiri Petru on November 01, 2010, 06:39:28 pm
Post by: konzill on November 01, 2010, 10:51:40 pm
* all their skills with a marker for which ones have turned on at the moment.
* current happiness level
* Squad membership with a shortcut to actually assigning them to a squad
* Burrow membership
* Gives per dwarf equipment control
* what percentage of the time they have no job
* relationships / pets
* navigation buttons that move to previous next / living dwarf in the fort so that I can cycle through all the dwarves and ensure and set them up .
Post by: zwei on November 03, 2010, 07:06:59 am
Lets consider this bar stockpile:
Code: [Select]
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxx
xxxxxxxxxxand this alternate display:
Code: [Select]
25 irn brs
80 stl brs
200 gd brs
2 lead brs
50 ccl brs
20 cke brs
1 slver br
==========
==========
==========Of course, this would only work well for larger stockpiles which would have enough space to display textual representation of content, seems that even 10x10 stockpile is too little, but it would be very powerfull feature as you would be able to see how much of something you have exactly without having to check stockpiles menu a search for it.
Post by: Sowelu on November 03, 2010, 01:29:58 pm
If you could display how much stuff was in a stockpile in a menu to the right though, that would be cool.
Post by: Jiri Petru on November 30, 2010, 08:39:29 am
We all hate it so I decided to make a new one. Inspired by Zwei's military screen (http://www.bay12forums.com/smf/index.php?topic=34949.msg1144846#msg1144846), this is my take. Although I'd prefer a mouse interface, I tried to make this design text-only (with possible mouse support) with no graphics, to make it easy to program and maintain.
There are several things that are wrong on the current DF military screen. First of all, it has too many options hidden in too many sub-screens and it's very difficult just to comprehend what's going on. This can be partially fixed by reducing the number of screens, fitting more information and functions in a single screen, and arranging the options and information around the screen in a more logical, helpful manner. Thus my first goal was to reduce the clutter of screens, and even get rid of some screens entirely, like the ammunition or supplies screens (you'll see).
Second, the current DF military system requires too much setup. The player has to manually toy with many options and in too many screens just to make the military barely functional. We all remember how easy was it in the old version (draft a dwarf, tell him what weapon and armor to use), and how horrible is it now (more than ten separate actions, incl. setting up ammunition, schedules, alerts, etc.). I will demonstrate how, with clever use of interface functions and default option, you can make the military require as few clicks as possible. My goal: the player should be able to set up a functional military in a single screen, and the only thing they should be required to do is ideally just moving a dwarf to a squad. Everything else should be handled automatically (while keeping all the customisation options).
Here is the mockup of the screen. This time I've probably gone too silly with the colors, I don't like the looks of it. Focus on the content, not on the looks, please.
(http://rpgforum.cz/temp/military.png)
From the top...
First there is some quick info bar filled with random stuff. None of it is really important.
Then there are three tabs: SQUADS, EQUIPMENT, SCHEDULES. These are the only subscreens of the military, and we are currently on the first one. The player should be able to play the whole game without using anything else than SQUADS. The other two are for customisation and are completely optional. So optional that I won't deal with them in this post at all. You'll see.
Making a squad
You click "n" for a new squad. If there is a commander/captain, already appointed, it simply creates the squad. If there is none, a pop-up appears, asking you who the squad leader will be. This way, the player doesn't have to go to the nobles screen every time he wants to create a new squad.
Another pop-up asks you for the uniform you want the squad to use (as in the current game), and just another pop-up asks you what schedule should the squad use (in absolutely the same way how it asks for uniforms). It's important to ask for schedules now, because having to do that later confuses many a player (at least it confused me when I created a squad, and it still wasn't doing anything). Voilá! You now have a fully functional squad, the only thing remaining is to put dwarves to it. You do that simply by clicking an empty position - a pop-up appears asking you whom you want to draft:
(http://rpgforum.cz/temp/military-draftpopup.png)
I believe that utilising simple, context based pop-ups like this is simpler and easier to understand way how to deal with intricacies of the military system.
Let's explore the details:
Schedules
When I started to learn the new military, I couldn't understand the relationship between alerts and schedules. What are they? What's the difference? Do I have to set up both (turns out I do)? This is one of the most confusing parts of the military, and it needs to be simplified - by getting rid of alerts altogether!
See, you don't need alerts for anything. The only use of alerts for military is to switch between active/inactive, and this can easily be done by schedules. We do have an "off-duty" order, right?. Then you could have a schedule that reads:
- Granite - Training
- Slate - Training
- Felsite - Off-duty
- etc...
If you don't want a backup squad that doesn't do anything, you simply create a schedule that contains only "off-duty" in each month of the calendar. It's exactly the same like setting squad to "inactive" in the current DF, with the important difference that the player doesn't have to learn and control a separate subsystem.
To make this feasible, schedules would be created/saved/named/applied in similar fashion as uniforms. There would be some useful default ones, players could create and save their own, and switching a schedule to an already created one would be a matter of two clicks. In terms of interface, creating schedules would be done in the SCHEDULES tab, but switching schedules could be done simply via a pop-up in the main SQUADS screen. With clever default schedules, players wouldn't have to ever visit the SCHEDULES tab.
Meaningful defaults: the game needs to come with default schedules that are useful and don't have to be changed. In the current version, AFAIK all players are advised to immediately change the default "training" schedule by lowering the number of dwarves that is required to train. This means the default need to be changed.
A suggestion: instead of setting the squad to "Train, 6 dwarves minimum", what about "Train, 60 % of the squad". This way, the game would accommodate to the size of the squad automaticaly, and the player wouldn't have to change the schedule every time he drafts or undrafts new soldiers.
Other than the "Train" schedule, other available defaults could be "off-duty" or even "patrol the underground" which would patrol a default underground burrow (this is a separate matter but I feel the game needs a default, already set burrow that can send all civilians underground without the player having to designate a burrow first).
The still is use for alerts, though: and that's limiting civilians or even squads to certain burrows in time of emergency. This functionality should however be separated from the military interface, as it's hardly ever needed for the military, and instead merged with the burrows interface where it logically belongs. I mean: when I want to order my civilians to go to a burrow, I'd expect the command to be in the burrows screen, not hidden somewhere deep in the military screen.
Uniforms
The current uniforms system is almost perfect. It offers several useful default uniforms, players can define and save their own, and it's very easy to apply it to soldiers. The uniform system is so good that it could be extended to schedules (see above) or even workshop orders (http://www.bay12forums.com/smf/index.php?topic=34949.msg1383575#msg1383575).
When you create a squad, a pop-up asks you for the squad uniform, and automatically applies it to all the members of the squad. You can then manually change certain soldiers to use a different uniform. Again, this should be done from a pop-up in the main screen, it definitely shouldn't require going into a separate screen. See:
(http://rpgforum.cz/temp/military-uniformpopup.png)
The pop-up offers you to create a new uniform - clicking the option would switch you to the EQUIPMENT tab (but you can go there manually, of course). But as with the schedules, once you define the uniforms you want, there's no need to come back to the EQUIPMENT tab, you can simply assign the uniforms via a pop-up. And as with the schedules, with clever defaults, a player wouldn't be required to ever visit the EQUIPMENT tab unless he wants to customise.
You can see in the mockup there are some soldiers with "custom uniform". These are those whose equipment has been individually customised in the EQUIPMENT tab, so they don't use any of the available uniforms now.
Meaningful defaults: The current "any headgear" etc. options are perfect, the squad is able to upgrade equipment automatically, and the system even recognizes partial matches. This is how clever the game should be in all matters interface. But there are still some ways how the default uniforms could be improved.
First, the heavy infantry (metal armor) uniform should support armour layering, ie. it shouldn't say "any armour" but "ani chainmail" + "any breastplate" (ideally recognising leather armour as a breastplate). The same for caps and helms, etc. This a change I always have to make to the default metal uniform, which I otherwise like.
More importantly, move quivers, arrows, food and drink to the uniforms! I hate having to set them up in separate screens, it makes no sense. Why can't I instead have an archer uniform that says, for example:
- Any headgear
- Any armor
- Any legwear
- Any footwear
- Any handwear
- A ranged weapon, individual selection
- 1 quiver
- --- 15 bone or wooden arrows (for training)
- --- 15 metal arrows (for combat)
- A backpack
- --- 2 rations
- A waterskin
- --- 1 drink
Sure, this means we move the "supplies" settings from squads to individuals, but is it really a problem? Changing is as simple as opening the EQUIPMENT tab and toying with a couple of options - ie. it's the same as doing it in a different screen, but again it doesn't require the player to learn a new subsystem.
The arrows are a major pain in the ass for a lot of players. I think most would agree the old system where you didn't have to care about ammunition was better. In any case, having to set up ammunition before soldiers can start using it is bad! Even if you decide not to move ammunition to uniforms, the game must be set up in such a way that by default, soldiers can use ammunition without the player changing anything.
Moving the ammunition to uniforms means you lose control over hunters' ammunition, but does anybody care? Just let hunters use anything they can find. It worked well in 40d and noone was complaining. Again, having to set up ammunition for hunters before hunters can start hunting is a very bad interface decision, and it confuses a lot of players.
Quick-drafting civilians
Normally, when you draft a dwarf you click on a AVAILABLE position and choose the recruit from a pop-up (see above). This is very similar to how it currently works.
However many people were complaining there's no easy way to draft the entire fortress in times of emergency, like it was possible in 40d. Therefore I present you with the quick-draft option. At the bottom of the SQUADS screen is a list of civilians (but it could easily be in a separate tab, eg. QUICK-DRAFT, as it's completely optional), ordered by their weapon skill. When you click on any of them, the game automatically places the dwarf on the topmost available position. When there are no free positions, the game automatically creates a new squad with the dwarf as its captain (a normal pop-ups asking for schedule and uniform would appear).
This is a completely optional, alternative way to draft soldiers, and players would never have to use it.
Meaningful defaults
As I've said in the beginning, I believe the game needs to come up with default settings that allow setting up the military in as few actions as possible. As a general rule of thumb: if there is an action that players have to do to make a functional military, it should be automated if possible.
I've already mentioned some defaults, but I'll list them here again and add some new:
- When a squad gets created, immediately ask for a schedule and an uniform so the player doesn't get confused that he needs to do this on top of recruitment.
- Default schedules that don't have to be changed to work. Have at least two: "Train all the time" and "Be off-duty all the time". But you can add more if you have good ideas.
- Get rid of the alerts system than only adds a completely meaningless action on top of schedules.
- Several default uniforms that offer anything you might ever want from a uniform.
- Supplies set in a way that doesn't need changing. This is actually well and true in the current game, I've just suggested to move supplies to uniforms to make it even simpler.
- !!! Ammunition set by default in a way that doesn't need changing !!!
- All barracks should start with training for all squads enabled, not disabled. The player should be required to customise only if they don't want their soldiers to train, not if they do want them to train.
If all goes well, the player only has to:
- Create a squad (choosing from a list of default schedules and uniforms)
- Draft soldiers
- Close the military screen and watch the soldiers train!
Anything on top of that is "customisation" and should be completely optional.
The end
That's about all that I had in mind. Please post your comments and questions, I'll try to react as the time allows.
Post by: Inglonias on November 30, 2010, 04:34:00 pm
Post by: JujuBubu on December 02, 2010, 07:22:38 am
Simple: Make the stock screen searchable.
THIS
and
[[ Include a option to save custom uniforms and schedules.
mostly everybody knows by now the optimized setup of a uniform,
but setting it up in every new game is kind of annoying.
So like WorldGen Settings, make a file for uniform settings so you don't have to create your standard uniform
again and again in every new game. ]] -- the search option says its allready in your wall of text, but I cant find it.
Post by: zwei on December 02, 2010, 08:55:26 am
...
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.
Post by: Jiri Petru on December 02, 2010, 11:37:14 am
...
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.
Post by: Ullallulloo on December 02, 2010, 12:15:58 pm
Post by: zwei on December 03, 2010, 02:15:26 am
...
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.
Post by: therahedwig on December 21, 2010, 03:12:06 pm
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.
Post by: Jiri Petru on December 21, 2010, 04:04:30 pm
...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.
Post by: Lord Shonus on December 21, 2010, 04:05:55 pm
Post by: therahedwig on December 22, 2010, 09:03:29 am
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.
Post by: Jiri Petru on February 04, 2011, 08:05:43 am
A Battle Lost through Attrition (http://tleaves.com/2010/12/31/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 (http://tleaves.com/2006/07/04/the-design-of-everyday-games/) (the rest of which isn't that much relevant).
Quote
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. (...)
Post by: NW_Kohaku on February 04, 2011, 11:03:33 am
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.
Post by: Jiri Petru on February 04, 2011, 11:19:58 am
Post by: NW_Kohaku on February 04, 2011, 11:36:10 am
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.
Post by: Lord Shonus on February 04, 2011, 01:16:41 pm
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.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.
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.
Post by: NW_Kohaku on February 04, 2011, 02:04:27 pm
Post by: Draco18s on February 04, 2011, 03:08:01 pm
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.
Post by: NW_Kohaku on February 04, 2011, 03:17:54 pm
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.
Post by: Draco18s on February 04, 2011, 03:51:24 pm
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 think that's why I didn't actually play the last version...
Post by: SirHoneyBadger on February 26, 2011, 09:59:47 am
How's that for a tantrum spiral?
Post by: Reganomics on October 04, 2011, 04:20:55 pm
Post by: slowpokez on January 07, 2012, 08:07:36 am
Post by: RAM on January 07, 2012, 09:37:12 pm
Post by: slowpokez on January 08, 2012, 06:12:10 am
Post by: Silverionmox on January 08, 2012, 04:33:43 pm
Well what i was personally thinking about was sort of a mix between the keyboard commands we have now and mousecontrols. The mouse would bacically be used to move around over the map (like WC3), scrolling through menus and raising and lowering a number(which we have the + and -key for now).The mousewheel would be used to scroll between z-levels. Well, while i'm still at it I might aswell add the ability to designate a digging over multiple z-levels(no more designating 140 stairs just to get to get ur magmaforge some fuel).While mouse alternatives are always fine, some people will always prefer the precision of a keyboard. The best use for a mouse is to point to places on the screen that are not easily reachable in succession by straight lines, as the keyboard tends to do. Indicating zones/burrows/designating and the like in freeform rather than squares, for example. But we'll always need the keyboard for making exact designations.
Post by: ayoriceball on January 08, 2012, 08:18:00 pm
Well what i was personally thinking about was sort of a mix between the keyboard commands we have now and mousecontrols. The mouse would bacically be used to move around over the map (like WC3), scrolling through menus and raising and lowering a number(which we have the + and -key for now).The mousewheel would be used to scroll between z-levels. Well, while i'm still at it I might aswell add the ability to designate a digging over multiple z-levels(no more designating 140 stairs just to get to get ur magmaforge some fuel).
That sounds amazing.
Post by: gislegron on January 11, 2012, 03:38:54 pm
As my older friend pointed out when i demonstrated df for him: "this is terrible, it reminds me of the first game i programmed, where i just set keys at random for testing purposes"
"uuuughh, there are different keys when you navigate submenues?!"
these are minor issues that a seasoned user does not notice, because we know the controls by heart, but now that i have noticed how arcane the interface really is i really want to do something about it, and i guess voting is all i can do.
Please toady, upen up for third party components, or do it yourself, somehow the interface must become less userhostile.
Post by: Drago55577 on January 25, 2012, 10:09:02 pm
snippity snip
(http://rpgforum.cz/temp/military.png)
snips
(http://rpgforum.cz/temp/military-uniformpopup.png)
snips and snails :o
its perfect.
Post by: miauw62 on March 29, 2012, 12:41:02 pm
Everything is ASCII and should stay ASCII, tough a reorganization would be nice.
Post by: NW_Kohaku on March 29, 2012, 12:45:47 pm
Your new interface doesnt fit into dwarf fortress alot...
Everything is ASCII and should stay ASCII, tough a reorganization would be nice.
Who are you talking to? If it's Jiri, be aware that he made this argument 2 years ago.
And the game isn't in ASCII. It's in graphics that, by default, use ASCII-like characters, and uses True Type, as well.
The menus that Jiri is talking about and displaying here are using True Type... which is already in the game.
Post by: Beyondrepair on March 29, 2012, 04:43:49 pm
Post by: Jiri Petru on March 30, 2012, 11:35:33 am
Post by: NW_Kohaku on March 30, 2012, 01:06:05 pm
I'm not sure if I should just start posting in this thread, or write a new thread, and have it linked, here.
Post by: Jiri Petru on March 30, 2012, 06:02:17 pm
Post by: knight133 on August 15, 2012, 09:31:28 pm
Post by: Draco18s on August 15, 2012, 09:39:34 pm
Is there something like this to Download?
This is in the suggestions forum.
This is not a mod.
Post by: knight133 on August 15, 2012, 10:37:48 pm
Post by: 10ebbor10 on August 16, 2012, 03:51:00 am
ha Jiri Petru, I now know this isn't a mod but, can you make it a Total Interface Overhaul mod?Sadly no. Not without decompiling and recompiling the source code*(Ie, reprogramming the game). There is a mousefort mod somewhere around the forums though.
*Before anyone asks, Toady is against implementing a UI api.
Post by: Elvang on August 16, 2012, 05:36:55 am
Post by: artemonster on December 25, 2012, 12:23:11 pm
Post by: Draco18s on December 25, 2012, 02:07:43 pm
I am just feeling so awfully disappointed about the fact that devs don't do anything about these brilliant suggestions :(
Quote from: ToadyOne
The interface is coming. Maybe not in your lifetime, but it's coming
Post by: annzilla on February 16, 2013, 03:31:33 pm
It all seems like quite the project though, and I was wondering if it's possible to start out with fixing the keys for scrolling through options?
I mean instead of having the arrow keys as well as +/-, just use the arrow keys. And instead of the different shortcuts for disabling/allowing/blocking etc. for example in in the stockpile settings, just relying on highlighting and pressing Enter.
Also, organizing menus alphabetically would be nice.
These are just minor changes but they would already make things a lot easier.
Even with the menus just as chaotic as they are now, one could at least concentrate on where to look for something, instead of wondering which keys to use to get there in the first place.
Post by: SirHoneyBadger on February 16, 2013, 04:02:02 pm
Post by: NW_Kohaku on February 16, 2013, 04:32:57 pm
Toady relatively recently redid the units list by adding "tabs", as a matter of fact, just to organize things.
Interface isn't something that is necessarily going to be done as an "arc". (In fact, it's pretty silly to think that Interface can or should be rewritten all at once unless you're actually going to do the full GUI overhaul.) It's more of a gradual refinement that Toady doesn't want to spend much time on, which is a pity, because Interface could be a serious low-hanging fruit at this point.
Even basic things like having an option to switch between "look" modes, having cursor memory if you jump out of a menu (especially a menu dozens of pages long, like the trade menu), and methods of sorting or automation would massively improve the capacity for players to grasp the game.
The fact that the majority of players memory-hack their game just because memory hacks are the only way to collate the data they need to make decisions alone is proof that interface is a major handicap to being able to enjoy the game.
Then there's Legends Mode - it's basically useless as it is in the game, and you need third party programs to actually organize the data into anything legible.
Post by: SirHoneyBadger on February 16, 2013, 05:00:59 pm
Then when the game has reached some alpha-state, to incorporate everything into one main body, and interface it all, then move on to polishing the result, as the game begins moving towards a beta-state.
It's frustrating (and I do mean that I'm personally frustrated by it, too.), but I also think that it's a choice that will eventually allow for a better overall result, since more aspects of the game will be able to be more smoothly incorporated, and it should be easier to debug, and also to get a feel for how well players are dealing with the result.
Post by: Draco18s on February 16, 2013, 05:04:15 pm
It's more of a gradual refinement that Toady doesn't want to spend much time on, which is a pity, because Interface could be a serious low-hanging fruit at this point.
He doesn't want to spend time on it and it's NOT low-hanging fruit, precisely BECAUSE of future changes which would rework large portions of the game which would make the interface work invalid (i.e. if an interface was made fancy, then the undelying mechanics altered* then that interface would no longer work and would have to be rebuilt).
*like the military was
Post by: NW_Kohaku on February 16, 2013, 05:26:34 pm
Rewriting the units menu so that it has tabs? Yeah, that's low-hanging fruit.
Toady could rewrite the trade menu to use a tree system similar to the stocks menu, or introduce cursor memory (which he'd probably still want to use in later iterations of the interface, so it's not "wasted") without putting terribly much effort into it.
The argument that Toady "can't possibly do anything because it would take too much time and it would all be undone later" is a false choice between two extremes.
Besides which, there are a lot of bugs in his game that don't get fixed because his interface is so bad that nobody even notices when there are bugs. The bug about stats not being trained by most jobs wasn't noticed by Toady because he never tested the game for a long enough period of time, there was no indicator for experience being gained, and it took people playing forts for years of game-time to ever notice the effects...
Then there's the eyelashes bug, where the game continually iterated the length of hair like eyelashes without ever stopping, taking up processor cycles, and never actually being measured in-game for anything. Nobody even noticed that the dwarves had eyelashes two feet long by several game-years into the game for a long, long time, until memory hacking found it.
Which means Toady is throwing things into his game that he doesn't even realize are broken or nearly untestable because he's failing to throw in the low-hanging fruit of even putting on a window to see how the mechanisms in the game are working.
That's not just low-hanging fruit, but it's actually something that saves him plenty of work in the long-term by catching bugs earlier on.
Post by: RAM on February 16, 2013, 08:01:48 pm
Working regularly on the interface would be impractical. Things would change, overhauls would be required, and a lot of work would be wasted. One alternative would be to get the interface refined early and make sure that everything added conformed to it, which isn't fun and can end up with an ill-suited interface, because at this point we still don't know what the finished product would be like. For example, we still have no idea how abstracted battles between settlements is likely to be. Will the whole world be modelled at once? Will the lands around armies be modelled as they move? Will you send off a bunch of soldiers and receive a battle report later? Will you just make donations to your civilisation and have them become more or less dominant based upon your donations? These would all require very different things from the interface and some would be inappropriate for the current interface. As it is, the interface trundles along with various features being catered to as they occur. It produces a very messy interface, but it adapts easily with the game rather than expecting the game to conform to it. At some later date, once the game is clearly defined, an interface overhaul would be appropriate, but at present it seems that short of getting more people playing the game in its current state, focusing on the interface in inappropriate. I will admit however that the interface will tend to get very messy as long as it is updated to match individual changes in the game, and could become very nearly unplayable if no attention at all is paid to the interface as a distinct entity.
Post by: NW_Kohaku on February 16, 2013, 08:29:51 pm
Working on the interface constantly and in small, iterative steps is the only practical way to handle the game.
If we are the alpha testers of this game, we need to have access to the information that is being passed around in the game to know when things are going wrong. (Or are we to believe that we are not in an alpha, and we are to treat everything in the game as though it is a finished product?)
Further, if you step away from the false dichotomy choices of "the only alternative to doing everything now is doing nothing now", you can easily see many things that need to be done for the long-term for the game that would be of great benefit, now, and could be kept without scrapping later.
Cursor memory, implementing basic scripting commands like the Standing Orders suggestion (which was the top ranked eternal suggestion, along with many other interface tweaks in the top ten like automining veins), putting in simple keypress links between information-gathering modes, working on ways to put information on the same page as the decision pages, and developing the automation and autonomy of the actions of the dwarves in general.
That last part, especially, will never be completed in a single thrust, and understanding the quirks of how it is (and will be) built will have a dramatic impact upon how the game is designed going forward.
You can paper a GUI over all the bare gears in the engine later in some big "overhaul" if you want, but the basic mechanics for the interface need work now, and when you've done a proper skeletal interface, you can actually have a much better grip on not only how the game works, but on how the player will eventually approach the game.
Don't lie to yourself - the way that you see the game now significantly colors the way you actually think about or do things. Playing the game by Stonesense means caring about things far different from things you care about when you play the game normally.
I'm probably one of the very, very few players who actually builds multiple vertical shafts to compact my fortress vertically, rather than spreading out the fortress in a bunch of huge, clunky rectangle rooms specifically because players only view one floor at a time, and the digging tool favors rectangles. Central staircase designs are a direct artifact of the current interface.
If you change that interface, you change the way that players approach the game. How? You'll have no idea until after you do it.
We rely almost entirely upon hacks and micromanaged tweaks to make the game work in its current state - if we are ever going to get a game that works properly, Toady needs to start work on understanding how the player should be controlling their dwarves... And right now, Toady really doesn't have an earthly clue. He can't even give a committal answer on how much autonomy or direct control players even should have over dwarves in general.
In fact, the longer Toady puts off understanding how to build an interface, the worse it will be for him to fix many of its problems, for much the same reason that putting off fixing bugs and building more systems on top of the bugs only makes the bugs far more difficult to fix.
Besides which, by these measures, why should Toady be implementing goblins and sieges into the game now when he's just going to change how sieges work in the future? Or do you like having them in there to be able to enjoy playing the game?
What about raws? Rawifying everything will take a long time, but the more Toady works on making sure that all his new things are in the raws, the easier the eventual rawification of the game will go, because so much of the rest of the game is already prepared for being transitioned.
It's a bizarre double standard to say that we should encourage Toady to make complex systems, but asking that we actually be able to see and interact with those systems is somehow too much of a burden upon him.
The case of the eyelashes is an especially egregious case of a fetishism for simulation without practical interface - if nothing in the game interacts with that mechanic, if the player can never see it, if you can't even notice whether that mechanic is even there or not, why, exactly, is it there, eating up memory and processor time every single tick counting down to the next time when the hair will grow another millimeter? (And it was bugged, and nobody ever even knew it until memory hacks revealed it over a year after it was coded in! Toady never even bothered testing or figuring out a way for anyone else to test it.)
This is the perfect case example of what not thinking about the interface will produce - a perfectly useless mechanic that merely exists to eat processor time. That's why thinking about the interface at every step along the way is the only practical way to code a game.
Post by: Destyvirago on February 17, 2013, 01:28:20 pm
My biggest hope is that when the Toady one finishes the current arch, he will spend some times fixing bugs that we have know about a long time as well as getting a better interface going.
I have read though the suggestions posted in this forum and I see that there are many good suggestions here. Of course not every one is equally good or practical to implement, but there are many suggestions here that can make the gameplay better and less of a fight against the interface. Pretty much all of us that post here are fans of DF and have already climbed the very steep learning curve to understand the game, but that does not really change the fact that the interface is pretty much non-existing at the moment.
I believe there is much to be gained from starting to fix the interface now instead of later as that will only make the task harder. Naturally some will fear change, but I think it will greatly help DF to be more accessible to new players. DF is simply such a good game that I think more people should get the chance experience it, but atm the interface is a huge barrier. More players mean more donations and that will help fund the development of DF further.
Post by: SirHoneyBadger on February 17, 2013, 07:27:51 pm
At the same time, I can only guess that he's working on the parts of the game that just happen to interest him at the time. It's not a logical progression, because it's not meant to be logical, it's meant to be fun for him, so that he feels less pressure to get away from the game entirely.
Obviously, I'm being an apologist here, and I agree with the points being made, from a rational view, but from the viewpoint that this is a labour of love, and that it's meant to be less like work and more like fun, it's hopefully more understandable.
Toady One seems to be entertaining himself, by manufacturing entertainment for us, but he's doing so in a way that remains entertaining for him, in equal portions.
Post by: zwei on February 19, 2013, 03:25:10 am
low-hanging fruit
There are many thing that can be done one at a time.
My favorite example are sorted menus:
Currently, items that come from raw are displayed in order in which they are loaded.
Finding "goblin" in corpse stockpile settings is nearly impossible thanks to huge amount of critters transalted to pages upon pages of listing.
If game sorted those items aplhabetically, it would have been much easier to find your (rocks|plants|bars|whatever) in stockpile and turn them on/off.
This sort can be done after loading raws - and thus at zero performance cost during gameplay. And it is dead simple to implement.
I'm glad and grateful for the enormous efforts and sacrifices that Toady One endures to put out the game. It's more than I am capable of, and seems fairly superhuman to me, to be honest.
At the same time, I can only guess that he's working on the parts of the game that just happen to interest him at the time. It's not a logical progression, because it's not meant to be logical, it's meant to be fun for him, so that he feels less pressure to get away from the game entirely.
Obviously, I'm being an apologist here, and I agree with the points being made, from a rational view, but from the viewpoint that this is a labour of love, and that it's meant to be less like work and more like fun, it's hopefully more understandable.
Toady One seems to be entertaining himself, by manufacturing entertainment for us, but he's doing so in a way that remains entertaining for him, in equal portions.
If he enjoys it, it is not sacrifice. Labor of love is also meant to be loved by audience. Artistry is a lot about refining what you have instead of producing new stuff.
Post by: Alu on February 24, 2013, 03:48:04 am
So when you select an object or, for example a dwarf, you get an ascii art with matching colors and all
Should be feasible, except for artifacts and forgotten beasts.
Something like this
Spoiler (click to show/hide)
Post by: JanusTwoface on February 24, 2013, 02:31:58 pm
An object/entity-window would be a great addition for this I think.How do you represent modded creatures? Particularly ones with completely alien (relative to the vanilla game) body structures? The way you can lay out bodies, you can get all sorts of strange things going on.
So when you select an object or, for example a dwarf, you get an ascii art with matching colors and all
Should be feasible, except for artifacts and forgotten beasts.
Something like thisSpoiler (click to show/hide)
I guess you could probably add it into the tags. But one problem with this is it sort of defeats the point of having everything in ASCII. Freed from the needs of graphically representing new additions to the game, Toady One can add all sorts of interesting things in and let a text description and our imaginations fill in the rest. Having to add in new code to draw any sort of new creature / object slows that down.
Post by: NW_Kohaku on February 24, 2013, 02:54:24 pm
How do you represent modded creatures? Particularly ones with completely alien (relative to the vanilla game) body structures? The way you can lay out bodies, you can get all sorts of strange things going on.
I guess you could probably add it into the tags. But one problem with this is it sort of defeats the point of having everything in ASCII. Freed from the needs of graphically representing new additions to the game, Toady One can add all sorts of interesting things in and let a text description and our imaginations fill in the rest. Having to add in new code to draw any sort of new creature / object slows that down.
Actually, given the way that the physics system is evolving, it may actually make more sense to have it declared in the raws how the body is structured, since we already are including the likes of attack directionality.
I think that there's just a hardcoded concept that the [STANCE] parts should be on the bottom and [THOUGHT] parts should be at the top (and harder for dwarves to reach if a really large creature, like a colossus) but if we're going to have more realistic models going forward, then changing the raws into dictating where each part is in relation to another part it is connected to would make sense.
(It's also the problem of how heads are connected directly to torsos, and necks are just sort of hanging off of heads right now...)
We also need to incorporate the idea of cylindric body parts, so that all body parts aren't represented as though spheres vaguely stuck together.
Post by: SirHoneyBadger on February 24, 2013, 05:51:54 pm
How do you represent modded creatures? Particularly ones with completely alien (relative to the vanilla game) body structures? The way you can lay out bodies, you can get all sorts of strange things going on.
I guess you could probably add it into the tags. But one problem with this is it sort of defeats the point of having everything in ASCII. Freed from the needs of graphically representing new additions to the game, Toady One can add all sorts of interesting things in and let a text description and our imaginations fill in the rest. Having to add in new code to draw any sort of new creature / object slows that down.
It's really unfortunate, but making any suggestions about changing the game from ANSII to anything else, even in partitioned areas of the game, just gets you yelled at by the community.
I haven't ever heard Toady One specifically be adamant on this point (and it's my--limited--understanding the dwarfs themselves are built with something other than ANSII), but there are some hardcore zealots out there that are very against changing the basic graphic mode of the game in any particular, regardless of the reason.
Personally, I'd like to see the game automatically switch over to sprites, once ANSII are exhausted, but artificially keep and promote ANSII as the basic and important mode of the game.
I'd also love to see wireframe implemented into the game in some manner, ala 'Dungeons of Daggorath' (Grandfather of all first-shooters, and still awesome incarnate over 30 years later)--Adventure mode would be an obvious choice--but people were literally coming out of the woodwork to vehemently disagree, even though these were all useful, popular (and easy to code) graphic displays from the same exact era, offered as respectful of ANSII, and suggested only as being supplimental to ANSII.
Good luck on that, though. I'm done pressing for it, atleast for a while, although I'd really like to know how "carved in slade" Toady One feels ANSII is, just for the sake of illumination.
Post by: RAM on February 24, 2013, 07:52:55 pm
It seems odd to me that the quote used should be captioned with the phrase "yelled at by the community". It starts with a legitimate question that could be easily taken as an opportunity to promote the virtues of the proposal or to adjust it to better suit the subject matter. It then goes on to describe why the poster enjoys the current arrangement and finds the proposal at odds with it. It is true that there may be some what of a presumption that the current graphical display is intended and proper, but really, all things considered, the quoted excerpt seems to be constructive well beyond any problems that it may create.
I suspect that Toady just has more interesting things to work on, but that is pure speculation on my part.
Sprites and text appearing concurrently would look somewhat haphazard, as though the creator of the game had started building sprites but then stopped. Such an arrangement could potentially gain some value if used to create contrast, perhaps by having terrain use pictures and creatures/buildings use symbols, which would free up some symbols, but just using pictures as overload relief would seem likely to come off as messy.
I am not familiar with D.o.D. but the idea of game-generated graphics does seem to have some potential. It could produce three dimensional renditions of a fortress(Though likely only represent whether a space is full or empty.), generate a stick-figurish portrayal of creatures, objects, and engravings that could be seen in their descriptions, perhaps even, as you suggest, some sort of personal-view exploration mode that could let someone play first-person adventures or tour their fortress. But all this would require significant information to be added to all physical entities and a lot of programming for something which seems rather tangential the current mechanics of the game...
Post by: NW_Kohaku on February 24, 2013, 08:58:54 pm
I'm fairly sure Toady's resistance to switch to anything beyond Curses was just his lack of desire to spend any more effort on it than necessary. If he started making graphics, he'd have to make graphics for everything he added.
For that matter, Toady's starting to hit the limits of what you can do with just 256 characters, since he has to start adding in "invert" just to make more use of the ones he already has for the minecarts.
I think that, at a basic level, we're getting near a point where he might start using "graphics sheets" that involve more than just one type of font (maybe including a split between worldmap and local typesetting) along with the fact that we have TrueType fonts, now.
Hopefully, something like what Stonesense has been doing will be included sometime soon, and we can start having multiple image layers on a single tile. That can mean we start getting status displays in-game by having icons hover over a dwarf. (For example, represent talking with a speech bubble, like in The Sims, which might hover between the tiles of the talking dwarves.)
Post by: zwei on February 25, 2013, 04:05:48 am
I remember that 40d had an unimplemented visualizer.
I'm fairly sure Toady's resistance to switch to anything beyond Curses was just his lack of desire to spend any more effort on it than necessary. If he started making graphics, he'd have to make graphics for everything he added.
For that matter, Toady's starting to hit the limits of what you can do with just 256 characters, since he has to start adding in "invert" just to make more use of the ones he already has for the minecarts.
I think that, at a basic level, we're getting near a point where he might start using "graphics sheets" that involve more than just one type of font (maybe including a split between worldmap and local typesetting) along with the fact that we have TrueType fonts, now.
Hopefully, something like what Stonesense has been doing will be included sometime soon, and we can start having multiple image layers on a single tile. That can mean we start getting status displays in-game by having icons hover over a dwarf. (For example, represent talking with a speech bubble, like in The Sims, which might hover between the tiles of the talking dwarves.)
Yes, 40d had one-layer only visualizer that id not really visualize much.
You are very correct about running out of character-tiles. We already have doubles: xxx (stairs next to to bin next to to archery target), in fact we have had many doubles for years.
I would think that community could easily fill order of tiles where authors surrender copyrights to toady and maintain given art style.
Thou obvious problem would be to filter crap out. Anytime website/project does logo contest, there is too much crap flowing in.
Post by: Scorus on February 27, 2013, 09:18:28 am
One non-graphical item that is already in the game that could be spread to other menus is the way we can narrow the work order list by typing in part of the name (e.g. throne, copper, bone, etc.). If this were possible in the corpse and animal lists, for instance, then that would be helpful.
Post by: SirHoneyBadger on February 27, 2013, 10:49:06 am
Apologies if this has been suggested, I haven't read the entire thread.
One non-graphical item that is already in the game that could be spread to other menus is the way we can narrow the work order list by typing in part of the name (e.g. throne, copper, bone, etc.). If this were possible in the corpse and animal lists, for instance, then that would be helpful.
I'm not sure if it has been, either (I think it probably has...), but yes, that would be really nice to be able to type "toy steel anvil", instead of having to hunt for it, so it's a good idea.
Post by: Chagen46 on March 02, 2013, 08:29:21 pm
I remember that 40d had an unimplemented visualizer.
I'm fairly sure Toady's resistance to switch to anything beyond Curses was just his lack of desire to spend any more effort on it than necessary. If he started making graphics, he'd have to make graphics for everything he added.
For that matter, Toady's starting to hit the limits of what you can do with just 256 characters, since he has to start adding in "invert" just to make more use of the ones he already has for the minecarts.
I think that, at a basic level, we're getting near a point where he might start using "graphics sheets" that involve more than just one type of font (maybe including a split between worldmap and local typesetting) along with the fact that we have TrueType fonts, now.
Hopefully, something like what Stonesense has been doing will be included sometime soon, and we can start having multiple image layers on a single tile. That can mean we start getting status displays in-game by having icons hover over a dwarf. (For example, represent talking with a speech bubble, like in The Sims, which might hover between the tiles of the talking dwarves.)
If Toady could figure out how to use more than just normal ASCII, then we wouldn't have this problem...there's literally thousands of other characters he could use.
I like your "multiple image layers on a tile" idea, though.
Post by: NW_Kohaku on March 04, 2013, 07:16:39 pm
If Toady could figure out how to use more than just normal ASCII, then we wouldn't have this problem...there's literally thousands of other characters he could use.
I like your "multiple image layers on a tile" idea, though.
He already has figured it out - the game doesn't use ASCII, it uses any arbitrary image that it is directed to use, and dices it up into 256 tiles.
It already is using "graphics" even in vanilla, it's just a (badly resized) picture of a font instead of any actual font.
The only thing stopping Toady from putting in full graphics support whenever he feels like it is Toady.
He could change one variable, and expand the size of the basic "curses" graphic and add double, triple, quadruple, or whatever arbitrary amount as many tiles for modders to choose from as part of the basic tileset. We already have raw-ified custom workshops where you can choose whatever tile you want.
In fact, there's little stopping Toady from going into allowing full "graphics" like with creatures, instead of being limited to two colors. As far as I can tell, he's mostly just too attached to the hard-coded tricks he put in when he was trying to be clever with the not-really-ASCII; For example, the " sign used for kobolds in the darkness turning into a ' when you put out an eye.
Meanwhile, if he simply embraced layered graphics, you could actually do something similar with graphics. Again, you can just have a "single eye" graphic and a "both eyes" graphic. It's just not "clever" if you use the proper tools for the job instead of trying to repurpose fonts into images, that's all.
At the same time, again, much of the game is focused upon what you can actually see happening. If you included layers and put images "between" tiles, you could convey ideas like "this dwarf is talking to that dwarf" by putting a speech bubble between the two dwarf tiles. You could even throw some sort of Sims-like icon on the bubble to let the player see what is actually being discussed, and that could let players get clued in when some sort of event is part of a rumor, and that would clue them in to zoom the interface in to look at what rumors are being discussed in some more detailed rumor mode. (For example, you could have a rumor of a dwarf that's been missing for a few days indicated by an icon, which might prompt the player to look at the rumor to see who's missing, then go and start putting out search parties for that dwarf.)
Again, what a player can see is crucial to how they can understand the mechanics of the game, and as such, those parts of the interface are crucial to build with the mechanics they display.
When players can't get the information they need to play the game without relying on memory hacks (not "to look more pretty," just to be able to play the game) it's indicative of how much more Toady needs to think about interface as he's designing the game.
Post by: RAM on March 04, 2013, 08:57:19 pm
Post by: NW_Kohaku on March 04, 2013, 10:51:42 pm
In fact, with Stonesense, you can make labels of the names, happiness levels, or job appear above the icon of a dwarf. You can see the equipment a dwarf is wearing, and even the color of their beard. The memory hacking done to get data for Stonesense can also pull up other things, like job data, so you could hypothetically have an option to push-button look at what every dwarf is doing as you see them on the map, rather than having to switch between the units menu and map or else going to each dwarf manually with a look function.
(For that matter, you could just plain have a push-button change in the color-coding of dwarves, so that pressing a certain button changed what color dwarves appeared as from profession class to things like happiness levels or hunger levels.)
Post by: sweitx on May 10, 2013, 04:44:03 pm
1. Dwarf Manipulator - The in-game/more integrated version of Dwarf Therapist.
2. Rename Building/Stockpile/Zone - Ability to give stockpile/building/zone a new name. Makes managing specialty building/stockpile more easily (for example, I always setup with 2 millstones. 1 for flour/sugar, 1 for dye). Sure, you can use the Label system. But it would be much simpler if you can just see what the building do with the "q" function.
3. Workflow - The #1 things that made my life of building mega structure easier. Since now dwarfs need cloth (3 pieces), drinks, and food, having an automated system to query jobs for you is a god-send.
Post by: falconne on May 11, 2013, 03:30:31 am
One non-graphical item that is already in the game that could be spread to other menus is the way we can narrow the work order list by typing in part of the name (e.g. throne, copper, bone, etc.). If this were possible in the corpse and animal lists, for instance, then that would be helpful.
You can get this now with DFHack r3. There's a search function in every screen with a long list.
Post by: Mathig on July 13, 2014, 03:50:11 am
as if it were an anti-GUI overhaul post, in order to conclude what we, as a community, should do.
1: ...And right now, I have no idea what would happen...
>Well sure. Life is uncertain. However, what danger does helping the community improve a game have? I mean, on the same token doing nothing carries an unknown risk.
2: If more than half the player base comes in off a third party interface
>Proof that helping GUI will double your player base :P
3: The pressure on me to work directly with them to get the interface out at the same time as the game itself would likely be immense and disruptive, given what little evidence we have from broken utilities.
>That assumes you are capable of speeding up the process. That merely means whatever method we use must be so fast that having The Toady One help won't speed it up one second.
4: First, I don't want to work with other people.
>Easy to implement.
5: If I didn't support it directly, but it was there, I'd still likely make more money, but I'd be unhappy.
>Why? Assuming no one says a word about GUI not being ready etc., where is your happiness lost? Does The Toady One really want to be the Sole Developer of Dwarf Fortress so badly, that'd he would accept making Dwarf Fortress worse than it could be, even if he gets all the credit and money anyways?
6: Given what I've seen here and there, it seems like a full third party interface might develop even without my involvement
>My goal :P
OK, so how do we come up with a way to improve the interface where The Toady One can't possibly help speed up, where The Toady One doesn't dedicate any time towards improving it, and where the players never complain about no interface updates???
Open Source. We find someone who The Toady One approves of as being respectable enough to safeguard his secrets open up the source code, and decipher everything. Probably multiple people, if they are to do this as a hobby. Those people first run through an old copy of Dwarf Fortress and locate all GUI elements. Then, they create an mod that edits Dwarf Fortress to have an API port to access the GUI. This is the hardest part. Next, The Toady One occasionally logs his changes, maybe on a weekly basis, and uploads them without commentary to the various respectable editors. Those editors, at this point, will be skilled enough at reading The Toady One's code, that even The Toady One couldn't help explain it to them. They merely locate changes to GUI and modify their mod that allows access to an API port. Finally, someone else creates ANOTHER mod using this API mod to overhaul the GUI. They can then work directly with the respectable people to proactively come up with new versions to match game updates.
The Toady One assumes one risk. The respectable people he lets look at his code for GUI elements aren't respectable.
The Toady One must work with the players on one thing. Occasionally backup his data to an external location, and select respectable people, probably from the forums, who he trusts. If he doesn't back up his work, he should. If he doesn't trust anyone, there is really nothing we can do... or is there?
Is Dwarf Fortress ALREADY open source(as in, open up the game file and edit away)? If so, ignore everything I said about The Toady one assuming any risks or doing anything, he already assumed said risks and did such actions, now we get to edit.
If not, does The Toady One already trust anyone enough to let them do this? Secondarily, would they be willing to do this?
Personally, I doubt The Toady One codes in the enigma, and so long as he codes in a language machines can understand, we community members can probably crack it. Once we have the code cracked, and available, finding the GUI elements could take about a month, maybe, and developing the API porting software maybe another month. Developing one of these options of GUI initially for the old variant of Dwarf Fortress might take a week... Following that, it may take some time to catch up to the latest version.
Yes its a stupid amount of work, but think of it this way. What if this 3rd party GUI overhaul makes Dwarf Fortress pull another Minecraft? Imagine The Toady One's delight at seeing his creation go viral... (Well, The Toady One ALREADY inspired Minecraft and tons of other games, so... he may be indifferent...)
Post by: Dyret on July 13, 2014, 05:19:11 am
Post by: fricy on July 13, 2014, 06:09:11 am
/snipShort: Opensourcing is not gonna happen.
Long: I suggest you read through the latest flamewar on this, (http://www.bay12forums.com/smf/index.php?topic=140124.0)it's been only 4 days since this has been discussed. Extensively.
Post by: Mathig on July 13, 2014, 02:05:13 pm
After glancing at the OP, that topic is unrelated. That is a suggestion to change the form of development. My suggestion was to implement better GUI by letting select people create a mod that does what The Toady One won't, create an API for GUI revamping./snipShort: Opensourcing is not gonna happen.
Long: I suggest you read through the latest flamewar on this, (http://www.bay12forums.com/smf/index.php?topic=140124.0)it's been only 4 days since this has been discussed. Extensively.
Besides that, I seriously don't understand The Toady One's point of view on avoiding pressure to work with interface editors. Clearly he is already being faced with pressure to cooperate, why he fears more pressure once he does cooperate is beyond me. While I understand his desire to work on the game as he sees fit, I don't understand the communities compliance with a "Leave the GUI such that millions will ignore the game, because the cover is crumpled" mentality.
Here is another solution that doesn't involve open source or The Toady One. Create a Virtual Computer for Dwarf Fortress that runs off of virtual key-strokes and stores virtual graphics. Then display a new overhauled version that cuts and pastes the pieces of Dwarf Fortress's interface in ways that makes it better. I know this is possible. The only problem with that solution is that I don't personally know virtual computing enough (yet) to do it myself. Unless the game is specifically programmed for Linux, then there are tons of people out there who basically already do this without the GUI overhaul. (WINE) is used to do this for other games...
Never mind, I figured out why The Toady One feels this way... Everyone loves his game so much that they care about it. That leads them to get all emotional and lose that part of their brains that lets them think. Following this, The Toady One has to step in to moderate, and probably spends more time dealing with idiots than working on Dwarf Fortress (I have no idea, but knowing how long moderating takes compared to posts, and looking at The Toady One's posts tells me that he spends WAY to much time dealing with moderating to develop Dwarf Fortress as epic as he should.) I shudder to think how horrible life must be for The Toady One dealing with those people instead of working on his game. Who knows, perhaps if we were more civilized, Dwarf Fortress would be released by now.
Nevertheless, I know there is a solution, because I can dream of a solution. If you can dream there is a solution, and if science does not restrict it, there is a solution.
Post by: Dyret on July 13, 2014, 02:30:46 pm
Post by: fricy on July 13, 2014, 02:34:29 pm
and lol, yeah. if a gui revamp is not going to happen, but we are going to solve the problem with wine. sure. why not build a dorfputer and run the game on it? at least that has been demonstrated to work. :)
Post by: Draco18s on July 13, 2014, 05:28:45 pm
Post by: Mathig on July 13, 2014, 07:04:31 pm
I said READ through, not glance at the OP and come back and tell me why a gui api is different. because almost everything you can say about the topic has been discussed there. and you are wrong, it's NOT completly different.-sigh- Not really. Page six and I learned the following... The OP thinks realism and sandbox (art) are antithetic in spite of the real life being a counter example. He wants opensource and collaborative development in spite of The Toady One's desire to do otherwise. He wants frequent releases despite the increasing complexity. He wants Dwarf Fortress to be about bug fixing instead of feature development. And he wants less stone variety.
and lol, yeah. if a gui revamp is not going to happen, but we are going to solve the problem with wine. sure. why not build a dorfputer and run the game on it? at least that has been demonstrated to work. :)
The next six pages consists of people complaining over whether stone variety is better than stone mechanics. To explain the remaining 6 pages, I'll quote a nice little post on page 6: "Well, ok then. Read this entire thread, and kinda regretting it now. I did skip over any post that ONLY "bashed" the op though, because it added nothing to the argument, and is typical internet BS you find on facebook or youtube from kids." Except I read all the bashing... and I can confirm it is pointless.
None of that relates to having a select group of people work closely with The Toady One's code, not The Toady One himself, to develop a mod that creates an API to use GUI for.
Returning to my suggestion about using virtual computing to overhaul the graphics... Since people here are so illiterate, I'll explain the gist behind Virtual Computing...
Virtual computing has been demonstrated, as I am describing it, to work for dozens of programs in the example of WINE(Wine Is Not an Emulator). WINE is a Linux software that converts commands given to it in a Windows Operating system to commands that work for a Linux operating system. The whole point is that games interact with operating systems, not actual hardware, and programs already exist that act as operating systems but aren't operating systems. Thus, the difficulty in redesigning GUI is merely the difficulty in manipulating those emulators to give fake signals that register as real signals to the actual programs. There are dozens of working programs out there that do exactly that. Auto-it is the only one that comes to mind, but any botting software seeks to do this, essentially, and there are hundreds(probably thousands, but that might be an exaggeration) of those. Software like Unity can be used to monitor the screen to be more effective, but I'm fairly certain any programming language can be utilized to reassemble the GUI. Finally, the example of StoneSense would remove any barriers for running the command interface and the mapping at the same time, which I previously thought to be a potential issue.
Anyway, I happen to have not read up on directly programming software like WINE so I can't do this right now to get it over with already, but I'm sure the Linux community has some answers out there already for this on some FAQ questions.
Side note, why does everyone think I am someone else returned with a new account. What, is it that I know too much to be someone who just stepped in? Whatever... Trolls be trolling :P
Post by: Alev on July 13, 2014, 07:11:11 pm
There are a LOT of people who always want Toady to make DF open source, when he has stated multiple times that he will not do it, maybe not even post 1.0.I said READ through, not glance at the OP and come back and tell me why a gui api is different. because almost everything you can say about the topic has been discussed there. and you are wrong, it's NOT completly different....blah blah blah? blah blah. blah! blah blah, blah...
and lol, yeah. if a gui revamp is not going to happen, but we are going to solve the problem with wine. sure. why not build a dorfputer and run the game on it? at least that has been demonstrated to work. :)
Side note, why does everyone think I am someone else returned with a new account. What, is it that I know too much to be someone who just stepped in? Whatever... Trolls be trolling :P
Post by: Mathig on July 13, 2014, 07:37:38 pm
There are a LOT of people who always want Toady to make DF open source, when he has stated multiple times that he will not do it, maybe not even post 1.0.I said READ through, not glance at the OP and come back and tell me why a gui api is different. because almost everything you can say about the topic has been discussed there. and you are wrong, it's NOT completly different....blah blah blah? blah blah. blah! blah blah, blah...
and lol, yeah. if a gui revamp is not going to happen, but we are going to solve the problem with wine. sure. why not build a dorfputer and run the game on it? at least that has been demonstrated to work. :)
Side note, why does everyone think I am someone else returned with a new account. What, is it that I know too much to be someone who just stepped in? Whatever... Trolls be trolling :P
I don't even care about open source, it was merely the first thing that came into my sleep deprived head after spending hours trying to find answers on the forums. I care about making the GUI work.
Paraphrasing someone else, why hasn't someone simplified this massive debate so that new players can find the current status on the issue? I mean most of the threads are morons flaming someone for bothering to ask the question. Sure, the last time someone asked the question a flame war happened, but starting a flame war to prevent a flame war is hardly logical.
Post by: Draco18s on July 13, 2014, 08:33:17 pm
Seriously, this is a thing. Click it. (http://www.wired.com/2014/07/dwarf-fortress-3d/)
Post by: Alev on July 13, 2014, 09:09:34 pm
Yes, I saw that a few days ago.Seriously, this is a thing. Click it. (http://www.wired.com/2014/07/dwarf-fortress-3d/)
Post by: Draco18s on July 13, 2014, 10:21:53 pm
Seriously, this is a thing. Click it. (http://www.wired.com/2014/07/dwarf-fortress-3d/)Yes, I saw that a few days ago.
Trying to get Mathig to look.
Post by: fricy on July 14, 2014, 02:57:08 am
Paraphrasing someone else, why hasn't someone simplified this massive debate so that new players can find the current status on the issue? I mean most of the threads are morons flaming someone for bothering to ask the question. Sure, the last time someone asked the question a flame war happened, but starting a flame war to prevent a flame war is hardly logical.
Ok, You have a point there. There isn't a faq about it, just countless topics that the newbies are usually instructed to read when this comes up. And please understand that this and "why not multithread" comes up a lot, and the answer is always the same, and after the umpteenth time it's a bit annoying, that's one of the reasons for the flamewar...this week this is the 3rd time someone wants to beat the dead horse. damn, we really need a faq. :)
and wine:
No, virtualization is not the answer, especially not because the number one reason for fortress abandonment is fps death. virtualizing, starving the game of resources will make that worse. And no, there is no 100% efficient solution, that's a myth.
And if I understand right what you propose it has been already accomplished, it's called dfhack. there are lot's of UI tweaks that come with it, practically any memory structure can be manipulated/overwritten/whatever...IF you have the skill and the patience to figure out how to do it.You can think of it as an unsupported/unofficial API that tend to get broken with every new release.
Post by: Mathig on July 14, 2014, 04:05:59 am
I looked at it the first time and mentioned it directly in my post. Aside from my comment concerning it, it is irrelevant.
Paraphrasing someone else, why hasn't someone simplified this massive debate so that new players can find the current status on the issue? I mean most of the threads are morons flaming someone for bothering to ask the question. Sure, the last time someone asked the question a flame war happened, but starting a flame war to prevent a flame war is hardly logical.
Ok, You have a point there. There isn't a faq about it, just countless topics that the newbies are usually instructed to read when this comes up. And please understand that this and "why not multithread" comes up a lot, and the answer is always the same, and after the umpteenth time it's a bit annoying, that's one of the reasons for the flamewar...this week this is the 3rd time someone wants to beat the dead horse. damn, we really need a faq. :)
and wine:
No, virtualization is not the answer, especially not because the number one reason for fortress abandonment is fps death. virtualizing, starving the game of resources will make that worse. And no, there is no 100% efficient solution, that's a myth.
And if I understand right what you propose it has been already accomplished, it's called dfhack. there are lot's of UI tweaks that come with it, practically any memory structure can be manipulated/overwritten/whatever...IF you have the skill and the patience to figure out how to do it.You can think of it as an unsupported/unofficial API that tend to get broken with every new release.
Virtualization does have one flaw, and you named it. However it illustrates precisely the fix we need. The fix is to replace Dwarf Fortress's menu system, and map system, with a new map and menu system. The new one having better GUI, obviously. If Stonesense works as described, that proves the map can be overhauled. It literally is a map overhaul, and apparently it relies on DFHack which is even better. All that remains is the menu interface, and guess what? Dwarf Fortress runs entirely off keyboard inputs. That is where virtualization comes in. Or, more specifically, virtual key strokes. If building a masons workshop requires the input command b-w-m then so long as you can send Dwarf Fortress a virtual b-w-m independent of the actual keyboard, you can program an interfacing software that allows players to access the menu in a more fluid, natural, clean setting.
This, is where WINE comes in. WINE IS NOT an EMULATOR. Wine converts inputs(well rather it converts outputs directed at the Operating System, but it demonstrates my point) from a windows system to a linux system, and consequentially doesn't use a massive amount of overhead. http://en.wikipedia.org/wiki/Wine_(software) There is also the example of Botting and Macro software. These software types often convert single keystrokes into multiple keystrokes. For example, ISBoxer is a multi-boxing software that allows players to manage dozens of separate EvE programs simultaneously with the same effort as one program. The problem, is that I, personally, didn't develop WINE or ISBoxer, or any other virtual keyboard input software personally. So where-as I know it will work, I don't know what code is needed. Something like /send keystroke('b') dwarffortress.exe but the devil is in the syntax. It probably be best found by locating the developers of WINE etc. and asking them. Or I could open up WINE (which is open-source) and look around for it myself.
I guess I'm just hoping that I'm not the first person to think of this, and that someone is already way ahead of me and about to release the alpha version, so I don't have to do research. Or maybe that I might find enough support to have someone else solve it for me. Do I have any volunteers? Or am I not only the first person to think of this, but the first person to think of this who has any motivation to do it. -sigh- I'll add it on my list. Thanks all! Your motivational speeches really work... *grumble grumble*
Post by: Draco18s on July 14, 2014, 06:59:48 am
"Trying to get Mathig to look."
I looked at it the first time and mentioned it directly in my post. Aside from my comment concerning it, it is irrelevant.
You mean aside from being exactly what you want, you mean?
You're not getting the semi-open source Thing you want. Deal with it.
Post by: Jiri Petru on July 14, 2014, 01:37:44 pm
Not only you won't ever get open-source, you don't even need it to create a better interface. In fact, I believe we already have all we need to create complex UI overlays. See this thread (http://www.bay12forums.com/smf/index.php?topic=140604.msg5473111#msg5473111).
Post by: Mathig on July 14, 2014, 11:37:39 pm
Quote from: Dracos18s
You mean aside from being exactly what you want, you mean?Trolls be trolling, enjoy the sewer water under that bridge!
You're not getting the semi-open source Thing you want. Deal with it.
Can we please leave the same old, same old open-source discussion?Literally I JUST...
Not only you won't ever get open-source, you don't even need it to create a better interface. In fact, I believe we already have all we need to create complex UI overlays. See this thread (http://www.bay12forums.com/smf/index.php?topic=140604.msg5473111#msg5473111).
I guess I'm just hoping that I'm not the first person to think of this, and that someone is already way ahead of me and about to release the alpha version, so I don't have to do research.THANKS YOU. Now, someone go post this (http://www.bay12forums.com/smf/index.php?topic=140604.msg5473111#msg5473111), and a link to the actual download for the latest version of StoneSense in the FAQ under the FAQ "Why is the interface so bad, when is it going to be updated?" Then we can finally put an end to this cursed endless rabbit hole. I sought; I found. Why not make it easier for those that come after? Unless we want MORE of these threads...
By the way, someone should still utilize all the information in this thread here to modify the utility most recently mentioned. I don't know, whereas it might be a great proof of concept, I'm not to certain its the perfect end spot.
Post by: Jiri Petru on July 15, 2014, 06:28:18 am
Post by: Zarat on July 24, 2014, 09:14:26 am
"Trying to get Mathig to look."
I looked at it the first time and mentioned it directly in my post. Aside from my comment concerning it, it is irrelevant.Paraphrasing someone else, why hasn't someone simplified this massive debate so that new players can find the current status on the issue? I mean most of the threads are morons flaming someone for bothering to ask the question. Sure, the last time someone asked the question a flame war happened, but starting a flame war to prevent a flame war is hardly logical.
Ok, You have a point there. There isn't a faq about it, just countless topics that the newbies are usually instructed to read when this comes up. And please understand that this and "why not multithread" comes up a lot, and the answer is always the same, and after the umpteenth time it's a bit annoying, that's one of the reasons for the flamewar...this week this is the 3rd time someone wants to beat the dead horse. damn, we really need a faq. :)
and wine:
No, virtualization is not the answer, especially not because the number one reason for fortress abandonment is fps death. virtualizing, starving the game of resources will make that worse. And no, there is no 100% efficient solution, that's a myth.
And if I understand right what you propose it has been already accomplished, it's called dfhack. there are lot's of UI tweaks that come with it, practically any memory structure can be manipulated/overwritten/whatever...IF you have the skill and the patience to figure out how to do it.You can think of it as an unsupported/unofficial API that tend to get broken with every new release.
Virtualization does have one flaw, and you named it. However it illustrates precisely the fix we need. The fix is to replace Dwarf Fortress's menu system, and map system, with a new map and menu system. The new one having better GUI, obviously. If Stonesense works as described, that proves the map can be overhauled. It literally is a map overhaul, and apparently it relies on DFHack which is even better. All that remains is the menu interface, and guess what? Dwarf Fortress runs entirely off keyboard inputs. That is where virtualization comes in. Or, more specifically, virtual key strokes. If building a masons workshop requires the input command b-w-m then so long as you can send Dwarf Fortress a virtual b-w-m independent of the actual keyboard, you can program an interfacing software that allows players to access the menu in a more fluid, natural, clean setting.
This, is where WINE comes in. WINE IS NOT an EMULATOR. Wine converts inputs(well rather it converts outputs directed at the Operating System, but it demonstrates my point) from a windows system to a linux system, and consequentially doesn't use a massive amount of overhead. http://en.wikipedia.org/wiki/Wine_(software) There is also the example of Botting and Macro software. These software types often convert single keystrokes into multiple keystrokes. For example, ISBoxer is a multi-boxing software that allows players to manage dozens of separate EvE programs simultaneously with the same effort as one program. The problem, is that I, personally, didn't develop WINE or ISBoxer, or any other virtual keyboard input software personally. So where-as I know it will work, I don't know what code is needed. Something like /send keystroke('b') dwarffortress.exe but the devil is in the syntax. It probably be best found by locating the developers of WINE etc. and asking them. Or I could open up WINE (which is open-source) and look around for it myself.
I guess I'm just hoping that I'm not the first person to think of this, and that someone is already way ahead of me and about to release the alpha version, so I don't have to do research. Or maybe that I might find enough support to have someone else solve it for me. Do I have any volunteers? Or am I not only the first person to think of this, but the first person to think of this who has any motivation to do it. -sigh- I'll add it on my list. Thanks all! Your motivational speeches really work... *grumble grumble*
I just wanted to add quickly that there's a major misunderstanding of what virtualization is in this thread. WINE is simply a re-implementation of Windows libaries on Unix-based systems. There is no overhead to WINE, because it boils down to just adding Windows libraries on Linux. WINE is not an emulator. Wine is not virtualization.
There is actually very little overhead of x86-based virtualization, because most processors these days are sold with virtualization features enabled. But there would be no gain to running DF in a virtualized system.
What you seem to be talking about is simply catching keystrokes and mouse movements and passing them through an additional layer which translates them into the canonical DF commands, which is basically no overhead at all. That's not virtualization or emulation either, though.
Post by: Nopenope on July 25, 2014, 06:17:39 pm
Post by: Bumber on July 25, 2015, 07:34:32 pm
The thread shudders and begins to move!
Posting this here for relevance:
For example,
Avron Zeronozada
Male, 126
Married to Obakhekh Otoderozera, 2 children
Fishery Worker, Proficient Fisherdwarf
Civilian, Striker
Dreams of creating a great work of art.
Owned Objects: 10
No rooms.
"I'm doing alright".
Instantly I know he needs a job change to an art profession, should be assigned a larger bedroom because of his family size, and all of this replaces the main profile page, which presently, following 'most logical format possible', is...
(http://i.gyazo.com/942afeae857348fadea3d55ad5e6aa49.png)
Your eyes slide off this black space -every time- you are on your way to another screen in the profile. How many times have you selected a dwarf to see how many rooms he's assigned? How many times was this page just a pop-up box to be dismissed on your way to the personality profile? Which, most logically, should be shown here?
Post by: Tristan Alkai on August 15, 2015, 09:14:24 pm
Post by: Draco18s on August 16, 2015, 12:02:33 am
I have some ideas, but if anyone wants a mockup then I will need instructions on how to post images to the forum.
http://postimage.org/