Print

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

[GavJ]

@Footkerchief,

That interview or whatever you posted sounds perfectly reasonable, but the thing that confuses me about it is that Toady seems to have had zero interest or even really very many ideas in features for the GUI. So what is the "risk" he's really assuming for the GUI side of things? It's framed as a risk of not being able to do what he wants to do with the GUI later if he lets it out into the free world now. But he doesn't seem to have anything in particular he wants to do with the GUI.

Plus if he did get a clear strong vision later about the GUI, if it's entirely modular (which is something uniquely possible for a GUI), he could still just code it all up and completely supplant any 3rd party versions, because if it really was that much better, people would just use his.  So still not seeing much risk.

Most of the logic there seems much more relevant to a hypothetical GAMEPLAY API. Which he addresses later in the quote regarding armies etc. And that makes total sense to me. However, a gameplay API is something that AFAIK nobody seems to even be asking for (other than the OP here, I guess), are they?

[Footkerchief]

How'd you mix up your quote like that?

Correct post by GavJ supposed to be linked that was instead attributed to me

No idea.  Thanks!

@Footkerchief,

That interview or whatever you posted sounds perfectly reasonable, but the thing that confuses me about it is that Toady seems to have had zero interest or even really very many ideas in features for the GUI. So what is the "risk" he's really assuming for the GUI side of things? It's framed as a risk of not being able to do what he wants to do with the GUI later if he lets it out into the free world now. But he doesn't seem to have anything in particular he wants to do with the GUI.

The risk is 1) losing control of the project as a whole, 2) losing donations and 3) being forced to collaborate more than he wants to.

Plus if he did get a clear strong vision later about the GUI, if it's entirely modular (which is something uniquely possible for a GUI), he could still just code it all up and completely supplant any 3rd party versions, because if it really was that much better, people would just use his.  So still not seeing much risk.

As Toady says in that post, he can't create a more successful GUI than a third-party team would.  So regaining control in that way wouldn't be feasible.

Most of the logic there seems much more relevant to a hypothetical GAMEPLAY API. Which he addresses later in the quote regarding armies etc. And that makes total sense to me. However, a gameplay API is something that AFAIK nobody seems to even be asking for (other than the OP here, I guess), are they?

No, Toady is saying that if he adds army movements, he then has to support it in the API.

[Severedicks]

The whole UI controversy is a bit obsolete at this point. DFHack's UI plugins provide a whole bunch of improvements that make one's UI experience enjoyable in every way. You don't even have to manage your labors these days, scripts do it for you. Hell, you can even make a fortress build itself. Yes, such plugins should be integrated into the game's main core in an ideal world, but at the end of the day the average player's end product is the same save for the hassle of clicking two links instead of one - not to mention it allows Toady to focus on actual content.

However, the main gripe I share with the OP is the current state of development cycles. The rationale is that there shouldn't be too much bugfixing when such bugs are destined to disappear in rewrites. The thing is, most stuff is destined to be rewritten at some point, even though that means 7 years later because of the astronomical development scope. So we end up with placeholders, age-old bugs, or some really obvious (in the way of realism) features that are absent (like boats). Granted, it is inevitable, but I am legitimately concerned as to whether the Adams brothers actually enjoy playing the game (since DF was destined to be a game they'd play themselves) when it's mostly made of placeholders who are likely to remain that way for several years. Perhaps more successive releases that add modular content every time would be more fun to develop and play, even though third party tools would suffer. 

[GavJ]

The risk is 1) losing control of the project as a whole, 2) losing donations and 3) being forced to collaborate more than he wants to.

Right, so if we apply those to:

A) Modular GUI:
1) If it is indeed modular, then Toady could go in and make his own module later without breaking anybody else's or being obligated to change his vision for the GUI based on anybody else's, so he isn't losing control.
2) Surely donations would increase with a variety of GUI options that make different groups of people happy and attracted to the game.
3) A modular GUI does require some collaboration, but really only on technical aspects in setting it up. Once a basic syntax and interface is established, he can just add new graphics-relevant things to it without having to collaborate. So yes a risk, but seemingly a small, one-time risk in terms of actual required collaboration.

B) Raws:
1) How do you lose much control by letting players change the freezing point of water to 15 degrees hotter if they want, or add new creatures? There is some minor risk in people getting attached to their raws and then having to redo them and not enjoying the downtime, but raws are generally extremely easy to port over.
2) Again, surely donations would increase if people had more versions they could choose to tailor to their specific preferences.
3) This requires no collaboration, really, outside of spending a little time here and there documenting what some of the more confusing tags do.

C) true gameplay variable access API:
Definitely much higher risk on all 3 counts, but who is asking for this?

DFHack's UI plugins provide a whole bunch of improvements that make one's UI experience enjoyable in every way.

Um, it took YEARS for somebody to figure out how to (or bother to) do something as simple as making a separate icon for every item type... which has since then taken a month or two and still isn't in fully documented stable release. what are you talking about? Something like that would be maybe a half hour project and done more efficiently to boot with a modular GUI.
Nothing dfhack offers (when it isn't down after an update, mind you) remotely approaches the amount of sleek awesomeness we could have with a modular GUI. In a fraction of the time, and with far more stability and no busy work fixing already-implemented features all the time.

No, Toady is saying that if he adds army movements, he then has to support it in the API.

Not if he doesn't have an actual API, which again, nobody seems to be asking for for gameplay stuff like armies.

[Putnam]

That didn't take years, it took a single guy who was annoyed at graphics text not nearly as long as you said.

Its not they couldn't figure it out, it's more that nobody was trying.

[Mictlantecuhtli]

Um, it took YEARS for somebody to figure out how to (or bother to) do something as simple as making a separate icon for every item type... which has since then taken a month or two and still isn't in fully documented stable release. what are you talking about? Something like that would be maybe a half hour project and done more efficiently to boot with a modular GUI.
Nothing dfhack offers (when it isn't down after an update, mind you) remotely approaches the amount of sleek awesomeness we could have with a modular GUI. In a fraction of the time, and with far more stability and no busy work fixing already-implemented features all the time.

This is disingenuous at best and hand waving the work that actually went into something like that. What next, rendermax is something that Toady could outdo in a week if only he wanted to work on it? For all the modding issues you've brought up, someone has already accomplished them if they had the motivation and skill to attempt it.

[GavJ]

"Took years" for it to happen. Not for the guy to code it. Sorry if that was unclear.

Its not they couldn't figure it out, it's more that nobody was trying.

Yes, it's a PITA to reverse engineer stuff, requires better coders, and requires more motivation, and you know is just going to break again.
So that's correct: nobody was trying, due to an extremely inconvenient and de-motivating system in place, despite an obvious need recognized by anybody who's every made any tileset.

someone has already accomplished them if they had the motivation and skill to attempt it.

Also correct.

A GUI API, however, dramatically decreases the necessary skill to do GUI things, and also requires less motivation since you have better reason to believe you won't have to constantly fix your code. Therefore, a great many more things will pass the threshold and be coded.

[Footkerchief]

A) Modular GUI:
1) If it is indeed modular, then Toady could go in and make his own module later without breaking anybody else's or being obligated to change his vision for the GUI based on anybody else's, so he isn't losing control.

As Toady says in that post, he can't create a more successful GUI than a third-party team would.  So regaining control in that way wouldn't be feasible.

2) Surely donations would increase with a variety of GUI options that make different groups of people happy and attracted to the game.

One could just as easily speculate that, with a third-party team working on the most visible part of the game, that team will begin to attract more of the attention, loyalty, and donations.  Given the uncertainty of the outcome, it is unambiguously a risk for Toady to change the status quo.

3) A modular GUI does require some collaboration, but really only on technical aspects in setting it up. Once a basic syntax and interface is established, he can just add new graphics-relevant things to it without having to collaborate. So yes a risk, but seemingly a small, one-time risk in terms of actual required collaboration.
[...]
C) true gameplay variable access API:
Definitely much higher risk on all 3 counts, but who is asking for this?

No, Toady is saying that if he adds army movements, he then has to support it in the API.

Not if he doesn't have an actual API, which again, nobody seems to be asking for for gameplay stuff like armies.

I lumped these together because they seem to stem from the same misunderstanding.  The difficulty here is not about a gameplay API per se.  It's still about interface, namely: 1) how does Toady add new interface elements to the API in a way that doesn't break third-party interfaces, and 2) how does Toady deal with feature requests for expanding the API? (e.g. status icons, wounds, clothing, animations, and all the other stuff that people would eventually want)

B) Raws:
1) How do you lose much control by letting players change the freezing point of water to 15 degrees hotter if they want, or add new creatures? There is some minor risk in people getting attached to their raws and then having to redo them and not enjoying the downtime, but raws are generally extremely easy to port over.
2) Again, surely donations would increase if people had more versions they could choose to tailor to their specific preferences.
3) This requires no collaboration, really, outside of spending a little time here and there documenting what some of the more confusing tags do.

I don't think anyone, including Toady, is opposed to moving constants into raw/init files.  However, it's also esoteric enough that it doesn't matter to most people, so there's not a pressing need.  I see this as an unrelated discussion.

[SmileyMan]

Also do you truly prefer ASCII to any sort of tileset?  Curious on that point. 

I do, and I genuinely mean that. None of the tilesets do anything for me; my only change is that I switch to the square 16x16 curses, because I like square map grids.

[GavJ]

1) how does Toady add new interface elements to the API in a way that doesn't break third-party interfaces, and 2) how does Toady deal with feature requests for expanding the API? (e.g. status icons, wounds, clothing, animations, and all the other stuff that people would eventually want)

In reverse order:
#2) By just putting everything in the GUI in the first place. Any vision-related variable or text should be made readable (not writeable).
#1) He doesn't. This is impossible, and any programmer of a GUI with half a brain should realize this is impossible. Stuff added to the game needs to be graphically represented. Stuff removed needs to be not graphically represented anymore. There is no way to avoid this, so don't bother trying to avoid it.

However, if he wanted to make things smooth, he could simply maintain a more detailed changelog than he does currently, which is not exactly "collaboration" and yet would go miles toward easing the transition to GUIs being able to update quickly after a release (they could go ahead and make graphics for, say, multitile trees with nothing more than the informaiton "there will be trunk sections, major branches, minor branges, twigs, and fruit and leaves on the ground." One sentence's heads up. Then after release, only minor effort spent hooking it up to the coding hooks in a weekend, and you're good to go)

[4maskwolf]

Also do you truly prefer ASCII to any sort of tileset?  Curious on that point. 

I do, and I genuinely mean that. None of the tilesets do anything for me; my only change is that I switch to the square 16x16 curses, because I like square map grids.

+1 to not needing graphics mods, I prefer my ASCII as is.

[thvaz]

Also do you truly prefer ASCII to any sort of tileset?  Curious on that point. 

I do, and I genuinely mean that. None of the tilesets do anything for me; my only change is that I switch to the square 16x16 curses, because I like square map grids.

+1 to not needing graphics mods, I prefer my ASCII as is.

No ASCII, no DT, nothing. Sometimes I use Stonesense to see my fortress in its isometric glory.

[GavJ]

@ People who prefer ASCII (including myself!):

A GUI API is still super useful even for ASCII players, by allowing things like unique ASCII tiles/icons for every item type (not sharing between, for example, manta rays and ballista heads or whatever) and creative ways of viewing multiple Z levels, and much nicer and easier to read font in conjunction with easier to see square tiles, and better resizing and scaling, and even the possibility of vector graphics and things like that (can still be ASCII aesthetic), and being able to animate things with flying trajectories as appearing in between tiles for flavor, blah blah

[Footkerchief]

#2) By just putting everything in the GUI in the first place. Any vision-related variable or text should be made readable (not writeable).

"Vision-related" seems pretty subjective.  Defined broadly enough, it could end up being 90% of the game.  That would be a nightmare of an API.

#1) He doesn't. This is impossible, and any programmer of a GUI with half a brain should realize this is impossible. Stuff added to the game needs to be graphically represented. Stuff removed needs to be not graphically represented anymore. There is no way to avoid this, so don't bother trying to avoid it.

Again, Toady already addressed this in detail:

How many threads were there about broken utilities when this version came out?  If more than half the player base comes in off a third party interface (and given how much the current interface sucks, and how much it is a source of first time downloaders dropping the game, this is not only imaginable, it is very, very likely), how would it be if it broke at each release?  There's no way to mitigate that without my direct involvement -- imagine a release down the line where you can suddenly move dwarven armies around on the world map, with a tactical view and various options.  That interface can't write itself, and it wouldn't be a quick patch, though certainly dedicated people, assuming that about whoever is maintaining the front-end at that time, can pull things together rapidly.  The pressure on me to work directly with them to get the interface out at the same time as the game itself would likely be immense and disruptive, given what little evidence we have from broken utilities.  That's not to say that I often get requests to work with utility writers (other than from the writers themselves, who I generally accommodate), but this would be at a different order of magnitude.

[cephalo]

You know, maybe the problem with modern DF is that it has outgrown it's business model. Maybe Toady should pull a Notch, or a Tom Francis and just start selling this thing. Make a couple million dollars, hire two or three bug squashing employees, and then travel the world for six months.

Then when he returns his minions have fixed the bugs, separated the UI code from the game logic and given him a nice clean slate on which to proceed. DF is my favorite game ever, ever, and I've been playing games since pong. Heck yeah I'd buy it. So what if it isn't complete? Minecraft still isn't complete.