Print

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

[Deathworks]

Hi!

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

[RAM]

Has anyone started a player-made game documentation thread yet?

[zwei]

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.

[Deathworks]

Hi!

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

[Jiri Petru]

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    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.

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.

[Zalminen]

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...

[HideousBeing]

You could do a check to see if the room has furniture in there when you designate it, but I don't really think it's necessary. Simply designating that as a "bedroom" zone should be fine; it just wouldn't provide benefits to the dwarf unless it had furniture. Like having a new house, but you haven't moved in all the furniture in yet, so you sleep on the floor with a couple of blankets.

[robolee]

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. Plus there's the fact that you're gutting a few of the things like the map panel which I doubt toady would get rid of.

heres my mock-ups:

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.

[Footkerchief]

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:

# 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.

[Jiri Petru]

Robolee: thanks for your mockups! It's definitely an improvement over the present DF but I'm afraid that more than anything it has shown the interface mustn't be limited to the game grid. It's really just an annoying limitation, and I think your Jobs screen is a good example - it's really clumsy because of the grid and you can't fit almost anything in there. Imagine how much better it would be if you could fit more text in the same space.

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.

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.

I absolutely agree with these though 

[Atanamis]

Jiri, that's a beautiful interface and well organized. I agree with you that the reorganization is the key thing, and that furniture based room designation has to go.

[marcusbjol]

OK here it is.  Outsource it Toady.

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.

[Footkerchief]

Pretty cool demonstration of what DF's interface could look like.

[hermes]

I like the proof of concept (though it is quite straightforward!).  Since DF already has mouse support, it's really only a question of time and more feature-freezes to get something like that working.  Perhaps the month end project?  (Does anyone know what that is by the way?)

[Footkerchief]

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.