Print

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

[LumenPlacidum]

The 'arc' that is being used in describing the segments of development is the same as is being used in the term 'plot arc' in which the term 'arc' is used to imply a path of steps (or, more specifically, the shape of such a path) from start to finish, while accenting the notion that those steps are in some way nonlinear.  Basically, it's a progression of logical steps from a starting point to a definite endpoint with an uncertain path between them.

[Glutton]

Ah.. so it is not some abbreviation, but valid word... hmm I should probably get some better vocabulary :-)

[Kaelis Asur]

Very bad idea to make an API available to the world when you plan on breaking that API with every release you make.  Worrying about breaking that API can be very constraining.  Also, it's just one more thing that Toady needs to update with each release...time that could be better spent.

My opinion was similar at first, but then i actually researched the topic (namely, building dlls), and it turns out its actually (in VC++) a matter of simply adding a keyword to declarations of functions and variables you want to be usable outside of the dll, and making a .def file with a list of those. So its actually quick and easy, nothing would break nor it would require more work from Toady during updates, interfere with his coding practice or compromise his privacy/source code.

The graphics won't be changed officially. The game is already a processor hog without having to worry about graphics processing. The ASCII drives away the casual gamers, raising the overall intellectual level of Dwarf Fortress. If you want graphical changes, there are options for tilesets.

Simple (2d) graphics are not processor intensive. And once again - this is NOT about graphics.

So... why should Toady spent precious time to creating 3rd party interface, if it will be useless in the future. It is not so easy change to allow 3rd party control the game as some ppl here are stating.

The whole point of my suggestions is that someone else could write the interface, from api or by just sending Toady his code, thus relieving Toady from coding it himself. Furthermore, if it was done through api (which isnt, contrary to popular belief here, time consuming and hard to do), it would enable the community to make its own interfaces.

I had a look at Kobold Quest source. Rendering tiles is done through a single array of characters, as i suspected. Handling interface input ultimately leads to checking two variables for keyboard (key pressed and shift state) and three variables for mouse (x, y, and lbutton). If Dwarf Fortress is anything like Kobold Quest in regards to tile rendering and input handling (which i imagine it is, because theres no reason to change those aspects), it means that implementing my idea of interpreter would not need from Toady any work at all.

When i have some time, ill do a proof of concept with Kobold Quest to show how simple it is.

[Granite26]

Also, how awesome would it be to be able to Mod in your custom room template as a dig designation.

As in, select dig, special designations, apartment floor, and big overlay pops up with your custom made apartment floor plan.  Place it where you want, ENTER, and wham, it's all designated to be dug out.  Go up a floor, repeat.

At any rate, the stated goal is to make the backend as customizable as possible with the RAWs.  What's with all the hostility towards doing the same to the front end?

[DJ]

It seems to me that many people don't understand the point of user-made interfaces. I would stay with ASCII graphics and yet I would very much like to get moddable interface? Why? Because then I could see 50x50 tiles at the same time, sort dwarves by any parameter (name, profession, specific skill, total skills...), designate a whole multi-floor building at once and do many, many other awesome things.

[axus]

I'd suggest making your own version of Dwarf Fortress; Toady has always been open and honest about his desire to retain full control of DF.  He has more integrity than all those people using others' code without attribution, pretending it's their own, and playing cult of personality.  He's not refusing to be a jerk, it's because he's honest about keeping control.

[Slitherrr]

I'm completely in line with OP, here.  There are tons of knee-jerk reactions here about integrity of the product, presentation format, difficulty of maintenance, etc., and they all stem from very valid, respectable concerns.  However, as OP has stated, none of those have to be compromised by giving out a presentation API.  The interface has little to do with the game mechanics--as any programmer should know, the concerns are (or should be, if Toady is worth his salt) very separate, and encapsulated accordingly.  Versioning between interfaces and DF core would be kept separate, and it would be the interface designer's responsibility to keep track of version incompatibility with the DF core.

The RAW file example mentioned by Granite26 is apt--people can already change aspects of the core mechanics by editing those things.  Why should they not be able to change presentation, an aspect that has even less to do with the game itself than the RAW files?

Let's consider WoW's experience with a powerful presentation API.  Due to the abilities provided to the interface, scripts were, at various points, able to overcome certain WoW design points (for example, an enemy level display on enemies that would normally be invisible).  Blizzard has had to introduce (and will indubitably have to introduce) various patches to correct oversights found this way, and has actually used the ideas from the scripting community in its core presentation design (e.g., extra action bars).  However, WoW is worried about giving players an equal playing ground in a way that DF is not, because Blizzard has to worry about maintaining a particular persistent world, while DF players all create and share their own worlds.  Also, this happens in DF even without the enhanced API, and it has arguably improved the game--consider how 0x517A5D's Regional Prospector (probably) influenced the inclusion of a feature-finding mechanism on the embark screen.

As a final note, I'll say that there's a good chance that Toady's presentation arc will incorporate these ideas, anyway.  I seem to remember various comments that indicated that Toady is interested in seeing a good interface for DF, and there's a good chance that opening up the presentation with an API is the easiest way to do that.  Until then, there's no need to shout down suggestions on programming design just because they look like an attempt by someone to butt in on the project, especially when they contain very salient points about said design.

[dreiche2]

Uhm, but why revive this thread? One heated discussion is enough, I think.

[Tormy]

Uhm, but why revive this thread? One heated discussion is enough, I think.

This should be locked, just like the other one. These are pointless discussions, and some posts are quite hysterical. Toady was quite clear, he needs no help, and he wont release any source code ever. End of story.