Print

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

[Mithaldu]

Toady has been working on this game for a horribly long time now. It has been playable for many people for almost 2 years.

Do you really think that he hasn't seen all noteworthy requests and then some on this already?

We all know that Toady spends a lot of time reading stuff here. How about we all make a concerted effort and save him time by reading the entire history of the entire forum before making any suggestions? Because, seriously now, that's exactly what Toady needs to do with every suggestions he sees. :|

[Omega2]

I was pointing out Torak just did what he told us not to do. So that reasoning doesn't work, it can't be applied to this discussion. You can't tell people to wait until Toady works on the interface before they can suggest things about it, because that would imply everybody would have to wait until the game is finished before being able to make any suggestions.

You're completely wrong, and I find your reasoning insulting in the least. I said not to worry about the interface because toady will remake it to his specifications. He has not said anything about multiple level designation, so it's free game. Don't try and mix my words around to make it seem like I am a anti free-thought junkie.

Relax, you're being paranoid

Now, read the paragraph below that one. DF is still a very early alpha, everything might be remade to Toady's specifications. Why should you be asking for multi-level designations if Toady might be going to do the same thing in the presentation arc? Why should you ask for a more complex and efficient health-care system if it's already in the plans? It's the same reasoning. Doesn't matter how much work would be involved in implementing a sugestion, or how far down the development line it is (or if it is in the development list at all!), as long as it's relevant to the game it should be discussed without "let's talk about it later".

Toady might just ignore the whole discussion, maybe even post a little note saying "it's not going to happen". That's okay. But at least the idea was put forth. So the next time someone comes up with it, we can point them to the old thread and ask them if they have anything to add to it. Or if Toady ever changes his mind, he can use concepts taken from the discussions here as a basis or component to whatever he feels like doing. That's what the suggestions area of this forum is for: inspiration and player feedback.

[ervill]

EDIT:...

[dreiche2]

This is an idea that sucks technically and sucks from a community/social standpoint. The bunch advocating this are being, in large part, whining jackasses

We must be using two different kinds of internets. I see no whining from that side, but a lot of hostility and even insults (see above) from those who are against (any discussion about) this interface issue.

Toady doesn't have to release any code, or provide any interface for 3rd party clients, no matter how many times people whine or scream. No matter what alternatives you provide, Toady does not have to provide anything.

And who said that he must do anything? Apart from (maybe) the one single guy on the first page who talked about the donations?

And you guys who think they do Toady a favour by flaming people who want to discuss the interface architecture, you're not. All you're doing is forcing him into this thread saying "people please don't argue", like he had to do several times recently. Seriously, can't we all

1. be polite

2. try to actually understand other peoples points before we argue against them?

[Frobozz]

The bunch advocating this are being, in large part, whining jackasses (threatening a dev with "no donations" doesn't work, by the way, and would ensure that those of us who actually respect a dev's work will donate more; I'm just waiting on a project to clear before I send Toady some greenbacks). I can't for the life of me understand why you want Toady to do something self-destructive like this.

Its rather humorous that you automatically included me in the list of those whining for a new interface when all I really did was suggest an alternative method of implementing a third party interface. Frankly I find the current interface to be adequate for playing the game. There were really only two issues I had with it and one of those was fixed in the latest "major" release (designating multiple constructions at once like walls or floors). The other is merely full mouse support since I would much rather work with a mouse. When it comes to graphics, I've tried several packs and didn't like any of them. I guess I just like the look and feel of ASCII.

You'd only free up maybe 10ms of CPU time (read the Kobold Quest source code, it has DF's rendering method), which on most computers is at most 1 more frame. Also, you'd probably lose 20-50ms just by sychronizing the data accesses.

Yeah if they went the route of sockets. If they went the route of an API like I suggested there wouldn't be a loss due to syncing things. The amount of overhead would be about equal to calling a function from a library. Too small to be worth considering unless it was done in a loop.

Toady doesn't have to release any code, or provide any interface for 3rd party clients, no matter how many times people whine or scream. No matter what alternatives you provide, Toady does not have to provide anything.

I think we get the point now that he doesn't have to do anything. Thank you though for making a reply that is basically a duplicate of what others have said. You've just added more time to how long it takes Toady to read this thread, if he bothers to, without actually stating anything new. Now that I think about it I've done that just now.

Edit: Attempted to remove some hostility in an attempt to extinguish the flames of war.

So the next time someone comes up with it, we can point them to the old thread and ask them if they have anything to add to it.

Precisely. It also saves Toady the effort of having to read the entire new thread. Any future threads could be safely ignored if they are under a certain size since Toady could assume someone redirected to the old thread.

[isitanos]

Toady has been working on this game for a horribly long time now. It has been playable for many people for almost 2 years.

Do you really think that he hasn't seen all noteworthy requests and then some on this already?

We all know that Toady spends a lot of time reading stuff here. How about we all make a concerted effort and save him time by reading the entire history of the entire forum before making any suggestions? Because, seriously now, that's exactly what Toady needs to do with every suggestions he sees. :|

You know, Toady reads everything on this board. So if you think that this discussion is so useless, why don't you save him some reading time by not posting in this thread? And that applies to everybody else who seem to think they are Tarn Adam's personal bodyguards.

I started this thread to discuss an idea, not to demand anything from this game's creator. So, more (objective) input on today's topic would be appreciated: would the appearance of many popular third-party clients really hurt Dwarf Fortress, or would it rather benefit the game and Toady?

[Torak]

And you guys who think they do Toady a favour by flaming people who want to discuss the interface architecture, you're not. All you're doing is forcing him into this thread saying "people please don't argue", like he had to do several times recently. Seriously, can't we all

1. be polite

2. try to actually understand other peoples points before we argue against them?

Far as I know, I am not flaming. But if we were to not argue over an issue such as this, why even make the topic, don't just expect people to come in and say 'You're right!' and leave it like that for 10+ pages.

[Frobozz]

Far as I know, I am not flaming. But if we were to not argue over an issue such as this, why even make the topic, don't just expect people to come in and say 'You're right!' and leave it like that for 10+ pages.

So you're saying you aren't flaming yet you turn around and say its stupid to make a topic and expect it to be debated in a non-hostile fashion? Just take a look at all the discussions in the suggestions category. Especially those that concerned ideas that are obviously stupid. I can't remember many off hand that resulted in a massive flame war the likes of which is only rivaled by Windows vs Linux, DirectX vs OpenGL, etc style threads.

[Torak]

So you're saying you aren't flaming yet you turn around and say its stupid to make a topic and expect it to be debated in a non-hostile fashion?

The idea is wrong (making a topic and not expecting an arguement), you cannot have a discussion about something without two opinions showing up and thus being argued, and if that didn't exist, there'd be no reason to make the post in a requesting manner(Such as the one being argued for/against here).

[Jifodus]

You'd only free up maybe 10ms of CPU time (read the Kobold Quest source code, it has DF's rendering method), which on most computers is at most 1 more frame. Also, you'd probably lose 20-50ms just by sychronizing the data accesses.

Yeah if they went the route of sockets. If they went the route of an API like I suggested there wouldn't be a loss due to syncing things. The amount of overhead would be about equal to calling a function from a library. Too small to be worth considering unless it was done in a loop.

Sockets, multithreading, any method other than a fine grained integration of the interface with the engine will result in a slow down. Or do you expect Toady to resend all the creatures and items every frame? Or wait no, the client side caches all that unchanged information meaning that it doubles the memory usage. Or wait no, we ask Toady to release the structures he uses and we use our own seperate thread so that:
1) we don't have to cache anything
2) all the creatures & items don't have to be resent or anything
3) Oops, why'd the game crash. Oooh... the merchant just got deleted while I was trying to access it... gotta add some synchronization. Wtf. Why is it running slower now? Thread synchronization is a costly operation, don't kid yourself.

So no, there is more overhead than you think.

While yes, I would love to create my own interface, Toady has said in the past he doesn't feel comfortable releasing the internals of the DF engine. So until Toady himself says that he will release an interface, I'm not interested in seeing these ten thousand* threads that ask/suggest/question why Toady doesn't make the game/interface/whatever open source/documented/whatever.

* Ok, there's only be about 10 threads, but they all end the same way, Toady saying he's not going to do it.

[dreiche2]

And you guys who think they do Toady a favour by flaming people who want to discuss the interface architecture, you're not. All you're doing is forcing him into this thread saying "people please don't argue", like he had to do several times recently. Seriously, can't we all

1. be polite

2. try to actually understand other peoples points before we argue against them?

Far as I know, I am not flaming. But if we were to not argue over an issue such as this, why even make the topic, don't just expect people to come in and say 'You're right!' and leave it like that for 10+ pages.

Dude... I meant "argue" in the sense of fighting about something in a hostile fashion. Now you're acting as if it was about not having any discussion at all. As for "flaming", I think your posts are unnecessarily hostile, starting with the very first ones (page one).

[Frobozz]

Sockets, multithreading, any method other than a fine grained integration of the interface with the engine will result in a slow down. Or do you expect Toady to resend all the creatures and items every frame?

The API method obviously offers the best chance at usability so I'm going to ignore any future mention of sockets.

Oooh... the merchant just got deleted while I was trying to access it... gotta add some synchronization. Wtf. Why is it running slower now? Thread synchronization is a costly operation, don't kid yourself.

You're confusing the interface with something that would have direct access to the game's logic. A third party interface would have no more capability than the official interface. Do you currently have the ability to delete a merchant in the interface as it stands now? Of course not. The interface would have two roles. Sending requests and outputting the current state of the game.

Let's start with sending requests. Say the player wants to build a construction at a specific location. Say a wall. Well the player clicks/types whatever has to be to select a wall and the location for it. The interface then sends a request to the game that a wall be placed at that location. The game then responds whether or not such a request was successful. Thus you've either placed a wall or the game responds back that it couldn't be done and the interface either refuses to place it or tells you that the attempt failed.

Now for output. The interface has decided it is time to render a portion of the game to the screen. The interface sends a request to the game. This request would amount to returning information on a visible tile/object at a certain location. The game would comply sending the data for that location. If the interface is set to render at a higher rate than the game currently updates then the interface could choose to cache the results it gets and keep using them over and over until a new game cycle occurs at which point the cached copies are labeled "dirty" and a fresh copy has to be requested.

As for threading, well threading the graphics wouldn't be too difficult at all. Simply have a thread that sits around doing nothing until receiving a command from the interface to render the current contents of the cache to the screen. The thread then immediately springs into action trying to render as fast as it possibly can. With hardware acceleration such a render shouldn't take very long at all. In fact in most cases the interface should be able to render fast than the game updates.

When it comes to threading I honestly have about as much experience as Toady does (though I do have some knowledge I picked up at college it isn't anywhere near as useful as experience). Perhaps even less. Thus I would probably avoid threading more than what can be easily threaded (like video, audio, events, etc). And you are right, syncing stuff can be slow. However the thread I mentioned above for graphics wouldn't have need of syncing beyond detecting if the cache has become "dirty" and possibly halting the current render if so.

Edit: I should mention that shortly after my last programming course ended (Java and it was last since I had run out of funds) I had started development of a text adventure game engine that involved a server/client like system using an API to communicate. It basically consisted of two commands. One fetched output and the other sent input. Not anywhere near as flexible as the interface for DF would have to be, but at least I can say I've tried it myself.

[dreiche2]

Yeah the way I see it an API would just mean organizing the interface functions and putting them into a dll or something. It's not fundamentally different from what happens now, but it *would* involve quite some work to organize it properly.

Also, rereading the other thread a second time, there might be another issue which Toady pointed out. Even though he wouldn't have to make the engine open-source, writing a public interface for it might make it more prone to reverse-engineering (see the thread)...

[Frobozz]

Even though he wouldn't have to make the engine open-source, writing a public interface for it might make it more prone to reverse-engineering (see the thread)

Well the game is effectively having to be "reverse-engineered" to a small degree to make the current third party hacks that exist. I think Toady worries a bit more than he has to. I just don't see how having an API for an interface to use would expose the game to more reverse-engineering than the current interface exposes since the API wouldn't have much more in the way of abilities.

Like the construction example I gave earlier. The API would have the ability to request it be built but not force it. The game would still retain the logic as to whether or not to allow it to be built. And if it said it couldn't, the API would have to go along with that decision. Even something like Regional Prospector could be prevented if the API doesn't have the ability to "see" hidden features.

At any rate I'd put off implementing something like this until Toady is ready to make a complete rewrite of his interface. Then, whether or not he wanted to allow others to use it, he could implement a system like I've mentioned. Doing so would allow him to make later changes to the interface without having to dive into the game logic to make it work.

[Andir]

Also, why can't you people whom are so eager to make a new interface project just wait for Toady to remake it on his own? It's not that far off in the future, maybe a year or so off.

So, would you rather wait for the bakery to make you a cake, then go back in and try to make it a chocolate cake by melting Nestle bars over the icing?  Or would you request that they make you a chocolate cake to begin with?