Print

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

[sivael]

How? Simple - allow the game to be a big library out of which you extract information - for example:
You have a terrain in your Engine. The "client" doesn't know it yet, but what it does is it asks the Engine for the terrain data - engine replies with a chunk of tiles. UI needs to intepret the information and display proper glyphs and such.

Also, You simply make a notification queue that the client can browse and display or discard(for example "dwarf x moved")

Now the types of messages can be exactly the same as in your original application, and all You have to do is make the original UI "hidden".
All the orders either way have their handler methods - so why not let others call it?

For example you want to create a farm - a user selects an area with a mouse, right clicks, make -> farm(probably a very dumb idea to make it directly under the "make" submenu but yeah...) now Your application receives a rectangle(If it needs to be selected first, it is, via APIs) and what to do with it.

Simple, elegant solution for humanizing the interface. And that would mean that You don't need to worry about the interface any more than You do now, all you would have to do it export some methods. Others would create and work on an engine that would display and interact with the user(possibly in a separate thread)

What do You think?

[GreatWyrmGold]

Well, first off, many people HAVE been programming to make DF's UI more user-friendly. I never use them, but my hat's off to them nonetheless.

Second off, it strikes me that separating the "user interface" from the rest of the game would e an arduous task, since the two are kinda interwoven. Just the display? Simple enough--but that's what the most work has been done to improve.

Third off, Toady intends to improve UI some day, just not until the features are mostly complete.

[10ebbor10]

Fourth, Toady has said that he will not make an User API, because he doesn't want to have to deal with the complaints when they break after every major release.

[sivael]

1. Yes. But those are only UI wrappers:P
2. User interface displays data that's stored elsewhere - for example it displays a dwarf object at x, y coordinates. The same way that it's sent to the current UI system it could be sent to another.
The argument that a lot of work has been done on it to improve it - well... yes. But maybe it needs a revolution not an evolution?
3. Why not let others do that? It would still let him control and create all the aspects of the game, just not force the UI to be rougelike. (I personaly like rougelikes, but the simpler, more accessible ones like Angband)

4. Yes, they might break every major release... but would they most of the time? I would say - no.
All You need is to version the methods.
If a version in the code is different than the version in the UI, it will raise a message that this UI is not yet compatible with: "Adding job priorities to a dwarf", added in version "0.36". Please report this to "newUICreator@hismail.com"

But if that's his decision, then I guess that's final...
Shame though.

[GreatWyrmGold]

1 and 2 require mutually exclusive definitions of "User Interface." 2 requires that it only be the display,but the only-display thing is referred to in 1 as "UI wrappers."
2: What do you mean by "revolution, not evolution?" Do you mean Toady should spend tons of time on a completely new UI that will need to be fixed every major update?
3. Dwarf Fortress is Toady's magnum opus. He doesn't want to share the work with anyone. This has been brought up a lot.  Besides, it's not like Toady has tons of income to blow--donations are pretty much his only income.
4. Well, most of Toady's time is spent on major releases, so...yes. The UI isn't a separate thing from the game, unless you're thinking of the "wrappers."

[sivael]

1 and 2 - yes. But unless the code is a total mess (and it shouldn't be as the game is more or less data driven) it should be relatively simple to implement.
2. Revolution as in I think that the interfaces require an overhaul, but not necessarily from Toady's side. Maybe let others create other UIs - it's done partly anyway but in a *very* limited way I just want others to have the power to create it properly:P
3. And I understand this. If You think of Dwarf Fortress - what's the first thing that you notice? The system. The incredibly complex and fun system enabling incredible amounts of emergent gameplay and such. And the system - The Dwarf Fortress is still all in his hands. Just enabling better UIs may be a way to increase the donation rate by introducing more people to Dwarf Fortress by easing the UIs.
I'm not saying - dumb down the game. I'm not saying alter it. I'm saying - maybe there are better ways to interact with a game than what we have at the moment?
4. I have seen the changes and they - indeed - are big. But the question is - would they break the UI. And I think not if the UI is written well.
He can also require that all the UIs that anyone but he creates are to be in public domain or something and that he can use the code to do whatever he wants to. This way he would be able to switch to the best UI that emerges. I'm not saying also to drop the "tiles" or use graphics for everything. People will do so anyway but his new patches can introduce new letters and colors without problems...
^
This is not to convince You that I'm right. It's just so that You understand my way of thinking.

And I would love a good UI for this game:P

[GreatWyrmGold]

1 and 2 - yes. But unless the code is a total mess (and it shouldn't be as the game is more or less data driven) it should be relatively simple to implement.

How does this address your contradictions?

2. Revolution as in I think that the interfaces require an overhaul, but not necessarily from Toady's side. Maybe let others create other UIs - it's done partly anyway but in a *very* limited way I just want others to have the power to create it properly:P

I see. How on earth could Toady let them do more than they have? Look at Dwarf Therapist, DFhack, etc. There's plenty of will and way.

3. And I understand this. If You think of Dwarf Fortress - what's the first thing that you notice? The system. The incredibly complex and fun system enabling incredible amounts of emergent gameplay and such. And the system - The Dwarf Fortress is still all in his hands. Just enabling better UIs may be a way to increase the donation rate by introducing more people to Dwarf Fortress by easing the UIs.
I'm not saying - dumb down the game. I'm not saying alter it. I'm saying - maybe there are better ways to interact with a game than what we have at the moment?

Maybe. Toady's not likely to add others' work into his game, though, so don't expect him to.
As I said, people have already improved the UI with various utilities, so there's not a lot of point in designing DF to be able to have improved UI. It would probably just break said utilities.

4a. I have seen the changes and they - indeed - are big. But the question is - would they break the UI. And I think not if the UI is written well.

UI is based on the inner code. Unless you're just referring to graphics--which are already as moddable as it can really get--the UI is set deep in the code. Each time the way dwarves choose jobs changes somehow, whether by adding new ones, improving AI, whatever, the UI with assigning jobs would probably be affected, especially if it's as complex as you seem to think it should be. Trust me, it's almost always more complex than you think it will be.

4b. He can also require that all the UIs that anyone but he creates are to be in public domain or something and that he can use the code to do whatever he wants to. This way he would be able to switch to the best UI that emerges. I'm not saying also to drop the "tiles" or use graphics for everything. People will do so anyway but his new patches can introduce new letters and colors without problems...

Again, TOADY WILL NOT INCLUDE STUFF OTHER PEOPLE MAKE IN HIS MAGNUM OPUS.

This is not to convince You that I'm right. It's just so that You understand my way of thinking.

And I would love a good UI for this game:P

Alright. You have succeeded in that. Congrats.
I guess I'd like one too, but I'd rather have new, if buggy, features than an equally buggy way for people to make better UIs.

[10ebbor10]

1. Actually not. Currently the UI and game engine are pretty entertwined. (More so than the game and graphics part, which are actually seperate threads.) Hence why the game pauses while you designate, amongst other things.

2. Don't forget the managing program (DF foreman or something) that actually ran as part of DF.

3. AFAIK, Toady used to be more open about the game and it source code, untill some forum members reverse engineered it and made it their own game. Don't know what happened with it.

4. They kinda will. Memory adresses change, entire menus are added or replaced. Even adding a singe item category could break the whole thing.

5. Can't we use a system similair to Dfterm + Stonesense and use that as a different UI. Stonesense esque visuals, and Dfterm had a way of remotely controlling stuff.

[sivael]

How does this address your contradictions?

I did not contradict myself. UI is display plus getting input and sending orders to the game engine.

How on earth could Toady let them do more than they have?

Like I said - make the UI a separate part of the engine and work through APIs.

Toady's not likely to add others' work into his game, though, so don't expect him to.

"The Game" and the UI are - I believe - two different things in this case.

Each time the way dwarves choose jobs changes somehow, whether by adding new ones, improving AI, whatever, the UI with assigning jobs would probably be affected, especially if it's as complex as you seem to think it should be. Trust me, it's almost always more complex than you think it will be.

Ok. If the interface reads a list of states a dwarf can have and displays one of them on a dwarf. the same with his leg or whatever. The interface can be just as data-driven as the game itself is. Assigning jobs - if you need to assign a job to a dwarf, then you do it. The new job cfor a dwarf can be simply an entry in the description files. It's been done already.
Look. I'm a programmer. I do that for a living. I know that it can be done and how it can be done. Because the process is essentially the same for every data-driven system. All you need is good design.

1. Actually not. Currently the UI and game engine are pretty entertwined. (More so than the game and graphics part, which are actually seperate threads.) Hence why the game pauses while you designate, amongst other things.

If the game part and the graphics part are separate threads, it's just one step further.
The game pauses because the UI tells it to. Not because it's magically connected.
It's a simple: "Hey... engine. stoopp... he's designating a new garbage dump... it's gonna take a while."
And later" Ok, engine - this is the new designation, do what you will. Now start again."

2. Don't forget the managing program (DF foreman or something) that actually ran as part of DF.

Yes. But that's all still another pretty much hacked-in tool.

3. AFAIK, Toady used to be more open about the game and it source code, untill some forum members reverse engineered it and made it their own game. Don't know what happened with it.

Wow. Didn't know that. It's a shame though:/

4. They kinda will. Memory adresses change, entire menus are added or replaced. Even adding a singe item category could break the whole thing.

Memory addresses don't matter when you do an API.
Entire menus don't matter if all you have is a list of actions that you can take, and that's categorized.
Adding an item category would in fact not break the system that's data-driven. It would simply work. Remember, that UI can have the same base data that the engine has.

5. Can't we use a system similair to Dfterm + Stonesense and use that as a different UI. Stonesense esque visuals, and Dfterm had a way of remotely controlling stuff.

I think that isometric is not the way to go.
1. Top-down gives you a much better overview over what actually happens where.
2. Can't cope with ASCII properly(it could be used as a fallback for items that have no sprites thus making additions to the engine not require graphics department.
3. I would rather have a ood way of controlling stuff ingame than through external tools. That's kind of my point. Not saying something like this wouldn't be used, but rather - it could be integrated easily.

[Trif]

BEFORE POSTING A SUGGESTION

    Check our development pages. You can find everything in one place at this link.
    Search for an existing thread. If you find a thread similar to your idea, you can bump it to expand on the suggestion, even if the thread is old.  However, please do not bump threads just to show support.

Improving the UI has been suggested many, many times in the last years, and an API isn't a new concept either. Toady is very aware of the fact that the current UI could use some (or a lot) of improvement. He also knows that he'll work on DF for 20 more years before it'll be out of the alpha stage, so he can decide when a new UI is appropriate.

If you want to read a discussion about an API, read this thread (Toady explained his opinion in detail there). Let's not repeat old arguments here.

[sivael]

Thank You for the links. Although I disagree with Toady about what would be best for the project, I can understand his arguments. Shame, shame...

Anyway - thank You:P

[GreatWyrmGold]

How does this address your contradictions?

I did not contradict myself. UI is display plus getting input and sending orders to the game engine.

Sure. My arguments are bogus and you didn't acquiesce that point.
Oh wait, they're not and

1 and 2 - yes.

How on earth could Toady let them do more than they have?

Like I said - make the UI a separate part of the engine and work through APIs.

As mentioned, the UI and game are pretty much intertwined. I'm kinda amazed at those people who managed to make Dwarf Therapist and its ilk.

Toady's not likely to add others' work into his game, though, so don't expect him to.

"The Game" and the UI are - I believe - two different things in this case.

Debateable. Unless Toady comes, we'll just be butting heads over this argument, but like said earlier, they're as inextricably intertwined as Hershey's and chocolate.

Each time the way dwarves choose jobs changes somehow, whether by adding new ones, improving AI, whatever, the UI with assigning jobs would probably be affected, especially if it's as complex as you seem to think it should be. Trust me, it's almost always more complex than you think it will be.

Ok. If the interface reads a list of states a dwarf can have and displays one of them on a dwarf. the same with his leg or whatever. The interface can be just as data-driven as the game itself is. Assigning jobs - if you need to assign a job to a dwarf, then you do it. The new job cfor a dwarf can be simply an entry in the description files. It's been done already.
Look. I'm a programmer. I do that for a living. I know that it can be done and how it can be done. Because the process is essentially the same for every data-driven system. All you need is good design.

I'm not a programmer, but I know that "good design" changes with what you're designing it for. DF 0.28.01 isn't like 0.38.01 will be. Toady's a genius, but he's not precognitive--he can't know what the UI will need to have programmed in 20-30 years from now. He didn't even know he was going to add in vampires and such when he did until he basically went, "I need to add vampires."

1. Actually not. Currently the UI and game engine are pretty entertwined. (More so than the game and graphics part, which are actually seperate threads.) Hence why the game pauses while you designate, amongst other things.

If the game part and the graphics part are separate threads, it's just one step further.
The game pauses because the UI tells it to. Not because it's magically connected.
It's a simple: "Hey... engine. stoopp... he's designating a new garbage dump... it's gonna take a while."
And later" Ok, engine - this is the new designation, do what you will. Now start again."

Um...what relevance does your statement have to the topic at hand? We get it. However, your argument doesn't address that the two codes--"engine" and "UI" are darn intertwined.

2. Don't forget the managing program (DF foreman or something) that actually ran as part of DF.

Yes. But that's all still another pretty much hacked-in tool.

So? Doesn't it still do pretty much what you want to be able to do?

4. They kinda will. Memory adresses change, entire menus are added or replaced. Even adding a singe item category could break the whole thing.

Memory addresses don't matter when you do an API.
Entire menus don't matter if all you have is a list of actions that you can take, and that's categorized.
Adding an item category would in fact not break the system that's data-driven. It would simply work. Remember, that UI can have the same base data that the engine has.

Willing to bet Toady hasn't made it that simple. DF isn't like a big-name game, where it was broken down into parts before being programmed. It was built piecemeal, making it more of a tangled grove than silviculture, to use an elfy metaphor. Toady has said so himself, although not in the same way.

5. Can't we use a system similair to Dfterm + Stonesense and use that as a different UI. Stonesense esque visuals, and Dfterm had a way of remotely controlling stuff.

I think that isometric is not the way to go.
1. Top-down gives you a much better overview over what actually happens where.
2. Can't cope with ASCII properly(it could be used as a fallback for items that have no sprites thus making additions to the engine not require graphics department.
3. I would rather have a ood way of controlling stuff ingame than through external tools. That's kind of my point. Not saying something like this wouldn't be used, but rather - it could be integrated easily.

1, 2: Obviously not, since there's Dfterm and Stonesense and such.
3. I use vanilla DF, no utilities or graphics or anything. No problems here except goblins and stupidity. Oh, and kobolds, badgers, carp, floods, megabeasts, zombies, falling logs...look, not UI.

[King Mir]

The biggest issue with creating an API for the interface, that Toady has stated, is that the interface is constantly changing as features are added. For example, the new domestication interface from the last major release, or the new multi-tile trees in this one. If people play the game via a front end that Toady does not write, then Toady must depend on the developers of that front end to incorporate the features he adds, before those people can use them. Toady does not wish to depend on other developers; they can be undependable.