#Trying to make a 2D grid-based Sandbox system

9 messages · Page 1 of 1 (latest)

small steeple
#

I'm trying to make a 2D block system similar to terraria or Minecraft. This includes breaking, placing, block updates, etc. There are multiple ways to achieve this but I'm not quite sure the best way to go at it. I'm looking for good performance and scalability. Can anyone help me with making the right decision?

ideas ive tried:

  1. Tilemaps:
    The problem with tile maps is their functionality isn't quite designed for what I'm looking for. Tile maps aren't really designed for this sort of thing. I'm looking to support things like block updates as well. Additionally, adding new blocks and block functionality is redundant and tedious if im using a tilemap.

  2. In-script (gdscript)
    I have a system "working" for this already. Chunks, block data, block ticks, block updates, all working. I can dynamically load and unload chunks of the work. The problem is it is 'duck tape' code which I wrote to try and work around gdscript limitations. Right now, the game is running great, but gdscript may not be fast enough later in development especially since i may be processing hundreds of blocks at once. Also, each block I'm rendering as a separate sprite and I'm not sure how performant this is either.

Ideas I have yet to try:

  1. Plugins
    I don't really know all that much about plugins, but I'm willing to learn them if it means making a better system. I know that plugins are generally more flexible than just using scripts.

  2. C++ Modules:
    Im generally familiar with C++, enough so that I think this is a valid option. I know that C++ is a ton faster than gdscript, and using modules allows me to achieve far more functionality than I ever could with scripts or plugins.

  3. Other ideas?

Any insight on any of these ideas would help a ton.

toxic turtle
small steeple
#

oh, nice, this looks great, ill check it out when I can

toxic turtle
#

Tilemaps aren't really a problem, gdscript performance might become one with large amount of custom block logic but you really need to figure out where the bottlenecks are before you optimize prematurely

small steeple
#

I do notice that frame time spikes a small amount every time a chunk is loaded. Would instancing a lot of sprites in one frame (16, because of 4x4 chunks) cause any performance problems?

toxic turtle
# small steeple I do notice that frame time spikes a small amount every time a chunk is loaded. ...

Usually you would run the chunk generation on a separate thread to avoid any stuttering. I haven't done this in my sandbox because I was to lazy and my chunks are tilemaps, which are a little bit harder to thread.
I simply worked around it by inserting
await get_tree().process_frame once in a while, let's say for every 100 blocks generated. So the whole chunk generation will be spread across multiple frames.
But yes, a lot of instancing can cause these spikes

#

But you should really reconsider using tilemaps. They highly optimized for drawing batches and all the perceived limitations you mentioned are just caused by the wrong approach

#

When you've been through my code you should understand how to set it all up correctly. Ofc if there's anything unclear I'm happy to explain. I barely used any comments, so some of it may be a bit confusing

#

I left a few branches in there from earlier versions so it's also possible to go step-by-step from the earliest least bloated project version, cuz the final one has gotten pretty complex