Print

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

[isitanos]

UPDATE 2:
Toady has posted two detailed replies to explain his position. Here are links to the first and the second one. Personally I'm satisfied with his answer and that closes the discussion for me.

UPDATE:
Let's try to keep all the flaming out of this, ok? There's a lot of misunderstanding and not ready the context going on.

I may have been wrong in starting the thread on two topics at the same time. It did cause a lot of trolling. But as things are, currently we are discussing two things:

SUMMARY OF THE CURRENT TOPICS (also posted on page 12 of this thread):

1. Would third-party interfaces hurt or help DF and Toady, and in what aspects?
- Donations
- Fan base/User adoption
- Toady being able to concentrate on what he likes doing
- Better interface in the short and long run

My personal opinion: third-party interfaces will only please (and increase a bit) the hardcore fanbase Toady relies on for a living, and allow him to spend more time on developing all the gameplay features he's planning. On top of that, those interfaces will be a testing ground for what interface suits better DF, and then Toady can implement his own by picking what he likes left and right.

2. What's the best technical way to allow third-party interfaces?
- Let people hack at the game as it is now
- Client-server separations through sockets (seems inefficient and hard to achieve, from some comments)
- Client-server separation through making the client or server a DLL
- If we admit that a client-server-like separation is best, is it better to have a documented public API to the server, or make the client open-source so it's kind of self-documenting.

My personal opinion (after reading many interesting advices on this thread): the best way to go would be a client-server separation through making the client (interface part) or server (game logic part) a DLL. Since Toady fears that maintaining an API for people will be too much work, I think a self-documenting open-source client would be a good solution. Things will break between versions (as they do now), but since Toady will have his own working client as an example, third-party ones will be easily and quickly updated. Lastly I suggest a license similar to the GPL for the client, so that Toady has full access to the third-party interface source code, and can integrate whatever he wants in his reference version without asking permission to anybody.

-----------------------

I wanted to add this to what I posted above:

People are making worst-case scenarios, such as Toady losing all his work and the project failing and so on.

I personally believe that third-party interface clients would only help, not hurt, Dwarf Fortress.

But what if by some amazing and unlikely bad luck one of those worst-case scenarios comes true and Toady feels he's loosing control of the project?
Well he still has an emergency exit: stop the third-party client business by not supporting them anymore (i.e. stop updating his public API or not publishing the source code for the next version of his client). This would certainly anger a lot of fans who are relying on those clients, but he could still count on faithful hardcore fans who are more interested by the game than by any client. I know that if this situation came true, I would keep playing the game and following it's development, even with a bad interface like the current one.

In the case of an open-source client, the license could specify that Toady can use any code from derivative works without publishing his changes. Basically, people using the client source code would have to share copyrights with Toady. This would allow Tarn to use any source code from third-party clients he sees fit, but revert the license to closed-source for any future version at any time. Not that I think it will be necessary, but you can't be too safe in a case like this.

Still in this worst-case scenario, I think Toady could revert to the current third-party hacking difficulty by reverting to closed source and changing the source code quite a bit. He could reintegrate everything in a monolithic EXE. Hell, he could even obfuscate his binary (though I don't know much about those techniques). Of course he can't completely prevent people to make third-party clients like the ones that currently exists. Even though, if he officially (and therefore legally) forbade doing this, I doubt many people would disobey. True (read: donating) fans would be unlikely to use tools that don't have Toady's "benediction".

-----------------------
Original Post:
-----------------------

In the interview on Kwanzoo, Toady mentions that "If a third party interface becomes popular, I think I might lose control of the project. I don’t want to be in a position where I have to accommodate and work with other people."

I think this is worth discussing as a community. I see two things that could be feared:
1. Third-party interface becomes so popular that people follow its development more than Dwarf Fortress development (thus drawing away from Toady's only source of income).
2. Third party interface becomes so popular that Toady has to modify DF just to allow new features in that interface - the devs of that interface would be a bit like the current modders who always say "Add more raws!". If he doesn't do it, he's hurting DF's popularity since people use mainly that client to play the game. So, he's just been forced to collaborate with the devs of this third-party client.

Personally, Toady, I think your fears are unfounded because:
- You're already accomodating and working with other people: asking for and discussing suggestions with people on the forum, doing some things so the game can be more moddable, and so on. You just have to set the rules clearly so things stay at a level where you feel comfortable.

- What people are really interested in is the cool gameplay features only you can add. While mods and third-party tools are interesting to follow, they revolve around making the experience of playing your game better. Your future plans for the game are so ambitious that they will easily dwarf* any interest in third-party development.

- One of the main barriers to DF adoption right now is the interface. However, all the time that you spend on improving the interface slows down the development of some amazing element of the Dev pages. Worse, the more you refine the interface, the more effort you have to spend to update it later.

- I believe what would help DF the most would be a model based on an open-source client and a closed-source server. Just to give an example of how this could work:
-- You separate the game into a client and a server that communicate through sockets.
-- The client asks the server each turn what it can see in a given "window", which can be a cube of X by Y by Z tiles.
-- The server returns a list of visible objects, and the client decides how to display them. This allows for 2d, isometric, 3d clients of any sort.
-- At any time, the client transmits to the server commands sent by the user interface, such as a 2d or 3d selection of objects together with the command "Select for dumping".
-- At any time, the server can inform the client that the game just paused, and similar game-interrupting stuff.

- To avoid collaborating with other people more than you want, you should set the following ground rules:
-- You only improve your base version of the client as much as you need it to be functional. (It could look exactly the same as the current interface...)
-- You provide no support whatsoever to third-party client makers: you can break external clients them every version, it's their job to adapt.
-- You provide no documentation, people have to read the client source code to know how to make their own.
-- You don't accept patches unless specifically asked for, and you reserve the right to integrate any code from third party clients any time you see fit. If you choose the GPL as your license it grants you that right anyways.

- About the client part: I follow a lot of open-source projects, and from what I can see, collaboration with external people depends largely on how the main devs set the rules. For example, in the roguelike Dungeon Crawl Stone Soup, there are two main devs, and about five people with commit access to SVN. The rest submit occasional patches, and otherwise discuss the game and make suggestions, just like DF players.
Since people generally respect you a lot, I think they'll have no problem accepting the idea that you're the only dev - forever. Even if the client is open-source.

I'd like to know what people think about all this, and especially what you Toady think about my suggestions.

 (*pun intended)

[SHAD0Wdump]

Hmmm,Crazed dog?

And yes this is Toady's project,Lets try not to shy away from that fact and steal it from him.

[sorbius]

So basically what you're saying is:

"hey toady, I know you like to work alone and that's cool, I think you make good arguments for not involving outside people in the project, but you should do it anyway, oh and while you're at it (and while I don't know anything about the game's code) why don't you make this huge epic change to the way the game works in order to accomodate the people you already said you don't want to working on the UI.  Don't be scared Toady, it's just exactly what you DON'T want to happen."

[Ruttiger]

While I love clients that make games more playable (I would have abandoned KoL years ago if it weren't for KoL mafia), I can understand Toady's sentiment.  It's his project and he shouldn't be working around clients or mods others have made.  At the same time, someone who wants to develop their client should be able to. 

But if that update the severely changes the engine comes along, it should be up to the client writer to make it work again, not Toady to make his new version similar to the old. 

[Sergius]

Once the game is out of alpha and into beta (meaning feature freeze or something) I'm sure Toady will consider more third party addons and whatever.

Alpha means, exactly, that you can't trust that the next version will be anything like the current version. So locking yourself with someone else's code during that stage is a bad, bad move.

[Tormy]

I dont think that Toady should worry about this.

[puke]

heh.  i love the feelings of entitlement that develop within fan comunities.

MMOs, p&p RPGs, small press or large press games, or basically anything with any size of fan base:  development needs to acknowledge or stay true to the fans.  respect personal ownership and simultanious anonyminity of fan-generated ideas posted on forums owned by the developer.  any code change that effects third party apps is an act of sabotage.  any change in gameplay is bound to anger 100% of the vocal minority; the best that can be hoped for is that half want more of the change and the other half want less of it.

I generally only read forums for games that are small enough and niche enough to have a pretty reasonable and mature community, but these sentiments develop on all of them.  so i think everyone should be able to understand some basic realities:

youre not anonymous.  youre in someone else's house.  act like it.  you're playing with toys that they built, in their generousity, to ammuse you.  the toys would still have been built if you personally hadnt been fawning over them.

[Frobozz]

This is definitely one of the better arguments towards going with this route, but with a few changes.

- I believe what would help DF the most would be a model based on an open-source client and a closed-source server. Just to give an example of how this could work:
-- You separate the game into a client and a server that communicate through sockets.
-- The client asks the server each turn what it can see in a given "window", which can be a cube of X by Y by Z tiles.
-- The server returns a list of visible objects, and the client decides how to display them. This allows for 2d, isometric, 3d clients of any sort.
-- At any time, the client transmits to the server commands sent by the user interface, such as a 2d or 3d selection of objects together with the command "Select for dumping".
-- At any time, the server can inform the client that the game just paused, and similar game-interrupting stuff.

The idea of using sockets is an interesting idea. It could allow the server to reside either on the gamer's computer or on a server that Toady has setup. Thus eventually allowing for the game to go multiplayer with the basic networking infrastructure already in place.

However, rather than use sockets I would make DF into a programming library with a basic API to send commands. For example, designating a particular section of the screen with the current interface allows entire sections to be selected at once. That is a detail that could be handed to the interface, with the API simply having a command to select a single location on the map.

Code: [Select]

int Designate(DesignateType type, int x, int y, int z);
Thus to select an entire section, the interface would merely call that function over and over sending all the locations the user has selected. Similar things could be done for constructions, etc. If the game had to be paused before all the constructions could be done, it could call pause/unpause (or lock/unlock) functions. This would also have the side effect that the interface could allow designations without actually keeping the game paused. Rather, it could be set to pause/unpause only after receiving the locations from the user. It could very well do it so fast the user would never notice it were paused at all.

You provide no support whatsoever to third-party client makers: you can break external clients them every version, it's their job to adapt.

Keeping a highly simplified system of accessing the server would more or less keep the client from ever breaking except in the sense that it would have to be updated to support new constructions, designations, etc.

You provide no documentation, people have to read the client source code to know how to make their own.

Documentation would be nice, but unnecessary with proper naming of the functions, data types, etc of an API. Take the code example I gave above. Does it really need documentation to be understood?

So locking yourself with someone else's code during that stage is a bad, bad move.

I fail to see how this would lock someone in with someone else's code. In the case of Toady, he could simply go with the method I gave above for his interface and simply not release the source to it. And in the case of third parties, don't we already have a ton of programs that hack into the data files and memory locations of DF?

youre not anonymous.  youre in someone else's house.  act like it.

You're also failing to notice that his housing is currently being paid for by this particular community. In a sense he has to let us play with his toys or he loses his income. Not that I'm trying to sound threatening. Like I said above, he could simply use the idea I gave to implement his own interface and never give the source or permission to do the same to anyone.

However someone creating their own interface can already be done. People are already hacking the game as it runs, placing hooks into it in a sense that allow them to pinpoint the location of various things. Its merely a matter of time until someone writes something similar to create a third party interface.

[Sergius]

So locking yourself with someone else's code during that stage is a bad, bad move.

I fail to see how this would lock someone in with someone else's code. In the case of Toady, he could simply go with the method I gave above for his interface and simply not release the source to it. And in the case of third parties, don't we already have a ton of programs that hack into the data files and memory locations of DF?

And that, is why you fail.
Any change in the "interface" will break compatibility with the third-party GUI. Either Toady needs to tiptoe around this so as not to upset the GUI, or he doesn't give a crap and breaks it anyway. If enough people are using this GUI, there's an uproar and people bitch and moan and nobody will play the new version until the GUI is fixed.
It's different from changing a few tiles. While I love using the graphical raws, I have no problem using the regular ASCII interface in the meantime. People who get used to a complete GUI revamp just won't want to touch the ASCII one with a 10-feet pole.

[Frobozz]

And that, is why you fail.
Any change in the "interface" will break compatibility with the third-party GUI. Either Toady needs to tiptoe around this so as not to upset the GUI, or he doesn't give a crap and breaks it anyway. If enough people are using this GUI, there's an uproar and people bitch and moan and nobody will play the new version until the GUI is fixed.
It's different from changing a few tiles. While I love using the graphical raws, I have no problem using the regular ASCII interface in the meantime. People who get used to a complete GUI revamp just won't want to touch the ASCII one with a 10-feet pole.

First off, you sir, don't know what you're talking about. Obviously you have no experience at all with software development. If you did you would realize that a simple well-thought out API would have no need to be broken every time Toady wanted to implement a new feature. Changing the internals of a library is quite different from changing the API. If it weren't, then libraries wouldn't be used for programming and everyone would simply use the hardware directly. There are of course some cases where things would be broken, but they would be the minority.

Adding new features though is quite different from breaking an entire API. Like the example for designations I gave above. There is simply no reason that should be broken if a new designation were added. Rather, it would simply have a new entry added to the enumerator DesignateType. And really, there is no reason that it would ever need replacement unless integers would no longer be large enough to contain all the possible location numbers.

Also you fail to notice that I never said anything about the graphical representation of the game. I also never said anything about a graphical user interface although allowing third parties to make their own interfaces would also include graphical ones. Although honestly I do think at least one third party interface based around ASCII would spring up to fix the disadvantages that exist in the current one.

Lastly you make the incorrect assumption that everyone favors graphics over ASCII. That simply isn't the case. I personally play games that are ASCII, 2D, 3D, etc. Graphics ultimately don't matter that much to me. What does matter is having a decent interface and good gameplay. Gameplay is already covered just fine by Toady, but the interface is currently just a hack job that I would expect any developer to make until the core gameplay is implemented.

[ervill]

Hi there,

i played dwarf fortress some weeks, its really awsome but i had too much troubles with the interface after a while (the simple ones were monitor burnins, eyestrain) so i stopped playing it. That means my troubles werent with the graphics because i dont need graphics for a good game... but this is not the "presentation" thread, so i stop writing about that.

Im with isitanos on this subject. I dont see the sense, why today should be spend time on so "primitve" things like creating interfaces (alltought its an important task). Besides that, there are so nice window toolkits/ framworks whatever out there that make creating mighty GUIs/interfaces very easy (QT as one of the best: http://trolltech.com/products/qt) . There is no need wasting time to reeinvent the wheel. Sadly, most of them are only free of cost for opensource projects and i dont think its in the budget to license anything so an opensource client would be an really good solution.

[Torak]

He's not going open source, ever. Stop asking the same goddamn question every two bit programmer asks.

[ervill]

He's not going open source, ever. Stop asking the same goddamn question every two bit programmer asks.

Its about an open source interface client not the whole program. It doesnt help anyone giving an example of operant conditioning everytime someone writes some deeper insight about that topic btw.
Especially not, when Today perhaps wants to evaluate all possible solutions.

[Qmarx]

It depends on five things

-Will this make coding easier in the long run?
-Will this create more none-coding work?
-Will this restrain how the project will develop?
-Will this obligate Toady to fill other coder's wishes?
-Is Toady actually interested in making an interface?
   -Will coding the interface make game development more or less interesting?

Now, if Toady starts doing a UI, and finds the work extremely boring/irritating, the possibility exists that he'd outsource the UI work to other devs (he is, after all, doing it because he finds it interesting)

Until that happens, who knows?

[Torak]

Its about an open source interface client not the whole program. It doesnt help anyone giving an example of operant conditioning everytime someone writes some deeper insight about that topic btw.
Especially not, when Today perhaps wants to evaluate all possible solutions.

Tell me why toady should work on an interface specifically for all of you expert programmers while he could be working on the game, or his presentation arc, which will cover all of this crap in the first place.