I agree, also thanks for sharing your reasoning on the previous comment, we can always tinker and change things later based on new stuff we learn from other people as well, no solution is final per say,
first I want to say that I'm loving these videos, most terrain videos I found are about procedural generation and almost none of them cover using a region system. I'm starting on an open world survival and this is very close to I wanted to achieve, are you going to cover saving/updating region data? I'm trying to figure out a chunk system to save and load data as the character moves around the world, keeping it persistent (like dropped items, animals positions and state, etc) keep up the good work!
New video is going to cover some basic ideas of keeping track of objects in a region, but they are very primitive and atm dynamic, not persistent, if you want persistent you will need to combine a save / load system with the File class from Godot to save and load objects into your world, you could implement your own system with just basic information or use Godot own way of saving data from nodes to files, there is a lot of videos about saving systems for Godot, thought possibly I will visit that idea to allow saving the game in this RTS project, so I should be dealing with some system for persistent data, but it isn't that hard to achieve what you want.
@@nanotechgamedev thanks for the reply! I have another question if you dont mind, I've seen people using multimeshes for performance, are those interactable? or mostly used for decoration like rendering grass? anyway, thanks again and I'm looking forward for your next videos
I don't know what you are defining as interactable, I will assume you want to apply modifications to the multimeshs like individual materials or different meshs, multimeshs have some attributes that can be edited but mostly are position, rotation, scale and maybe instance shader properties (haven't tested), also you could make multimeshs to be only the visual part of your world, and place collision mesh on top, the part that is interacting with your character and collision systems is going to be the collision mesh, giving illusion of iteracting with the multimeshs, Multimeshes are made to be statically rendered together, because they are used to reduce drawcalls by combining instances of the same mesh together to be rendered by the gpu in a single drawcall, almost like combining objects in blender, but all objects are instances of one another, no object is different than another by their mesh content, that is why people use it with grass, because it's basically the same grass mesh repeated over the entire map, rotated and scalled differently with some shader code on top to make it look nice or to be interactable by the player through global shader parameters, Now technically you can interact with multimeshs like iterating over them to do something, but it's not advisable because you will start to break what they are suppose to do, be combined and left alone to be rendered by the gpu together, once you start to "interact" or edit them individually, you are passing work from the GPU to the CPU, which was why you wanted to use multimesh in the first place, to avoid that. I plan to make a video about making decoration props for maps, but this will require some Godot post-import script to build multimeshs from Blender objects with the same name, I have already worked a concept proof for a open world project test and it worked nicely, Fundamentally it's almost the same if you combine instances in Blender, just more perfomant inside Godot if you need less draw calls,
Godot is a game engine, you can make any game with it, including an RTS game. So yes, everything can be done in godot including damage calculations. What you can't do in Godot is making assets for your game like sounds, textures, 3D models ... etc.
Good video btw, my nitpicking only apply to an ideal case, as long as you finish that's good, done is better than perfect 👌
I agree, also thanks for sharing your reasoning on the previous comment, we can always tinker and change things later based on new stuff we learn from other people as well, no solution is final per say,
first I want to say that I'm loving these videos, most terrain videos I found are about procedural generation and almost none of them cover using a region system. I'm starting on an open world survival and this is very close to I wanted to achieve, are you going to cover saving/updating region data? I'm trying to figure out a chunk system to save and load data as the character moves around the world, keeping it persistent (like dropped items, animals positions and state, etc) keep up the good work!
New video is going to cover some basic ideas of keeping track of objects in a region, but they are very primitive and atm dynamic, not persistent, if you want persistent you will need to combine a save / load system with the File class from Godot to save and load objects into your world, you could implement your own system with just basic information or use Godot own way of saving data from nodes to files, there is a lot of videos about saving systems for Godot, thought possibly I will visit that idea to allow saving the game in this RTS project, so I should be dealing with some system for persistent data, but it isn't that hard to achieve what you want.
@@nanotechgamedev thanks for the reply! I have another question if you dont mind, I've seen people using multimeshes for performance, are those interactable? or mostly used for decoration like rendering grass? anyway, thanks again and I'm looking forward for your next videos
I don't know what you are defining as interactable, I will assume you want to apply modifications to the multimeshs like individual materials or different meshs, multimeshs have some attributes that can be edited but mostly are position, rotation, scale and maybe instance shader properties (haven't tested), also you could make multimeshs to be only the visual part of your world, and place collision mesh on top, the part that is interacting with your character and collision systems is going to be the collision mesh, giving illusion of iteracting with the multimeshs,
Multimeshes are made to be statically rendered together, because they are used to reduce drawcalls by combining instances of the same mesh together to be rendered by the gpu in a single drawcall, almost like combining objects in blender, but all objects are instances of one another, no object is different than another by their mesh content, that is why people use it with grass, because it's basically the same grass mesh repeated over the entire map, rotated and scalled differently with some shader code on top to make it look nice or to be interactable by the player through global shader parameters,
Now technically you can interact with multimeshs like iterating over them to do something, but it's not advisable because you will start to break what they are suppose to do, be combined and left alone to be rendered by the gpu together, once you start to "interact" or edit them individually, you are passing work from the GPU to the CPU, which was why you wanted to use multimesh in the first place, to avoid that.
I plan to make a video about making decoration props for maps, but this will require some Godot post-import script to build multimeshs from Blender objects with the same name, I have already worked a concept proof for a open world project test and it worked nicely,
Fundamentally it's almost the same if you combine instances in Blender, just more perfomant inside Godot if you need less draw calls,
Im very very new to game dev. How does one build an engine for an rts? or everything can be done in the godot? like dmg calculations and so on.
Godot is a game engine, you can make any game with it, including an RTS game. So yes, everything can be done in godot including damage calculations. What you can't do in Godot is making assets for your game like sounds, textures, 3D models ... etc.