Print

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

[Putnam]

Dwarf Fortress isn't an "indie perpetual alpha".  It just has a very (very) large requirements document, and Toady has only gotten about 30% of the way through that list.  I'm sure Toady will rework the UI once enough of the game is completed that the chances of major UI reworking are minimal.  Doing the UI rework before that point is, at best, wasted effort on his part.

Nah, there's some mention of post-v1 stuff.

[MrWiggles]

And we also shouldn't forget that the UI does get worked on, every now and then.

[ShadowHammer]

The controls do exactly what you expect them to at all times if you know what they do.

Well, can't argue against that...

[Aatch]

I don't normally get involved with threads like these, but programming is being talked about.

User interfaces are hard. There's no two ways about it. It takes a lot of effort and know-how to implement a good interface. DF's user interface is bad, based on standard ideas of what makes a good interface, but not because it's ugly or requires arcane key sequences. It's the inconsistency. Unfortunately, there is more to consistency than just "Same key to make bins in all workshops" etc, etc. There's the matter of visual consistency, when you can and can't use the mouse and various other things. Those things will change as the project develops. Because they require a good understanding of the entire system to know what broad strokes to use, you have to take a high-level view of the project, but the project isn't done yet!

Personally, I agree with the general suggestion that Toady should expose some hooks that effectively allow other developers to write their own interfaces. However, I can certainly see why he could be against that.

[reality.auditor]

Any UI made afterward would have to either be up to the standard of the new UI (I.E difficult and time-consuming to make) or made as Toady wants to (not up to snuff).

On what basis you assume that adding New UI components to handle new features after rewrite will be harder than adding Current UI components to handle new features?

Example to consider: do you think creating military screen (one of new things between 40d and 0.31) was "constant overhaul"? Why?

Dwarf Fortress isn't an "indie perpetual alpha".

Yes, it is. I will be blunt: development of DF will end when Toady will die of old age.

Doing the UI rework before that point is, at best, wasted effort on his part.

According to this logic, everything that Toady does right now is wasted effort, as in next 20-30 years everything currently in game will be rewritten more than once. Singling out and criticizing just UI on that basis is unfair.

And we also shouldn't forget that the UI does get worked on, every now and then.

Oh noes constant overhaul!!1111oneonoene.

[Putnam]

Any UI made afterward would have to either be up to the standard of the new UI (I.E difficult and time-consuming to make) or made as Toady wants to (not up to snuff).

On what basis you assume that adding New UI components to handle new features after rewrite will be harder than adding Current UI components to handle new features?

Example to consider: do you think creating military screen (one of new things between 40d and 0.31) was "constant overhaul"? Why?

Read what I said earlier. Components have nothing to do with it. The components are well-designed. The issue is the high-level UI design, which has absolutely nothing to do with components and everything to do with presentation in the form of organization and consistency, both of which have to be constantly kept in mind.

[wierd]

Indeed.

What I personally would rather see, given the reasoning presented by toady one and others-- and why:


The core game does an "abstraction" for what tiles to present in game, which is internal, and changes at toady's whim-- coupled with a high level presentation wrapper, which maps the internally abstracted token with either a set of text glyphs (ncurses mode) or a tileset image.

Basically, say-- "a kitchen" gets an internal "kitchen" token, which then goes to the configurable presentation layer, and either gets the appropriate 9 character grid, or a 3x3 tile size sprite displayed. Toady then just deals with the internal tokens, and has a generic wrapper for presentation. Keeping a graphics pack up to date between versions is already something that graphics pack makers have to do themselves anyway. Toady would just have a "default" presentation descriptor file with only minimal upkeep, and no assurances to modders that the presented token entities will stay consistent between versions.

What that would give us:

Since more than just creatures would have abstracted tokens that can be paired with sprites, we could not only display "bush", but have specific glyphs for type of bush. A kitchen could be stylized to actually look like a kitchen, etc.

Again, all *that* work would be the onus of the graphics pack maker. Toady just has to keep the ncurses section up to date and that's it. He already has to do that amount of work now anyway.

Being able to fully "window dress" the game like that would go a long way toward resolving the constant and continual "graphics are ugly! Eww!" Complaint-- it would put the onus on THEM to make the graphics to their own liking.

Key bindings are already user configurable, so that part of the UI can be modified right now. The last remaining part of the UI is just how the menu system is laid out.

Getting the above change in how graphics are selected by the presentation code in conjunction with the existing keybindng mod capabilities would allow a nearly "from the ground up" windowdressing of the UI in a modpack fully possible. Toady's "slow" release cycle makes maintaining modpacks like that reailistic. (We already have things like LNP and pals, after all.)

The major bottleneck for user-created graphics packs is the re-use of glyphs. The "male" symbol gets reused for bags, et al.  Tokenizing "bag", and then allowing the presentation layer to take the "bag" token and do whatever it wants with it afterward would break this "hard association" restriction. (The default would just say to use the "male symbol" anyway, but the point is that you could instead point it at some other character, or at a sprite index instead.) It would allow graphics that don't muck up the text of the UI, and sprite loading and indexing code is already present in the game right now anyway. Seperating the internal tokenized entities from the presentation code would have other beneficial effects for later code modifications as well, since the two would be mostly independent of each other. (Meaning it toady finally felt the game was mature enough gameplay-feature-wise that UI improvements were a good use of his time, doing those improvements wouldn't break the core game mechanics, because it would be isolated.)

I fully "get" why toady doesn't want to change the default presentation away from ascii, and wants it as dead-simple as possible. But implementing the above change would work out in his benefit much later down the line, and would give the "UI is ugly!" Crowd a bone to quiet them up at the same time. I really don't comprehend why he hasn't done it.

[BoredVirulence]

Obligatory response:

As many other programmers mention. Interfaces are mean, for far too many reasons to mention. But that's not the real issue, its not that he doesn't want to deal with interfaces, its the time required to maintain a quality interface as new features are added.

Even if he makes a better interface now, as he adds features he will have to spend time making sure those new features have proper corresponding interfaces. He will spend his time covering holes because certain features aren't implemented, and insuring that everything remains consistent. This is maintenance. For every feature he adds, he will have to make sure its on par with everything else, if he didn't the inconsistencies he will have the same problem we have now, making the effort meaningless. Couple that meaninglessness with the knowledge that everything will need to be redesigned as those features are updated, and you are looking at a lot of unnecessary work. If you're getting paid to do it, you suck it up and do it, but we aren't paying him, we're donating money because we like what hes already doing.

I agree he should create an API for outside developers to work with. At the same time though, he looses control of the game, and risks alienating and fracturing the fan-base. However, that happens regardless. We use memory hacking applications to change our experience, and he seemingly has no qualms about that, a proper API would do the same thing, except perhaps release more control than he is comfortable with.

[wierd]

He's already released a sort of API that would work here, in the form of the structured raw files.

All I am really suggesting is moving some of the data currently held in he entity data into its own raw, which then tells the pesentation system how to roll.

Eg, the custom workshop raws currently state what glyphs to use for the workshop space, et al.

Most of the functionality I suggest above would be accomplished just by that restructuring, and by restructuring it, it would actually make maintenance easier. (Since the presentation data would be all in one place, and easy to manage; compare against hunting through 20+ raw files. As the number of creature and item entities increase, leaving these jumbled together represents an exponential curve in difficulty to maintain. Seperating them makes it just a linear one. It really is the sane choice.)

All that needs to pass to the presentation layer is a small object class, that has the following members:

String (Token)
UnsignedInt (color index)
Boolean (Multitile yes/no)
UnsignedInt (width in tiles)
UnsignedInt (Height in tiles)
UnsignedIntArray(X,Y,Z coords of entity's top left corner)

Basically, the game engine proper tells the presentation engine that X entity token has X color assigned to it, where it is, if it is multitile or not, and how many tiles it consumes. The presentation engine is unconcerned about the nitty gritty details of the object it is depicting; that's the game engine's job to worry about.

The rest is handled by the presentation engine, which has its own raw file, with the following data in it.

[Entity token]
[Ncurses mode glyph string]
[GraphicsTileBitmapPath]
[GraphicsModeTileIndexAssignments]

Again, by default all toady needs to populate is the EntityToken and Ncurses glyph string portions. Generating this file can be done automagically because of its simplicity. It basically lists every single entity in the current game, and what characters to use to display it. (Or what tiles).

The game as-is already has code to load tiles, it already has some level of graphics engine abstraction in place, etc.  This functionality would be relatively easy to implement, and would make entity maintenance easier later down the line, and would save a good deal of pain and suffering on toady's part when v.99B comes out 20 years from now, and he feels he's ready to do UI work. (The same structure could feed a 3d presentation layer as well as a 2d one, with only a litte tweaking. The game engine tells the presentation layer what entity token to display, where, and what color(s). The presentation layer then queries its own raw file, and works accordingly.)

Another side effect is that the two layers could work as seperate worker threads in the parent process with minimal effort.

The big deal, from a modder standpoint at least, is that the hard associativity between a glyph and an entity is broken, at least for graphics mode anyway.  This means the text glyphs can be left unspoiled, allowng the UI to not end up with pictures of bags and amulets all in the windows, while the game properly displays bags and amulets in the play window.

The longer toady puts off that kind of housekeeping, the harder it will be for him later on.

I can't force toady to do anything, and I don't presume to. I am just speaking my mind on the matter. Toady will do what toady will do. I am fine with that; this is HIS game. He can write it however he likes. That still doesn't make the current arrangement efficient to maintain.

[Putnam]

How would that glyph string work? Tiles in buildings, creatures etc. are as of now are read as a uint_8 (0-255). I think it would make far more sense to keep building, item raws etc. and instead just build on top of current creature graphics by having, say, this system for building graphics:

Code: [Select]

[TILE_PAGE:BUILDINGS_FOR_DWARVES]
[FILE:folder/file.png] file that contains all BUILDINGS_FOR_DWARVES tiles
[TILE_DIM:16:16] size of each tile in pixels, w:h. Does not have to match tileset being used, even in actual current version of DF.
[PAGE_DIM:12:30] size of page in tiles, w:h

Here's where it gets different.

    [BUILDING_GRAPHICS:SOAP_MAKER]
        [START_TILE:0:0:0] the first 0 is the stage; the other two are the tile in the tile page.
        [START_TILE:1:4:0]
        [START_TILE:2:4:0] 4:0 is the top-left corner of the building's sprite; the rest is filled in using the building's DIM. For example, the SOAP_MAKER there has a 3:3 DIM, which means that the SOAP_MAKER graphics when fully built will be:
4:0 5:0 6:0
4:1 5:1 6:1
4:2 5:2 6:2

Coloring could probably be done similarly to buildings, but more like this:
    [COLOR:0:0:MAT:AS_IS:MAT] first 0 is stage; second is row.
    [COLOR:1:0:MAT:AS_IS:MAT] MAT refers to being colored like the material; AS_IS means as the graphics are.
    [COLOR:2:0:MAT:MAT:MAT]

Buildings are the most difficult example I could think of, so I thought of how that could be raw-ified graphics wise.

Also, the word "entity" is a terrible one to use there, since "entity" in Dwarf Fortress refers specifically to organized groups of creatures; in the raws, this refers exclusively to civilizations.

[wierd]

I fully concede the "entity" nomenclature being confusing, but I can't really give an alternative that isn't similarly confusing.

"Object" has a specific meaning in programming parlance
"Identity" could well be confused for "name" in regard to named creatures/trees and the like and lacks the generality of the class intended.
"Feature" has a specific meaning in game context as well..

You get the idea. I admit that the choice was poor, but I really don't have a suitably concise word to use.
In defence of the choice, there *are* multitile creatures in the game. (Wagons ftw.) As such you would need the same code for handling creatures as you would need for buildings anyway, and imposing a distinction at presentation introduces unnecessary complexity. Basically, buildings are just entities that never move, as far as the presentation system is concerned.

Again, toady can do it however the hell he wants. He's entitled to that. However, I'm entitled to disagree with that choice, but I am not entitled to tell him what to do.  As long as that line is never crossed, there will never be a problem. This thread asked an opinion, and that's all I am offering.

The problem with leaving the presentation information in the current raw structure is fairly easy to comprehend:

Let's look at the rate of new creature addition per minor release toady has been doing-- toady uses new entity perks as a reward for generous donations, so it is safe to assume that the rate of these inclusions will be rapacious, and will continue to be so for the foreseeable future. From the standpoint of a tileset maker, the more entities you include in your graphics pack, the more entity entries you have to manually change and maintain in your pack. The more raw files you have to touch increases the chances of several major problems happening when updating a graphics pack for a new release:

Risk of inadvertantly creating a duplicated entry
Risk of mangling the entity heirarchy with a typo
Risk of number of files that could potentially have errors introduced to them by maintenance
Number of files can increase in proportion to the number of categories toady breaks them into
Significantly more complicated laundry list to check off when doing the maintenance.
A graphics pack has to be very carefully merged with any other mods (say, Masterwork) manually.

Putting the presentation data into its own little raw gives the following perks:

A duplicated presentation entry won't make you embark with fleshballs, or have dwarves drinking foeted ooze.
The risk of breaking the game engine becomes essentially zero, making the game-changing consequences of using a graphics pack less severe. You will just get goofy graphics.
Maintaining a graphics pack becomes considerably easier.
The presentation code can run in what is essentially a vacuum from the game code, since they don't even use the same files.
It allows toady to make large changes to the other game raw files, and if the tokens don't change, then a graphics pac has a good chance of simply working as-is. (As opposed to having to manually parse and edit each and every raw file)
It is very easy to see what new entities have been added on a new release just by running a diff on the presentation raw against its predecessor vanilla flavored file. (If the files are identical, then the pack will work as-is! Otherwise, the diff with clearly show what new members to add, and they all go in one neat little box.)
Gameplay mods update different files from graphics mods, making the risks of causing chaos from mixing and matching them much lower.

Basically, it just avoids a byzantine cockup in the making from happening as the game gets ever more complicated and feature enriched, and saves lots of headache in the modder section.

[Putnam]

I was saying specifically that it should be placed into the graphics subfolder in separate files from the objects, yes >_>

Also, object is the correct term here.

[wierd]

Sounds like we agree then.  I really don't care a whole lot on the how's, but more on the why's.  As long as the implementation is reasonably consistent, does not introduce more problems than it tries to solve, and provides a workable solution to the complaint issue with minimal headache, I consider it a good implementation.

That means that if the game currently does something X way, the best way to go is to retain as much of that process as possible to avoid "unforseen consequences".  That's a complete no-brainer to anyone trying to write software, and why I pointed out that the game already has code that does basically everything I suggested already.

I am disappoint that DF tries to do everything in the outdated OneBigThread model, when many aspects of the game could clearly benefit from thread parallelism, but that's just my opinion, and short of writing one hella binary patch, there isn't much I could do about it. (The work to do that would be wasted anyway, because I would have to write it all over again on the next release. As such, it's pointless to complain. I still disagree with the choice though.)

The big thing I want to see in regard to the "UI is ugly!" And "graphics look like something from 1980!" Canards, is an expanded graphics mode that allows full abstraction away from strongly enforced glyph assignments.

Coupled with a graphics pack, a custom monospace TTF font, and a custom keybind file, you could completely facelift the game without changing much of anything under the hood.  The major hold up to that is the inability to designate sprites for buildings and non-creature assets in a font-agnostic fashion in graphics mode.

Having the ability to point to that option, and say "get to work" would go a long way to resolving the recurrence of threads like this one. That, and the large number of simple low hanging fruit that abstracting the presentation system from the game engine offers is what makes me wonder why it hasn't happened.

I don't want toady to revamp the UI code, he's already provided a means to remap basically every key combo as it is. We can practically do that ourselves now. The hold up is that we can't improve the menu appearance without cocking up the game, or beautify the game without cocking up the menu.

Fixing that would make a full facelift possible.

[Oort]

The reason Dwarf Fortress is so awesome is because the simple graphics don't distract from the development of actual gameplay. It's like reading Tolkein and complaining that there isn't a picture on every page.
Have some imagination. I think you guys are playing the wrong game.

[wierd]

For me, it isnt like that at all.

I dont really mind, other than I dislike contrivances, and love options. If you note, my opinion on the matter would not remove ncurses mode at all, and would only add more flexibility, and remove hassle.

It isnt a complaint about the game being ugly aesthetically. It's a complaint about the game being needlessly restrictive, which then in turn makes a fairly large portion of the player base crabby. A simple fix could adeqately address the problem, and would save him a world of hurt later on.

that's it.