> If they open source it they can still control things and follow their vision for their own main branch. But they can accept patches that have improvements for things that (i) are needed and (ii) do not necessarily go against their vision.
Open-sourcing it dilutes their brand. It increases the likelihood that they can't fund it anymore because other people start blathering about their forks and distract from the game's actual mindshare.
> However, an expert in parallel programming should be able to improve this a great deal. AFAIK, DF currently runs as a single thread, and many of its processes can be split off
DF's simulation model is deterministic. Most aspects of it depend on prior aspects. It is a great case of Amdahl's law. Ripping that out and changing it would change the core of his game. I can't really see him wanting that if he doesn't understand it and, like Baughn's work on the graphics subsystem, I can't see him spending a lot of time to understand it. (Toady isn't a computer scientist and he isn't really a hacker as is commonly understood here. He learns what he needs to make his game and it pretty much ends there. This may sound critical but I mean it as a compliment.)
> But if he opensourced it perhaps someone else would fix the interface for him.
His supporters are content with the interface. It isn't preventing them from enjoying the game and it's not hindering their ability to fund continued development. You are suggesting that he potentially damage his revenue stream to fix problems that aren't really problems right now.
I haven't sent him any money yet, so I'm not sure if I count as a supporter - but I am damned not content with the interface. If it weren't for Dwarf Therapist, the game would be nigh unplayable.
I've never used Dwarf Therapist (and I realize I'm in a minority there), but I also have given him money because the interface does not bother me. Enough people are doing likewise that I don't think the interface should be a priority until the game's there.
DF's simulation model is deterministic. Most aspects of it depend on prior aspects.
I don't see what that has to do with using parallel programming to improve the performance of DF's simulation. If you are implying that threading implies nondeterministic behaviour in a simulation, you are mistaken. In fact, a system with such a discrete space model as DF would be quite easy to parallelize in a safe and deterministic way, with the proper expertise and forethought.
Sorry, you're right. Nomdetermimistic isn't the right word. "Heavily shared" might be better: it isn't perfect cellular automata, a lot of the game word cheats in a way that would necessitate really weird locking or sweeping changes of the game world. Couple that disruption with Toady not really understanding that sort of architecture and I can't see him ever being okay with other people doing it. He'll learn to do it when he absolutely has to.
The lack of perfect cellular automata isn't an obstacle either. One of the simplest and most robust way of doing parallellization of a system like DF avoids all such issues in a very simple way with no almost no synchronization needed.
Basically, when starting the game, spawn X threads and partition the world between them so that only one thread can write to any particular world block. Then, when calculating a new frame, make a read-only copy of the previous world frame. Any reads are done from that copy; any writes obviously occur only in the blocks assigned to a particular thread. Wait for all threads to complete, then render thread. No messaging, locking, event handling or whatever needed. Just care and forethought.
But you are right that Toady likely not possessing that kind of knowledge. That's the very reason why people would like to see others involved for things like optimization and UI design and the main point these people are trying to make; Toady seems either not able or willing to do it himself, and it could improve the state of the game tremendously.
Comments
> If they open source it they can still control things and follow their vision for their own main branch. But they can accept patches that have improvements for things that (i) are needed and (ii) do not necessarily go against their vision.
Open-sourcing it dilutes their brand. It increases the likelihood that they can't fund it anymore because other people start blathering about their forks and distract from the game's actual mindshare.
> However, an expert in parallel programming should be able to improve this a great deal. AFAIK, DF currently runs as a single thread, and many of its processes can be split off
DF's simulation model is deterministic. Most aspects of it depend on prior aspects. It is a great case of Amdahl's law. Ripping that out and changing it would change the core of his game. I can't really see him wanting that if he doesn't understand it and, like Baughn's work on the graphics subsystem, I can't see him spending a lot of time to understand it. (Toady isn't a computer scientist and he isn't really a hacker as is commonly understood here. He learns what he needs to make his game and it pretty much ends there. This may sound critical but I mean it as a compliment.)
> But if he opensourced it perhaps someone else would fix the interface for him.
His supporters are content with the interface. It isn't preventing them from enjoying the game and it's not hindering their ability to fund continued development. You are suggesting that he potentially damage his revenue stream to fix problems that aren't really problems right now.
I haven't sent him any money yet, so I'm not sure if I count as a supporter - but I am damned not content with the interface. If it weren't for Dwarf Therapist, the game would be nigh unplayable.
I've never used Dwarf Therapist (and I realize I'm in a minority there), but I also have given him money because the interface does not bother me. Enough people are doing likewise that I don't think the interface should be a priority until the game's there.
I don't see what that has to do with using parallel programming to improve the performance of DF's simulation. If you are implying that threading implies nondeterministic behaviour in a simulation, you are mistaken. In fact, a system with such a discrete space model as DF would be quite easy to parallelize in a safe and deterministic way, with the proper expertise and forethought.
Sorry, you're right. Nomdetermimistic isn't the right word. "Heavily shared" might be better: it isn't perfect cellular automata, a lot of the game word cheats in a way that would necessitate really weird locking or sweeping changes of the game world. Couple that disruption with Toady not really understanding that sort of architecture and I can't see him ever being okay with other people doing it. He'll learn to do it when he absolutely has to.
The lack of perfect cellular automata isn't an obstacle either. One of the simplest and most robust way of doing parallellization of a system like DF avoids all such issues in a very simple way with no almost no synchronization needed.
Basically, when starting the game, spawn X threads and partition the world between them so that only one thread can write to any particular world block. Then, when calculating a new frame, make a read-only copy of the previous world frame. Any reads are done from that copy; any writes obviously occur only in the blocks assigned to a particular thread. Wait for all threads to complete, then render thread. No messaging, locking, event handling or whatever needed. Just care and forethought.
But you are right that Toady likely not possessing that kind of knowledge. That's the very reason why people would like to see others involved for things like optimization and UI design and the main point these people are trying to make; Toady seems either not able or willing to do it himself, and it could improve the state of the game tremendously.