Print

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

[Spriggans]

@Alexchandel :

The hard part in this client-server approach is the client.
As I understand it, the client will have 2 components :

- The display component. It allows you to see a portion of the fortress.
It reads the state of the server every xx frames.
So, every xx frames, it refreshes the state of the fort to display.
It takes in keyboard inputs to move the view in the fortress (< > up down left right and Fkeys basically)

- The controller component. It allows you to send requests to the server.
Now, when we do stuff with this component, the client will stop refreshing the state of the fortress.
So for instance, if we press "k" to inspect something, or "b" "t" to place a table, the display component will stop asking the server's state. Thus, the client will localy freeze the fort so we can place things, or inspect an entity without it moving non stop.
During this local pause, the server keeps running.

Once we are done with our controls, the controller sends a request to the server and the display component refreshes the fortress' state.


-> What does this "Remote Fortress Reader" do exactly ? Does it take care of the "display component" part ?
Can we get RFR to refresh (read fort data) whenever we want ?
Can we use RFR to move the viewport ?
If so, that the display part sorted out.

-> I have some ideas on how to implement the controller part.
I'd like to dive into that eventually. But I'd like some well documented code. DF's memory edits are just.... 

EDIT : ho and btw, this controller part means we will be remaking a new GUI.
It means lots of possible bugs.
It also means it will need to be updated every release.

[Bumber]

- The controller component. It allows you to send requests to the server.
Now, when we do stuff with this component, the client will stop refreshing the state of the fortress.
So for instance, if we press "k" to inspect something, or "b" "t" to place a table, the display component will stop asking the server's state. Thus, the client will localy freeze the fort so we can place things, or inspect an entity without it moving non stop.
During this local pause, the server keeps running.

This sounds like a bad idea. Things could radically change while you're working with stale information. How are you going to know when it's safe to pull a lever?

What we need is a better way to select and view moving entities. If we need a custom GUI separate out player controls, it might as well do that too.

[wierd]

Something similar to how mpeg streaming works (conceptually at least) might be useful here.

Every so many milliseconds, a full scene is transmitted to the viewer to stay up to date, but in the intermediate period, only delta information on changes is transmitted from the last full status update. (Similar in concept to key frames and i-frames from mpeg) This way, when a user is looking at a menu (likely they arent strolling all over the map with the menu open, so the viewport will be mostly static aside from li'l urists running all over) the local slice is updated via the smaller/easier to process delta packets, so the burden on the viewer's presentation system is less.  It would also be more efficient for transport over the wire.

The idea is that the menu surrogates do not pause the running game, even in the local viewport. Dwarves still run all over the place doing this and that while you paint designations, or order a lever pulled. This keeps data in the viewport up to date with the running instance, and does not pose a nuisance to other players. (That feeling when your buddy pauses the game to designate stuff to trade at the depot, and then the mighty need to answer nature's call mid-trading causes a minute or so pause session to become a 20+ minute ordeal, where all the other players get rightly angry-- that kind of thing. Instead, the game world continues unfettered unless PURPOSEFULLY paused when the remote players define items for trade, or give orders to pull a lever.)

[Bumber]

Should a multiplayer server be actually running unpaused, or is it better for the server to be advancing time manually (default ".")? Is there a huge difference?

I would assume we may need extra time to resolve conflicts and latency.

[wierd]

Hammering the pause button programmatically might be a useful feature, but I would not want that as the default. Otherwise a slow client will degrade other users performance. I would rather the client have sync problems than degrade server performance.

[Klitri]

...Make one, then, and come back and show us how feasible it is, since your idea is here and all written out!

[quekwoambojish]

Are you guys just looking this shit up as you go?
...
Or is every frequent poster here a professional server manager, while I’m here just trying to figure out how to put annoyingly long Christmas socks on?

[wierd]

STEM vocational training/education, and playing DF, have a surprising level of overlap. 

[Bumber]

I had a few relevant courses as part of my CompuSci degree. Databases, network protocol.

[Magistrum]

It is incredible how easy it is to grasp the more abstract problems of this.
Of course, the actual execution is way more complicated.
This is just the conceptual talk that needs to happen before any attempt.

[Sanctume]

There is only 1 process, df.exe 

Warmist has pretty much done a proof of concept to send command via remote. 

Issue 1: How much delay should there be with df.exe simulating the fortress, and have users send to command to be executed? 
IIRC, running the game cap at 1 FPS can get this thing going. 

Issue 2: How much info will the server need to send out when a client needs data to render their viewable / visual area of the fort?
IIRC, Warmist has some function to send the user a cube of data via x,y,z coordinates. 

Issue 3: What are the limitations provided to the user in the context of manipulating the fortress? 
The limitation will be in the function available in the client; and what commands are available in dfhack utilities. 

Each one of these client-command could be it's own utility.
For example, I'm thinking of digging. 
I get a 10x10x10 viewable area and using my client, I designate dig a 3x5 hallway, with a 1x1 doorway, and 3x3 room.  Will the client allow me to send all 25 tiles to be dug?  Or will it send 1 tile dig, then wait for completion, then send dig the 2nd tile, and so forth? 
And of course, the client itself can be coded automate the send dig tile 1, then wait, etc, until all 25 tiles are dug before I can send new commands. 

That's one function / concept.  How will workshop builds be done?  Will the user rely on fortress manager, and then wait for the job orders to be executed dependent on however busy / not busy the manager is?  Or will the user be able to manually queue in a build / add from specific workshops? 

--

Multiplayer DF gameplay would be chaotic the way I am picturing it now in terms of sending df.exe a bunch of commands that may conflict with other users.

[wierd]

Here is what I was thinking:

On initial connect, the client gets fed an initial seed of the world data. This is a full cube of data. and represents the revealed area only. (the client does not need to know what is unrevealed. It can easily fill that in locally with black tiles.) We do not send tiles for creatures, only for plants and minerals.

After this initial seed, we only send the client deltas about world geometry. Somebody dug a tile, or cut down a tree, etc.  If the client thinks it is very out of date, it can ask for another complete re-seed, but this should be minimized as much as possible.

Dwarves, creatures, water, magma, steam/smoke, etc--- will all be tracked differently by the client. Similar to world data, an initial seed sets the state (pausing the world when a user connects then resuming would help with this) then deltas are sent with a unit ID, and an info packet containing changes, if there are any.  (I expect liquids would be very painful. Some form of abstraction might be needed, such that the client only cares if there is less than 4 water in a tile, so that sloshing is less of an issue on pushing updates.  EG, we have 3 states instead of 7:  Empty, has some liquid but less than 4, Has 4 or more liquid That is enough for the menu logic, without having to send a live update stream for liquid flows)

 

[Sanctume]

What is the purpose of knowing the tiles 4x, -6y, 0z from the user's center seed is 4/7 water or whatever? 

Is it fortress mode with an controllable adventurer?  I doubt it's doable at this time. 

Or is it fortress mode,  where the user can issue dig designations?  If so, then the user can go ahead and try dig that 4/7 water, but the df.exe should handle that it is an invalid command; or the tile is unreachable. 

I can envision a starting scenario for a multi-player df. 
Host player goes the world gen, and choose embark position and items and starting skills for the first 7. 

Embark.
Idea: Host player can start the multi-df which allows df-clients to log in the fortress.

Idea: df-client will provide a list of "available_dorfs", and user can choose one. 

Idea: when all available dorfs are claimed, other users can choose to follow any dwarf for viewing. 

Idea: A user choosing an available_dorf can update that dwarf's labor setting: miner, mason, mechanic, hauler, etc...

Idea: Based on a chosen dorf's labor, command will be available in the df-client: digging if miner; access to mechanic shops, etc.

Idea: When noble position for Militia Commander is set, that dwarf will have df-client command to create uniforms, request orders for weapons and armor, approve Squad Captains requests, schedule training / defend burrows.

Idea: Squad Captains can choose their squad's uniform; select which barracks to train, and update schedules.

[thompson]

You'd want to start with a simple concept that adds something to the game while requiring less effort to set up, then progressively add functionality from there. Trying to build a full UI for DF from scratch with a concept that requires too many features to work would be setting this up to be abandoned down the track.

So, which specific areas could be given multiplayer functionality while also adding to the game? You'd need digging and building placement to start with, then allow work commands (starting with manager only perhaps?). Controlling squads would be nice to implement reasonably early.

Features that aren't implemented in the client are the responsibility of the host. This rollout strategy would help keep the project on track and reduces the workload of the developers before the release of version 0.1.

Edit: Scratch my comment about implementing squad orders early. Start with features that don't require real time access to item/animal/dwarf information simplifies the initial rollout considerably. Perhaps in the first version you only have information on layout and furniture. I'm sure people will accept it if they know more features are coming.

[Rose]

I just want to chip in and say that the RfR plugin would need a bit of work to allow multiple simultaneous users, but it's doable.

Alternately, a new plugin can be written from the ground up to have multiple users in mind, but it's probably easier to modify the RFR plugin.


as for ideas how the gameplay would work, I recall a DFHack plugin that's been made that forces the game to never pause. I believe there's a debug flag that can be set.

Resources would need a way to be separated between the players. Perhaps dwarfs too. Every time migrants arrive, they're split evenly between players, with each player being able to assign labors on his own dwarfs. Perhaps also set areas where players are allowed to designate, with some shared areas.