Print

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

[PatrikLundell]

Brooke's Law: Adding people to a late project makes it later.

The reasoning is pretty much what Patrik mentioned about negative productivity, though I wouldn't call DF "late" as much as I'd call some of DF's fans impatient.

If what the new person brings to the table has a sufficient value (such as useful knowledge/skills unavailable otherwise, or a long term commitment that results in a significant net gain) taking on a new person can be worth it. Given the time scale of the DF project more people should speed things up in the long run, but that hinges on both the ability to afford it (and I don't think donations are there yet), and even more on Toady's ability to stand becoming a part time administrator/manager without succumbing to loss of enthusiasm. I'd certainly not trade a couple of years of 1.5 times the current development rate for a premature termination of the project.

[Random_Dragon]

Hahahahah. As a former contributor to Catacluysm: Dark Days Ahead, I can tell you that new additions can create a coding clusterfuck. You always need to be extremely wary of what gameplay vision any new coder has, how they style their code, how consistent they are about adhering to a given style, etc.

That said, these two games are extremes in that regard. Dwarf Fortress has Toady and that's about it. He has a simple, sane, complete approach to the game as a whole, but he tends to leave the game riddled with minor mistakes and trivial fixes because no one person can handle EVERYTHING.

Conversely, a big open-source game on Github can have people quickly identify and quash bugs, but they also have a thousand different people fucking the code up in their own unique ways, all with different ideas of what the game should be, and what parts of the game interest them.

[Calidovi]

I didn't explain myself well enough before
As many of you have said, fantasy adds a lot of things, and all the things that happen in a non-magic world also should happen in a magical world(mundane things like wars, misery, hunger, etc.)
The problem is, that's not the hostility slider, that's the fantasy slider
In a fantastical world there are dragons, horrible creatures and sacrifice magic cults, but there are also fairies, healing potions, and a generally more advanced culture, in terms of technology (see 'The Witcher')
Magic wisemen means culture, knowledge and common sense, something that affects the world positively, resulting in less wars, better controled countries, etc.
That's very general and all, but it makes a point.
What I mean is that in a well designed system like the sliders, everything kinda equilibrates , and it's not about difficulty, but flavour, which you can decide how much you want, and that's totally cool

Yeah, now I get that. I guess I was thinking about present DF, which is pretty fantastical but also horrific as well. I didn't think of any 'good' balances being added.

[LordBaal]

Thing is, bringing anyone for anything code related at this time would need several months at least of getting used to the code to even begin to have informed guesses on how to implement a new feature. They only way somebody can bring in something worth is if it's either a coding god or is willing to study the code for months for free and then work much overtime for not a great pay and that if Toady is even willing to share the code with anyone at a official, professional level.

What I think is most likely it's going to happen is that once Toady "finish" the code and is willing to share it or make the game open source then a swarm of enthusiasts will go through the code and possibly several forks of the game will appear. Perhaps then and only then multithreading will be a thing for the game. Or perhaps somethimg better is available then. Who knows if quantum computers will be practical by then... well just my weird thoughts.

[Shonai_Dweller]

Thing is, bringing anyone for anything code related at this time would need several months at least of getting used to the code to even begin to have informed guesses on how to implement a new feature. They only way somebody can bring in something worth is if it's either a coding god or is willing to study the code for months for free and then work much overtime for not a great pay and that if Toady is even willing to share the code with anyone at a official, professional level.

What I think is most likely it's going to happen is that once Toady "finish" the code and is willing to share it or make the game open source then a swarm of enthusiasts will go through the code and possibly several forks of the game will appear. Perhaps then and only then multithreading will be a thing for the game. Or perhaps somethimg better is available then. Who knows if quantum computers will be practical by then... well just my weird thoughts.

It's been said many times that "multithreading the game" is the equivalent of "making the game from scratch" (multithreading bits here and there may or may not help, I don't know). So you wouldn't need Toady to release the code to anyone, you just need someone to sit down and make a game like Dwarf Fortress but multithreaded.

Nobody will, because nobody has the time. The closest you'll get is a multithreaded fortress simulator or a roguelike with a complex world neither of which are the total all-encompassing mess that DF strives to be. And, oh, people are already doing that so there's no need to change anything at all.

--edit
Don't you think a "coding God" with an interest in working for little/no pay on a fantasy simulator is more likely to, I dunno, write a fantasy simulator, than squat in Toady's flat trying to decipher his code? I wouldn't hire someone who apparently has no idea what to do with his talent. Seems like someone just as likely to walk off with the source code at the end of the week.

[PatrikLundell]

Quantum computers (should they become reality) are a bit like graphics co-processors in that they're very good at a fairly narrow range of rather important problems (as well as trashing the banking system by rendering the current encryption scheme worthless), but not that good for general computing. Complete and accurate path finding would be a possible use for a quantum computing co-processor in a DF perspective, for instance. However, that hinges on whether DF can rely on one always being present or not.

[Calidovi]

Quantum computers (should they become reality) are a bit like graphics co-processors in that they're very good at a fairly narrow range of rather important problems (as well as trashing the banking system by rendering the current encryption scheme worthless), but not that good for general computing. Complete and accurate path finding would be a possible use for a quantum computing co-processor in a DF perspective, for instance. However, that hinges on whether DF can rely on one always being present or not.

atomic dwarf 2045

[wierd]

Thing is, bringing anyone for anything code related at this time would need several months at least of getting used to the code to even begin to have informed guesses on how to implement a new feature. They only way somebody can bring in something worth is if it's either a coding god or is willing to study the code for months for free and then work much overtime for not a great pay and that if Toady is even willing to share the code with anyone at a official, professional level.

What I think is most likely it's going to happen is that once Toady "finish" the code and is willing to share it or make the game open source then a swarm of enthusiasts will go through the code and possibly several forks of the game will appear. Perhaps then and only then multithreading will be a thing for the game. Or perhaps somethimg better is available then. Who knows if quantum computers will be practical by then... well just my weird thoughts.

The flipside to this is that the DFHack community has been effectively reverse-engineering DF for some time, in order to tack on new features WITHOUT access to the source codebase. 

The main thing is that Toady has openly stated that he will never release the sourcecode, and accepts the existence of fanmade contributions as high flattery. He has even adopted some of the binary patches as fixes after fully examining them.

In this respect, community fixes do find their way into the official build, while still respecting Toady's wishes.

DFHack's team is more open to community collaboration (and is always looking for volunteers), but the work is harder, because you need to understand compiled binaries to create binary patches.

[LordBaal]

Thing is, bringing anyone for anything code related at this time would need several months at least of getting used to the code to even begin to have informed guesses on how to implement a new feature. They only way somebody can bring in something worth is if it's either a coding god or is willing to study the code for months for free and then work much overtime for not a great pay and that if Toady is even willing to share the code with anyone at a official, professional level.

What I think is most likely it's going to happen is that once Toady "finish" the code and is willing to share it or make the game open source then a swarm of enthusiasts will go through the code and possibly several forks of the game will appear. Perhaps then and only then multithreading will be a thing for the game. Or perhaps somethimg better is available then. Who knows if quantum computers will be practical by then... well just my weird thoughts.

It's been said many times that "multithreading the game" is the equivalent of "making the game from scratch" (multithreading bits here and there may or may not help, I don't know). So you wouldn't need Toady to release the code to anyone, you just need someone to sit down and make a game like Dwarf Fortress but multithreaded.

Nobody will, because nobody has the time. The closest you'll get is a multithreaded fortress simulator or a roguelike with a complex world neither of which are the total all-encompassing mess that DF strives to be. And, oh, people are already doing that so there's no need to change anything at all.

--edit
Don't you think a "coding God" with an interest in working for little/no pay on a fantasy simulator is more likely to, I dunno, write a fantasy simulator, than squat in Toady's flat trying to decipher his code? I wouldn't hire someone who apparently has no idea what to do with his talent. Seems like someone just as likely to walk off with the source code at the end of the week.

My points were about precisely the difficulties of Toady hiring someone. I guess is harder to convey a tone over text.
Edit: Last time I checked he was unsure if he would release the code at some point. I could be misrecalling though.

[wierd]

If you think about what a program does, and how a computer works, with concerted effort a really dedicated programmer could implement multithreadding as a whole series of binary patches to trap and redirect execution.

it would just be really hard, and nobody would want to do it.

[kontako]

Unsure if this has been touched on before, but:

What's your stance on immortality / respawning ingame? -- Not as a natural ability coming straight out of the womb of course, but a power gained through a relic or a spell allowing the player character or other non-player characters to return continuously or a limited amount of times. I recall a story in which a nightcreature regrows from severed limbs which escape a pyre, but beyond this perhaps respawning trapped in another plane to be freed out of ritual

[Max™]

I know for a fact that the "dying > going to an afterlife > trying to make your way back" is at least a general sort of thing the game is heading towards, it's partially covered in the Cado story.

Myself I'm still hoping that it will be simple enough and agreeable to add an -o or --output-offsets=[range|list|/link/to/target/filename.format] type option.

[PatrikLundell]

If you think about what a program does, and how a computer works, with concerted effort a really dedicated programmer could implement multithreadding as a whole series of binary patches to trap and redirect execution.

it would just be really hard, and nobody would want to do it.

I disagree with the assessment (unless "a series of binary patches" essentially means replacement of everything). To implement multi threading you need to protect data stores so access is blocked while the data items are modified, and you need to ensure modifications are performed in the correct order even when done by different threads, based on the correct version of the data (not old data available when the thread was started, later superseded by another thread), etc. This means you need administration to set the threads off to work with defined sets of data (as opposed the semi random state of a common store at various access times), as well as collection and integration of the results from the various threads into a new common state, and you may need to use several "pulses" within a tick. Micro threading, however, is a different thing that might be achieved by a good compiler or possibly through binary patches.

[LordBaal]

It is a sad state of affairs. Dwarf Fortress might very well be moored to increasingly obsolete technologies. Updating it is not impossible but improbably difficult and virtually undoable by Toady alone.
Df could in theory be re-done from the ground up by a team or a company but the sorry ass shape of the game industry today also means that's even more unlikely because DF is in no way a quick-cash, milkable, "dlc'able and microtransactionable to death", mercurial game that currently most people seek (only to get bored five minutes and/or 100 bucks latter).

Unless..

[wierd]

If you think about what a program does, and how a computer works, with concerted effort a really dedicated programmer could implement multithreadding as a whole series of binary patches to trap and redirect execution.

it would just be really hard, and nobody would want to do it.

I disagree with the assessment (unless "a series of binary patches" essentially means replacement of everything). To implement multi threading you need to protect data stores so access is blocked while the data items are modified, and you need to ensure modifications are performed in the correct order even when done by different threads, based on the correct version of the data (not old data available when the thread was started, later superseded by another thread), etc. This means you need administration to set the threads off to work with defined sets of data (as opposed the semi random state of a common store at various access times), as well as collection and integration of the results from the various threads into a new common state, and you may need to use several "pulses" within a tick. Micro threading, however, is a different thing that might be achieved by a good compiler or possibly through binary patches.

A compiled binary is a long string of instructions, a bit like a chain of pearls.  Instructions are executed, and position on the chain is tracked using the stack pointer. This pointer gets updated on conditional jumps, which move the execution to different locations on that chain, depending on what it just did.

The hypothetical binary patch set I mention, would insert a new routine that traps execution, and spawns new execution threads, sending them to the appropriate parts of the binary stack.  At the end of each thread instruction, is a call to return to this new landing pad area, where the worker thread instance then determines it is not the master thread, and waits for a new assignment.   The exact same code that toady uses for say-- finding a path from point A to point B would be called, it would just be executed a bunch of times in parallel, the results sanitized by the main parent thread, and then after paths are calculated, the next logical process would happen.

EG, look at what the process flow is for the activities of each creature is, then parallelize those processes. Trap execution before moving to the next execution step, check sanity (and re-run as needed to retain concurrency), then continue execution to the next batch of evaluations.

Not a complete re-write, but it would be a mammoth undertaking. Like I said, nobody would want to do it.

You are of course, correct about needing to protect all the data to keep the threads from walking on each other. That is one of the major functions of the main thread, after it gets trapped in our little patched in routine. It becomes the watchdog, and handles the necessary spinlocks to prevent write accesses, tracks threads that have failed due to race conditions, and aborts/restarts them as needed.