Hi, I’m currently attempting to build out a grid based multiplayer game. So far I’ve only barely dipped my toes into the frontend of the game and have mostly been focused on implementing the logic server side. The general idea is that the client will be very dumb and simply render out state with some interpolation and submit inputs.
I’ve got a few questions about how best to go about this if I were to go with Babylon.js as my frontend, primarily around the map, which I’m flip flopping heavily on based on what is easiest to implement and scale into a full game for a solo side project.
In terms of data, the map is currently represented as a graph/grid with each tile entity having some associated data about it’s base height, type, static entities (e.g. Trees, environment clutter) on it, etc. The player would render out tiles within some radius around themselves and only receive state from the server for that area of interest.
The way that the guides/docs are laid out, Babylon seems to encourage rendering a single large mesh for the ground. Would it be significantly more efficient to have chunks of the map as pre generated meshes, or would it be relatively efficient to render each individual grid tile out as an individual mesh? The latter approach would be sort of like minecraft rendering each tile individually except that I’m not rendering voxels, just flat ground meshes for the floor at 0 elevation and 3D meshes if the elevation difference from the tile next to it is different.
On the assumption that the above may not be feasible or too time consuming to implement well, I’ve also been considering rendering the map as a 2D tilesheet, but I would still want to use 3D character models within the 2D game world. Think Paper Mario, but flipped the other way - 2D world + 3D characters. I’m unclear about whether this is even possible in Babylon. There seem to be a few Unity games like Dead Cells that do something similar, but they’re side-scrollers so their approaches aren’t fully applicable as I want the 3D characters to be able to walk/move along the spritesheet, and I’m not simply rendering a relatively flat 3D world in forced perspective to simulate 2D.
Any general thoughts or comments would be greatly appreciated!
I agree that you could use instances for tiles and manage them via chunks. Then manage game logic on an above layer that tracks the game logic and only finds and manipulates tiles when needed.
I used tilemaps for a phaser CE game that had 256x256 or even 512x512 tilemaps but it was so slow that I needed up blitting the entire tilemap to a single image and using a simple array of ids to track gamelogic and what tiles the user was clicking on.
Ah okay, so the instanced mesh feature lets you spawn vast numbers of identical meshes for (nearly?) free. That is great to know. I think I misunderstood how that worked reading over the docs thinking it probably only optimized it slightly. The idea that rendering 1k square tile meshes will be only mildly more expensive than rendering 1 tile sounds wild to me. I don’t understand how 3D rendering computation works so I’m not understanding how that’s possible given the tiles can be at different points in space, etc. but I guess that is something to read up on later.
That information makes the implementation details a lot simpler for what I’m envisioning. I think I’ll come up with a set of meshes that snap together well and build out the map using that set of meshes like they’re Lego pieces. I’ll probably end up using the Tiled Map Editor to do this manually and just using the json output to render 3D tiles instead of the 2D tiles in the editor.