Hello. I'm new here, maybe this question was already somewhere here and I just can't find it.

I'm creating open world game with huge world and a lot of entities. Now I have some engine created in Game Maker, but I'm thinking about move this to Godot - why not? :)

I need open world engine based in loading chunks and other data depending on area. I know in Godot is function set_sleeping(), but I think it will be not enough for disable real big entities number in my game.

Question - is here some tutorial, sample project or forum thread how to start? I planed to make game in game maker and for 2D (top down) is enough and relative easy for me, but in Godot I can move this project to top down 3D game, deal with open world is same in both situations. Also I have some 3D experiences, so creating nice assets in 3D can be more effective in my case than great sprites for 2D.

About world size, now I can walk more than few hours every direction, so I'm thinking about some really not small world.

Any advices? Thank you!

My advice is to make a smaller game in Godot first - that way, you can get a more accurate and in-depth feel for the engine, before taking on such a big project.

Allow me to regale you with a small story. I first became interested in game development almost 10 years ago, and had dreams of creating a big game, with an open world and online missions and all of that usual "it's gonna be a great game!" talk.

I actually got decently far into making the assets for the game - which, to my then 15-year-old self looked good, but to my 25-year-old-self I would be ashamed to ever publish - but when it came time to put everything together and learn the actual programming, I lost motivation and quickly scrapped the idea. The amount of information I was lacking was so great that even almost a decade later, I still haven't put it together. Also, though, the idea was boring! :smile:

So, my advice is to start small, and make each project focus on something you need to learn - say, for example, make a small game based on random terrain generation. Research what you need to learn, and once you feel comfortable with it, incorporate that into a larger project. Then do the same thing with the next subject you need to learn.

If you go in thinking you're going to create a huge game, you will be disappointed as you realize just how huge of an undertaking it actually is. Pace yourself, and stay confident in your abilities.

I agree, but I can do it everything in Game Maker, means open world game with game mechanism I need. I know, starting it all in new engine is hard and much better is to create something simple, but maybe I will find someone who is more experienced in Gotod or I will work still in Game Maker, where I can finish what I need.

I think about Gotod only because 3d game (however third person top down) can be much more interesting - let's say, and I can create nice 3d world. We'll see .

Thank's for your reply.

Off the top of my head, my first thought would be to have the different parts of the world divided into scenes and load them like a grid. So, have the scene where the play is located plus the surrounding ones. So, if the player moves to the right, the next scene is already loaded and you just have to scroll it, once they reach it, move all scenes along one and add a new one to the end. I don't know if this would create any performance issues or if it's practical, but it's a way to have limitless world.

7 days later

@sionco, I suppose you deal with the unloaded scenes by packing them and saving to file? (so that memory usage is kept to a minimum)

I tried that approach a few weeks ago to make an infinite space universe, and it does work pretty well. Performance-wise it seemed just perfect, as far as I tested it, although I had nothing but empty space and one dummy asteroid per sector (the unit I divided space into (3 * screen_size) ).

The good thing is Godot makes it really easy to save stuff in this way. If you export all the necessary variables and set object ownerships properly, Godot does all the magic (and so you don't need a separate JSON file to store script variables).

There is a caveat that you'll end up with many separate files (one per sector/chunk). I never dealt with this before, so I don't know if that's to be expected. My sectors were big, but if I was making something like minecraft, I'd have a million files in a heartbeat. Still not sure if that would ever be a problem.

I still tried to get around that caveat, by saving the sectors in a single PackedScene, but then, for some reason, they were no longer saving all their children. In fact, they were saving as default sectors with nothing set... However, that allowed me to realize that bundling them like that did hurt performance (the game would hiccup when crossing sector boundaries), and the reason was that I was constantly packing and unpacking and saving and loading that same scene (and, by the way, switching the parent and owner of sectors to and from it).

I went around that by loading it and unpacking it at the start, and packing and saving it at the end, but I don't quite remember if that helped by much (did by a bit at least). However, that meant memory usage would grow as the player would travel. I guess the solution for that would be to divide space further into bigger chunks, which would once more involve creating more files, but still much less than before. So in a more Minecraft-ish type of game, my sectors would be the cells/blocks, and I'd save a bunch of them in a chunk scene.

Since I failed to successfully save the sectors in this way, I never got to implement that solution. But I'm guessing the problem is a mistake of mine and that that would be the way to go.

Sorry for double posting, but on afterthought, it seems to me that one could also use a JSON file to save all the values for each chunk and its cells, instead of saving packed scenes. And then every time you load a chunk or cell, you load a default one, and apply any values that are saved for the cell/chunk at the respective coordinates.

It's not as trivial to save values than packed scenes, but packing and unpacking a whole chunk is likely a more demanding task for the computer. I'm thinking we might get away with saving the values for a higher amount of chunks in one file.

Thank you for all replies. I had solution how to do it in Game Maker and it worked with real big world and a lot of objects to save. I tried few days godot and it looks like a great tool, however it need more experience and time to create something. I moved my game do UE4 engine, where after just few days I can do most of things I need in my game just in blueprints and I think I will stay in UE4 for now.

Maybe a feature to save a whole scene state maybe useful in Godot.

@Facet said: think I will stay in UE4 for now.

It is a good thing to do, to stay where you feel more comfortable. What matters is that you can make your ideas come true. :)

@NeoD said: Maybe a feature to save a whole scene state maybe useful in Godot.

If you pack a scene with PackedScene it will be saved with all the changes you make, including its children (you have to set the parent as their owner with Node.set_owner() for that to happen). If you add a script to it, you need to save the variables you create, but if you export those variables, then the scene will be packed with the current value of those variables. For example:


export var speed = 10

or if you can't give it a value right there,

# export needs to know the type of data you'll store in it
export(int) var speed

Another way of saving the variables is by creating a dictionary with all of them, and then, if I remember correctly, using the Dictionary class to save it to a file. See the saving games section of the docs. You can adapt that knowledge to save individual parts of the game.