I touched on this previously, but I wanted to go a little deeper.

Is there a way to implement an open world concept in Godot? I gather that it isn't built-in. From what I understand, you basically set different parts of the main world into various nodes and spawn them as the player gets in range with them, and deactivate them when the player distances itself from them, correct?

This, however, may trigger some unwanted side-effects.

Ie, how does one spawn enemies in said open world so it doesn't completely wreck the engine? I might have up to 100 enemies or more that need to spawn if the world wasn't open-world, but I also need the already- spawned ones to continue to chase the player after leaving that chunk of the world. And I'm not even talking about the enemy hordes that come every ten minutes.

Same can go with the trees, as each tree goes through stages per game day. In theory, I could spawn the trees to only appear when the player reaches that part of the game, but upon returning to the previous area, the trees might already have turned dead and rotted.

Here's a quick view of all the trees before the game goes open-world, so you can get an idea of what I'm talking about with them. They are currently black, as they are to mimic the colors of the "Sky" when the sun goes up and down, without being effected by the light2D on the lantern and flashlight.

The same will also go for the different collision layers in the game. in this world, there will only be 2 of them- plus whatever floors you add to your base. As I mentioned, this gets a bit complex.

In the second world- not in the free demo- there will be at least 3 collision layers.

For better understanding, this world is going to have a few different "biomes"- the sandy biome, which has mostly a lot of trash and a few scattered trees; the green biome, which has far more trees- especially if the biome is near water- and the final one, not yet seen, is the gray biome. This gray area, the caves, are on the next collision layer. When you go through the cave, the rest of the map goes dark and the collision layer/ items being spawned changes to mostly rock, with no trees growing. I don't want to use another scene, as I still want the zombies/beasts/monsters down there to keep chasing the player after they enter/leave.

Okay, I think the biggest point I feel I have to make is that in most cases the concept of an open world is a bit of a marketing lie but don't take this as me trying to slap you around it's just people generally have a misconception of how open worlds are actually constructed in code. Even the biggest projects you'll have heard of like GTA IV and Fallout 4 which have made millions or even billions on the premise of open world frequently use all kinds of rendering tricky and effects to faked loading screens to try and trick players into thinking there aren't any.

If you get a dev claiming that there aren't any loading screens, I feel quite comfortable calling them a liar. Or rather, they might be obfuscating what a loading screen actually is in order to sell their game. All games no matter what size they are have some degree of data loading going on in the background, because if you actually tried loading up everything at once and having a real open world game a lot of PCs would just crash on the spot. This is where all these techniques like frustrum culling and cell based loading come in which make the player feel like they're going through an open world without any loading times. Another load of common dirty tricks big game devs use is when you're in an elevator like in Fallout 4 for example that's actually a loading screen and then there are other games in Dying Light 2 that have your character shimmying through narrow passageways etc. and do the loading of the next area during that.

I would argue that yes, these are all capable of being implemented within Godot and from the looks of things it seems somebody has already implemented but you need to have a proper understanding of what you're trying to implement first before even touching an open world type project.

Even games like minecraft by the way make use of frustrum culling and LOD to help with performance and the biomes generated are absolutely huge. I just thought I'd post this video up to help you as well since you were asking about Godot implementations specifically.

Thank you. My biggest issue is that the old game engine I used "technically" did all this out of the box. It pre-calculated the game based on the distance you want players to see up to, and it will generate everything to that point. It resulted in tree-popping and other minor bugs, if the distance wasn't far enough.

And yes, Fallout 4 is actually full of loading screens. You can still tell, however, where all the chunks are as the game breaks about every time you land on one (assuming you had my experience with it, lol).

The origin of my game- the reason for coming up with the idea-is actually smaller than even Minecraft. It was a relatively small open world, with one other "scene", I guess, but the game was too busted to make much progress with it. The game I'm talking about is Dead Town. I still miss it.

https://apkpure.com/dead-town-zombie-survival/com.lemonpuppy.deadtown

Well this is one of the great and frustrating things about working from scratch in an engine, much of what you want to do is possible generally, you just need to have a proper grasp of the scale of what you're trying to work on.

Dead Town was a fairly easy one by way of mechanics. Items spawn, enemies spawn a distance from the player, the player uses items to make weapons and craft structures, and you get hordes at night. It should be simple to replicate and add new features to the game concept, once the open world concept is finished

I love the challenge, though. If I didn't, I would've left game developing years ago.

As for open-world, I'm more concerned about optimization and overloading the engine with a ton of nodes. As you progress, more zombies appear.

Might want to look at multi-threading code in that case which will help, at the end of the day though, what you describe is something that every programmer has to deal with right from the beginning. You also have to accept depending on how out there it is that your idea might not be possible to implement with current technology or it may be only really high end systems that can handle it. If you're looking to spawn 1000 zombies on the screen at once for example all with their own hitboxes and animations even pretty high end systems will struggle.

I will definitely check multi-threading. However, I doubt the game I'm working on is high-end. Dead Town was a mobile app made with Unity.

For the zombies, a few other methods that came to mind.

One was to have the area that the player enters check how many zombies are already chasing the player. If it's more than whatever, don't spawn any, or make sure there are always no more than X in that area at a time. Once those zombies are gone, spawn that amount in nearby areas that the player hasn't already visited recently.

Or, alternatively, what else I could try is have the enemies always spawn somewhere near the player, though not completely on top of it. In this manner, if you kill one zombie, another one spawns nearby in a place you haven't visited recently.

The trees may just have to not spawn until the player "discovers" them (enters their chunk of the world).

That's exactly the right sort of thinking for this type of project, definitely put hard limits on the zombies, alternatively as part of optimisation what you could do is create a slider that players can choose themselves. That way if somebody has some ridiculous high end rig with a threadripper and a 3090 they can tweak things how they like and then someone else doesn't have to suffer if they've got a low end rig.

Another nice feature to increase difficulty is bosses, sort of like how you can swap soldiers for better units in Risk. Ie, boss 1 would have the damage and health of 5 zombies, another one could have the equivalent of 10, 25, and so on. Simply resizing the sombies and changing their colors, and editing their damage, should be pretty efficient.

I have recommended this video a few times, in your case I'd watch it just to check out how the different threads work.

This video will help me especially for the next world. Thanks!

I was also considering an XP system, like have the enemies have randomized base stats and at various skill levels based on difficulty, time elapsed, and whether the zombie is a boss.

Say, for starters, you won't have any bosses, and zombies range from level 0-3, and they increase minimum and maximum level each day. At around day 3 or so, level 5 is unlocked, which means a boss is unlocked- say, the irradiated zombie, or the fire zombie, or whatever.

For randomised stats like that you would setup a scene in your assets folder and have the stats generate on start when you add the fresh scene in your main scene.

Correct. In case anyone reads this for ideas for coding...

That part of it should be simple. I've done something similar to randomize the items that spawn in-game.

var junk_list = [preload("res://StickCollect.tscn"),preload("res://StoneCollect.tscn")]

func _ready():
	randomize()
	item_number = rand_range(100, 200)
	spawn_junk()

func spawn_junk():
	for items in item_number:
		var child = junk_list[int(randi()%junk_list.size()+0)].instance()
		add_child(child)
		move_to(child)

It's a lot of nodes already, but at least all of these are simply a bunch of area2Ds that don't move. They are only removed once the player collects them, and the rest are removed and respawned each game-day. Like the zombies, I will more than likely make sure they spawn around the player, rather than random numbers, in the real game, and simply shrink the amount, then, when the game-day is over, I would re-spawn them while the player won't see it happening.

Zombies are also easy. What I did was put all the zombies in the "zombie" group, and then what I'd do to randomize stats, I would edit the spawn_zombie code so it would randomize stats for each one using a for loop.

func spawn_zombies():
	for z in zombie_count:
		var zombie_basic = Zombie_Basic.instance()
		add_child(zombie_basic)
		var x_range = Vector2(-3000, 3000)
		var y_range = Vector2(-3000, 3000)
		var random_x = randi() % int(x_range[1]- x_range[0]) + 1 + x_range[0] 
		var random_y =  randi() % int(y_range[1]-y_range[0]) + 1 + y_range[0]
		var random_pos = Vector2(random_x, random_y)
		zombie_basic.position=random_pos

Sorry, I had a teacher who basically showed me how to do a lot of things that no one else would've taught me- and now I sort of want to help beginners get out of the pit I was once in. :)