Minecraft Forums

Hello God_Kra!

If you're still looking, I have just started a new series dedicated to teaching programming using Java in a slightly different way than most do! If you have any questions, throw a comment in one of the videos (I don't check my messages on here too too often).

Name? Tyler[/i]
In Game Name? CoderTheTyler[/i]
Age? Older than 18[/i]
Country? USA[/i]
Favorite Aspect of Online Play? Sharing interesting and amazing creations with others[/i]
Lease Favorite Aspect of Online Play? Griefing, stealing, and people who can't help but spam the chat bar[/i]
Were You Referred By An Existing Apollo Player? No, just happened across the thread in search of a relaxed, mature server[/i]

I also dislike servers that will ban indiscriminately and without sufficient reason. I have been on more than enough servers where I have been perma-banned simply for accidentally breaking a block then trying to fix it. It becomes absolutely ridiculous after awhile. If that doesn't happen here, I would be honored to be able to join the community for some good fun.

Thanks!

Try walking backwards or to the sides. Do not press W. If the problem does not occur with those directions of movement, it is your keyboard as @Techy4198 suggested. Try using another keyboard and ensure the contacts in the USB port are clear of any debri.

Quote from Freedomna»

You are complaining about a map 8x bigger than the entire planet Earth?

As people said it is a memory problem, and 8x the size of the Earth (cannot stress that enough) is more than enough for survival.

Quote from Talco»

Isn't 30 million from spawn good enough for you?

He isn't complaining about it. He is curious to know why is it that way. Read the initial post before commenting.

Quote from Bjossi»

I keep in mind who actually asked the initial question, it is a person who most likely is not well versed on this subject, and floating points are generally far more difficult to comprehend than integers, so to introduce the concept of how hardware limitations can lead to math errors I went with integers.

You make a good point, but he also wants to know the technical side of things. And I quote:

Quote from Alexcamostyle »

That makes sense. I was wondering what the technical side to it was. Thanks!

So let the complicated technical side of things floweth forth!

Quote from BC_Programming»

It is mainly a consequence of OpenGL using float values. I'm pretty sure Java doesn't come into it, since the same issue would appear regardless of the programming language chosen if implemented in a similar manner.

Sorry, I didn't mean to throw it on Java. My point was that OpenGL is strictly a rendering API. As a consequence, the only things affected by this would be rendering. Minecraft uses Java primitive types to do all of its calculations, and OpenGL, as far as I know, is simply the means by which all of those coordinates are translated into what we see on screen. Problems like the world not moving due to loss of precision (which I've come across in my own games) are a direct consequence of the game engine itself and not the rendering API. Of course, there are problems which could be encountered using OpenGL with floating point precision which I've also run into in my ventures. These are mainly solved by simply avoiding sending large numbers to the GPU by rendering all aspects of the game world relative to the player (like in my Kerbal Space Program example). Using this may still lead to rendering issues, but they are again restricted to the floating point precision of the game engine itself and not the rendering API. I hope I understood you correctly... :D. And yes, these problems occur across all programming languages. This is what I meant, but I failed to communicate that clearly when I went on to talk about how it could be traced deeper to the JVM and beyond. My bad.

Quote from BC_Programming»

Regarding terrain gen, that's something that could be solved in the game- or at least partially solved, come to think of it, since the implementation of terrain gen is purely within Minecraft and not dependent on any external API such as OpenGL that limits data types. So, feasibly, it could use double- or even scaled integer values in some fashion. double would at least allow it to work for much larger values without losing as much precision. I wouldn't want to try to play a version of the game that tried to avoid the problem altogether and used BigDecimal, though.

While it would be interesting to see an engine using BigDecimal, it would also be terrifying as all *expletive kinda*. Imagine all of those Strings... so immutable, so cold...

Quote from Bjossi»

I had thought of that possibility myself (storing changes instead of the state itself), though everything has its drawbacks: you would always need to generate the terrain and then apply the changes that were stored for the relevant chunks regardless of you having visited the area before. This approach sacrifices computation for disk space, pretty much, and could have performance implications for some machines.

You are right about having some performance implications. This has a few fixes. The first would be to change the terrain generation algorithms they're using. At the moment, they are using an incredible amount of overhead simply trying to make the terrain *be* more realistic. They have oceans which span for kilometers on end, beautiful transitions between biomes (for the most part these days), and complex cave systems running throughout the map. This is my first piece of advice: simplify the terrain generation algorithm. I know of plenty of Minecraft clones which have all but perfected terrain generation and made it faster. This really isn't an issue, but we don't seem to have anyone who has actually studied procedural generation to every end. If there is one of those on the Mojang team, I would be a bit disappointed with the job they've done. That's not to say I don't feel they have built a terrain generation algorithm worthy of praise (because they have), but it isn't professionally optimized. That needs to happen (and they've done quite a bit of it lately from what I've read/heard).

My second beef with their terrain system is their choice of chunk formatting. They use 16x16x256 chunks. Why. They take long enough already to load, so why did we double their height and not simply double the number of chunks? Seriously, cut the chunks vertically as well as horizontally. I believe there was a mod which did this (very, very inefficiently might I add) which allowed infinite world height (or at least a few kilometers). That is the idea behind what I want. Split the chunks vertically so we don't have to load every single cave, monster, etc when we have no intention of even visiting them! From experience, I can say that terrain generation is by no means more complicated if more subdivisions of the terrain are done. Granted, it would take some finagling to change the game so it actually used this sort of system. But I digress.

I can't remember what my third point about terrain generation was, but when I remember it, I'll use it to bolster this wall of text further :D.

Quote from Bjossi»

Also, what would you do about passive mobs? Some kind of logic that determines which mobs are of interest to the player (persistent) and which ones can be just thrown away once the chunk is unloaded (generated on the fly)?

I don't understand what the problem is here. This is already done by Minecraft anyway. I can see where you're coming from though. It would take a lot of memory to store all of those passive mobs while moving half the speed of light across the terrain. You'd be correct again in saying that. If that is what you mean, then I can say this also isn't an issue. We again need to rehash how we are thinking about this whole ordeal. I'll revisit the idea of how the player perceives the game world over the nitty-gritty mechanics of it. Because no one cares *how* it works, just that it works. The simplest solution, albeit a bit asinine in itself, would be to simply wait a few seconds until terrain generation is completed to spawn in the mobs. I believe this is how this works anyhow. That solves the problem of people moving extremely quickly across large parts of the terrain. The next, more pertinent problem is how we deal with someone casually strolling across terrain for days on end. My question would then be, have you ever simply walked in one direction without end to go on a simple adventure? I've encountered hundreds of passive mobs on my way which were no doubt saved, but I will most definitely, without a doubt never see them again. Or I'll at least never remember them when I happen across that area again. Therefore, I would propose an algorithm which stored passive mobs but removed them after a given period of time. This would then lead to the argument of "I left my base for a month now they are all gone!". I'll concede that then. A better solution (if you don't like that one) would be to simply change the way passive mobs are dealt with. Don't have them persist. Instead, get rid of them and only save them once the player has interacted with them. This interaction could be anything from having them follow the player once they whip out some wheat, meat, etc or to attacking them. This would reduce hard drive space greatly and would create only minimal noticeable abnormalities in the world behavior.

So those are my propositions. I've only implemented a few in practice, so feel free to bash me and/or disagree with my points.

Quote from Bjossi»

The maximum size of a Minecraft world in any given cardinal direction could be much larger than 30 million, but not infinite, we need computers with infinite resources for that.

While it is true the world cannot be infinite, it can be psuedo-infinite. As a game designer, all you care about is the gameplay and how the player will perceive the world. All we need to do is throw a few clever tricks in the pipeline to make everything work, and no one (the player) will never notice the difference. In this case, the mere ability to travel in one (or all) direction(s) as long as you want at whatever speed is the goal. That is not impossible to achieve. While it is true that even if you removed the barriers of the precision of number (which I detailed in my response above), the only real issue would be storing the world data on the hard drive. This isn't even difficult when you think about it. The way Minecraft stores data is terribly inefficient as it is. Why not store all the *changes* made to the world in file instead of storing every single block ever loaded? It is asinine to try and save every single block. That is part of the reason many people complain about how Minecraft is programmed. Not much thought was put into the way the world is set up to maximize performance, overhead, and memory usage. If we were to remove this roadblock of hard drive memory then, the world IS infinite. We can now travel in one (or all) direction(s) *literally* forever. This sort of thing would be a bit of a pain to implement now that Minecraft is so far along, but it is by no means impossible.

Your answer is correct, BC_Programming. The only thing I would add to your explanation is that the limitation is not simply on OpenGL by itself but mainly as a consequence of Java. If you really want to get technical, it isn't even Java's fault, it is the underlying JVM which is built to specify the number of bytes each primitive data type can use (even further if you say how many can be processed by the floating point calculator on most computers). OpenGL is primarily a 2D and 3D rendering API which simply gets chummy with your graphics card instead of having to go the Java AWT or Swing route of doing many of the graphics calculations on the CPU (if I understand that part correctly). Anyway, yes, it is about precision. Great answer!

EDIT:
And yes, it would be an extraordinary pain in the Minecraft donkey to get around this inherent limitation of data types. It may not be as hard as initially thought, though. The simplest way it could be done is the same way Kerbal Space Program does it (or used to do it, I don't know if they changed it). When you move sufficiently far from the origin of the map, the entire world shifts so that your new position is the new "origin" of the map at (0, 0) or however it is defined in your game. All that needs to be stored is how many times this frameshift of sorts has been carried out and in what direction and everything else follows suit. OpenGL rendering issues are the first things solved with this system. Everything is simply rendered in relation to either the new origin or the player (whichever is preferred). Terrain generation is a bit more tricky with any sort of fix like this. No matter how it is done, large numbers still need to come into play if terrain generation is to be kept smooth and continuous, especially with generation algorithms such as Perlin Noise. In any case, it would be an interesting theoretical data structure which might have some perks and some drawback but would most definitely be intellectually challenging to pursue (for some, anyway).

And that is my rant for the day.

How far behind it does it trail? There is some natural latency on most computers

Quote from Ham62

Intel Core 2 Quad processor @ 2.4 GHz, and 2GB DDR1 RAM. Oops! I left Google Chrome running in the background when I tested it! I tried it again, and it was only at 4-8% CPU usage and the RAM went down to 34%. Of course it's always at 32% RAM anyway, so it's pretty good.

Could you make a main class file for your game for Java 6 to read, that points it to your other files, or does it not work like that? I don't know anything about Java programming personally, It was just an Idea.

Good game engine though. After 5 minutes of holding down "W" and "D", you game gave up at drawing the top and left sides, and the player was almost falling off the map. Just thought I'd tell you.

Yeah, when you guy that fast you start to catch up with the chunk loading. You won't be going anyone near that speed in any game built off this engine though lol. And I could make it Java 6 compatible. I would just have to rebuild the project using the Java 6 JDK. Let me try that... Thanks for all the info though and the correction of the data, it helps quite a lot.

Quote from BKrenz

I managed to catch the Chunk loading on my machine.

RAM usage stayed constant.

Sweet! Thank you for that last bit

Quote from Ham62

Too bad it only runs in Java 7. I was going to test it on my PC(s), but it only has Java 6. The Java 6 engine said:

"Could not find the main class. Program will exit."

On my dad's PC, it worked smoothly, but the RAM stayed at a constant 67% usage, and ~28% CPU usage.

The RAM stayed at 67% usage? Oh my... and 28% CPU? What kind of PC is it? And yeah, Java 6 will do that.

Quote from user_2115487

Worked fine on Windows 7 64 bit.

Thank you sir! Mind doing some stress testing?

I've been working on a little Java program which will eventually be a little dungeon crawler RPG, but I just need a few people to test to see if the basic rendering components are working and in order (I'm using my own polygon filling stuff, etc). I also want to see if it isn't terribly under-performing on other computer builds.Only working on Windows to my knowledge. If any Mac users out there want to try, be my guest (but it likely won't work).Here are the pix and the clix.And if it does/doesn't work nicely, just make a post below with your operating system and what's wrong/right. I appreciate the help! And no, I don't have friends to test this.. Oh and try stress testing it a bit. Try accelerating to extremely fast speeds and try to catch up to the edge of the chunk loading. If it suddenly stops, you've found something that's broken.