Print

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

[Parisbre56]

I was reading the eternal suggestion thread and saw that the suggestion "Seperate the game into a server/client model" only has 4 votes and is only mentioned once in the suggestion board in a thread about multithreading. And I thought I'd make this thread to promote it, as I believe it is a very important suggestion, that could solve many other problems and suggestions if implemented.
Wouldn't it be simpler to make all the game information available through some kind of interface and have the ability to launch the game in two modes? The current mode and a "server" mode that runs the game without displaying any output. Then you could connect to the "server process" with a custom built "client process" and ask for information your client requires to display whatever you want it to display, or do whatever you want it to do. (You just want to display the creatures' symbol, that's fine, you just go through every tile and ask for creature type information. You want to display a different symbol or sprite depending on whether or not your dwarf is missing his left or right leg and whether or not he has a crutch? You program your client every time it wants to display a dwarf to ask whether or not he has a leg.)

Pros:

• The sky is Your programming skill and dedication is the limit. Want to simply extract some combat logs or legends info? Sure. Want to make a clone of the standard DF window with a few UI tweaks? You can do it. Want to make an isometric 2D viewer with mouseover texts and all that fluff? You can do that to. Are you crazy enough to attempt to make a 3D realtime visualizer? All the info is there. If you think you can do that and remain sane, I'm not going to stop you.
• The client is a separate process, so lag in the game would not affect the client. You would still be able to move around and view things and issue orders, as those things will be buffered by your client and passed to DF whenever it has finished doing whatever it's doing that's lagging.
• No more memory hacking. No need to release an update for DwarfTherapist just because Toady made a small bugfix release. All you have to do is add support for the new features coming from major releases (for example, how to display those multi tile trees or army management options).
• Easier scripting support. Want to make a program that checks if you have enough booze and if not makes some? Sure. Want to make a program that gets some stats for the fort you're currently playing and updates your forum signature? You can do that. Want to make a program that only selects those worthless stone crafts when trading, while avoiding wooden bins when trading with elves? You can do that too.
• No more tile restrictions. A theoretically infinite number of objects are possible, since DF no longer gives output in the form of tiles but in the form of pure information. (For example in this tile there is a microline floor, the upper left corner of a wooden carpenters workshop, the severed right front leg of a cat and a tantrumming dwarf on fire, submerged in 2/7 water. Water has just flowed in this tile from the left and smoke from the right. On the tile in the right there is a custom creature named 'Lizardman' with those stats and body parts: male, 2 legs, 2 wings, green scales etc.)
• Interface cleanup. One of the most voted suggestions could be implemented by the community with this.
• Ports. Have you chanced upon some kind of phone left behind by a time traveller that can adequatly run Dwarf Fortress? (More realistically you could be running Dwarf Fortress in a phone with Ubuntu OS in a few years if processing power continues to increase.) All you need is to program a client that works with touches and gestures and voice commands.
• Multiplayer. Some hotseat-style multiplayer clients could be created this way, with a group of people playing the same fortress (or adventurer, but that would be a bit strange). Maybe people will try to create a megaproject together, maybe one would manage the military and the other farming, maybe one would try to kill the others' dwarves first by building suicide rooms...
• Don't like those newfangled interfaces because they strike you as too flashy or are just too buggy? Then play the game as the Toad intended: with the good old openGL display we're using now.

Cons:

• May lead to performance and memory issues, as information must be transferred and stored between the two processes.
• There is also the problem of synchronization, as what you're seeing might might be a few ticks behind what is actually happening. This will only be aggravated if multithreading or openCL support is ever implemented.
• Creating custom creatures or modding preexisting creatures can create problems if the client is not written with support for this stuff. (Although that's more of the client's developer problem.)
• Potential for abuse. Put all these information out there and someone will find a way to abuse them. (For example by having a program that finds vampires. Although I think that DFHack can already do that.)
• Requires Toady to divert work from adding features to creating what is essentially an interface between a client program and DF's memory. (I understand that DF is written in c++, so that would mean adding sockets and a small part of the program that reads requests or input and gives data, as well as documentation about how all this works.)
• This would require extra work every time a new feature is implemented (for example, army control is implemented->you need new commands to relay your orders from the client to DF, retrieve information about army position, army composition etc.).
• Doesn't actually solve the graphics/standing orders/interface problem, it just makes these problems the community's responsibility. (Although I'm pretty sure the community is up to the challenge.)
• May lead to complaints from tool and interface developers when Toady inevitably decides to change something in the way info is stored and displayed that breaks compatibility with previous tools.
• Toady may not like someone else messing with how things are displayed. After all, it's his game.

Anyway, just a thought. If I have made a stupid mistake somewhere or this has already been talked about before, please tell me about it and forgive my ignorance.

[Putnam]

Creating custom creatures or modding preexisting creatures can create problems if the client is not written with support for this stuff. (Although that's more of the client's developer problem.)

nah.

Toady may not like someone else messing with how things are displayed. After all, it's his game.

The SDL code is already written by others. HOWEVER, Toady is quite a bit against things that would pressure him to keep compatibility with outside programs between versions; already-existing programs don't have his official support, so he doesn't feel quite as pressured there.

[GreatWyrmGold]

Could someone summarize what this entails for certain people who have no idea what the OP is talking about?

[Putnam]

Could someone summarize what this entails for certain people who have no idea what the OP is talking about?

Have the game run miscellaneous stuff while there's a separate graphics engine displaying everything.

Toady's already said no to things like this.

[vanatteveldt]

Have the game run miscellaneous stuff while there's a separate graphics engine displaying everything.

Toady's already said no to things like this.

It goes a bit further than this. The suggestion is to separate the "backend" doing all the simulation, AI stuff, assigning jobs, pathing etc, from the "frontend" where you actually give commands.

I think it is a good idea, because it allows the player community (which I think includes quite a number of good programmers as this is the kind of game that would attract them, and as also witnessed by helper programs like dfhack, therapist, etc.) to concentrate on making real contributions instead of hacking away at a moving target. Also, after the initial effort it allows the developer to do what he is brilliant at (simulating a dwarven world) and not waste time on things that are obviously not his main interest (UI stuff).

A related model is the linux music system called "mpd" or music player daemon. There is a main program "mpd" which knows how to play music, manage the library etc, and there are many different clients, ranging from command line (mpc), graphical (ario) to andoid app (mpdroid), programmed by different people, which all provide a nice GUI to access and manipulate the actual music player.

Toady: everyone loves your game and 90% of those people have lots of interface frustrations. Please allow us to scratch our own itch by separating the game into backend and client and open sourcing the client. The client is really not your business asset (the backend is), so there is little business risk. I would happily donate / pledge a kickstarter to get this done, as I think this game has much more potential than currently utilized.

[Putnam]

Again, Toady's said no to this, as it would put pressure on him to support these UIs that aren't made by him--something he doesn't want. He won't do it if it takes enjoyment away from development, as far as I know.

[Kipi]

As stated already, this has been suggested before and Toady has already stated that it won't happen.

Did some searching and found out this. That post explains why Toady isn't willing to do a change like this just to support modders.

[Parisbre56]

Okay. Sorry. Hadn't seen this. Locking the thread. If anybody knows how to delete it, please do.