Print

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

[Neonivek]

I can answer some of these

1) Because there are tons of arguements made by toady across many topics and it would make a massive list that frankly... no one would read anyhow. As well we don't really need more stickies, this topic comes up once every few months. Why gum up the thread?

2) Not a question

3) Toady has no problems with Copycats. By the way MANY people trying to make a Dwarf Fortress Copycat has sprung up over the years and NONE of them are still here today.

4) Toady doesn't have the art skill and because of the sheer scope of the project he doesn't want to be at the mercy of some fickle artist after every new release anyhow. He supports graphics support but he won't be using any art himself.

[Kogut]

the game should not go open sorce. it kills games. infiniminer is an example.

WTF?

@OP tl;dr

[Kogut]

-ops-

[ArPharazon]

1) Because there are tons of arguements made by toady across many topics and it would make a massive list that frankly... no one would read anyhow.
[/spoiler]
I'd read it.

[Eavan]

The best example seems to be the implementation of multithreading in DF. I ran across tons of threads where this was derided as not realistic, necessary, and too hard. That’s jaw-droppingly wrong. Processor cores are not going to get much faster – and by the way, clock speed alone is not a good indication of actual speed at all, as I have seen some say when recommending that players buy processors with fewer but faster cores.  One of 2.8ghz cores in my Core i7 is much, much faster than , for example, a 3.8gbz Pentium 4. But as this is not the place for an in-depth explanation of processor architecture, I’ll just say that single core speed is going to stay basically static while the number of cores is going to increase. But more importantly, multithreading produces fantastic performance improvements even in single core processors. That’s why essentially every single application on your computer is multithreaded – except, of course, Dwarf Fortress – and has been before dual core processors were a gleam in anyone’s eye.  Most important, perhaps, is not so much the raw performance increase but the perceived increase in responsiveness that the user gets when, for example, the UI is offloaded onto another thread. There is nothing difficult about multithreading: everyone does it. And while nobody serious is really going to say that n threads gives you an n increase in performance, it is quite drastic, especially in applications such as DF which can be highly parallelized (and yes, it can – might even be interesting to see how much can be offloaded to the GPU.)

What I find most interesting about your argument on multithreading is that you claim that all the uninformed people are saying it wouldn't help, while in reality it is your misunderstanding of multithreading that is the issue. Parallel programming isn't magical, especially in a project that has been worked on for years already. The existing codebase would have to be almost completely redone--multithreading isn't some switch, it's a design strategy. In nearly every case, you have to be thinking of concurrent programming before you write your first 10000 lines of code, or you'll have to start over anyways.

Now, other than the simple difficulties of multithreading (which are only exacerbated by working in C++), what exactly would you propose to be multithreaded? What could be pushed to the GPU? Almost nothing can be made parallel in DF, despite your wild and unfounded claims, and those things that could be made parallel would only provide a ~20% benefit due to massive overhead for synchronizing the hundreds of things that are constantly happening in game.

Also, "essentially every application on your computer is multithreaded"? That's insane. Windows Explorer doesn't even use multiple processes unless you flick a switch in the options! Firefox runs in a single thread. The exact opposite of your statement is true: multithreaded applications are unusual gems, so much so that Chrome's being parallel is seen as a major feature. Please, actually look at facts before letting loose this naive nonsense.

[thisisjimmy]

What I find most interesting about your argument on multithreading is that you claim that all the uninformed people are saying it wouldn't help, while in reality it is your misunderstanding of multithreading that is the issue. Parallel programming isn't magical, especially in a project that has been worked on for years already. The existing codebase would have to be almost completely redone--multithreading isn't some switch, it's a design strategy. In nearly every case, you have to be thinking of concurrent programming before you write your first 10000 lines of code, or you'll have to start over anyways.

Now, other than the simple difficulties of multithreading (which are only exacerbated by working in C++), what exactly would you propose to be multithreaded? What could be pushed to the GPU? Almost nothing can be made parallel in DF, despite your wild and unfounded claims, and those things that could be made parallel would only provide a ~20% benefit due to massive overhead for synchronizing the hundreds of things that are constantly happening in game.

Also, "essentially every application on your computer is multithreaded"? That's insane. Windows Explorer doesn't even use multiple processes unless you flick a switch in the options! Firefox runs in a single thread. The exact opposite of your statement is true: multithreaded applications are unusual gems, so much so that Chrome's being parallel is seen as a major feature. Please, actually look at facts before letting loose this naive nonsense.

No, Zarat is right.  He knows what he's talking about. 

You are mixing up threads and processes. They are quite different. Firefox is multithreaded.  Chrome, on the other hand, creates a new process for each tab.  The main advantage of this is stability and responsiveness, not performance.  If one tab crashes in chrome, it won't affect the others.

Multitheading isn't the easiest thing in programming - especially when you aren't experienced with it - but it is used all the time. 

Almost nothing can be made parallel in DF, despite your wild and unfounded claims

Ironically, this is a wild and unfounded claim.  How, exactly, did you come to this conclusion?  Have you seen the source code?

Just given what we know about the algorithms used in DF, I can think of plenty of things that can be parallelized.  Pathfinding is an obvious example.  Each dorf could run A* in a separate thread.  Since each dorf paths independently of the others, this is an embarassingly parallel problem (http://en.wikipedia.org/wiki/Embarrassingly_parallel).  It could potentially provide near linear speed-up for pathfinding.  It's not hard to do.  I've done it myself.

[SRD]

Goddamnit man, another one of these threads?

tl;dr the whole thread.

[Eavan]

Ironically, this is a wild and unfounded claim.  How, exactly, did you come to this conclusion?  Have you seen the source code?

Just given what we know about the algorithms used in DF, I can think of plenty of things that can be parallelized.  Pathfinding is an obvious example.  Each dorf could run A* in a separate thread.  Since each dorf paths independently of the others, this is an embarassingly parallel problem (http://en.wikipedia.org/wiki/Embarrassingly_parallel).  It could potentially provide near linear speed-up for pathfinding.  It's not hard to do.  I've done it myself.

I may not have seen the source code, but I have asked ToadyOne. He agreed that pathfinding is the only one that one might initially *think* is obvious. But what about dwarves pathfinding around other dwarves? What if something changes while the dwarf is pathfinding?

[Starver]

But what about dwarves pathfinding around other dwarves? What if something changes while the dwarf is pathfinding?

To be fair, this is a problem with the current "I'm going somewhere, get me a path and then I'll follow it until I can't, at which point I work out if I'm still able to get there by trying to get another path" pathing system.  Otherwise known as the IGSGMAPATIFIUICAWPIWOIISATGTBTTGAPPS.  (Snappy, eh? )

Which is not to say that replacement pathing systems that overcome the given inherent issues in the current method would be necessarily more likely to be viably made parallel to the environmental simulations.


I think you could spin off other things as parallel processes, but I agree with the version of opinion that states that whatever does get split off would need a major re-write to do so (as would the bits of 'traditional' data-maintaining code that work on the direct informatic interfaces between any parallel process and its stick-in-the-mud parent...).  Big job.

I'd, personally, be looking at making the existing code "Parallel-ready" as I revamped it for other reasons, ideally.  But unless the intended parallelisation methods are already pretty well thought out, there'd still need to be some substantial revisiting and correcting of emergent bugs as and when any transition is made.

(And while there is a difference between threads and processes, there's... no never mind, I can't express the terminology quite how I want to, to avoid confusion.)

[thisisjimmy]

I may not have seen the source code, but I have asked ToadyOne. He agreed that pathfinding is the only one that one might initially *think* is obvious. But what about dwarves pathfinding around other dwarves? What if something changes while the dwarf is pathfinding?

Not a problem.  DF could keep the strategy it's already using.  When a dorf initially chooses its path, it doesn't take into account that the map might change or that other dorfs may get in the way.  It simply chooses a path from the map's current state. If later it's walking and there's something in the way, it can adjust its path (if there's a dorf in the way), or run the pathfinding algorithm again (if the map has changed).

Fluid dynamics and temperature calculations could also be sped up, but admittedly, it's not as easy as pathing.  You would have to take the area that needs updating, and partition it into subregions.  You could then process each subregion in a separate thread, and then do a final pass to patch up the seams.  If you can partition the data so that there are no seams (for example, separate bodies of water get different threads), the problem becomes embarrassingly parallel.

Those are the main things I know of that slows DF down.  Obviously, you only want to parallelize the slow stuff.  If you know of any other intensive tasks, perhaps they can be parallelized as well.

[Zaphod728]

So i have been part of several different game development forums. This sort of thing always pops up, but i must say that overall the people here seem a little more grounded, and less flamey than i have seen in other forums. So lets stoke the fires (JK).

The entire idea of having DF "release" worthy seems odd to me. Why the heck does a game need to be "released" anyway? Money? i think toady has made his views on money pretty clear. DF could be released in its current form imo. I have played buggier games. I personally like the idea of DF never being finished, because it will never be perfect. I really wish more games would take the model of making a game that is constantly developed till it gets things right. Take MMS. How many CoDs, and other such games need to be released. I know that CoD has become a whipping boy, but its just too easy. Pretty much all modern big title games are about making as much money as possible (big shock ). Its their jobs to make a ton of money. Just dont expect amazing innovations, TB had a great mailbox on this. This is the point: dont expect the same business model from DF. Put simply, someone has chosen to make money doing exactly what he wants to do. Can he make more? yes, but having total control is "exactly what he wants to do." Its not just the game, its his game. If toady could snap his fingers and have DF 100% complete, and release it for lots of money, with blackjack and hookers; I dont think he would. Its making the game itself that is the important part. I know the satisfaction of crafting something that is entirely yours. Maybe I am totally off base, but that's my impression.

I get frustrated with development in pretty much every game I play. For example, play some of the minecraft mods, and see how fast the modders develop, then look at vanilla. Yes, modding is not exactly the same, but that doesnt change the fact that the modders work faster. Its the small things that can be the most annoying. I cant play minecraft without treecapitator. There are many other examples of small mods that would make the game better, if not standard, why not as options. These kinds of things are true for all games that are modded. Oblivion anyone? There are mods for that game that fix literally hundreds upon hundreds of bugs. I dont play DF without Dwarf therapist. I would like to see some sort of noble in the game that would take care of that stuff, (just 1 example).

The core question is still there. Can development go faster and better? Unquestionably yes, there exists that possibility. If you want the final project sooner, more people makes that happen. With the perfect mix of people anything can happen. The more important question is; should it happen? Depends on what you want i guess.

Toady wants full control, its his project, I dont have a problem with that at all. Its very common for people to become extremely attached to the person making the game (minecraft). Another example is the sorted re-development of Shadowbane (MMO). This eventually lead to the "main" person quitting, and the actual developers, (true to the project) getting to closed alpha on their own. It got bad enough that the head person in charge threatened to release the source code to skrew over the entire project. Regardless, there are pros and cons to a totalitarian (no offense meant) approach to development. Yes it could be quicker with more people, but it takes a huge deal of trust. For me, the end of the story is its his project so its up to him.

Doesnt mean that these discussions are wrong or even bad. I am not always right, no one is (not even toady ). As long as people keep that in mind, and act rationally then things usually go good.

PS I love this game, if thats not clear. I would also recommend people support the development financially if they also love the game. I payed $100+ to play f@#$ing rift for 6 months. It was fun, but i have gotten more actually enjoyment out of DF. It would be kinda irrational for me not to support this game. I have seen other great projects disappear. [/soapbox]

[MaskedMiner]

Honestly, Dwarf Fortress seems to be Toady's dream project. Kind of art project you want to do yourself because otherwise it is not yours anymore. It doesn't matter whether it is impossibly hard and time consuming to finish it, if he has enough willpower, he will do it because otherwise he might as well give up. If I would create framework of puppet and someone else finish it, it wouldn't be mine alone anymore. So yeah, I can understand Toady, though my own personal ideals make loneliness abhorrent and I would prefer to have awesome team of people to do games with. But when I do other forms of art(yeah, I consider games work of art, bite me ), I hate it when teacher starts painting on my painting to show how to "improve it" so I can understand it.

You have to remember that Dwarf Fortress isn't  really usual kind of game. If it would be, there wouldn't be need to plan so much detail, you could have less and people would still consider it great. Its life project that you don't have any other reason to do than that it would be awesome and you want to do it.

So yeah, while I personally would prefer to have team of people to do games with(mainly because I can never see myself having all skills needed), I find it admirable what Toady does and it would be preferable for you to not tell what he should do in your opinion.

You also have to remember that nature of Dwarf Fortress' development is different too. Toady isn't creating the game for donators, donators are just helping him achieve his dream and enjoy the work at same time. While Toady can't develop the game without donators because he needs money to live, he isn't creating it for them, hes creating it for himself. I would make allegory with some sort of other art type, but I can't remember one that would be suitable. Anyway, point is, he can do with his project whatever he wants to whether it really is "Good idea" or not.

[Neonivek]

Don't forget MaskedMiner that many people have come and tried to make Dwarf Fortress better, faster, or with focuses on different areas.

They have yet to finish. (mind you there are some that use DF as inspiration and borrow concepts but are otherwise their own game)

So there is something about ToadyOne that makes this game possible.

[MaskedMiner]

Exactly. Toady is pretty much only stubborn(note: I'm not sure if word has negative meaning, but I mean it in positive sense) enough to make his life goal to be extremely complicated game. Thats what I meant with will power and that you don't "need" that much detail: Normal people would just release the game when it seems "good enough" and give up on the extra details they wanted to put in them. Most people don't want to develop 20 years game.

[Starver]

Exactly. Toady is pretty much only stubborn(note: I'm not sure if word has negative meaning, but I mean it in positive sense) enough...

"...is tenacious enough..."?

Stubborn does read as negative ("I told him to not do it, but he stubbornly continued, and look how it all went wrong for him!") as opposed to any reference to tenacity ("I told him not to do it, but he tenaciously continued, and look how it all went right for him!").

Other synonyms exist, but... well, F.Y.I.