I am now going to go down the rabbit hole of arm specific bugs in the libraries I use because so far all of the applications I dev (arm ubuntu) have never encountered any bugs.
Code should be judged by inputs and outputs only! I hate code reviews. We end up rewriting well-structured code anyway simply because it is always easier to rewrite than to do surgery
I do agree but too often they turn into "well I would do it this way".
If it is some very big and very critical system then yes, code reviews can be beneficial compared to the alternative. But for systems that are innovative and rapidly going through iterations as it is, it's better to judge coverage of test cases (and adequate performance but not optimal)
What about performance? E.g. you don't want to implement an O(n) algorithm if an O(log(n)) equivalent exists, and merely testing inputs and outputs won't reveal that.
I do agree, but it depends on the criticality of performance and the level of change the system goes through by default.
For us we are always implementing complex new logic for not very many users, so there's not much benefit to some clever data structure that we are all too dumb to understand. If I get a ticket that involves inserting something into the logic you wrote, and I can't understand how to operate your current solution, I will be hacking up an n logn solution as long as it is adequately performant
If you are not comfortable spending x amount of money on one of your interests (which is totally a valid feeling to have), then it is time to prioritize and innovate! Necessity is the mother of all invention.
I think it's arguable if you even need skill - I believe Toady One has mostly taught himself good project design through having to deal with Toady One's code from three years prior. Changing a fixed 2D legacy game to 3D and completely rewriting fluid dynamics in a shipped title will do that to you.
I agree entirely about motivation though - he's stuck with that project for an immense amount of time. Urist Borushdumat[1] and Boatmurdered[2] are both from 2007 - George W Bush was president then and The Colbert Report had barely gotten started - your nephew in high school was still
in diapers. However - over the full run of nineteen years dwarf fortress has been in development[3] he has received pretty tremendous community support - well probably since 2005 or so - I don't know if anyone knew it existed in 2002.
3. Wait - wtf - it's older than Firefly! (that's the show that made Nathan Fillion famous before Castle or Dr. Horrible's Sing-a-long-blog FYI) I can now use the line "I'm getting too old for this sh*"
I think that’s just more a result of the game style/architecture. I don’t think there’s much hidden state that’s not encoded into the map/entities, and even things like AI is I think ultimately preserved as a simple stack of pending tasks.
So being a proper simulation, and combined with the lack of replay, you can almost entirely discard the past events. The game is largely modeled as f(world-state, sim-rules) -> world-state, and so you simply take the old save and continue running it under the new simulation rules, and no one has to really care how many rule sets the world has seen. It only matters that they produced a valid world-state, every time.
The issue with saves and compatibility is that the saved world state needs to remain a valid world state in a new version. This can be as simple as initialising missing data to sensible defaults or a lot more complex if simulation changes have caused the world state to change significantly. Then to avoid breaking things you need to somehow migrate the old data to the new data. And you may need to do that several times if someone loads a save from eight versions ago.
To code something like Dwarf Fortress takes an uncommon level of dedication. The project has been going for a decade and a half!
It's only recently that the project has been paying off via community funding/patronage. A great deal of those early years must have been very difficult for them.
mostly my professional life too. Lesson learned : a ton of up front work doesn't lead to success. Replace "work" by "delegate, socialize, have lots of luck" and you'll go much further :-)
Also work. Don’t do a PhD if the work is a problem. Do a PhD only if the work is in your bones. And also socialize, and do other luck-maximizing activities. But work is indicated.
I know it’s silly but for me the most impressive part of the whole project is that he doesn’t use version control. I can’t even comprehend how that’s possible.
Regarding your edit, I do not disagree. DF does not require a PhD. It would help, but it is not necessary and the people downvoting you, in my opinion, are misusing the privilege.
That said, talking about downvotes on HN is pretty boring, so I won't be replying to responses to this comment.
Certainly one of the most important shared attributes between getting a math PhD and working on the same game for 15 years is the stick-to-it-ness required.
One attribute that people don't often ascribe is luck. This was a labor of love and luck.
We hear about projects all the time that have been developed for longer (Linux, Star Citizen, Temple OS, et al) and those are the successes and failures that people have actually heard about. Lots of other people fail along the way (or succeed in not achieving much) with decades of development. I think DF's development need not be elevated to a quasi-religious tale because someone got good enough life RNG, anymore than being born with the money to brute force it is laudable.
I'd recommend thinking a little about the algorithms involved in efficiently assigning a nearby task to each dwarf and then planning a path for each dwarf to its destination.
It gets interesting pretty fast and a PhD would not hurt. :)
Would you maintain a roadmap telling you how to get from place to place, or just constantly replan? What happens when you change the available paths by building a wall or locking a door?
Pathfinding is largely not that bad — hierarchal A* for long distance pathing, flow field for dense agent areas (eg your fort). With sufficient density, it’s worth recalculating the field repeatedly. Partitions can also be used for resource-lookup, threat caching, etc. Brogue’s djikstra maps[0], and Dave Mark’s modular influence maps[1] are very interesting possibilities as well..
Your paper is dealing with a completely different problem — collision avoidance is hard, and you really shouldn’t care about it in a game like DF anyways. Simply treat existing dwarves as a wall, or allow multiple dwarves to be on the same tile momentarily (with a very strong preference to stand on their own tile).
Task assignment is DF/rimworld/etc is also pretty dumb — they’re fairly obviously simple greedy algorithms. you don’t need to be anything close to optimal to be effective. There exists a list of open tasks (place building, move x59 stone, fight baddie. User actions generally corresponds to multiple tasks). When a dwarf is idle, he takes the task-list, merges it with his needs (food, water, self-preservation, etc). Filter this list by permitted activities for the dwarf, prioritize the list (needs first, then by user-defined job priority, then by random roll). Lock any relevant object (eg x59 rocks in a move task) and execute.
As far as I know, there’s no attempt at global coordination in DF beyond simple locks — which I’m not sure are actually that strict. In DF I’m pretty sure two dwarves can go for the same pile of x50 rocks, and it’s simply first one wins. In rimworld it’s quite clear only one entity can hold a claim. DF in that case is much simpler and error-free (don’t need to care about dwarves dying while holding a lock) but rimworld’s would be more consistent and make better progress over time (eg a far away entity doesn’t keep getting screwed trying to grab resources from the base).
Pathfinding is largely a solved problem. Resource allocation doesn’t need to be smart.
I’m fairly positive DF’s biggest hurdles are largely in finding game-sufficient and efficient estimate models for complex processes: planet, fluid, wind (a kind of fluid), plant growth, etc. These models are all fairly well defined (to our gaming needs) by their respective communities, but they’re also far more involved than what we need — we just need to be roughly correct, and ideally have a self-stabilizing sim.
The difficulty of gamedev generally is simplifying the problem to find only what actually matters.
Because most humans are functional enough to understand the concepts of metaphor and allusion.
No rational person would read this headline and assume that some cosmic force prevents you from coding Dwarf Fortress unless you have a math PhD. Therefore the most reasonable conclusion is that the creator of Dwarf Fortress does have a math PhD, and that it provided significant transferrable skills. That this is not what the headline says on a literal reading does not prevent a reader even with zero familiarity on the topic from correctly understanding it.
Because the creator himself specifically addressed the headline in the article. So either you think you know better than the creator, or just saw the headline and knee-jerk wrote a comment without reading the article contents.
Saying "You don't need a PhD you just need to believe in yourself", or whatever, is fine - but it's not related to the article, so gets down votes.
The headline is part of the article. You could say “so you think you know better than the author” by quoting the body or “so you think you know better than the subject” by quoting the headline. Both are quoting the article to react to other parts of the article. The fact that the single most salient and most read part of the article sucks is plenty worthy of criticism.
Yay free money!