Print

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

[Xazo-Tak]

Just because you don't think my reasoning is valid doesn't mean I had no reasoning in the first place.

Well, it is reasoning, but on a suggestions forum for a closed source game I'd say that "It's too difficult to change the code" makes too many assumptions.

[Putnam]

I've seen Toady's code for Liberal Crime Squad. I'm sure he's improved since then, but his consistent mentions of "unsanctioned mess" and "real programmers" makes me think that DF's code may actually be bad, not "a bunch of structs and functions all packaged up in a single file" bad, but bad. Sure, he may be the only person qualified, but it's not like one can't make a really good guess.

I wouldn't say the problem is that it's too complex, it's that it's too different. This is definitely a good suggestion for if I decide to start my own game, but I don't think it's reasonable to expect something this different to be put into DF because it's likely there's a bunch of weird shit in there (I.E. all of the map generation code, as mentioned earlier) that relies on tiles. I think I've seen Toady mention the algorithms he uses for site generation on the tile level, it's all very tiley from what I can tell.

And yeah, reductionism is not convenient for computer science at all. Reality is probably turing-computable, but abstractions are just as good on most scales and orders of magnitude of orders of magnitude faster. Even professional flight simulators are going to use abstractions instead of modelling each individual atom of air and plane using quantum mechanics.

That's an exaggeration compared to what you're suggesting, but it's sort of part of my point; the game already has FPS issues and implementing real-life physics is liable to make it worse, not better.

[Xazo-Tak]

Fair point about FPS, even 10 years in the future and with multicore support, computers will still probably struggle with normal Dwarf Fortress, and if just one of the major changes to a mesh system is done poorly it'll kill the FPS. If the terrain generation wasn't so tiley, it could have a very low mesh resolution and thus the pathfinding algorithm I had in mind that worked by mesh topolgy could run blazingly quickly, but goodness, by your description a mesh system would be a nightmare to implement. One thing I hadn't considered was that since the oldest code in the game must be from when Toady was far lesser a programmer, the game's oldest features would be pretty much impossible to change since everything would be built around them in an inflexible way.

[stuntcock42]

only someone with access to the source code is qualified to say that the code can't easily be adjusted.

And what about the guys who decompile the game, map out its memory structures, write and apply binary patches, and spend years tinkering with the mechanics and UI?  They don't have access to the source code, but it's probably a good idea to listen to them anyways.

It's worthwhile to argue your side of the question and ask your interlocutors to be specific.  But if you're five pages in and nobody is budging on the "requires too much re-coding" objection, then it may be time to revise the original suggestion.  Find some way to reduce the scope, or explain how it might occur via parallel development (so that taverns, wars, magic, etc... don't get postponed for years while Toady works on meshes), or present a few overwhelming advantages of a mesh-based system which would vindicate the delays.

[MobRules]

I wouldn't say the problem is that it's too complex, it's that it's too different. This is definitely a good suggestion for if I decide to start my own game, but I don't think it's reasonable to expect something this different to be put into DF because it's likely there's a bunch of weird shit in there (I.E. all of the map generation code, as mentioned earlier) that relies on tiles. I think I've seen Toady mention the algorithms he uses for site generation on the tile level, it's all very tiley from what I can tell.

Yeah, this.

I've seen Toady's code for Liberal Crime Squad. I'm sure he's improved since then, but his consistent mentions of "unsanctioned mess" and "real programmers" makes me think that DF's code may actually be bad, not "a bunch of structs and functions all packaged up in a single file" bad, but bad. Sure, he may be the only person qualified, but it's not like one can't make a really good guess.

Also, the kinds of bugs that pop up tend to indicate that the code might not be the cleanest. (as though  some hard-coded thing got updated here and here and here, but that other instance of it got missed.)

Damn, it is relevant.
But still, it's barely above "shitposting" in that it provides an opinion on the subject with the so-called argument being unrefutable without drifting from the original topic

No, I was just frustrated by your continued insistence that changing the entire underlying geometry of an already-existing, highly-complex game would be easy, without ever making what seemed to me like a real case for why this would be so. (You demonstrated why switching from a pure algorithm doing it one way to a pure algorithm doing it the other way would be easy, but I don't think anyone ever contested that point). This is complex, existing code where the almost-certainly-hardcoded assumption that pure tiling is being used embedded throughout the codebase. Much more than just a simple algorithm swap.

Sure, it would have been possible to design and code a game like DF in such a manner that the underlying geometry model could be swapped without too much difficulty. But the swappable model would need to be an assumption throughout the coding, and all indications are that the opposite is true. It's unlikely Toady would have built flexibility into aspects of the game that he had no plans to change, ever.