Print

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

[Dozebôm Lolumzalìs]

That sig cracks me up, OW.

Seriously, our biggest argument is that the game must be rewritten, and you think that will be simple. Are you a coder/programmer even?

And those quotes were all saying the same thing: the idea may be simple, but the coding is NOT.

[Bumber]

For mechanical simulation, I'd say converting it back into tiles is the easy part:

Spoiler (click to show/hide)

A mesh on the right rotated into two different positions, with tile conversions on the left

What happens when I want to start taking parts off of it? Is there still the same amount of material as was before it collapsed? Have the material types remained the same? (How are we keeping track of this?) How does mining even work in a mesh-based view, considering that the terrain has been fused together and may settle at an angle (not grid aligned)?

I mean, we could have fine-grained voxel-based terrain, but DF was in no way designed to work with that.

[Xazo-Tak]

That sig cracks me up, OW.

Seriously, our biggest argument is that the game must be rewritten, and you think that will be simple. Are you a coder/programmer even?

And those quotes were all saying the same thing: the idea may be simple, but the coding is NOT.

Yes, but I mainly just study data structures and algorithms.
It's a completely unconstructive argument though, it's easy enough to say it's difficult but trying to find a non-difficult approach gives the idea a chance of being fruitful.

For mechanical simulation, I'd say converting it back into tiles is the easy part:

Spoiler (click to show/hide)

A mesh on the right rotated into two different positions, with tile conversions on the left

What happens when I want to start taking parts off of it? Is there still the same amount of material as was before it collapsed? Have the material types remained the same? (How are we keeping track of this?) How does mining even work in a mesh-based view, considering that the terrain has been fused together and may settle at an angle (not grid aligned)?

I mean, we could have fine-grained voxel-based terrain, but DF was in no way designed to work with that.

If you want to take parts off the mesh, what happens depends on what type of mining is implemented.
A: Boolean cutouts, i.e. take a cube sized chunk or something out of the mesh when mining is done. Efficient and easy, handles all terrain perfectly fine.
B: Rough-hewn walls have quite a bit of mesh detail, and mining them will push the vertices of that mesh away from the miner. Benefits are that caves can have very natural forms, and mining is easier to give to things that shouldn't be able to burrow through the ground at high speed such as goblins and adventurers. Problems are that some very clever ways of transforming mesh topology would be needed to handle digging tunnels and removing pillars otherwise the following would happen:

Spoiler (click to show/hide)

Heavy mesh distortion and possible intersection

...and a cave would have a very high mesh detail unless the ways of transforming mesh topology were artifact-quality.
C: A cross between the two, small-scale boolean cutouts. Not as difficult to get right as B is, but B would be much better if done right.

If letter denotes method and +- denotes quality with which the method is programmed, here's my list of how good/bad the methods would be.
*Best*
B+ (Everything C does only harder, plus being able to prevent the mesh from intersecting with itself)
C+ (Would have to be able to reduce unnecessary mesh density, as well as play nicely with pathfinding)
A (Not really any way to get this wrong)
C- (Mesh density varies across the underground like crazy from digging, causing unnecessary performance tolls)
B- (Completely unusuable)
*Worst*

Putting it like that, it's really not clear how mining should be handled, especially when one considers that B is the hardest to program and A is the easiest.

Material quantity doesn't change during a collapse, because while the volume of a mesh converted to tiles would appear to change as the mesh rotated, the tiles are still display-only and the mesh is still the same volume. Still no issues if the collapsed object snaps in two. If the thing that collapses is a big metal block which gets dented however, then preserving volume could get tricky.
Material types would be defined by different parts of a mesh, e.g. this closed off volume of the mesh is copper and this closed off volume is wood.
Once again keeping track of the quantities of materials depends on being able to preserve volume as the mesh is distorted.

[Dozebôm Lolumzalìs]

You don't get it: this would take at least a year to implement. That is my ONLY complaint. Otherwise I think the suggestion is great and well-thought out.

[Putnam]

Wait, when you said "faster" earlier did you mean faster to implement or faster to simulate? I'm assuming the former, since the latter is sorta ridiculous.

[Eagleon]

I'm normally for the stance that suggestions should never consider difficulty of implementation because it's difficult to say without access to the code what will be problematic (enjoyment of the task comes into play as well), except that this has explicitly been mentioned as a reason it wasn't being done.

Toady abandoned 3D graphics exactly as you describe them (almost word for word, in fact) because it was a complete slog to develop for, and made what should have been simple take an inordinate amount of testing. Armok was a buggy mess that crashed at the slightest sneeze. Granted, he's more experienced now, but when the developer is taking a clear preference for development away from what you suggest, it's counterproductive to make a huge argument trying to convince everyone else otherwise. Saying that he himself doesn't have to implement the meshes or do the modelling or whatnot does not remove the need to test and fix everything that breaks in everything new as a result of having that capability available. If he ever does do this, it'll be when everything visual is in, and all that's left is poetry generators. To be clear, it's not a problem of how long it will take to implement now, it's a problem of how much time it adds to develop every single thing else later.

And no, keeping it sortoftile-based doesn't make it easier - if anything, traversal through a local/world coordinate system is much more computationally expensive and unwieldy to develop with than just magnifying the size of everything and giving floating point values instead of integer tiles. It represents the limitations inherent in systems like Box2D, where you have to juggle a half-dozen coordinate systems just to make a ball jiggle in Android. I know because I've tried to work with this method, and it's disgusting how much back and forth happens finding local/world/local coordinates, finding vectors between the two, etc. It's not fun.

[Putnam]

Oh, nice. All my complaining was from the experience of working with Source 2, which isn't even remotely as bad as rolling your own 3D engine.

[Xazo-Tak]

Half a dozen coordinate systems to make a ball jiggle?

[Eagleon]

Half a dozen coordinate systems to make a ball jiggle?

You take the center of mass of an object as one coordinate. In order to handle things like objects that are attached to each other, that can only relate to that object's local coordinate, though - to find where it is in the world, you're referencing the world object to find a new set of world coordinates, and something has to happen to make that translate. Now, you want to move the object towards another object, like an attractor (a planet to a sun, for instance) - you have to go into that object, find its coordinate system, find its coordinate in the world using that, and then with those adjust the acceleration of both. My memory is fuzzy, I haven't worked with it in years, but you may also have to let the objects know that you just moved them to handle attachments jiggling, jerk from their feedback, etc.

Box2d handles all of that quite nicely with a few functions - if your game is simple, you can even encapsulate them into play-time functions and never have to worry about it again - and box2d is physics, not graphics. But it's also not looking to generate procedural 3d models that, again, would have to respect rules regarding their relations to each primitive that don't just come out of nowhere by magic. Every single thing in the game that has a visual would need to know where to go so that you can see it, needs to be updated appropriately by its parent model, and needs to not decide to randomly start overlapping another part because the connection tree has a weird topology you didn't account for when updating modding. If you keep it tile-based, everything in the local coordinates of a tile needs to move smoothly from tile to tile without discarding the information of which tile it's in, which would involve separate coordinates for each part to handle arrows flying through a tile that a dwarf is partially in, unless you really want to fudge something so obviously visually important as arrows accurately embedding themselves in limbs.

It's not an easy problem, but that normally wouldn't be a problem, because obviously Armok happened and it was glorious - I'm willing to bet Toady helped to influence the field, even if it was second-hand, into attempting Spore. The real problem is that it presents an awkward race in which introducing new features takes a backseat to fixing a stupid graphical glitch that broke some modder's hard work because there was a conflict between the color of a dwarf's backside and the newly introduced tanning system that respected material color, or because dwarves suddenly needed fingers for the rings that turn into saw blades, or etc. You could obviously say "to hell with it" and let modders deal with the bugs as they please, but that is obviously not a nice way to treat the people keeping long-term players like myself interested in the game (thank you guys, by the way)

[Xazo-Tak]

Oh, I'm not suggesting it should remain at all tile based on the level of simulation.
I'm just saying it should only be tile based in terms of designations and graphics.
With the graphics it'd be sort of like viewing a 3D scene slice-by-slice in an extremely low resolution, and then each pixel gets blown up to a tile representing the mesh that is being viewed; so a dwarf is one pixel that gets blown up to a smiley face, an elephant would be large enough to show up as a few pixels which become "e" tiles, and the terrain would be the usual lot of .,'"; but all of these would have their own meshes, which are not affected by the tile system.

[MobRules]

(oops, double-post)

[MobRules]

Something else this conversation also reminded me of:

[Orange Wizard]

There is always a relevant xkcd.

[Xazo-Tak]

There is always a relevant xkcd.

Hardly qualifies as relevant.
With physics, one starts with a bunch of disassociated mathematical relationships, and finds more generalised formulas that can then be converted back into previously unknown abstractions; but constructing this tree of mathematical relationships is likely to end up with complications.
With computer science, one starts with a bunch of already known abstractions that are best achieved with a generalised process, but the generalised process can be hard to make truly genera-
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; specifically in this case, saying that "OP doesn't know how hard this is" rather than finding actual difficulties in the idea. This thread is extremely long for a suggestions thread, but there's been only a few posts that predict actual difficulties in my approach, a bunch more which attempt to predict such difficulties but get confused about the mesh-tile relationship, a few which make reasonable attempts to estimate the number of difficulties in the approach without predicting anything specific, and then mostly just "Screw this idea it's too complex" repeated by the same people over and over.
To be honest, I'm only interested in predictions of specific difficulties, since only someone with access to the source code is qualified to say that the code can't easily be adjusted.

[Putnam]

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