Print

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

[PaulMurrayCbr]

Newbie, here.

Many parts of the game don't involve selecting areas (squad management, queuing production) and could be done with a web interface. A very, very basic HTTP server with basic authentication is pretty easy to do.

The obvious thing to do is to spit out some html screens, but what might be even better is a webservice type interface that accepts commands via POST or GET and returns JSON objects. This decouples the job of exposing the innards to http and the job of making a web interface.

An interesting side-effect of doing this is that it becomes possible to play DF co-operatively, one player managing squads, another managing production (doing the job that the manager does now) and so on.

[PaulMurrayCbr]

The commands would be based on the existing menuing, meaning less to learn. So to turn on mining labor for a dwarf, you'd do something like

http://localhost:8080/v/Besmar Taniden/p/l/Mining?cmd=on

Where the selector could be a name, a unit number - whatever works best. Note that the urls have to be UTF-8 encoded to support diacritics if you want to use the names.

[PaulMurrayCbr]

With POST commands, you could introduce a syntax for selecting areas (basically, define a set of rectangles and z-layers).

Now ... lets say we have this syntax for selecting rectangles. Lets say that it's good enough that you can specify rectangles relative to a designated point (which you might be able to select multiple ways).

This would make it possible to create digging templates, eg: those efficient bedrooms on the site, and exchange them.

[Telgin]

I think this has been suggested before and Toady said he didn't want to have to maintain an API.  So for now, it's not happening, unfortunately.

I'm not sure if that was an HTTP interface or a DLL based interface or something, but in either case it seems unlikely he'd implement it any time soon.

[JanusTwoface]

Why the triple post?

I'll admit I've not seen an http interface suggested like this, but honestly it seems a bit strange. A web server isn't terribly hard to write, but it seems like it would be slow and high bandwidth for the sort of thing you're talking about.

What would probably be better for that would be a programmatic API. Most likely bindings for something like Lua or Python. Unfortunately, Toady has pretty much said he doesn't want to do that at least at the moment. There's a nice quote for that somewhere (as Telgin referenced) but I can't find or at the moment. So many someday.

[PaulMurrayCbr]

The advantages of this over a progammatic api are:

1 - It is not platform specific. I run DF on a Mac.
2 - Programming of the UI can be done in javascript, again - not platform specific, and by third parties.

Bandwidth is a non-issue if it is used on localhost - localhost is an in-memory pipe on most systems.
I am not suggesting that the existing view screen pump out updates over the network. The web interface would not be for designating regions to mine or viewing the fortress.

As for the triple post - I was thinking aloud.

As to the other objection - Toady just doesn't want to do it - well, ok. Hard to argue there

[JanusTwoface]

1 - Any API would be cross platform, it's not particularly hard to add of you're already adding the API.

2 - A web based UI requires an entirely different skill set to program. That could be handled somewhat by relying on others for development. But that's the primary reason that Toady has been against an API in general--what happens when Toady makes API breaking changes and one or more UI devs have moved on? You get broken components that many may rely on to play the game. Who takes the blame for that? Toady. It's not a great situation and it's probably deal-with-able, but it's still a pretty big problem.

So far as bandwidth, perhaps that was the wrong word. What I meant was that for HTTP traffic you have to establish a new TCP connection for each and every packet, you have to include headers in the request/response, and there's no good way to push updates to the client. Each is surmountable, but none are particularly problems with either a direct API or writing a custom network protocol.

[Telgin]

there's no good way to push updates to the client

This actually is probably the biggest issue of implementing it.  The web client would have to poll it, and while this could be pretty fast in theory it's a suboptimal way to implement an API.  It would cause a lot of overhead, and DF's side of it probably couldn't really run in another thread so it would bog the game down some.

[GreatWyrmGold]

Why would we do this? Multiplayer is the only concievable reason I can think of for internet use in DF, and there's plenty of reasons against that...

[Telgin]

This would allow anyone who knows HTML and Javascript to build a web interface for DF.  It could be run to access a remote instance of DF, but could just as easily be run on the local host.  In that case it would just be another way for building things like Dwarf Therapist, but wouldn't require knowledge of a compiled language or use of DFHack or anything like that.

If Toady was going to go through the trouble of making such an interface, I suspect he'd much rather provide an API for use with plugin DLLs instead.  It would likely be far simpler for him.

[GreatWyrmGold]

...I still have no idea why someone would do that. To play DF on someone else's computer?

[Telgin]

Presumably so you could make a DT like interface that ran in a web browser.  It would be tremendously simpler for people to modify as opposed to DT itself, and it can work for a local copy.  The page would just have to connect to http://localhost:8080 or whatever port DF bound to with its AJAX calls.

[JanusTwoface]

In regard to making an external interface, it's not really different than any other language for an API. What you gain is a theoretical ability to access it over a network (which would require having an external IP and no firewall blocking non-standard ports though, so quite often you won't even gain that). In exchange, you have to deal with using HTTP as your framework with the pitfalls that I mentioned earlier. And if that's really a big deal, any other modding framework could add in a 'networked interface' mod that adds an HTTP interface on top of what's there. That's not something you can easily do the other way.

I'm all for DF having some sort of programatic API. Something like Lua (used extensively to build mods and UIs for games like World of Warcraft or Civ V) would be great. But until Toady actually decides that the benefit of such a setup outweigh the costs (and I do understand his viewpoint on that, even if I don't like admitting it) it's basically not going to happen.