How to work with a big world? EXTENSIVE QUESTIONS

Newbie & Debugging Questions
#1

I’m using LIBgdx. My game seems to be pretty intensive in the future. Actually I’m interested how to not overload my system?

  1. I’m wondering how many sprites can be drawn simultaneously on the screen? (For a normal computer. I’m having about 15000 right now)
    -Should I care about cheking whether I see a sprite on the screen?
  2. How many objects should I have in my game?
    -Imagine I have a tiled map.
    -Can I have a separate object for every tile? (Now I’m making a list of objects. I have about 15000, but need more for bigger world)
    -Or should I better have some arrays, where every array stands for a certain property of my object?

For Example, let’s take Minecraft. There’s a huge world. Millions of blocks. The world lives all the time around you. Especially when there’s a lot of players.
-How does he draw them?
-How does he update the world?
-How can I make the chunk System?

P.S. Can Eclipse check how much that or that action takes? I understand I can put System.nanoTime(); but in NetBeans there’s a special tool for it.

#2

I believe Notch/Markus/Mr. Perrson uses lwjgl for his rendering.

For “chunks” and how the world is stored, picture the whole world as 2d array of chunk objects. I imagine an initial 1000 x 1000 x 300 (w, h, d guess) chunk is generated with his algorithm for spawn, then an additional chunk is generated for each adjascent chunk surrounding the spawn chunk. Basically, always keep chunks around the player so they can see on the horizon.

Whenever the player would be about to move to an edge chunk (no more chunks in that direction PAST the one you’re about to enter), generate border chunks for THAT chunk.

Any chunks you’ve already had generated that aren’t in your “box” of chunks around you are probably written to a file and dumped from temp memory until you backtrack to those areas again.

I’ve never seen Minecraft’s code, but that’s how I would do it.

#3

I am no expert, but right now I have a game where there are chunks. Each chunk has its own 2d array of blocks, and the chunks are loaded depending on where the player is. I save the chunks in a text file, in the format:

chunk.x.y

It works pretty well for me. Updating them is very easy. When you load a chunk, you put it into an ArrayList, and make a max amount of loaded chunks. If you reach that max amount, you check to see which chunk you can remove, save it, and remove it from the ArrayList. The only problem I have is with optimization…

#4

This behaviour is actually quite easy to see if you install any admin mods that allow you to fly faster than the recommended speed.

Since chunk loading is handled on its own thread, the effect in-game is minmal and mostly unintrusive. However, if you pick a direction and fly very quickly - you’ll eventually start seeing chunks loading on-screen. The division between the chunk areas in this instance is very easy to see.

I may be wrong, but I believe the chunk size in Minecraft is 64x64x256 (1,048,576 blocks). Obviously there are easy ways of graphing this data to be more accessible and quicker to load (since they aren’t 1.04 million unique blocks), but generally speaking that’s still a vast array of data to store - so it should give the OP some idea of the clout possible with modern CPU / rendering techniques.

I do get the impression, however, that the OP needs to be a little more familiar with zoning and other techniques for improving CPU load and render performance. I would never subject a game to 15,000 simultaneous object updates - or in fact 15,000 renderable objects in one pass. You should be using techniquies such as view culling, and zoning out areas where updates shouldn’t be happening (as mentioned by another poster).

This is the best place to ask such questions though, just don’t be afraid to try out some of these things and make mistakes along the way - that’s how we all learn :slight_smile:

#5

You’re wrong. :wink:

Chunks are 16x16x128, but are stored in region files which contain 32x32 chunks each.

Except it just changed, so now chunks are 16x16x16, and there may be up to 16 chunks in each vertical collumn (so the max height is now 256). Which means I have to re-write my map renderer again.

More info on the wiki, if you want: http://www.minecraftwiki.net/wiki/Anvil

#6

I stand corrected! So, the layout is essentially divided into 4 chunk columns (in each region file), and up to 16 chunk slices in each column of 16x16 within that 32 x 32 region. Thinking logically, that’s a better organisational method, since it’d be trivial to view-test the bounding area of a chunk for rendering rather than based on the player’s position. So really, unless you’re looking into an enormous quarry, you’re actually not seeing a whole lot of chunks at runtime.

Anyway, this is veering off the OPs question now, and delving into the intricacies of data management in everyone’s favourite brick builder!

#7

Could you advice culling and zoning tutorials.

Don’t think I’m lazy. I tried to Google it. Mostly I found 3D connected topics.

My question is not so about chunks and Minecraft. But about OO programming. Don’t millions of objects slow up the project? Is it better than having an array or List?

#8

The idea is not to have millions of objects. You split your world up into manageable chunks somehow (like a regular grid minecraft uses) then load and unload only the chunks near the player so you’re only acting on a small portion of your huge world. Loading and unloading should be done on a separate thread so you don’t jam up your main update/drawing thread.

For culling you might want to start with googling quad trees.