Print

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

[Mozleron]

I have been looking through some of the threads pertaining to interface changes, and while there are a lot of good ideas out there, there is currently no way to really test any of them.

My idea is an interface into DF that allows a UI to be layered over the top of, or inserted in place of the current system.

Something like this would require a very distinct boundary between the engine and the UI components of the game, and opening up of some of the calls into the game engine itself, either through some kind of API, or via some kind of script engine.  Honestly, i'm not really sure about the actual implementation requirements, this is just an idea and not a full fledged solution after all.

Essentially, if we are able to create actual interfaces, either based on the current one and tweaked, or completely re-written, we would be able to rapid prototype different interface elements, and eventually come up with a good starting point interface that could wind up shipping with the game, and allow players to go crazy customizing it to taste.

At this point, I know it would take a lot of work to make something like this happen, and there can be real pitfalls associated with decoupling an engine and interface, but I think that in the long run, it would allow for much faster iterating through interface elements, and allow for a stronger overall interface in the end.

[orbcontrolled]

Well, abstract the interface is currently in 26th place on eternal suggestion voting, with 44 votes including mine.

It's a touchy issue though. Toady doesn't seem to like the idea of others working on any part of the game, and the community tends to jump to his defense with quite a bit of... uh... vehemence whenever this kind of topic is brought up.

[KaelGotDwarves]

Meh. It's not so much vehemence as it usually degenerates into people making demands of Toady, and the community demanding they not make demands of Toady, and you get this endless cycle of suck.

You're welcome to work on UI while keeping within the TOS, make suggestions, and make mockups to your heart's content. Just don't lash out at anyone because of the lack of an API or open source development of DF's UI. That makes people crabby.

Dwarf Foreman, manager, and the various visualisers all work despite no input from Toady, and contributes ideas which he may choose to implement later, like he did with the site finder and d# update.

[Mozleron]

I don't imagine something like this would go in at any point in the near future, partly due to the low noise about it, the amount of work to do to make it happen, and the fact that the UI (Presentation?) is low on the list right now.  I think it would be really cool, but I won't hold my breath.   

Sure, the current interface has quirks, but once you've gone through at least 3 or 4 fortresses, you pretty much get them all figured out and it reaches a level of... shall we say, Serviceability?

[SSBR]

I dunno, I think it'd be handy. For instance, look at Stonesense, or look at that nifty tool that puts curses on DF. There are lots of possibilities if you abstract it away to, say, line-based input/output (it'd probably be slow, but useful for prototyping and all sorts of other things), and it does move a lot of work from toady onto the community, which is nice. However, this thing about Toady not liking anybody but him working on parts of the game is not encouraging.

Dwarf Foreman, manager, and the various visualisers all work despite no input from Toady, and contributes ideas which he may choose to implement later, like he did with the site finder and d# update.

AFAICT the tools basically muck around in DF's memory for information. Not a very dependable foundation for a tool, and they can never be trustworthy or considered stable in any sense.

[Mozleron]

I agree about messing about with memory being prone to 'issues'. 

If something like this ever did come about, i'd imagine there'd be some kind of API where we could query for some set of data from the main game engine, and send in commands to be executed. 

I think there are two extremes in direction that it could follow.  On one end, data could be moved in and out via a few API calls that let the UI query for any given set of data, such as item lists or current unit orders, and allow giving commands relating to said data sets.  On the other end, it could just parrot what the UI currently gives out, but in a for more easily manipulated, and only allow for echoing the current command set based on whatever mode you're in.

I guess on the command input side, we can already kind of do this sort of thing by using stuff like AutoIt or other Macro creation tools, though that's a pretty one way channel...

[KaelGotDwarves]

For instance, look at Stonesense,

Dwarf Foreman, manager, and the various visualisers all work despite no input from Toady, and contributes ideas which he may choose to implement later, like he did with the site finder and d# update.

AFAICT the tools basically muck around in DF's memory for information. Not a very dependable foundation for a tool, and they can never be trustworthy or considered stable in any sense.

Uhm Stonesense, like many of the visualisers, is built on knowledge through DFHack, which was made to muck around in DF's memory for information. It's fairly stable and semi-trustworthy as far as those things go

However, this thing about Toady not liking anybody but him working on parts of the game is not encouraging.

Once again, meh. I say Dwarf Fortress is where it is solely because of Toady and Threetoe's vision and Toady's hard work, and then people are going to insinuate that we worship Toady and won't tolerate dissidence.

The truth is, instead of doing what many people in the suggestion forums do and complain/whine, we should make a proof of concept of how the UI in DF should work. Dwarf Manager gives a lot of help to managing lots of dwarves professions and jobs without having to go through 40 dwarves' screens. Maybe something like this will be built into the game in the future.

The sitefinder program was practically a necessary utility for some players who had to find the perfect map, so Toady put a version of it in the game. Baughn did a hacky fix for OpenGL prior to the d# series and Toady realised how bad the implementation of it was in DF, so now we have their collaborative fixes built into the game. Chances are we're not going to get an API, and we're not seeing open source DF, so with that in mind we should move forward.

Stonesense is attempting more features and DFHack I believe recently got the amazing job down of being able to relay keystroke input back into DF. So there's a start -those guys are on the path, consult with them in that thread over the possibilities.

[Impaler[WrG]]

DFHack has currently being upgraded to pipe keyboard input to DF and it can read and write to the cursor memory in DF.  If you wrote something on top of DFHack that could take simple arguments like dig rectangle x/y at x/y/z, and converted them into necessary keystrokes that were then piped to DF you'd be getting close to having a kind of Hacked-API.  From their people could create the actual GUI and link to this Hacked-API to actually do stuff without worrying about the low level details.

[SSBR]

Uhm Stonesense, like many of the visualisers, is built on knowledge through DFHack, which was made to muck around in DF's memory for information. It's fairly stable and semi-trustworthy as far as those things go

Right, "as far as those things go". Which isn't very far at all. It may be dependable for a hack, but it's still a hack, and not only can it break when Toady changes things, it probably will, sinking effort in making it compatible with new releases when, ideally, we'd have a fairly simple API for handling this stuff that doesn't change in backwards incompatible ways very often.

Once again, meh. I say Dwarf Fortress is where it is solely because of Toady and Threetoe's vision and Toady's hard work, and then people are going to insinuate that we worship Toady and won't tolerate dissidence.

Okay...? It's not particularly relevant. I simply stated that it'd be pretty nice to write up new interfaces and the like, but Toady's stance on delegation makes this unlikely. I didn't intend to argue against Toady's management style or anything like that, which you appear to be defending. I honestly don't know how he does things, and wouldn't presume to argue against him. I am only stating what it is I agree with. If this contradicts him, fine. I'm not personally attacking him or his work.

The truth is, instead of doing what many people in the suggestion forums do and complain/whine, we should make a proof of concept of how the UI in DF should work. Dwarf Manager gives a lot of help to managing lots of dwarves professions and jobs without having to go through 40 dwarves' screens. Maybe something like this will be built into the game in the future.

I concur. You know that's what this post is about, right? It's about making prototype UIs easy to create.

Chances are we're not going to get an API, and we're not seeing open source DF, so with that in mind we should move forward.

An API is an interface for interacting with software from other software. Having an API has literally nothing to do with being open source. Your argument is by association-- open source code likes having well-specified APIs, whereas internal closed-source code doesn't need it. But that's beside the point.
For an example, Windows is certainly not open source, and yet the Win32API exists.

Your argument against having an API for coders to use is very simple, but the actual economics [of time] involved are not so simple. Modding tools add value to a game in ways worth far more than the work you put in, and can increase the value of the game far more than other work would cause. So modding tools have become very popular in the game world, because they are often worth it. DF is very interesting because coders like it so much that they've done the work themselves and messed around-- similar to, say, id Software's Doom. In the end, id released tools, and it gave them a huge amount of help in selling their software. It was a good decision, worth it. Would DF benefit from it significantly? I don't know, I can't. From my perspective, considering how much effort people put in already, it could be. So it might indeed someday get such an API, of Toady thinks it's worth it, which is not an unreasonable thing to think. I can't assign probabilities to this with confidence, but it's not out of the question, and not something I'd necessarily want to move on from. It's a good idea, just possibly not as good as alternatives for time. Possibly.

DFHack has currently being upgraded to pipe keyboard input to DF and it can read and write to the cursor memory in DF.  If you wrote something on top of DFHack that could take simple arguments like dig rectangle x/y at x/y/z, and converted them into necessary keystrokes that were then piped to DF you'd be getting close to having a kind of Hacked-API.  From their people could create the actual GUI and link to this Hacked-API to actually do stuff without worrying about the low level details.

Not knowing the DFHack API, I would only suggest creating an API overtop that is sufficiently abstract to be usable from a decent selection of languages and be replaced by an API that DF itself could release. DFHack may already be like this, meaning nothing need be done.

[KaelGotDwarves]

I'm not arguing against an API (yes I know what an API is), nor am I defending the stance to not release an API, I'm merely stating what's been said time and time again on these forums, that Toady already said he's currently against it and putting parts of DF on the public domain for a plethora of reasons (It being his income, baby, forcing him to deal with updates, a team of people) and we're not likely to see that change - the raws next version are already pretty damn complicated- so might as well work on DFHack if you want to do something constructive. Heck, someone just released today an updated version of dwarf therapist utilizing DFHack, and that's essentially an interface that DF ought to utilize with respect to jobs.

Not to mention the absolutely unfounded hostility I've seen some of the coders around here display to everyone when it comes to DF.

It being Christmas, feel free to post whatever reasons you feel this is wrong, unfair, etc... You can try PMing Toady but don't shoot the messenger (me) for relaying that it won't change anytime soon - so we've all gotten used to it and moved on.

[SSBR]

I'm not arguing against an API (yes I know what an API is), nor am I defending the stance to not release an API,

Sorry, my bad.

Not to mention the absolutely unfounded hostility I've seen some of the coders around here display to everyone when it comes to DF.

Oh, I don't know if it's unfounded. It's pretty easy to get hostile about something you care about, and people tend to care about the oddest things.

It being Christmas, feel free to post whatever reasons you feel this is wrong, unfair, etc... You can try PMing Toady but don't shoot the messenger (me) for relaying that it won't change anytime soon - so we've all gotten used to it and moved on.

Man, I've been dealing with games for all my life. I'm used to the way people think they should work, and have no problems with things staying the way they are, except for the relatively minor problem that I don't think the way things are now is quite perfect in a few respects (and of these, OSS/etc. is even more minor-- games are open in other respects). Toady is not the first to refuse to open his game up, he won't be the last, and it's quite a normal attitude. Anyway, if you say it's okay, fine. I suppose OSS is almost relevant, considering that a move to open this up is one method of allowing UI prototyping (via forking codebases).

I'm merely stating what's been said time and time again on these forums, that Toady already said he's currently against it and putting parts of DF on the public domain for a plethora of reasons (It being his income, baby, forcing him to deal with updates, a team of people)

There appears to be a leap of logic I don't get-- I'd probably only need to see what Toady has explained-- from what I can tell he gets money only through donations (and if DF is his sole source of income, that's mighty scary-- he's in poverty?), and I don't see why OSS would change this-- perhaps he has plans for selling DF as shrinkwrap or something, or perhaps he is worried about people forking his code and stealing his donations. The former is valid, the second is slightly less so-- he could get a major fork if he were tyrannical, but mostly people don't fork very often, and where they do they don't tend to really steal donations or even become very major. There are exceptions, but such is life. I am not some crazy OSS apologist, I just think it's pretty cool and honestly don't see the harm here, though I acknowledge it does do harm in other places, in a sense. On the other hand, half of this paragraph was previously arguments for why OSS could actually help his donations/income. Maybe I like it more than I like to think.

Also, you appear (or whoever said what you're repeating appears) to have flawed information: OSS doesn't have to have a team (in fact, by the number of projects I'd bet it usually doesn't), and it's usually much more restrictive than "public domain". In particular, copyleft via the GPL tends to be popular. I personally like BSD/MIT/zlib etc. (permissive licenses), but GPL is simply better for some kinds of software-- in particular, it's probably better for games in general, in terms of income.

so might as well work on DFHack if you want to do something constructive.

If *I* wanted to do something constructive about DF? It needs a good interactive tutorial, possibly. Could probably do it by writing a UI-writing API as suggested above, and then writing a simplified tutorial API and so on with a preset map. To be honest I just wouldn't find it as interesting as other projects I have. Plus I'd have to use C++ or SWIG or something, blech.

On the other hand, writing about what other people should do is definitely interesting. And reading other peoples' suggestions and considering them (and other peoples' responses to them) is just plain worthwhile, as a game programmer. Please do not fault me for my priorities, I beg it of you. Constructive things take many guises (and anyway, it beats discussing the weather).

[peterix]

Hey guys, just skimming the posts here.. most of it has tl;dr qualities...

Some basic facts:
DF doesn't have an API yet and Toady isn't making one any time soon (IMHo, he doesn't want to spend time on it when he has tons of things that will change).
With DFHack, I'm making a DF API because it's an interesting problem and I'm a stubborn bastard with too much free time Help is welcome. When you use it and add your own stuff you research, everyone who uses it benefits from it.

My current goal is to make the API into more of a communication protocol, sending messages back and forth using shared memory. I have a working prototype on Linux and it's crazy fast compared to the other methods

About the topic here:
DF just doesn't expose the engine without the UI. The d## versions on linux are dynamically linked against libgraphics, which just draws images on the screen as it is told by DF. So, I'm afraid hacking is the only way right now. I do have a general idea how to make such interface API, but I don't know if I'll have the time for it in the next month or so.