Show HN: Iteratively Building Virtual Creatures in Minecraft
github.com"Creatures" is a stretch given that the environment is Minecraft, but the idea is simple: iteratively add blocks conditionally (tensor convolution) on the current environment (blocks) to maximize some reward. In this case I use PPO RL to train creatures to touch a glowstone block but you can adapt it to use any algorithm and reward (easily, as it uses the Ray framework).
What I like about this work: iteratively finding solutions has a long and colorful history of doing things well: gradient boosting, ResNets, Stable Diffusion, etc. We're after some end optimal state and usually try to get right to it via some flavor of SGD. Baking in improvements as part of the problem structure is helpful. I like to think of this as solving the derivative of the solution with respect to time and then integrating over time. The Minecraft environment naturally prevents overfitting because you can spawn creatures in a diverse array of environments and train one policy over them all.
What I don't like about this work: Minecraft was chosen for computational reasons but doesn't make cool creatures that walk around and look like cheetahs or whatever. I've compared it against nothing, but it works real good! <g>. Videos in the README.
You can install / run with Docker and observe metrics with Tensorboard. Should be plug and play. If not comment. Enjoy! > cool creatures that walk around and look like cheetahs or whatever Once you have the actual behavior, everything else is just animation. Maybe you could evolve some keyframes fitting particular criteria? Creative idea - I'll think about this. Check out the paper about the AI in the original FEAR. https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... Much of the "smart" behavior players loved was actually just a simple state machine with nice animations. > The locations of the creatures are output in (x, z, y) format (don't ask me why the Minecraft devs did this) It's the same in Unity and three.js. Probably so the first two coordinates mark axis on the plane the player is looking at (width and height; until they move), with the third one being "depth"? Instead of the third one being height as one might expect. It’s just convention which axis represents up. Typically you don’t see the axis labels rearranged like in the OP but instead coordinate systems described as y-up or z-up. Similarly left and right handed. Well, it's about the order. In vanilla Minecraft client you see height as the second coordinate out of the three. Right because vanilla Minecraft uses y-up, so the second value ‘y’ represents height. The comment is somewhat misleading. Minecraft uses (x,y,z), and uses the 'y' coordinate for height (not 'z'). This is very common for exactly the reasons you outline. Also, flipping two coordinates changes the handedness of the system. OpenGL uses left-handed coordinates while Minecraft uses right-handed. I'm not sure this is relevant here, it should be an internal conversion. You have created the most convoluted way to build from one point to another in minecraft. Congratulations. Cool project. You could definitely do more with this with more modern Minecraft tech like custom models and physics engines. Awesome idea! I would put "Minecraft" somewhere in the title. Thanks!