5
\$\begingroup\$

I'm working on a 2D minecraft-like game, I use chunks to save my world and each chunk has 128*128 blocks in it. And infinite chunks can create an infinite world.

Memory should never be infinite and only several chunks near the character are shown on the screen and loaded into memory. How can I handle logic based blocks like red stone signals when they are in chunks far away and so not loaded in memory?

\$\endgroup\$
3
  • \$\begingroup\$ FYI, Minecraft doesn't do this. Far-away circuits will stop running. If a circuit crosses the edge of the loaded area, it can be hard to predict what happens. \$\endgroup\$ Commented Jul 30, 2014 at 2:13
  • \$\begingroup\$ Thank you FYI. If minecraft doesn't do this, I wanna to know is there any interesting algorithm can implement this function \$\endgroup\$
    – warmwine
    Commented Jul 30, 2014 at 3:07
  • \$\begingroup\$ It's impossible without loading the chunks into memory. If you use delta time it's possible to simulate the chunk loads of times to make up for all the time it hasn't been ticking, but that's likely to put a lot of strain on your CPU if there's a lot of updating to do. If you're unsure what delta time is, there's a half-decent article here: gameprogrammingtutorials.blogspot.co.uk/2010/01/… \$\endgroup\$
    – Pharap
    Commented Jul 30, 2014 at 10:23

5 Answers 5

16
\$\begingroup\$

What you need to do is separate terrain from live blocks. For example you could store the live blocks in a dictionary that uses a point as key. And then unload the terrain. This way your live blocks stay in memory in a way you see fit, and you can still look them up based on position, but the terrain is stored on disk for later retrieval.

This will increase memory a bit, but you can't avoid it entirely.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Alternatively, you could have the circuits refresh themselves when adjacent chunks are loaded in, which could potentially result in some circuits glitching based on how large / how you load your chunks in. Considering you have an infinite world, it might be acceptable, or even not noticeable. \$\endgroup\$
    – jgallant
    Commented Jul 29, 2014 at 12:05
  • \$\begingroup\$ The approach would work. As data structure, I could also think of a linked graph which represents the wire connections. Therefore, I'd be easy to find connected components for simulating. \$\endgroup\$
    – danijar
    Commented Aug 22, 2014 at 19:14
5
\$\begingroup\$

In Minecraft, circuits in unloaded chunks simply do not work. Especially with pistons and other ways of interacting with the environment, it could get expensive quickly to keep far-away circuits running in an infinite world.

I see three main possible choices for your game:

  • Keep all chunks loaded. This is just a big nope.
  • Keep nearby chunks loaded. For chunks too far away, save the state of the chunk. When coming close to the chunk, load the state again.
    • This means that the circuit will continue where it left off. Complex circuits won't break this way.
    • On the downside, the circuit won't run when the player is too far, though this is generally acceptable.
  • Store active components separately. For chunks too far away, unload the terrain data but keep circuitry active.
    • This will cause things such as sensors, timers, etc... working all the time.
    • Bigger resource hit. An infinite world means possibly infinite circuits constantly running.
    • This would only work if circuits cannot interact with the terrain, or if they can only interact with the terrain within proximity of the player.

Of course there may be other ways to work around this, but those are likely going to be some form of hybrid between these ideas.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks, I learned a lot from your answer in this thread. At the beginning , I think don't handle these is the easiest choice. And some form of hybrid between these ideas should be implemented in the later version. \$\endgroup\$
    – warmwine
    Commented Jul 30, 2014 at 3:18
4
\$\begingroup\$

Tekkit (a popular minecraft mod) does this by allowing players to build anchors that keep a few blocks around them in memory regardless of player proximity.

It might be a good choice if there is clear distinction between dynamic blocks that require the presence of the player (an automatic door) and others that don't (a generator of some sort).

http://tekkitclassic.wikia.com/wiki/World_Anchor

\$\endgroup\$
1
  • \$\begingroup\$ +1 for suggesting a solution that lets the player decide. Keep in mind though that world anchors in Tekkit have a reputation for causing latency and framerate issues for both the server and the clients, especially if the process that it keeps loaded is one with long duration and/or complexity, like automated resource gathering or building. \$\endgroup\$
    – Nzall
    Commented Jul 30, 2014 at 13:24
0
\$\begingroup\$

Just an idea on a way to handle this without it bogging the game down too much.

What you could do instead is enforce a game mechanic that only runs that "redstone block" when it is connected to some sort of rare or hard to craft "Power" block, suggesting that the presence of the player powers the "redstone" and is required to run it.

I believe that how it actually works is dependent on what your "redstone" does. Does it physically move the block and do you handle moving blocks in unloaded chunks? What if it throws TNT into 10 chunks away, how would the "redstone" handle that?

I believe that to get a serious suggestion on a particular issue the question about the logic will have to be more specific.

\$\endgroup\$
0
\$\begingroup\$

I will just focus on just one topic in this answer: If you want to unload distant circuits to save CPU time and/or memory, what will happen to complex circuits that spred across multiple chunks?

  1. Igore this problem. Easy to implement, but unsatisfactional behaviour.
  2. Let player be aware of this problem, and give him a tool to display chunk bounds. I think there was such item in one of Minecraft's mods. Player then can build circuits only on one chunk if he needs to.
  3. Create some connective block, when placed, it will guarantee that all circuits in a set redius will be always loaded/unloaded at the same time. Assuming that radius is smaller than chunk size, one such block will connect maximally 4 chunks together. However overusing these blocks can lead to infinitely many connected chunks.
  4. In Tekkit mod, there was World Anchor block, that kept surrounding chunks loaded all the time. Good choice if you want to have some machinery running away from player.

Summary: Depends on what you need, I wouldn't be afraid of combining 2, 3 or 4 (or all) together, you can also nerf 3 to connect maximally N chunks.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .