Pretty cool but another thing missing from this is the dynamic lighting. If you make an enclosed space it's just as bright inside as daylight. The lighting in minecraft is simple but extremely effective. Here's a nice demo/test from Notch from when he was working on that:
Is there any reason why it couldn't work if it were implemented like full screen mode (displaying a message telling the user to press escape to reclaim the mouse)?
No problem. I looked it up last week because I thought this was the release that was going to have the new fix for add-on-related memory leaks[1], but it turns out that's not coming until Firefox 15 next month.
Fullscreen also has security issues, more in fact, I believe? And it is not behind a flag. Also, mouse lock is enabled in Chrome in NaCl apps, but not HTML5 ones. So I am not clear on what's going on there.
Yeah, it does exist and is usable in current versions of Chrome if you change the flag for it. I'm not sure if the Chrome version of the API is what the final one will be though, since it seems to differ somewhat from the version documented on MDN: https://developer.mozilla.org/en/API/Pointer_Lock_API
Still it would probably be fairly easy to add support for it to this and replace the annoying click-drag camera movement when possible.
It's tiring to see that WASD is always used to control movement, regardless of keyboard layout. On a French keyboard, this is how WASD is laid out: http://en.wikipedia.org/wiki/File:KB_France.svg
Needless to say that it is highly impractical… Why not bind the arrow keys?
The arrow keys are usually at the right of the keyboard, next to the mouse, which makes playing with two hands awkward. You also need to move the hand on the keyboard to push pretty much any other key, which makes it difficult to do other actions (reload, open inventory, sprint, etc.)
Of course the better solution is to give the player the choice...
> You also need to move the hand on the keyboard to push pretty much any other key
- cost of binding arrow keys: ~0
- benefit to non-wasd compatible layouts: ∞
(did you know that my keyboard can actually move to where arrow keys are comfortably used, or that left-handed and right-handed-who-use-their-mouse-on-the-left-because-it-makes-sense-with-a-numpad-and-makes-RSI-bearable people exist? ;-)
Sure, it makes sense in some cases, but not for most casual gamers (due to using a laptop, limited desk space, being right-handed with the mouse, etc.)
> The arrow keys are usually at the right of the keyboard, next to the mouse
Usually yes, but not if you're using your left hand for the mouse as I've recently switched to do.
At a bare minimum both WASD and arrow keys should be enabled.
But yes, reconfigurability is by far the best solution.
Though I suppose for pastebin et al. those are just database links. There is too much data here to store it in the actual url string itself :(
Maybe just an export/import to json button then?
I would use this, like, immediately to share designs and pattern ideas with friends.
Also possible tweak: I just built a very tall tower and jumped off. But it doesn't quite "feel" like Minecraft gravity over long distances. The acceleration or maybe just the terminal velocity feel too slow.
Random bit of maths, given if you want compatibility with older IE's you're limited to around 2000 characters in the fragment string. Assuming you base 64 encode to generate valid urls, you can only fit an 8x8x8 grid into the fragment string.
The seed could be generated using the default random function of your platform without specifying the seed (the default seed is likely based on some timestamp component).
You would then take the value the default random function gives you and feed it into the overloaded constructor which allows you to specify the seed.
That way you could still record the seed's value which was used to generate your terrain.
If you read my first comment in this thread, I stated that by recording the seed it would allow you to save the terrain generated by the game not any modifications or alterations a user added to it with their own block placement.
This is used frequently in Minecraft for players to share interesting maps which have randomly generated.
Yeah this is a very limited subset of what Minecraft does and arguably the implemented bits are the low hanging fruit. I wrote a "game" in my teens that covers this functionality, though in C++ not JS on a browser.
If you have to look at your keyboard to write things that is unefficient anyway? I never look at my keyboard unless I have to type some weird character that is never normally used.
That's an extremely simplistic look at the problem. The issue isn't looking at the keyboard, it's the extra mental effort of doing the keymapping every time you run into a new application which has stupid defaults that don't take alternative layouts into account.
That is true. Wouldn't mapping specific keys (physical, on the keyboard) to actions/events better than mapping actions to the characters pressed? I thought that was how things worked now.
Nobody using Dvorak will want WASD as movement controls for a game for example, but they will most likely want to use the same keys, right?
The problem is, only the keyboard hardware knows where the keys are physically located. The OS knows the layout and could probably expose the QWERTY-equivalent keys, which would be sufficient for not-too-exotic keyboards, but I don't know if that is available to applications in a way that is sufficiently portable for browsers to expose it.
Chromium seems to expose this to Pepper plugins; here is the bug for making it an experimental js api: https://code.google.com/p/chromium/issues/detail?id=119362
Getting the lowlevel keycode is nonportable (I didn't find the implementation, but found switch cases and fallbacks if it doesn't exist). Conversion to a portable usb-hid-equivalent keycode is left as a stub in the patch that introduced the Pepper feature.
Last I looked, the vector math part of 3D wasn't handled by webGL, this uses Three.js to handle that, and looks to be the main bottleneck. Until you can do matrix/vector math using hardware, webGL is pretty much useless.
use typed arrays effectively to do very fast matrix and vector math in JS. A modern JS engine can transform such code into something very efficient, more than fast enough to do things like even first person shooters.
That is pretty much about right. I wrote a bit about the implementation[1], and the discussion went over how to optimize this (including, but not limited to, using shaders to do the drawing and not relying on Three.js so much).
Would be interested if its worthwhile/possible using shaders as a wrapper for three.js. All I got when I was searching was there was a mozilla bug report and a hacked patch to expose SIMD through js[1], and a project to add SIMD support to vectors in Dart[2].
Does anyone know of a JavaScript (or CoffeeScript) library that will read the latest version of the Minecraft files? I wrote some JavaScript code that worked with the old version and then updated it for the version that came after that but haven't had time to get into the new version. Was thinking maybe someone already did it.
I made something similar a while ago but more with a focus on the world gen and larger worlds than the crafting aspect. If someone wants to hack on it or look at code, be my guest: https://github.com/mitsuhiko/webgl-meincraft
There's a bug in this, on 2 adjacent sides you can walk one block further then you can create. The world isn't as big as it looks so this is easy to test.
http://www.youtube.com/watch?v=xnvqvFsNkq0