Print

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

[gchristopher]

Rewriting from scratch misses that point that it's not really DF anymore. You'd be sorely lacking a whole bunch of features.

True, but Rimworld started right here on the DF forums as a "I want to make a DF clone, but as an actual game." That worked out quite well for him, judging by Steam sales figures.

If throwing money at Toady to do groundwork like refactor to decouple his simulators from the interface would actually help, I'd definitely support that! But sadly, like bringing in other programmers to help, that'd just stress him out instead of helping anyone.

[mikekchar]

It seems like in the case of a game like DF, *limited* multiplayer is more valuable that massive multiplayer.  As in, being able to  invite your friends around and do something fun together, split apart do what you want to do alone and then merge back together again seems like it would be awesome.  I remember Toady talking about partitioning different "realms" and being able to move back and forth between the realms.  That would be a killer feature, I think.

[Bumber]

Rewriting from scratch misses that point that it's not really DF anymore. You'd be sorely lacking a whole bunch of features.

True, but Rimworld started right here on the DF forums as a "I want to make a DF clone, but as an actual game." That worked out quite well for him, judging by Steam sales figures.

Yet it's not nearly as ambitious, from what I've seen of it. Sales are beside the point.

[mikekchar]

Yet it's not nearly as ambitious, from what I've seen of it. Sales are beside the point.

Rimworld is arguably a better game.  It's more approachable.  It has very few bugs if you don't use mods.  It's more consistent in its approach.  It's reached 1.0 ;-)  It really *is* pretty much what would happen if you tried to build DF, but were building it to appeal to a large audience.

In that way, I think the sales are indicative of the approach.  It clearly shows a need for more games in this genre -- not just sandbox games, but emergent story telling with procedurally generated content.  Is there even another comparable offering?

But I agree with you.  From a DF perspective, it's still not trying to achieve the same thing.  It's trying to make a game.  It's *not* trying to build a world simulator.  I think from a different view there is a big difference as well.  Toady's approach is kind of crazy, IMHO.  He's pulled on about a million threads and he has to sort it all out.  Normally programmers try to *contain* complexity.  He seems to go out of his way to make things *more* complex.  The craziest stories which we're all searching for wouldn't happen in Rimworld because the developers aren't going to build some ridiculous infrastructure that complicates stuff with no real benefit to *game* play.

And as much as we all complain about its deficiencies, I don't think you can build DF in a sensible fashion.  I might be wrong about that, but I don't think I am.  The weird and wonderful result is *because* of the chaos under the hood.  Toady has no need to fear competition, I think.  But in the same breath, I think we can't ask for something that can't be done -- you can't make a "normal" game out of DF.  It will be what it will be.

[gchristopher]

And as much as we all complain about its deficiencies, I don't think you can build DF in a sensible fashion.  I might be wrong about that, but I don't think I am.  The weird and wonderful result is *because* of the chaos under the hood.  Toady has no need to fear competition, I think.  But in the same breath, I think we can't ask for something that can't be done -- you can't make a "normal" game out of DF.  It will be what it will be.

(first, agree with all the other observations.)

Someone _could_ build DF in a much more sensible fashion. The limiting factor is Toady's stress level.

In the long run, Toady's life would be easier if the simulation engines were decoupled from rendering and UI. But who starts a one-person programming project and plans for code structure 20 years in the future? (almost nobody)

In a perfect world, Toady would have the money and stress tolerance to manage a few programmers working for him. Those people would do grunt work to free him up to spend more of his time on designing systems and tuning them to his liking.

That's how it is to be a senior/principle engineer or a computational research scientist. They still code, but more of their time is using different or higher level tools than what the programmers under them do.

By all accounts, that's not how Toady would want his life to work, even with unlimited money. But in the universe of unlimited scope procedurally-generated games (of which DF is the only one I know), there's at least the possibility for it to be successful as more than a one-person effort.

[Cathar]

In a perfect world, Toady would have the money and stress tolerance to manage a few programmers working for him. Those people would do grunt work to free him up to spend more of his time on designing systems and tuning them to his liking.

I am very, very very happy Toady manages to do his work alone, despite the whole world telling him not to. That's how we know we're dealing with someone for who passion is more important than money or expedience.
Toady is a true creator and in an ideal world, we would all be like that, and not the opposite.

That last Q&A when that journalist asked him how he communicate his vision to his team ; that put a smile on my face.

Edit : I mean that seriously, as a player I'd rather wait ten years and have an occasionally clonky, but grand scale and ultimately personal and artistic game than to have a team of programmers cobbling up a rimworld clone. No contest.

[Putnam]

There's plenty of dfhack scripts that designate things and no-pause interface screens are quite possible as well (as shown in putnam's mouse gui prototype).

For the record, the mouse GUI prototype either planned to or currently lets the game's own menus take over for a lot of things and those definitely pause the game without any way to unpause it.

[Bumber]

My vision for MP DF is a single copy of a fort on a server with 3rd party client interfaces sending commands to the server. The server processes these commands every n ticks in a transactional manner. It keeps track of who is allowed to do what and where, and sends the clients only what they need to know. This is close to what warmist made for his MP arena, but for fort mode.

You can have the illusion of separate forts by merely not letting the client scroll past an area, using burrows, and only listing units and items in the player's area. You can make the forts seem far apart by giving them different biomes and sending any traveling units on a temporary mission. (Or just keep them busy in the buffer zone.)

The downside here is the performance issues that come with running any large fort. The more players, the smaller their forts have to be. The upside is that you don't have to sync any data, because there's only one true fort.

[Bumber]

I just got an idea for multiplayer adventure mode. One big obstacle is that only a small area of the game is loaded at a time. However, I'm pretty sure that visited camps and sites are all loaded in their entirety. Rumrusher recently discovered that you can move adventurer camps around, and it will integrate copies of smaller sites it visits.

That particular method might not pan out for stable gameplay, but it made me consider the possibility that we could load areas of the world into a large retired fortress and have players doing their own separate things in a patchwork map. This would require that the upcoming improved party system bring with it better control over party members, and that they won't revert to following the main character once they get out of view.

This idea also banks on the assumption that we can gather information about the tiles of the fort that aren't inside the main character's view.
I'm also not sure how the loaded NPCs would react to not being in their proper site. We might have to fool them somehow.

[Putnam]

I could see that exploding spectacularly.

[Nopenope]

While I agree with remarks about the difficulty of implementing world scale multiplayer, I don't understand people saying anyone would be foolish to even attempt this. It's one thing to deem a task difficult, it's another to actively discourage people from attempting it. Would you react the same way if, say, two brothers set out to make a world simulator with ascii graphics and a schedule stretching over 20 years, in 2019?

Also, there are different kinds of multiplayer. Two people managing different forts on the same world would be difficult, but the following are feasible or already done (check Warmist's thread on multiplayer)

-"Hotseat", i e. multiple players take control of the same game instance in a cooperative setting. Already done, check dfterm2, dfterm3, webfortress (although they haven't been updated in a while)

-Two people managing two different fortresses on the same embark site, possibly being hostile to one another. It requires the game to render two different views of the screen at the same time and some work has been done on that.

-Different people managing the same fortress, but with different screens for each person (so, let's say, one takes care of labors, another one may manage the military, and so on). Same as above

-A player runs an instance in fortress mode, and other players control a single unit arena style. Pretty cool in my opinion, and already doable.

-Mutiple players controlling multiple adventurers. Requires a fair amount of bodyswapping for each action and each player, but doable. When the new release comes out with a proper implementation of multiple adventurers it'll be presumably easier.

-Otherwise, I guess a turn-based fortress mode would work. Two players take turns retiring, playing and unretiring their fortress, build and send squads at each other. It'd need to catch the "wait two weeks" process and prevent it, and I'm not sure whether offsite squads are properly tracked and what happens if a player-sent army arrives at a newly unretired player-controlled fortress, but if everything is accounted for by the game it could be neat.

I'm sure I'm missing lots of possibilities there. Don't dismiss the idea out of hand.

[Bumber]

-A player runs an instance in fortress mode, and other players control a single unit arena style. Pretty cool in my opinion, and already doable.

That is pretty cool!

You could do all sorts of role-playing.

[Cathar]

All of my yes. If it is doable by all mean please explain how

[Bumber]

All of my yes. If it is doable by all mean please explain how

Warmist's multiplayer arena demonstrates we can override a unit's target destination, as well as provide each player a separate view screen centered on a unit. The "forceequip" command allows dwarves to pickup and wear items. Assigning a job to a given dwarf should be fairly straightforward with a script.

Not sure if we can overwrite combat AI, but we could force a retreat like when hunters run out of ammo.

Anything else I'm missing?

[Putnam]

You can overwrite combat AI by making every unit which is currently player-controlled have its attacks be deleted if they weren't player-initiated.