Print

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

[Malenfant]

It'd be great to see a client/server version of DF that simply outputs the current game state from the server and accepts input via a client system. That way the community can write their own front ends, 2D or 3D doesn't matter, the core information that DF produces is enough to create either.

This has a number of benefits:

-   Toady can focus on the core game mechanics such as how long can a Mule can survive in stagnant water before meeting its tragic death. I think it goes without saying that everyone is happy with this; we’d all rather see him perfecting game mechanics than wasting time on graphics problems.

-   It's a neat and tidy principle that's been used before in countless games, the best example been the Quake series. Since the frontend can be completely rewritten without affecting the core game mechanics you do bizarre things like play the entire game in textmode

-   It would allow the community to make real and considerable contributions, no one group would be left out in the cold. 2D purists would have their day in both textmode and graphical tiles. The 3D hardcore could bump map a dwarfs behind to their hearts content.

-   A fancier interface would bring in more people. I know this might be seen as a downside by many but I’m of the opinion that the more the merrier. Too many people I’ve spoken to are intrigued by the description but flat out refuse to play once they see the interface. It’s really a shame, doubly so when the next release comes out.

As I said, it’s a proven design pattern which would really allow the game to make a leap forward interface wise without detracting from the work been done on the core mechanic.

Well folks that's my 2c, apologies if this has been mentioned before, it wasn't exactly an easy topic to search the forums for prior posts. I'd really be interested to hear if Toady has weighed in on this matter before today and how other coders feel about the idea.

[Faces of Mu]

Hi Malenfant,

This is a great idea with obviously many benefits.

Do you mind if I ask what problem you feel it is solving, besides making improvements? What do you feel is lacking right now that this could "fix"?

[Malenfant]

Depends what you currently define as a problem really. Things like control consistency (up/down or +/- or PgUp/PgDn), ASCII graphics or limited mouse support are very much a matter of opinion. To many people on these forums these are either irrelevant or even cherished but to many others they make DF largely inaccessible.

I think the main thing it could offer is a natural vent for the DF community, if a feature is really in great demand I'm sure there are enough programmers available on these boards to help provide it. If anything this isn't so much a fix for DF but a fix for the DF community.

[Turgid Bolk]

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

I'm a little unsure how feasable this is and how much effort it would require on Toady's part. No doubt it would require a new new version that would probably be incompatible with the new version. But this would allow a completely customizable interface, with completely customizable graphics? Kind of a MUD-style setup (only for local single-player), right? I have no doubt the community would come up with some great clients for this. One person already attempted to change the display (B.Barabanus' GreenGlass patch).

On the other hand, it might be more work to implement something like this and keep it maintained as the game changes, than to simply wait for Toady to finish the game and make the real interface. The reason he hasn't worked on the interface is that many features aren't in yet, or not finalized, and this would be just as difficult to maintain as that. He'd find no lack of community support for it, though.

[Capntastic]

I'm pretty sure this would be a lot of work, and wouldn't really further the game's development.   It would be a lot better than some ideas I've heard for making DF have 'prettier' graphics:  Usually telling Toady he needs to make it 3d or else he's a jerk.   Which just ain't true!

I don't really know the bitsmithing involved, though.    And if you say that the DF community right now doesn't make useful contributions (Bug testing, feedback, mods and tilesets) currently,  then you're just a big meanie!

But I'll give you super credit for providing a suggestion regarding full-on-custom graphics that isn't essentially a blood smeared note saying "3D OR DIE" daggered into Toady's front door.

[Tahin]

This would probably be a ton of a unnecessary work on Toady's part, but if he's up to it, I would love to see this implemented.

[Malenfant]

I think the difficulty all depends on how DF works internally. If for example it's using some sort of MVC variant then it could possibly be quite easy. For all we know the interface (or view) is already separate from the model and breaking it into two programs wouldn't be much of a problem. Of course I have no idea how it's actually written but it's not necessarily impossible or massively time consuming.

Like most people I'd prefer Toady worked on the Bloats and Powergoals (bloat 147 in particular, oh how I long to be an evil wizard) which is why I'd rather he continued to do so rather than focus on this potential future interface. If he does make any changes to the model then I'm sure they're likely to be done incrementally rather than in sweeping overhauls. But if they were full scale changes then he would have to rewrite the interface himself anyway, so yet another benifit of leaving it up to the community.

[Malenfant]

quote:Capntastic - And if you say that the DF community right now doesn't make useful contributions (Bug testing, feedback, mods and tilesets) currently, then you're just a big meanie!

To rephrase: "It would allow the community to make *more* real and considerable contributions."  

[Toady One]

My project is a mess of course, but it's not hopelessly intermingled.  However, regardless of how things are set up, I don't really understand how this sort of thing works, so I can't really gauge how hard it would be.  For instance, if you say something like "outputs the current game state from the server", exactly what do you mean?

[Funkadelic Jive Turkey]

I think I remember Toady saying he did plan to rework the interface anyways, at some point. I don't remember the details, and somehow I doubt he meant DF in 3d, 3.0 shader model , HD, etc. but I do remember him saying something about not being happy with the locked # of tiles (80x25?).

@ Capntastic:
I don't recall anybody ever screaming "3d l33tness or deth", granted I've not been here since 2002 but...yeah...anyway, it seems there's more of an ASCII purist community than a "modernize it" one. Furthermore I think most people on the forums  fit into a 3rd category of being able to cope with or without fancy graphics.

[Funkadelic Jive Turkey]

quote:Originally posted by Funkadelic Jive Turkey:
<STRONG>I think I remember Toady saying he did plan to rework the interface anyways, at some point. I don't remember the details, and somehow I doubt he meant DF in 3d, 3.0 shader model , HD, etc. but I do remember him saying something about not being happy with the locked # of tiles (80x25?).

@ Capntastic:
I don't recall anybody ever screaming "3d l33tness or deth", granted I've not been here since 2002 but...yeah...anyway, it seems there's more of an ASCII purist community than a "modernize it" one. Furthermore I think most people on the forums  fit into a 3rd category of being able to cope with or without fancy graphics.</STRONG>

Edit: Lo! The Toad hath spoke while I hast been typing!

[Malenfant]

quote:Originally posted by Toady One:
<STRONG>My project is a mess of course, but it's not hopelessly intermingled.  However, regardless of how things are set up, I don't really understand how this sort of thing works, so I can't really gauge how hard it would be.  For instance, if you say something like "outputs the current game state from the server", exactly what do you mean?</STRONG>

The simplest method would just be a wrapper on top of the current DF executable that makes the current game window viewable and trappable by a 3rd party application. If we are able to grab the information that is been displayed as plain ASCII data (with allowances for the fact it's not pure 2D, ie. The dwarf, his rock and the floor he's standing on) we can render that into whatever we please. The commands sent to DF can also then also be remapped to whatever takes our fancy.

A more complex way I can picture it is that the main DF executable would run the core game mechanics independent of the interface, separate and unseen by the user. A pure simulation engine in other words, this would be the server component. The client would then deal with the interface issues such as accepting requests to build a woodpile or displaying the current portion of the fortress. How they communicate would be up to you, they can either use a standardized API or perhaps you could have them communicate via network sockets (now this is bloatalicious, you could then have dedicated DF server machines at home with clients running at work, crazy stuff).

A third possibility, possibly the cleanest, would be to have your user interface completely enclosed in its own dll.  The dll provides a fixed set of functions (createGameWindow, drawDwarf, drawFireplace) which the game engine can call to do all the ui.  All you need to do is select the ui library you want to use.

As long as people know the API they need to provide in their DLL to create a UI, anyone can make one and they can do it in whatever language they like, as long as it can build a win32 dll.

Further Reading: http://msdn2.microsoft.com/en-us/library/aa365574.aspx

[ October 20, 2007: Message edited by: Malenfant ]

[axus]

Good ideas... as soon as you had a separate DLL that output and input to the user, the DLL can also be programmed to accept input over the network.  That's not far from loading multiple DLLs (or loading one multiple times) and cycling through input/output on each of them.

The hard part is keeping a lean set of outputs from the main code to the client.  The even harder part is writing the client!

Civ Evolution (http://www.c-evo.org/) uses the server with client DLL method to great effect.  Instead of writing new user interfaces, players wrote AI modules for each DLL.  The same could be done here, write a player AI without a UI, but that's a task for the possessed.  I've written an AI DLL, and a network interface DLL for c-evo, it was a lot of work and I never had much of a remote client interface.  But it would be nice to have as a theoretical possibility for DF.  Again, because the game will always be evolving, we can't get a complete interface for a long time... and you really need a complete interface to do it right.

[Eagleon]

I love this idea. Very elegant. It wouldn't even have to output everything the simulation does, just what the player can see by default and a little extra in the case of multiple levels. If/when player control of individual dwarves is implemented, it could also allow for rudimentary multiplayer in fortress mode with a bit of alteration and suitable front-ends.

[Toady One]

It's the lean set of outputs I was asking about.  Saying that someone would be able to make the game display in 3D would require a bit of work somewhere, depending on what you intend as the field of view.  Would the client ask for all the things in a given rectangle?  Where is the control on how much is sent (there can be hundreds of thousands of objects in the rectangle)?  I suppose the client could also send in an item cap or something like that.  Seems like it would be quite a bit of work on my part, and that I'd also essentially be in the position of supporting 3rd party app performance.  It could also just pass across a pointer to the object list and let them do all the culling, but then I'd have to publish all my object definitions, which I'm somewhat leary of, and I'd also have to maintain and update and explain that information constantly, which is a lot more work for me.  Or I'd have to set up a second object list with less information that gets sent across?  In which case the performance of DF in general decreases as this new data structure is maintained.  Or perhaps there's something else.

Regarding the DLL, I don't quite understand that either.  I know they were just examples, but when would the game engine ever use the dll to call something like drawDwarf?  I thought the engine wasn't in charge of that.  Does the game engine do more work with drawing game objects than reporting information about their type and location?  I thought the client would take the location/type information and do whatever drawing it wanted to do independent of the engine.  Or maybe drawDwarf was a name for the location/type report?  I guess it couldn't be drawDwarf, because dwarves don't exist outside the raws, so it would have to be something fairly general, and some of the issues raised above come up again.