Hello all,

I am looking for a suitable engine for a 2D game with massive tilemap (up to 20,000x20,000 tiles, each 4x4 pixels) that needs constant updates through a cellular-automata-like system. This might get compute-intensive, so it's good to distribute the load, but I can spread it over time to the certain degree only. (While I could make chunks of the map and update next chunk each frame in a alternating manner, it must be ready for immediate rendering and interaction as a whole.)

I’ve been testing Godot 4 but encountered some limitations:

  • Modifying the TileMapLayer from a thread seems impossible or challenging.
  • The autotile feature requires the entire map to be present, making chunking and loading from the hard drive unfeasible. (If we slice the map, the edges obviously aren't autotiled.)

I imagine similar challenges arise in multiplayer worlds where the tilemap needs constant background updates based on remote instances.

What are my options for achieving this in Godot?
Are there any recommended solutions or design patterns for updating large tilemaps constantly?

(Any examples, documentation, or articles would be very appreciated.)

Thank you for your help in advance! 😊

  • xyz replied to this.

    ppel it must be ready for immediate rendering and interaction as a whole

    What data needs to be stored per tile? How much computing you need to do per tile each frame?

    You may want to separate the cellular data from any visual representation. Use Godot's tilemap only to display the smaller part visible on the screen. Populate it with data periodically as needed, possibly in chunks.

    • ppel replied to this.

        xyz What data needs to be stored per tile? How much computing you need to do per tile each frame?

        Only the tile index in each tile (default setup). The rest of data will regard on-screen tiles only.

        If a game entity affects a tile, the tilemap should:

        • Recalculate the autotiling of neighboring tiles.
        • Modify other tiles based on their type, which can be deduced from the tile index. (around five if statements of my code)

        xyz You may want to separate the cellular data from any visual representation. Use Godot's tilemap only to display the smaller part visible on the screen. Populate it with data periodically as needed, possibly in chunks.

        You mean, storing the world in e.g. ByteArray and use TileMapLayer only as on-screen rendering tool?
        Wouldn’t that require us to clear the TileMapLayer, and populate it with tiles every frame?
        Let's assume a resolution of 1920x1080, 4x magnification and 4x4px tiles, that would give us 120x68 = 8160 tiles on screen.
        Looping through that every fame could be slow.

        • xyz replied to this.

              ppel Every tile changes every frame? What type of game is this? 🙂 In any case updating 8160 tiles is much better that updating 400 millions of tiles.

              • ppel replied to this.

                  xyz

                  Not every tile changes. Most of them usually don't.
                  But if I understand your idea correctly, we have to copy only visible (on-screen) tiles to the display node (TileMapLayer), right?
                  That's still quite much.

                  I'm not convinced, the solution is the way to go. We lose autotiling, collision detection and other TileMapLayer features, for everything off-screen.

                  Are there any recommended solutions or design patterns for that?
                  I'm looking for examples, documentation or articles, if there are such.

                  • xyz replied to this.

                      ppel No, update only the tiles that changed.

                      • ppel replied to this.

                          xyz
                          Isn't that, what the TileMapLayer node supposed to do? Crop the visible part of tilemap data and display it?

                          • xyz replied to this.

                              ppel It does much more than that, so for half a billion tiles you may pay too much of an overhead, performance and storage wise. But you're welcome to try it and se how it goes.

                              With that many tiles you need some kind of space partitioning scheme. Bruteforcing the tilemap is not a very wise approach.