Minecraft

Featured Games
#41

The multiplayer mode is great!

A map and visible coordinates would make it easier to operate in multiplayer mode. For example you could say that you are at coordinates X,Y,Z and you will build a tunnel to X’,Y’,Z’. Then other players could begin building the tunnel from a different point and meet up at X’,Y’,Z’. Now it’s hard to find where others players are building, when you see only them chatting, but you have no idea that where are the places that they talk about.

Map/coordinates would also help in getting less disoriented in single-player mode.

It would be nice to have some way to pump water and lava away after an accidental flood. For example you could build a water pipe and a pump that would slowly pump the water to somewhere else. Or do you think that it would make the game too easy and less exciting?

#42

I don’t like the coordinate/map idea because it drags the player too far away from the game world. I mostly play with maps via the map and not the main game screen. Some kind of beacon system might work better.

Draining water and lava is badly needed. =)
The reason I haven’t added it yet is because it’s fairly complex to implement in a good way.

#43

Two days ago on “The Giant Pyramid” server it happened, that the whole level (!) got flooded with lava. Apparently one of the hills contained lava and it spread from there to cover the entire map with lava, maybe 20 blocks deep. After some hours of struggling, the level was restarted.

The way that water and lava spead right now, is rather unrealistic. If there is one block of water/lava, it will multiply unlimitedly in volume until everything has been covered up to that high. It would be more realistic if the water/lava volume would stay constant. If there is one block of water and next to it is one empty block where the water could flow, the water will be divided between the two blocks so that both of them will be covered by half a block of water (if it spreads over a very large area, it would disappear). If the empty block is at a lower level, all of the water would move there. The only place where new water would come unlimitedly, is from the sea outside the map. Perhaps new lava could come similarly from a lava pit at the bottom of the map.

This would mean that water/lava is more fluid than blocky, so I understand that it would be harder to implement than the current block system. Do you think that fluids would fit the game style, where everything else is blocky?

I have one idea how draining water could work so, that it would fit into the game world. You could build trees that will drain water. You need to build a line of tree trunks that will on one end touch the water, and on the other end there would need to be leaves under the sun. The thicker the trunk and the more leaves are in the sun, the faster it would drain the water.

#44

already said that but this is a fantastic idea !

two problems I had :

Work fast and very nice standalone but I cannot get more than 5fps when playing multiplayer mode :frowning:

I also got a problem when closing the browser window it always crash and I have to make a kill process of IE (IE6 Java 1.6-07 XP PRO SP3)

#45

Haha, while playing online, a lot of people like to destroy things you make, so I made a tower with a total of 6 staircases. 4 twisting around the externals of the tower and a double helix staircase in the middle. After the tower got ravaged by griefers, 3 of the staircases were still functional :stuck_out_tongue: Guess my planning succeeded! :smiley:

#46

I don’t get it…or maybe i just don’t like it!? I ran around, placed some blocks, destroyed some blocks, got kicked for doing so (or for whatever reason, i don’t know)…where’s the actual game? This isn’t fun at all to me… ???
Apart from that, i got a crash in the display driver after some minutes while trying to build something. The driver recovered somehow, but the applet was gone afterwards and the whole system feels quite jerky now. I guess i have to reboot. I didn’t get any stack trace (ATI Radeon HD4870, Catalyst 9.5, Windows Vista Ultimate (which is identified by the game as “unknown Windows” btw, Java6).

#47

Well I absolutely love it. As far as sandbox games go, it’s about as sandbox as you can get, which is great. I’ve been programming in Java for about 2 years now and I want to foray into gaming development but I’ve never dont anything more complicated than a frogger type game. What are you using to generate 3d graphics like that? Is your cube system basically a 3d array where each cube space can have a different state, each one being associated with a different texture or not one at all? This style just fascinates me so much. Excellent game.

#48

This is pretty cool. I think it would be cool if you take out the bottom of a tree, the whole tree falls.

An objective would help with longevity for the Game lifespan. Was that gold blocks I saw underground? Do I get point for getting those?

#49

It looks like he probably uses some sort of 6-way linked list rather than a 3D array in order to save (a lot) of memory. This would explain why you can’t simply spawn a block in mid air, and must link it to a preexisting block.

#50

A 6 way LinkedList (LinkedGrid?) will use so so much memory it isn’t funny. A single int[] or byte[] as the basic datastructure is best for quick lookup. Around that, you can have all kinds of highlevel datastructures that manage your tesselators and spatial subdivision for rendering.

#51

Riven nailed it. =)

#52

Darn, I should have thought longer before I posted that. You’re right of course - every single piece of the grid is then using at least 6 bytes, and that’s only if they don’t have any relevant data included. Depending on how much empty space there would be in the level, this really won’t be any better than 3D array.

#53

Not only that. First of all, those 6 pointers are either 32 or 64 bit, not 8 bit - so it would be using 24 or 48 bytes, not 6. Secondly, all your objects have headers, that are either 8 or 16 bytes. Then you’ll be dealing with following those pointers and null-pointer checks (+99% cache misses?) so performance would be horrible. Then you only have the datastructure, no data, so that’s at least one more field, which is conveniently word alonged (+4 or 8 bytes). Now let’s be nasty, and say you have this 64 bit JRE. You’d end up with 48+16+8 = 72 bytes per cell, as apposed to 1 byte per cell in a massive byte[].

For better cache locality (because even that byte[] will have horrible cache behaviour), you’d have to build a structure in your byte[] that makes all tiles near to eachother in 3D, also near to eachother in 1D. Now this can’t be perfect, it will mean a few more calculations, and a heck of a lot less stalling: if you have all your data in 1 byte[], and you check the 6 neighbouring cells, you’ll have 3-4 cache misses on average, and cache misses are terribly expensive. A full page is read from RAM, typically 4K for every cache miss, so for every border-check, you’d be streaming in 12-16KB.

If you replace that 1 byte per cell ‘cache trashing’ to your LinkedGrid, you’ll probably shake your head and call it a day. Besides that, how do you do random access in a linked grid? Random access in a LinkedList (1D) is already terrible, 3D will have the performance characteristics of a turd.

#54

I am defeated. :’(

#55

I’d use an octree, sparsely populated with simple arrays of blocks arranged in 3D. Most of the octree would contain nulls as chunks of empty space. Fits very nicely with rendering requirements too.

Cas :slight_smile:

#56

Indeed.

What you describe are the higherlevel datastructures.

For physics, it’s very convenient to have 1 byte[], as you can lookup a cell instantly.

#57

Interestingly, I did try that, and lost framerate in pretty much all scenes compared to what I do now (chunked rendering of blocks of 8^3 tiles).
The result felt very counter-intuitive to me, but as I did the math, it kinda started to make sense. The frustum culling I do now isn’t as fine grained as a proper oct tree, but there are less checks done now than with oct trees, and the extra rendering is faster than the extra culling would be.

I’ve now got two more optimizations to try, one of them is to keep tile data in local groups as suggested by riven in this thread. The other one is to join tiles with the same texture, but this can only be done along one U/V axis because I use a texture atlas. I should also spend more time optimizing the chunk updates, since as the framerate gets higher or the cpu gets slower, the stutter from the updates get more and more obvious. Stutter is a bigger problem than low framerate.

#58

I liked this. Quite a few cool moments, like digging a deep hole, wandering off to explore, coming back and finding half a dozen dudes bouncing around in the “trap”. I also found a small gap in a slope (if you can call it that) so peered inside and found a whole underground cavern. Jumped in, swam around and eventually found an exit the outside ocean.

Some points:

  • Textures for the trees shimmer when viewed at a distance, I suspect reducing the texture res at distances might help. Not a big deal, just looks a bit off.
  • A counter for how many guys are running around - I had quite a few with no noticeable lag which was great
  • I didn’t notice any sound or background music, but can’t imagine hearing anything other than Dire Straits - Money for Nothing with those block guys
#59

Sounds like you might have got something wrong in your octree there. It should be fast as hell. One common pitfall is discovering huge numbers of unclassified boxes in the root of the octree because they sit on a boundary (the way you classify them is important!)

Cas :slight_smile:

#60

Octtrees ARE slower in some cases. For example, if your entire game world consists of eight (n) small boxes in the corners of a huge (m) empty space and the player is in the middle.
O(n log m) for octrees versus O(n) for brute force.

I have no idea what you mean by “unclassified”.