Print

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

[Xazo-Tak]

I can't name a required change because it's a fundamental change. This game has had 13 years of development and all of that would have to be redone with the new worldtype in mind.

I've already named the required changes.

Alright, then I'll try to name some difficult things.

1. Positional logic, especially as it relates to pathfinding, movement in general, fluid physics, combat, stockpiles, buildings... wait, I'm listing everything in the game.

2. Modding issues. Despite what you seem to think somehow, this would be significantly more difficult to mod for than the current system. Meshes are difficult to work with. Numbers representing positions relative to some origin (as I assume you're referring to) are not really intuitive at all.

3. Visuals. Armok 1 is an uglier game than Armok 2. A mesh-based game would likely look far uglier than a tile-based game. Vaguely cat-like boxy things are harder to recognize as a cat than the letter 'c', simply because a vaguely cat-like boxy thing also looks like a vaguely dog-like boxy thing. The best way to mitigate this would be texturing, and there you go making it harder to mod again.

4. UI. Designations would become more complicated and switching to meshes won't magically make the rest of the UI any better; in fact, the likely lack of slice-based rendering makes the UI in general far worse than it currently is. That will have to be redesigned as well. Viewport isn't that big of a problem, actually.

5. Dimensions were already a fairly difficult problem. Meshes suggest an exclusively privileged fourth dimension as opposed to, for example, one that can be traveled through at-will by certain agents or the player's viewport.

6. Looking in directions that aren't top-down would be silly when embarks are only a certain size.

For 3 through 6, you're still completely ignoring what I've repeated over and over about there being a system in place for converting meshes to tiles for the sake of viewing and interface.
I've even visually demonstrated this system for a rotating mesh.

For 2, creature raws almost describe a mesh already, with only an elaboration of one tag and an addition of another being necessary. These tags, once made functional, would be very quick to add to all raws because almost all creatures refer to a template for their body structure.

As for 1, I've covered all those already (stockpiles and buildings would be only a minor abstraction of the pathfinding algorithm, for stockpiles creatures just pathfind to a point that's in the stockpile designation that has enough empty space to drop what they want, for buildings I'm not quite sure what kind you mean but there's a plan for all 3 things you could mean)

[Putnam]

5 has nothing to do with visuals, by "dimension" I mean "alternate worlds". A w dimension along with x,y,z.

Having a plan isn't equivalent to simplicity of implementation. I can imagine your description of stockpiling alone being a buggy mess for years, and that doesn't even go over the fact that items would have to be completely rewritten.

[Xazo-Tak]

5 has nothing to do with visuals, by "dimension" I mean "alternate worlds". A w dimension along with x,y,z.

Having a plan isn't equivalent to simplicity of implementation. I can imagine your description of stockpiling alone being a buggy mess for years, and that doesn't even go over the fact that items would have to be completely rewritten.

"completely rewritten" as in giving them an x, y, and z size?
Wow, adding a box to something really completely rewrites it!
Seriously, everyone in these thread is throwing around "complete rewrite" without actually explaining why.

As for stockpiling, I'd imagine it'd be buggy for a sloped surface (but unless items were allowed to slide on steep slopes, this issue would be extremely minor), but other than that it'd be an abstraction of the pathfinding algorithm. So no additonal work.
And any stockpile issues related to slopes of the surface could be solved by having any stockpile designation cause the stockpile itself to be drawn on the mesh below, with any parts of the mesh that are too steep not counting as stockpile.

Not sure why you want a fourth dimension for the game now, given that it's 3D meshes viewed by converting them to tiles viewed in 2 dimensions.

[Dozebôm Lolumzalìs]

The basic assumption written into all of the code is: "there is a tile". If you use meshes, EVERY SINGLE PIECE OF CODE THAT REFERENCES A TILE MUST BE CHANGED.

That is... almost everything, as Putnam said. It's a good suggestion, but a lot harder than you think it is.

[Xazo-Tak]

The basic assumption written into all of the code is: "there is a tile". If you use meshes, EVERY SINGLE PIECE OF CODE THAT REFERENCES A TILE MUST BE CHANGED.

That is... almost everything, as Putnam said. It's a good suggestion, but a lot harder than you think it is.

It's a lot of code to be changed, but it's very often just about how far away something is affecting the distance in which an interaction occurs, or something equally simple.
Combat? The range in which you can fight with any particular part becomes the distance of the used part from the head (which becomes measurable with the tags I proposed).
Sound? Goes from being a large cube to a simple distance.
Chains? Again, from cube to distance.
A dragon aiming fire? Goes from aiming at the tile a creature is in to aiming straight at the creature (adventurer mode would still use tiles though)
Rooms? Still uses tiles.
Minecarts colliding with walls and ejecting their contents 1 z-level up? Change that to giving the contents a small vertical velocity.
Minecarts deciding they've collided with a wall at enough speed to cause an eject? Check to see if the cart lost more than 5m/s of speed.
Occasionally you get something that isn't trivial like dances, but that's still not that difficult.

Lots of them can even still reference tiles if needs be, until mechanical stress is a thing mechanisms will always be dead-centre on a tile.

A lot of things have to be changed, but the changes are almost always extremely simple tweaks to the simpler things in the game, the bulk of them could probably be run through in a few days (the toughest of them, mainly one's I've mentioned previously, would take much longer though).

[Orange Wizard]

It's a lot of code to be changed

simple

simple

not that difficult

extremely simple tweaks

simpler things in the game

probably be run through in a few days

When basically everyone else is saying "this will be prohibitively difficult" you might want to think about just how simple it would be

[Xazo-Tak]

It's a lot of code to be changed

simple

simple

not that difficult

extremely simple tweaks

simpler things in the game

probably be run through in a few days

When basically everyone else is saying "this will be prohibitively difficult" you might want to think about just how simple it would be

I'm explaining why it would be simple, and everyone else is saying without giving a reason why it'd be difficult.
Putnam's done most of the complaining, and he clearly posted without even reading the thread.

[Orange Wizard]

everyone else is saying without giving a reason why it'd be difficult

Not at all.

rewrite the entire game from scratch ... So much technical stuff that we can't even know the extent

It's simply changing the geometry under which everything operates

Tiles are the most fundamental part of the game

I don't think the benefits of such a switch would even remotely outweigh the cost (in time) of making it

Alright, then I'll try to name some difficult things

If you use meshes, EVERY SINGLE PIECE OF CODE THAT REFERENCES A TILE MUST BE CHANGED

[Putnam]

Yeah, I think it's mostly severely underestimating the sheer amount of code in the game. Switching the game to 3D took more than a year. That was just adding a single coordinate to the tile system. That was also nearly 8 year ago, from version 0.23 to 0.27.

[Xazo-Tak]

everyone else is saying without giving a reason why it'd be difficult

Not at all.

rewrite the entire game from scratch ... So much technical stuff that we can't even know the extent

It's simply changing the geometry under which everything operates

Tiles are the most fundamental part of the game

I don't think the benefits of such a switch would even remotely outweigh the cost (in time) of making it

Alright, then I'll try to name some difficult things

If you use meshes, EVERY SINGLE PIECE OF CODE THAT REFERENCES A TILE MUST BE CHANGED

You're literally quoting at random.
"every single piece of code that references a tile must be changed" was the only relevant quote, everything else is exactly the kind of unconsidered discussion I was talking about.

Yeah, I think it's mostly severely underestimating the sheer amount of code in the game. Switching the game to 3D took more than a year. That was just adding a single coordinate to the tile system. That was also nearly 8 year ago, from version 0.23 to 0.27.

Changing the game to 3D is a much bigger change.
Not only does it affect everything related to tiles just like this suggestion, but most changes are more complex.
Constraining physics to a tile system while maintaining even a small amount of accuracy is a tough challenge, adding an extra dimension to completely arbitrary physics sounds like hell.
But conventional distances and physics are much simpler to implement once you have the data structure for it, to the point that even though there's so much more stuff to change it'll still likely be faster. Most of the tile based stuff has been around since that version anyway.

[Putnam]

Changing the game to 3D is a much bigger change.
Not only does it affect everything related to tiles just like this suggestion, but most changes are more complex.
Constraining physics to a tile system while maintaining even a small amount of accuracy is a tough challenge, adding an extra dimension to completely arbitrary physics sounds like hell.
But conventional distances and physics are much simpler to implement once you have the data structure for it, to the point that even though there's so much more stuff to change it'll still likely be faster. Most of the tile based stuff has been around since that version anyway.

You can't just sorta put equations in and expect physics to come out. Materials use real physics for the most part and 0.31 was one of the longest update cycles ever due to a simple creature/item rewrite based around them.

Unrelated to the quote, but pertinent: map generation is by far the most worrisome part of changing the tile system at all and I don't see any mention of that. Map generation was the reason 0.27 took over a year, it was the reason 0.40 took over a year, it was the reason 0.34 took over a year and the latter two weren't even updates to 3D, just new site maps! Problems with map generation are the biggest dev problems around and this would cause horrific dev problems, likely persistent ones.

[Orange Wizard]

OP: "Hey guys I've got a cool idea for DF"
Us: "that's cool but it'll be really hard"
OP: "I don't think it'll be too much work"
Us: "Yeah it will because you're gutting half the game"
OP: "That doesn't sound hard"
Us: "everyone except you seems to think it'll be hard"
OP: "But they haven't explained why"
Us: "... because you're gutting half the game"
OP: "I don't think that'll be hard though"

[Xazo-Tak]

Unrelated to the quote, but pertinent: map generation is by far the most worrisome part of changing the tile system at all and I don't see any mention of that.

Finally, a legit argument from a wizard that is orange!
I have mentioned it in the thread, but I only glossed over it because the change for terrain could either be very easy or very difficult depending on something that I wouldn't know.
The change for structures is simple enough though: blocky structures convert into blocky meshes in a 1:1 match.
For terrain however, it seems like it'd be waste of making a transition to meshes to do the same conversion rather than getting neater and more realistic terrain (which would admittedly only show most changes in third party 3D renderers that are able to see the meshes).
Unfortunately, such a change requires that for the current version slopes and angles of features are known before everything's converted into tiles, which I'm really not sure of.

If the terrain does generate like that, the current small scale terrain generation can be cannabilised for generating a mesh.
Otherwise, small scale terrain generation would have to be rewritten truly from scratch to get the same kind of accuracy, and that's something that even I agree is not something that should be rewritten.

[Putnam]

huh, didn't even notice that the shitty wizard was orange, might wanna change that again

[Xazo-Tak]

huh, didn't even notice that the shitty wizard was orange, might wanna change that again

What's it meant to be? Red?
Also, if you're changing it, I'd suggest making the arm mounds bulge out more so it looks like his arms go behind him and his hands meet behind his back.
It may be a shitty wizard, but wizard mannerisms are pretty neat.