• 3D

  • How big can you make an open-world game in Godot?

I was wondering if anybody knows how much Godot can handle the size you get when making an open-world like Minecraft, Far Cry, or Fallout 4.

Depends on how you design it. Could be infinite if designed for it utilizing some methods for loading chunks dynamically. In theory anyways.

Open world game is such a broad topic. I'm making a game that has destructible terrain and that requires chunks, for example. Lots of chunks so that I can perform updates to the terrain relatively quickly. So if I made a map that was very large I suspect I'd run into issues with the number of separate meshes that I'm trying to manage. That's one possible limitation.

But there's thousands different things that could become a performance problem depending on what type of game it is and how you are building it. You cannot expect a game engine to be good at handling anything you throw at it, that wouldn't be fair.

I haven't been having trouble with game performance in godot so far, but I haven't tried to build Far Cry or Fallout 4 with it. :)

7 days later

Like you, I wish to make an open world style game one day and I have decided to use Godot for now as I believe it will let me get there. That being said, I am fairly new to 3D game development so take this advice with a grain of salt.

Godot can handle an open world game as much as any other "AAA" engine. The difference is how much work its going to take on your part to do it. When creating a huge game map like in Fallout 4, there are a couple of things that you will have to handle.

Memory Management The first thing is memory management. When you load a huge map in a game, no engine can handle all the stuff that something like Fallout 4 has all at once. For instance, if you're in Sanctuary, the game is not loading any objects from downtown Boston into memory. Instead, it's only loading some of the surrounding areas(I believe Bethesda's engine calls them "cells"). When you get close to Boston, it unloads the cells around Sanctuary and starts loading the cells around the part of Boston that you're entering.

When you create an "Open World" style game you will have to do something similar. Other game engines have code and Assets to help quickly handle that. Godot does not(at least, not yet).

Floating Point Precision Another consideration is what's called the "floating point precision" problem. Without getting into the math of computer graphics, the basic gist is, the further away your objects are from the point of origin, Vector(0.0, 0.0, 0.0), the less precise your object drawing is going to be and your player will start seeing your objects clipping and drawing weirdly.

Again, other "AAA" game engines have a built-in way (or something in their Asset Store) that helps you handle this. Basically, it's a piece of code that resets your origin point after your player moves a certain distance away from it. With Godot, you'll have to write something that does this.

Conclusion So can Godot do it? Yes. But you'll have to keep those two things(and possibly other challenges that I don't' know about) in mind.

You might ask, "Why, if other engines do it 'automatically', would I go with Godot?". I can't speak for your situation, but I have 2 reasons: 1. The other engines might have an "auto-magical" way of dealing with those two issues, but If those solutions don't work the EXACT way I want them too, I'm stuck writing my own method from scratch anyways. 2. Godot is so fast and easy to use, I'm confident that I'll be able to write the code to handle those cases in just the way I'll want to when I cross that bridge.

As far as open worlds go in a nutshell, the total amount of logic and detail that the engine can handle without slowing down will be the most limiting factors.

Otherwise, Godot worlds can extend as far as floating point accuracy allows, though for absolutely massive worlds we don't yet have some helper features like movable origins for worlds.