Print

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

[Tulthix]

I was thinking, something that may really help DF along would be embedding a scripting language like python, ruby, or lisp for the purposes of UI modding.

The concept would be somewhere between Emacs lisp customization and what the (ugg) WoW UI does.

Maybe it could expand chronologically down this list
1) allowing in game macros composed of sequences of keystokes, allowing these to be bound to keys
2) exposing some of the game database elements to the language, such as stocks and citizens
3) exposing the command windows so that they could be customized

As an example, I'd like to be able to write a function that would transfer a squad from on duty to off duty, swap them all from axes to unarmed, and vice versa.

The nice point would be it would allow the community to contribute on the UI front, and hopefully the development for this would be mostly a one-time cost to Toady's time.

[Exponent]

quote:Originally posted by Tulthix:
<STRONG>...and hopefully the development for this would be mostly a one-time cost to Toady's time.</STRONG>

The problem with a lot of changes of this sort is that the game content is not complete and stable, and changes to game content require changes to the interface as well.  So the more complex the interface is, the more work it is to make each game-content change.  I think Toady is trying to delay as much interface work as he can until later, when a larger bulk of the game is unlikely to get changed or overhauled in the future.

[Tulthix]

quote:Originally posted by Exponent:
<STRONG>
The problem with a lot of changes of this sort is that the game content is not complete and stable, and changes to game content require changes to the interface as well.  So the more complex the interface is, the more work it is to make each game-content change.  I think Toady is trying to delay as much interface work as he can until later, when a larger bulk of the game is unlikely to get changed or overhauled in the future.</STRONG>

I could be totally wrong, but it seems like changes in content could minimally affect Toady's work on changing the embedded scripting.  For example, say a citizen is a C structure.  For a python embedded scripting system, this structure could be auto-exposed during the build.  When a citizen has a new field added, the autogenerated python structure would automatically change during the build.  This would break things for UI implementers, but thats fine by me.  It offloads the work to third parties as things break.

[DJ]

This is a most excellent idea. If we could access data easily in real-time, we could add any sort of graphics we want (even 3D), which would allow Toady to delay the presentation arc for as long as he wants without losing any potential players.

[Fieari]

I see this suggestion as REPLACING the presentation arc, to be perfectly honest.  

It's the best of both worlds.  Toady gets to keep control of his baby, no one forks the backend like he's afraid would happen with open source, and yet lots of dedicated coders get to handle the one part of the game Toady doesn't want to have to deal with: the front end.

Each new feature he added would get a hacked on "default" implementation, just as he does now, but he'd also add a hook so that it could be hooked into by the scripting language.  Then, he never looks at the front end again, leaving the hackneyed GUI for the vanilla download, and modders to provide something that actually works.

Even 3D.  Although I'd BY FAR prefer 2.5D, or even just our simple top down view like we've already got.

[ March 26, 2008: Message edited by: Fieari ]

[Toady One]

This has come up before, but I don't remember if I've actually entered into a discussion on it.  As it stands, without knowing much about it, my issues are as follows:

It seems like I'd have to publish all my class definitions to make this practical.  I don't anything about reverse engineering, but it doesn't seem far from opening up the source at that point.

The class definitions would also not document and otherwise support themselves, and there would be pressure on me to do so, which is not a one-time cost.

In fact, if a third party front-end becomes popular, I think I'd be forced into relationship or even a state of dependence on the third party that I'm not comfortable with.  And I don't think we can just gloss over version compatibility.  Ignoring it or handling it before releases -- either approach has ramifications for me.

Certainly players would benefit from having third party front-ends.  They'd benefit from open source and third party back-ends too.  If it means cutting myself out of my own game, I'm not going to support it.

I also don't know anything about scripting, and it's tough for me to say whether time spent learning a scripting language, implementing scripts and supporting third party front-ends is better spent adding modestly to the interface myself.

[ March 26, 2008: Message edited by: Toady One ]

[numerobis]

quote:Originally posted by Toady One:
<STRONG>It seems like I'd have to publish all my class definitions to make this practical.</STRONG>

The utilities hack through and deduce the data structures right now.  The main thing that's not easy to deduce is the fundamental algorithms.  While C++ forces you to put a bunch of juicy details up-front and personal in the header file, it's pretty easy to hide that detail using a single level of indirection (it's even pretty easy to script it so you never have to write the single-level-of-indirection nonsense).

quote:<STRONG>... something about maintenance and documentation ... </STRONG>

You break everything, we fix it, it's all good.

quote:<STRONG>I think I'd be forced into relationship or even a state of dependence on the third party that I'm not comfortable with.</STRONG>

This is really the main issue.

[Mikademus]

quote:Originally posted by Toady One:
<STRONG>It seems like I'd have to publish all my class definitions to make this practical.  I don't anything about reverse engineering, but it doesn't seem far from opening up the source at that point.</STRONG>

No. As I have solved it for (among other projects) my Rogue-alike engines is to export an intermediary interface, where for instance, a character matrix of the output map an input buffer are provided.

In short, what you do is to provide specific functions returning read-only data is defined by you, where numeric values can even be cooked as strings if you feel extra paranoid. Thus, you don't have to reveal any of your internal structures, and still allow interface designers full flexibility.

Also, forget about stuff like scripting languages, just export a .dll with the functions necessary for writing a custom front end for DF. It will be enough to offload interface refinement from your shoulders.

[Toady One]

"You break everything, we fix it, it's all good."

I don't think it's that simple.  Even the utilities that people use cause some grief when they are broken -- it would be far worse for a popular front-end.  If the majority of the player base has to wait after each release for third party fixes to a broken front-end that may or may not even happen, it puts a lot of pressure on me to resolve the issue by working more closely with the third party, a completely unknown entity that happens to maintain the front-end most people use.  It would be difficult for me to retain my independence once in that position.

I think somebody mentioned in an email discussion I had that in that case I should just incorporate some of the more popular aspects of third party interfaces back into the main release in order to avoid forming that kind of tie and to avoid serious bumps in playability for front-end users after each release, but I don't know the legal ramifications of that, and my first impression is that I'd be setting myself up for trouble, though some major publishers seem to do this without issue from what little I know about it.

I can vaguely see how something could be set up to automatically prepare a lot of this now, but it still seems like the functions etc. that are created would need to be documented to be useful, especially if the front-end needs to be patched quickly.  If variables are removed or changed around, it seems like the incompatibility for front-ends relying on a previous version of the automatically generated system could be pretty severe.

[numerobis]

the legal ramifications

If you have a written agreement that the author gives you an unrestricted license to the code, then you're clean.  If you don't, then you're not clean: the author has a copyright and you'd be violating it.  If I were to offer you any code, I'd make sure beforehand to place said code into the public domain, where anyone can do anything with it, and thereby you'd be sure that you in particular would be allowed to use, mutilate, and make money off of the code without having to tell anyone.  Free licenses in the sense of the FSF and open-source movement aren't compatible with your distribution setup.

Of course, I am not a lawyer, your mileage may vary, etc etc.

[numerobis]

Oh, and if you don't want to cede control of DF, then you don't want to have a published API powerful enough to write meaningful UI.  I would love for there to be an API for us to write front-ends for, but I don't think it's compatible with your view of how you want to run the project -- at least not now.

You could probably support the subset of what something like 3dwarf needs without great harm to your control over DF: a query interface that loads in a save file and reports a few basic things (colour, and whether there's a wall, stair, floor, tree, shrub -- no items, no units, no buildings).  Those are likely to be very stable for the indefinite future.  I think.

[Toady One]

I suppose if there were some sort of GPLish license that applied to anybody working with a front-end DLL (including whatever basic front-end I provide), it could live in its own separate space from the back-end and they might still be distributed together under different licenses, but the wording/legal mess for that seems like a pain if it's even possible.

What's the bit about 3dwarf?  Do you mean a 3D dwarf fortress or something like the visualizer utility that is more for a static model of a fort?  I haven't downloaded any utilities so I don't know their filenames if 3dwarf is a filename.

[numerobis]

quote:Originally posted by Toady One:
<STRONG>I suppose if there were some sort of GPLish license that applied to anybody working with a front-end DLL (including whatever basic front-end I provide), it could live in its own separate space from the back-end and they might still be distributed together under different licenses, but the wording/legal mess for that seems like a pain if it's even possible.</STRONG>

That's definitely possible.  By design, there's no requirement for a GPL thing to only link to GPL things -- this lets GPL infect closed-source operating systems.  I'm not really up on how module systems work -- where the backend loads up a DLL at run-time -- but clearly you can do that from open-source (e.g. firefox) to closed-source (e.g. Adobe Acrobat).  There are a billion permutations of these licenses.  The problem here isn't legal, it's control: if the main front-end is not written by you, then you are, as you noted, co-dependent with it.

I was thinking more about you incorporating code from utilities into DF, where you have to be a lot more careful about licensing.  If would really suck for you to be in the position where you are legally required to excise part of the code before you can distribute DF again.  So, before grabbing code from anywhere, make sure it's ok with the author.

quote:<STRONG>What's the bit about 3dwarf?  Do you mean a 3D dwarf fortress or something like the visualizer utility that is more for a static model of a fort?  I haven't downloaded any utilities so I don't know their filenames if 3dwarf is a filename.</STRONG>

3Dwarf is the visualizer that just takes a static picture in gorgeous, gorgeous 3D (static, but you can move your camera around, of course).  It only draws terrain, trees, and constructions -- not buildings.  And yet people futz around memory hacking to make this thing work.

One possibility would be to cut your teeth on a really minimal API that made 3Dwarf be robust to version changes.  Not even linking to the main DF executable, but just a library that loads straight from the file.  As the game matured, and as you felt like it, you could add things to the API, like viewing legends or maybe modifying the world (a la lavatile, which lets you turn one tile into lava) or whatever.

[Derakon]

I believe 3dwarf refers to a standalone app that parses the saved game and produces a 3D image of it.

I'm sure there's some way to rig things up legally the way you want them, and it's probably not even all that complicated, but I don't know offhand how it'd work.

Honestly, aside from a few interface annoyances, the current UI for doing things in DF is fine by me. The big wins I'd see from "accessories" would be purely informative in nature - things like sorting your dwarves by various metrics ("who's my best carpenter? Which dwarves are married? How old are my children dwarves?"), finding valuable furniture, and so on.

[isd]

quote:Originally posted by DJ:
<STRONG>This is a most excellent idea. </STRONG>

I second this...
While the world becomes more and more complex we also need more powerful ways to handle it, and scripting would be the tool!