Print

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

[MDFification]

Anyway, to my experiences in events like tis, the project at large is more likely to die. You cannot expect a coding community to start from zero to full should the event arise, such a thing needs years of caring to build up. Small fixes, chaotic add-ons, yes. But no more a dedicated project.

I respectfully disagree. (cut)

History of open-source games shows otherwise. Project like DF needs extremely dedicated person like Toady. No Toady, no project. At most, few years of small development, bugfixes, trying to make some things, sad agony when amount of interested people dries up and later death.

As others said, it makes sense to start new project. There is only one teensy weensy little detail left: find some new Toady-like extremely dedicated programmer. Good luck with that.

Freespace Open has been going for about a decade I think and has some pretty massive download rates.

Freespace's Engine was finished when it went open-source. If it was released in an unfinished state, with bits of code for features that nobody knew being left around and cluttering up the place, and hadn't gone through extensive bugfixing/optimization before hand, it would have been a lot more difficult for someone to pick it up and start making additions. Not that it would be impossible, but you would need people studying the code extensively.

Fortunately avoiding all of this is rather trivial modding - just open toadyone.txt and add [NO_AGE], [NO_EMOTIONS], [NODRINK] and [NOEAT]. Memorialize everyone on the map to avoid ghosts then atom-smash them. Turn off caravans, immigrants and invaders, and seal the fortress off from wildlife. Toady can now continue working until you experience save corruption.

[Sizik]

It's like taking Moby Dick or Hamlet, and adding LEGO dioramas. Blech.

Lego dioramas are pretty original, IMO.

It works for the Bible.

[tahujdt]

I think I remember seeing that somewhere.

[Loud Whispers]

so no murdering for the source code!

Presumably if you were willing to murder him for it, you'd also be willing to simply break into his house or whatever and steal it WITHOUT murdering anybody. 
Plus, even if you are a weird psychopath who sees the code as more valuable than a human life, you'd still have to realize that keeping him alive = more / better code in the future that you could steal again, etc. etc.

Unless they were one of those crazy people out for the infamy. So clearly we need to have contingency plans that would ensure that all motivations are foiled and all murder attempts are nonexistent. Someone wants the code? Throw code into magma. Someone wants the fame? On the same day, nuke Justin Bieber and say North Korea did it. Any other motivations?

I suppose our greatest threat will be the reprogrammed terminators sent from the future by the human resistance to try and stop Toady from creating DorfNet. It's all in vain however, and I for one welcome my graphicless overseers. Cave in traps should deal with them.

[Tawa]

so no murdering for the source code!

Presumably if you were willing to murder him for it, you'd also be willing to simply break into his house or whatever and steal it WITHOUT murdering anybody. 
Plus, even if you are a weird psychopath who sees the code as more valuable than a human life, you'd still have to realize that keeping him alive = more / better code in the future that you could steal again, etc. etc.

Unless they were one of those crazy people out for the infamy. So clearly we need to have contingency plans that would ensure that all motivations are foiled and all murder attempts are nonexistent. Someone wants the code? Throw code into magma. Someone wants the fame? On the same day, nuke Justin Bieber and say North Korea did it. Any other motivations?

I suppose our greatest threat will be the reprogrammed terminators sent from the future by the human resistance to try and stop Toady from creating DorfNet. It's all in vain however, and I for one welcome my graphicless overseers. Cave in traps should deal with them.

No guys.

DF causes the future to play out as "Dorf Matrix", and everyone finds themselves in the highly-boring-unless-you're-a-dwarf-or-adventurer world of DF, being played by Toady, ThreeToe, and the playerbase, who now abuse 14 billion (est. number of people) humans. They're also the future of humanity.

That's right, the future involves spending the rest of your life with a fellow forumite. Partner up now so the good ones don't get taken.

Then again, limiting the future of the world to the crazy people called "us" around here is a highly volatile move.

Oh, and we keep scientists around to mutate us into dwarves.

[Button]

so no murdering for the source code!

Presumably if you were willing to murder him for it, you'd also be willing to simply break into his house or whatever and steal it WITHOUT murdering anybody. 
Plus, even if you are a weird psychopath who sees the code as more valuable than a human life, you'd still have to realize that keeping him alive = more / better code in the future that you could steal again, etc. etc.

Unless they were one of those crazy people out for the infamy. So clearly we need to have contingency plans that would ensure that all motivations are foiled and all murder attempts are nonexistent. Someone wants the code? Throw code into magma. Someone wants the fame? On the same day, nuke Justin Bieber and say North Korea did it. Any other motivations?

Some men just want to watch the !!world!!.

[reality.auditor]

History of open-source games shows otherwise. Project like DF needs extremely dedicated person like Toady. No Toady, no project. At most, few years of small development, bugfixes, trying to make some things, sad agony when amount of interested people dries up and later death.

Freespace Open has been going for about a decade I think and has some pretty massive download rates.

Amount of downloads and time of staying alive does not say anything about tempo of introducing new features and the like. But okay, let's say Freespace Open counts. So what? One (or few) exception from general rule does not change anything.

In my opinion, DF Open Source will burn out for simple reason: legacy issues. I am not even talking about bugs, presumably bugfixes would be first things that would be taken care of in case of DF going open source (this alone would be for me enough to make whole thing worthwile, even if nothing happened after that).

So what I mean by legacy issues? Toady do not want to do anything involving such newfangled (merely many decades old) concepts like multithreading*. In modern and future world where you have zilion slowish cores in one processor, CPU-heavy program relying on single thread is doomed to fade into irrevelance. DF is alive only thanks to promises of new features and development done by certain extremely dedicated individual. Without Toady, DF cannot stand on its own.
IMSVHO starting from scratch (and using Toady code as guide and start point to develop things like algorithms for world generation etc) would be simpler than rewriting DF code for multithreading. This way in my view holds greatest chance of success. We avoid any legacy issues, old code that would break in unexpected ways and plehtora other issues - but it would still be DF in spirit.

And Stonesense. They should be able to fully integrate it as UI before project "DF Open Source" burns out.

Can't STAND stonesense. The ASCII graphics are far superior, IMO.

I don't think anyone will ever drop ASCII. Stonesense, ASCII, 3D - that would be just another user interface layer. Assuming anyone would get arsed to make decent UI API for Open DF, of course...

* There are other problems, but multithreading one is most jarring.

[Putnam]

I can't even describe how much you're overstating the importance of multithreading. Better branch prediction is at least twice as important. What could be shoved onto a different thread? Pathfinding? The game would still have to wait for everything else to finish before it did its pathfinding.

[GavJ]

What could be shoved onto a different thread?

There isn't (or doesn't need to be, rather) any causal contingency within a single tick. As in, you as a player have no right to complain, per se, that in one case, the machine on the left fired first within the same tick, and in another instance, the machine on the right fired first within the same tick, or what have you. Or that monster landed a hit first versus dwarf, or that magma flowed or temperature updated first, etc.

Therefore, within one tick, I think it's entirely reasonable to do pathfinding, temperature, flow, combat ALL as separate threads, why not?  MOVEMENT might have to be privileged at the end, so as not to walk inside a wall that was completed in the same tick.  But that's about it, I think, and movement is going to take up a very small part of the processing time of a tick.

If you pathfind and then in the same tick, a wall finished being built, so what? As long as movement itself is privileged, you'll just get a cancellation and a repath the next tick, that's all.



Edit: Actually now that I think about it, I don't think multithreading would even have to lose your guarantee about which machine fires first, etc. Since you could still APPLY all the changes in a canonical order. All that matters is that temperature doesn't have to rely on the combat outcomes of that same tick, and it doesn't. So they can be calculated on separate threads.

[GavJ]

That said, multithreading is still not the be all end all of optimizations, though. It will AT THEORETICAL BEST double or quadruple your framerate, and in reality, of course much less than that. Probably more like 50% boost

Whereas other optimizations probably could have even more of an influence than that. For instance, proper item stacking, and not checking every boulder in the fortress to see which is closest. Which goes hand in hand with not keeping track of so many irrelevant details of each object, or so many pieces of clothing. Also, creatures in closed rooms don't need to keep trying to path out every tick... they can just retry whenever a tile is mined or wall built/torn down, etc. etc.

(Masterwork for instance only has "leather" not "giant blue female diabetic mole leather" and several other optimizations of that sort, and runs 25% faster so they claim than vanilla, even with more content)

Altogether, I'm guessing it would add up to significantly more speed than multithreading, but multithreading would still be a major player in optimization for sure.

[Putnam]

You were the only one who said anything about machines. I only complained about pathfinding, since that's what's always brought up and that's probably the least feasible one (since state changes elsewhere can all affect pathfinding).

Also, boulder checking is optimized, believe it or not; an individual boulder is checked position and closeness-to-stockpile-and-buildings wise two ticks in a row, then 2 later, then 4 later etc. until each only is checked every 1024 ticks. When a boulder is checked and its state found to be changed, it'll reset back to the beginning. This was in an interview.

I'd say multithreading's best is a 50% boost. It'll probably be less.

[GavJ]

I only complained about pathfinding, since that's what's always brought up and that's probably the least feasible one (since state changes elsewhere can all affect pathfinding).

It doesn't matter if stuff AFFECTS it. What matters is only if stuff affects it in such a way that impossible events or game crashes result due to the conflict. Which I can't think of any examples of.

Like I pointed out in the previous posts, if for instance a wall gets finished being built in the same tick, then a multithreaded pathfind might still assume that route is open. But that won't crash the game... it will simply cause the dude to run into the wall and then go "huh..." and repath.  Just inefficient movement is the worst outcome.  And honestly, even that would only happen 0.2% of pathfinds. How often do walls get finished being built in the same tick as your path IN your path? Even  if it's in the very next tile, as long as you privilege movement at the end of everything else, you won't get crashes.

And so what? 0.2% of the time a dwarf walks further than it needed to. That is a VERY reasonable price to pay IMO for 50% faster FPS. It's totally in line with the quirky personality of dwarves anyway.

[Putnam]

Creature blocking is way more a problem than wall building.

[GavJ]

Again, prioritizing actual applied movement as something calculated after everything else is done during a tick solves any issues of creature blocking.  All paths will be correctly and reasonably based on the positions of creatures at the beginning of the tick. All creatures will prone and collide appropriately, and so on.

But as far as I can think of, movement is the only thing that needs to have its own calculation phase.

[imlovinit]

Fortunately avoiding all of this is rather trivial modding - just open toadyone.txt and add [NO_AGE], [NO_EMOTIONS], [NODRINK] and [NOEAT]. Memorialize everyone on the map to avoid ghosts then atom-smash them. Turn off caravans, immigrants and invaders, and seal the fortress off from wildlife. Toady can now continue working until you experience save corruption.

Wait since when did Toady drink? I just assumed he absorbed H2O out of the air through his skin.