Fights board & base effects

[Sceat]

Here is an issue about what is needed to complete the basic fight system on the client side.

Fight board

Currently when a player click on a group of mob a packet is sent to the server, if everything is valid the server create and send back a fight, but it stops here so we need a way to show the fight board

type Fight = {
  id: string
  team1: Entity[]
  team1_positions: Position[]
  team2: Entity[]
  team2_positions: Position[]
  spectators: string[]
  top_left: Position
  bottom_right: Position
  started: boolean
  locked: boolean
  need_help: boolean
}

• We need a function that take the top_left and bottom_right positions {x,y,z} to create a fight board, like in dofus by "cutting" or "only rendering" the board as voxels.

Here is a map from Dofus unity:

And here is the same map when someone starts a fight on it, its basically turned into a board

Here is a simplified version of a board, as we can see there are 3 type of blocks,

• ground (we can walk on them, line of sight is fine)
• holes in dark (can't walk on them, line of sight is fine)
• plain in white (can't walk on them, line of sight is blocked)

• We can also notice that the voxel are like a checkerboard (alternating light square and dark square), this I guess should use the color of the voxel but darken and lighten them
• It would be nice to have an effect cutting the map outside the board, maybe with some fog or by making the fight board float in the air, blurrying the map around, not sure about what we could do here

Placement phase

Before the fights starts, players will be able to choose their positions, the Fight packet from the server will contain those as an array of position which will need to be rendered with blue and red colors, (blue for team 1, red for team 2)

• The first function creating the fight board should also render those blue/red positions

Fight started phase

Example of a fight in dofus to better understand: https://youtu.be/r3f7116JHow?si=mQDao8albr7Jg8ay
Example of a fight in waven to better understand: https://youtu.be/I8QX7GI5UHw?si=i3h74KmcqQDmMSxA&t=423

Once the fight is started (when everyone is ready or when 60s passed), those red and blue positions disappear and we will see a blue square or red hexagon under each entities like this. Note that both players and creatures can be in both teams, the represention of red team is always a red hexagon and blue team a blue square

• need a way to hide the start positions
• and a way to attach those glowing shapes on the feet of each player/mobs
• when hovering above an entity, the distance at which he can move should be represented with a green zone (like blue zone in the picture above), each fight_entity has a mp property which represent how many blocks he can walk, this should be impacted by non-walkable block on the map, like the screen below
  
• when the turn of a player stats, he should see reachable cells with the same green zone as above but in light green instead, like in the screen below, when he hovers distant cells the path taken to reach the cell should be highlighted in green. The work here is not to move the player, but just show where he can move (we need some kind of deterministic A* pathfinding util

When a spell is selected, we will render the cells where it can be launched with a blue zone.
Here is a tool to check this line of sight system https://www.dofusroom.com/insightroom

A spell will have a min range and a max range

• need a way to render the line of sight zone by highlighting all cells in blue
  

[piellardj]

Initial thoughts for the rendering:

• in the examples you showed, when entering combat the world disappears and only the arena is displayed. This is great for us because it will allow us to use a different rendering system that will be more flexible than the current one
• since the arena seems quite small, I think we could use instancing to render the voxels. The advantage is that it requires minimal processing and supports dynamic terrain, in case some voxels need to change during the fight
• my understanding is that an arena is basically 2D, which simplifies many things
• the overlays such as the blue squares, the circle around the characters etc. could be rendered as planes floating above just slightly above the ground. To render an area on the ground, in your screenshots you have 2 different things:
  • on mosts screenshots the area is represented by colored squares. Those are easy to render
  • on your fifth screenshot, the area is represented by a continuous blue blob. This will be a bit trickier.
• isometric camera should not be an issue

For the rest:

• if the arena is a 2d grid, then path finding is very basic and should not be an issue, it is super easy/fast to compute

[Sceat]

• In our case, i'd still like to show the real world or at least enough resemblance so that the player think he is just in a world instance without the other players nor wild creatures, but still see some trees around and the distant LOD, it doesn't have to be the same terrain/rendering, but something similar (even esoteric) should show, so that we feel we're in the world or a parallel reality of this world with potentially different colors/blur/appearance

• the terrain won't be dynamic, just a immutable simplified/checkboard version of the world

• well in our case it's still 3D and use the perspective camera (I didn't manage to have a clean orthographic camera switch because of post processing and other issues, but if you want to give it a try it can be nice), dofus is just an example of how it looks in 2D/3D isometric

• about colored square

  • a continuous blob is better to show the area of where an entity can go, it will also be used in some spells creating glyphs and traps (note that it can be straight without the round corner)
  • colored square with padding will be used for turn interraction to show line of sight of the current player and cells where he can click to move

---

From some tests, here is

• orthographic camera (isometric angle)
  
• perspective camera (45deg angle)
  

[piellardj]

Proposition d'APIs:

Quand la dapp veut créer un plateau de taille maximale (maxRadius) autour de la position de joueur (coords):

• la dapp demande world.getPlateau(coords, maxRadius) qui retourne
  • PlateauId
  • Plateau = grille 2D
  • liste de patchId à invalider

ensuite la dapp demande à l'engine:

• engine.setPlateau(PlateauId, Plateau): l'engine calcule et positionne le mesh du plateau
• engine.deletePatches(liste de patches): on dit à l'engine de supprimer ces patches

ensuite lors des itérations suivantes:

• dans le flow normal d'exécution, on calcule quels patchs devraient être visible, et parmi eux lesquels ne sont pas encore calculés. on voit que les patches précédemment supprimés devraient être calculés, donc on va requêter à nouveau le monde et recalculer les meshes. Le monde va donner la nouvelle version des patches (= creusés pour faire de la place au plateau)

Quand la dapp veut supprimer un plateau, elle fait:

• world.removePlateau(PlateauId)
• engine.removePlateau(PlateauId)
• engine.invalidate(liste de patches)

ensuite lors des itérations suivantes:

• dans le flow normal d'exécution, on calcule quels patchs devraient être visible, et parmi eux lesquels ne sont pas encore calculés. on voit que les patches précédemment supprimés devraient être calculés, donc on va requêter à nouveau le monde et recalculer les meshes. Le monde va donner la nouvelle version des patches (= pas creusés puisqu'on a viré le plateau du world)

Et pour le format de données stockant le plateau:

enum EPlateauSquareType {
    FLAT = 0,
    HOLE = 1,
    OBSTACLE = 2,
}

type PlateauSquare = {
    readonly type: EPlateauSquareType;
    readonly materialId: number;
};

type ColumnId = { readonly x: number; readonly z: number };

type Plateau = {
    readonly id: number;
    readonly size: { readonly x: number; readonly z: number };
    readonly squares: ReadonlyArray<PlateauSquare>;
    readonly origin: THREE.Vector3Like;
};