16
DF Dwarf Mode Discussion / Re: Simultaneous multiplayer is feasible
« on: December 18, 2017, 08:47:31 pm »
Edit: typo, accidentally quoted instead of modified (ლ‸－)(－‸ლ)
Bay 12 Games Forum
- April 06, 2024, 05:45:21 am
- Welcome, Guest
News:
March 6, 2024: Dwarf Fortress 50.12 has been released.
News: February 3, 2024: The February '24 Report is up.
News: February 4, 2021: Dwarf Fortress Talk #28 has been posted.
News: November 21, 2018: A new Threetoe story has been posted.
Forum Guidelines
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: 1 [2]
17
DF Dwarf Mode Discussion / Re: Simultaneous multiplayer is feasible
« on: December 18, 2017, 08:46:58 pm »…
(The better multiplayer systems suggested, IMO, are parallel forts that are never allowed to get further apart in local time than can be put down to travel time between.separate forts1 The faster-playing player (or the one on the better FPS machine) might be asked to hold on whilst the other finishes the trader-trading, then instantly receive the wagon (in the state it left the first) the moment as much of the whole entourage has safely left the first site as last minute happenings might allow. In this version, extend that to the process of raiding parties (never so far into the future that a raiding party 'should have already arrived', or an existing one thence can have returned (or not). But same-site-sharing clearly cuts this allowable bi-directional buffering to zero.)
There are no actual technical issues (that can't already be cobbled together, right this moment, from 3rd-party (DF community) and 3rdier-party (OS-level) add-ons), only logistical alterations necessary to add compromise play-modes that are going to be far from universally agreed-to.
1 Or current Most Unexceptional-travel timings for an Adventurer when one or more player is in that mode of play. Two (or more) Adventurers at varyinh (including negligible) distances from each other. Or from the simu-playing Fortress Mode players, if that inherently differently tick-passing play method is allowed to co-exist.
An orthogonal type of simultaneous multiplayer, where multiple forts on the same map evolve? If fortress-evolution calculations are sufficiently isolated from background-world-evolution (specifically, if they're not interleaved), it might even be possible to run each fort on a separate thread, assuming you stick to a client-server model (which seems far, far easier than coordinating servers' world synchronization).
You could even have same-fortress multiplayer and cross-fortress multiplayer in the same game (e.g. 2 players on one fort, one player on another, exchanging raiding parties).
It's always been the problem that play tends towards being asynchronous with game-time varying wildly from play-time. Not a problem with a solo game (complaints about depressed FPS aside, which I don't consider game-breaking anyway so long as it does still tick, however slowly) but two players meshing together is a practical problem that no mere 'recoding' can handle. It's, as said, a change in game-play, with either micromanagement allowed to throttle the freer player, or 'plot progression' potentially happening full-throttle whilst things (that need to be 'menued' in-depth) continue unhandled.
…
See I'm thinking 'plot progression' could happen full-throttle, unless explicitly paused by either player (e.g. bind pause to the backtick/"`" key on every screen). One could still attempt to 'menu' things as deeply as possible real-time, explicitly pausing when it wasn't possible.
It's worth hacking this feature into the current (single player) game, to see how it plays. From a technical point, the only potentially problematic question is "what does the current menu code do when a menu should've changed?" As long as the answer isn't any variation of "the game crashes" or "the game gets corrupted," it's fine.
18
DF Dwarf Mode Discussion / Re: Simultaneous multiplayer is feasible
« on: December 17, 2017, 11:58:35 am »That WOULD change the game quite a bit though...
Definitely adds some new potential dynamics to it. I think it breaks into two changes:
- Adding the ability to prevent Dwarf Fortress from auto-pausing whenever you open a menu, a.k.a. "extra fun mode"
- Creating a remote client that lets someone else view and modify your game while it's running
19
DF Dwarf Mode Discussion / Re: Simultaneous multiplayer is feasible
« on: December 17, 2017, 11:49:31 am »Given that dfhack can add/remove designations and flags without pausing (Many scripts use the pointer/cursor to select items in the item vector, but this is just a convenience to avoid having to somehow magically know which "green glass blocks" you are meaning to have used, etc) so theoretically you dont need to pause at all when sending it instructions.
Sure, I'm not worried about whether dfhack could make changes to a running game (which it possibly does with ease due to DF being single-threaded). I'm wondering how the existing menu code (e.g. a workshop screen, the military screen) will behave if the game isn't paused. For currently, DF is auto-paused whenever you open *any* menu. A simultaneous multiplayer game shouldn't automatically pause every time either player hits q or v: that would be annoying. So what happens—what does the code do—when a dwarf destroys the workshop you're viewing? Does the menu just close? Does the game crash? Do your clothes catch fire?
Effectively, what happens if you use dfhack to hack the game so it doesn't auto-pause whenever you hit q/v/i/k/view any menu/etc?
20
DF Dwarf Mode Discussion / Simultaneous multiplayer is feasible
« on: December 17, 2017, 02:23:24 am »
Now that Remote Fortress Reader exists, simultaneous multiplayer is finally possible to implement well. Specifically, you could design a client that queries a running fortress via RFR, displays the same menus/information DF displays, & submits changes back to the game with RFR.
The primary questions are how pausing works (Should it pause when either player opens a menu? Should pausing be decoupled from menus in multiplayer?), and, assuming time can pass in simultaneous multiplayer when one player's in a menu, whether the existing menu can code cope with background changes. (Does drafting a dwarf who died in the background merely have no effect? Will he be dynamically removed from the menu as he dies? Will the menu just close? Will the game crash? Will DF eat your laundry?)
A game that runs in the background while you're busy inspecting the status screen could lead to unique/unusual amounts of "fun," so I'm all for it.
Also as a side concern, one might want to pump the gamelog updates over RFR too, so remote clients can use SoundSense.
Edit:
I'm imagining a client-server model, where only one player runs the game logic. The others just connect with "viewers" that merely let them remotely view slices of the game state & manipulate it, as the real DF window does.
The primary questions are how pausing works (Should it pause when either player opens a menu? Should pausing be decoupled from menus in multiplayer?), and, assuming time can pass in simultaneous multiplayer when one player's in a menu, whether the existing menu can code cope with background changes. (Does drafting a dwarf who died in the background merely have no effect? Will he be dynamically removed from the menu as he dies? Will the menu just close? Will the game crash? Will DF eat your laundry?)
A game that runs in the background while you're busy inspecting the status screen could lead to unique/unusual amounts of "fun," so I'm all for it.
Also as a side concern, one might want to pump the gamelog updates over RFR too, so remote clients can use SoundSense.
Edit:
I'm imagining a client-server model, where only one player runs the game logic. The others just connect with "viewers" that merely let them remotely view slices of the game state & manipulate it, as the real DF window does.
21
DF Suggestions / Re: Mimic creature.
« on: November 14, 2017, 12:48:19 pm »
Sorry to bring this back from the dead, but mimicry seem like a great ability. You could have a forgotten beast arrive at your fortress during a migrant wave, disguised as a migrant. I suppose to prevent you from noticing it, it would even have fake thoughts & relationships.
22
Utilities and 3rd Party Applications / Re: SoundSense: a sound engine for dwarf fortress.
« on: May 15, 2017, 10:14:28 pm »
The `soundSense.sh` file needs to be converted to LF (Unix) line endings. A CRLF script will always fail to run on OSX/macOS, whereas an LF script will always work on Linux and macOS.
Also for those on OSX/macOS, if you have any other application that comes with java, like Minecraft or Mathematica, then you don't need to install java. Just create a symlink to that program's `java` executable in `/usr/local/bin`, or else change the sh file to directly invoke the application's `/Applications/Foo.app/Contents/Resources/runtime/java/whatever-foo-bar/bin/java` rather than just calling `java`.
Also for those on OSX/macOS, if you have any other application that comes with java, like Minecraft or Mathematica, then you don't need to install java. Just create a symlink to that program's `java` executable in `/usr/local/bin`, or else change the sh file to directly invoke the application's `/Applications/Foo.app/Contents/Resources/runtime/java/whatever-foo-bar/bin/java` rather than just calling `java`.
Pages: 1 [2]