Hey HeadClot, I'm more than happy to address those questions:
1. How big is the game world? How big can the game world get?
Its 16km2 - 4km by 4km - at the moment but there is no limit how big it can get thanks to Recursive Search Grid System. I’ll address this below.
2. You mention a grid system. Can you go into detail about this? I am guessing that it is similar to the one that Bethesda Softworks uses in the creation kit.
I’ve never used creation kit, but I’ve heard about this technique a few times from different sources so its safe to assume that its a common technique - no credit there for me 😃
The terrain is created with Blender, exported as .obj. The engine imports it in editor mode, split is with the resolution I choose. Then I end up with a lot of smaller terrain pieces saved as JSON files - I’ll refer to them as Cells from now on. Cells contain mesh data and other preprocessed info that makes rendering and Recursive Search faster.
Recursive Search: Finding a Cell as fast as possible is crucial, the cost could grow exponentially when multiple processes involve searching for Cells. Therefore we don’t want to iterate over all of them, but keep track of the Cell that the Player/NPC is standing on and use that as a starting point. Then we can do a Recursive Search looking at the neighboring Cells and their neighbors. In order to speed up the process, we save the links to the neighboring Cells on every single Cell. I’ve done more optimization of Recursive Search because of extensive use but you might not be interested in that, let me know if you do.
Loading Cells on Demand: the first Cell and the ones around the player loaded as soon as the game starts. When the player starts moving around in the Open World environment mere Cells are loaded when they get in range. Cells drive the loading of every other asset. When a Cell gets processed, the engine collects the other assets - like trees, rock, etc.. - to put them on the loading queue. So we really only load the assets we need and no more, and we load them in a sorted order. Whatever asset is closest to the Player gets loaded first just like Cells.
Dynamically Generated Assets: Grass and clutter use the Grid System as well. The engine only generates dynamic assets for the loaded Cells. They are generated in a different thread to keep the rendering thread smooth and they are not saved in any shape or form.
NPC and AI: NPC needs to be aware of their environment to navigate obstacles and find their prey. Same problem here, we don’t want to iterate over all the NPC we use Recursive Search and Grid System to reduce the number of NPCs to be checked out.
Precomputed Scene Occlusion Culling using a Grid System: Most of the optimization is happening real-time or triggered on a regular basis while running the game with one exception: the Engine keeps an optimized list of all visible Cells recorded on every single Cell in the Grid. This Optimisation is done in the Editor once the terrain is split:
The Engine goes over every single Cell in the Grid and renders them from the point of view of a specific Cell, pick randomly. A Cell is either visible or occluded by some obstacle or just out of range, by looking at it from the randomly picked Cell. The Engine records the visible ones and moves on to the next Cell to do the same occlusion checking. This reduces the number of Cells to be rendered significantly, but it takes about 40 hours to run this optimization for the whole terrain.
Possible Improvements: The Engine only uses one resolution to create the Grid. I can see why multiple resolutions could make the engine run faster. Small Cell means less waste. We may only see a fraction of the Cell still precess the everything in it. The engine could use a small resolution to work out what Cell needs to be checked out then a higher resolution could work only with those few Cells to work out the labor-intensive details.
3. In regards to rendering why don't you use an existing engine such as bablyon.JS?
Before I’ve started the project, I've checked out the available games for the web, and I wasn’t impressed. I thought there must be a reason why they all look so simple. I’ve noticed that Unity can compile to JS, but it had to load all the game assets in advanced. It took to long to start up a game, and its an obvious limit on how many assets you can include in a game. I come from a strong JS background so I thought, I will investigate the performance of whats involved to make a game run in the Browser ..a year and a half later I’ve ended up with Age of Reptiles
Any off the shelf solution comes with tradeoffs. Fast to start, slow to finish when you start hitting those obstacles... I wouldn’t recommend writing an engine because it takes forever, but I ended up with one because I was curious and enjoyed the process.
There is an upside though to write your own engine: you can optimize it for what is most important for you. My focus was to load assets progressively, to make Large Scale Open World environment possible in the Browser.
If you guys have any other questions, I'm more than happy to go into details.