To think about: Deny free movement and make it grid-based

[eugeneloza]

To look like Duungeeon map, but to be more advanced with non-1x1 tiles. While it will look ancient and lame, there're only "pros" to this:

1. Easier to generate interior and overworld (and anything).
2. Easier to manage the world (and everything).
3. Easier pathfinding.
4. Easier AI.
5. Much more diverse effect ability (e.g. they can push, drag, etc.).
6. More tactics - characters can be accurately placed in the place.
7. Easy editor
8. Thin places can be generated.

Cons:

1. Doesn't look all that awesome, as a free roaming.
2. Should discard most of the work done on overworld generation (and done with it).
3. The paths won't be smooth.
4. Breaks the idea of "flexible pause" (e.g. simultaneous actor's movement now will be a problem).
5. Enemies sizes would be "fixed" to integer 1:1, 1:2 or 1:3 (and, maybe, larger).

Still thinking about that. But I'm very close to returning 3D world into reboot branch, and so it seems that it's the right thing to implement from the very start (and forget about any other possibility). Let's be reasonable - there appeared too many problems, which I was unable or slow to solve, to complicate things even more. Let's make it more simple with hope it'll increase chances, that something will ever be instead of trying to make everything cool and wonderful, but never.

[eugeneloza]

Actor can "block" (size = 1) or "partially block" (size = 0.7) a grid node, when allies can be "let through" to pass, but not enemies.

[eugeneloza]

Looks like 5x5 grid for every cell (with party being 3x3) is the best version (usually passages will be 3 tiles wide). That would also require, the central space of every tile to be 3x3 free (not to break party formation). Seems to be ok. Thou party will "jump over" 2 steps on each movement (no problem thou).

Party may be ambushed on movement (especially on "squeeze-through"), and also can ambush enemies.

Breaks party movement, as the party members may be split in action, and must be "reassembled" at some position after combat. Fleeing or moving large distances will also be very boring as all characters will have to be moved separately? Or multiple characters may be selected and ordered to move (relative to each other if possible).

(Yeah, gameplay seems to be very unbalanced at the moment, as all the previous ideas were attached to free world roaming)

Variant: Retain free roaming "WITHIN" a grid space (i.e. player characters will move accordingly to fixed rotations / positions, but the cameraman can move freely move within 1 space from the walls). Demand each passage be at least 3 tiles wide. This creates a lot of troubles for the concepting "how the characters are oriented against the camera" (the camera will rotate freely, but the party orientation will be very discreet (i.e. only 4 actual orientation angles). Thou, how strange it looks, there is no practical problem in that - just the party will be lagging behind the cameraman a bit. I like the idea, as it will allow to retain "non-rectagonal tiles" for the overworld (which is far more natural).

[eugeneloza]

Too simple tiles pattern will break the strategy idea behind tiled movements. I don't like the idea.

Maybe " party movement" between tiles centers and autoarrange the party formation according to current situation (thou not optimal and harder, but better) Unless the party is ambushed the formation can be rearranged without penalties. The tiles size of the tile may be much more detailed than simply 5x5 (however, that also creates problems (interface overcrowded, too long movements, hard to manage large areas), maybe, just more vivid tile structure is better).

[eugeneloza]

Jabb is 3x3 at least, maybe more, thou it shouldn't be too large to be able to kill it with ranged weapons easily (thou other large targets may be fought this way)

[eugeneloza]

Different path graphs for different actor size. I think only square actors may be used (or circular - less clear logic for pathfnding), because that'll complicate things too much with "passing" narrow passages in different rotations.

[eugeneloza]

Only 1 actor group may occupy a tile. Actor groups may move syncrhonously, but never 2 will meet in 1 tile unless combat (even then they are virtually located at different tiles). Let's also define a more clear terminology: Tile - a large 1x1 rectagonal object at map, Cells - sub-tiles for actors movement. Each tile consists of 5x5 cells. Each Chunk consists of ~10x10 tiles. Each Block consists of 5x5 chunks. I wonder if this can be better "fractalized" to determine optimal parameters? Thou these seem fine.

I still think rectagonal will be better even in the overworld, however, development of non-rectagonal approach would be welcome, even if such mode will never be implemented. Just align 4 rotations to normals to tile borders (and define them clearly).

[eugeneloza]

Change FOV in combat/travel mode.

[eugeneloza]

Oh, it's so tempting to forget about "beautiful tiles" and make all tiles 1x1 (3x3 cells) - so much less artwork and so much easier to implement both management and logic and so more smooth gameplay... But that's an oversimplification unless I manage to make them "compatible" within a single World instance. (upd) Hmm... that'd be a nice trick for overworld... (or any 2.5D world, caves may also be generated this way)

[eugeneloza]

In case everything goes smoothly, it'll just be the same faces compatibility checks, but in this case every cell (except for the borders of the world) will be filled with something (? may be unneeded for dungeons, thou why not?) Also adjustments for floor/ceiling topology is required. Moreover, some tiles have min and max allowed height (trees may not be taller than ceiling, and solid walls may not be lower than ceiling (i.e. not blocking the passage completely). The topology map also has it's min/max difference during generation. Important stuff: generated tiles (from a set of objects / or use placeholders?) Especially important in very uneven terrain.

[eugeneloza]

The more I think about grid-movement the more I like a mix of free and grid movement.

Camera can move freely only over "mid" cells always staying at least 1 cell away from tile borders, which allows for "normal" formation of the party, thou it's rotations will be quiet discrete.

(+) We can still move the party as one (if formation is not broken too much) (+) Very deep optional micro-management of every character location, action and movement (+) Easy 2.5D maps generation and management (including overworld) (+) Much, much more clear idea on the Decoherence 2 combat, as firearms are planned to be the main weapon and taking cover being more important than rushing to attack.

(-) If formation is broken, party movement would be quiet inconvenient, especially in case party needs to retreat. (-) Specifying group actions both in 2D (individual movement, selecting target) and 3D (group movement, selecting target) doesn't seem obvious, and looks awkward. (-) Rectagonal grid looks lame and cheap. (-) "Jumps" in formation would look terrible, even if smoothed.

Anyway that'll give the game more Wizardry 7 feel, than Wizardry 8.

Another conclusion: "curved" tiles idea doesn't seem to be worth the effort. It won't provide much of improvement in visual (as it'll still be semi-rectagonal) but will create a lot of problems with cells management, with party formation. However, I haven't discarded this idea completely, still thinking about that, as still rigid rectagonal tiles look too ancient. And Might and Magic X is a horrible example of that :)

[eugeneloza]

Hey, we have absolutely no need in having overworld generated in a rectagonal manner. Tiles will have no relation to the actual passages, i.e. the world will be generated by cells (i.e. 1/5 of a tile), usual passages being 3 cells wide (worm algorithm, I've been exploiting since 1995). With blocking objects placed on blocked cells (algorithm doesn't seem to be complex). While not being entirely "Free" it will look way better than "rectagonal tiles grid".

[eugeneloza]

Setting a graph of larger-scale movement logic is also not a problem. Just need to mark a single internal cell to "cover" all other movable cells in 2-3 cells radius. Should work perfectly.

[eugeneloza]

Yes, in this context I'm just building an "own" rectagonal NavMesh. Maybe, there is sense in trying to make it somewhere near a "Standard" solution? Need to study the issue for already available solutions. Anyway, I'll be better with a equal-sized cells solution for tactics, but they aren't forced to be exactly rectagonal and their size may vary. It'll make some problems with "actors larger than 1x1", but being close to rectagonal cell (~20% will do) does not seem to harm too much. Off-navmesh cells aren't needed to be equally sized and may be used to "force" equal size on navmesh. This doesn't seem as a "Standard" solution, but worth trying.

[eugeneloza]

The 2.5D world will come in layers. 1 - ground level (grass) doesn't hinder movmenet 2 - middle level (bushes, rocks) block movement for walking 3 - top level (tree top) block movement for flying, but not for walking 4 - sky level (very high trees (rare) or walls/rocks stretching very high (or into the cave ceiling) doesn't hinder movement

e.g. a normal tree would have very narrow 1st and 2nd level (trunk) and wide 3rd level, with zero 4th level. A huge rock will span over all levels and a small one - just 1st and 2nd. Bush will use 1st and 2nd. House will have equal map at 1-3 levels. Vivi tree will be a special complex object spanning 1-4 levels.

[eugeneloza]

While non-regular cell grid is very tempting, on the practical side there no sense in that kind of stuff. The overworld will still be non-rectagonal due to random objects displacement in the cells, towns will still require rectagonal grid (to be in fit with rectagonal houses), and its much easier to manage a NxM grid, than a graph. Moreover, it's more clear how to manage larger size enemies, and easier for pathfinding. It's still not very clear how to manage multi-level tiles in the dungeon, including getting z of stairs up/down or non-zero-based tiles, and tiles in dungeon will become three-times redundant :D Thou everything is practically solvable, just complicates things a bit (a lot) - anyway easier than managing a procedurally generated navnetworks with inevitable nodes placement bugs.

So, yeah. There is no serious alternative.

1. 2.5D overworld with 4 levels (only 2nd and 3rd levels affect pathfinding, 1st and 4th - only for generation purposes.
2. 2D tile within 3D dungeon.

I don't like "2D" in the dungeons, because they don't allow for flying enemies in the internal locations. Should think about that a bit more.

[eugeneloza]

Moreover, this way we can modify the landscape by some effects (like massive explosions, forest fires, etc.)

[ResonantExplosion]

Visualize cells grid in Constructor (to correctly edit it) and in game to specify character movement in combat without using the radar.