Modding Minecraft for 3d Automata: First Attempt

I like messing around with Minecraft. I went through a phase of actually playing it, but I now mostly just enjoy looking at what other people make. I love the mutability of the world. What bores me about it, however, is the lack of dynamics. In the basic game there is essentially no way to move blocks in an automated way. The in-game redstone wiring mechanic is interesting, but limited. Adding such functionality doesn't seem to be a priority for the developers, which is their right, of course. However, the game has a thriving community around engine modifications.

So, I thought I would implement 3d cellular automata (CA) in the game and see where that goes. Interestingly, although a huge amount of research has been done on 2d CA, e.g., Conway's Game of Life and that book by Stephen Wolfram, fewer things seem to be known about 3d automata. To get started, I implemented a couple of the rules in this paper by Carter Bays in the journal Complex Systems. The paper discusses totalistic CA, where the state of one cell depends on how many of the adjacent 26 cells are occupied. Bays uses a notation E1, E2, ... / F1, F2, ... where the En indicate the sums which lead to an extant cell continuing to be occupied, and the Fn indicate which sums cause an empty cell to become occupied. I tried out the 6,7,8/5 and 2,3/5 rules.

The video below shows the result of the 2,3/5 rule. Note that this isn't really "proper" because I'm not stepping everything forward at once. I am depending on the block-wise updates that Minecraft already implemented. I've appropriated the mossy cobblestone block. I've also set it up so that it cannot evict any cell other than air. So it cannot grow into the ground and other objects in the world. It basically takes over the game to such an extent that it becomes unplayable.



Here's a rendering of another 2,3/5 run:


Next up: 1) making the CA update in lockstep to allow gliders, 2) enabling interaction with other blocks in the environment.

Resources for Beginning SDL Development

I'm currently messing around with the Simple DirectMedia Layer (SDL). For just getting going with putting a window on the screen and starting an event loop, I found this tutorial by Tim Jones to work as advertised, even though it's almost four years old. Following that, I expanded it with his OpenGL tutorial and was in business. My silly codename for this project is "NZ" -- don't ask why. So, I have four interesting files right now: Makefile, main.cc, NZ.hh and NZ.cc. These put a colourful square in the top left corner of the screen.

Makefile

---

main.cc

---

NZ.hh

---

NZ.cc

Run 'make' and then './main' in your terminal and you'll get something like this:

Graphics Engines for Mac OSX

I'd like to be able to create a simple project that I can use to put graphics on the screen. With this, I could explore different ideas for game design in my half-assed and perpetually-unfinished kind of way. Rather than reinvent the wheel, I'd like to be able to take advantage of other people's expertise in rendering and simply use a library or framework. I have a couple of requirements:

• The tools need to work reasonably well on Mac OSX. Like many academic computer scientists, I use Apple products because they run a UNIX-like operating system but without the time-consuming interoperability problems of Linux. I spent many years using Linux as my desktop of choice, now I use Apple; this is a discussion for another time. Note that I still use Linux for all of my compute-heavy research, so in a multiplayer-type game I would probably still wind up using Linux for the backend. In the "perpetual prototype" stage, however, I need to be able to easily perform development on the laptop that I'm also flying around the world with for other reasons.
• I want to be able to code in C or C++ and directly interface with library routines. This is not for the reason that you think, however. I am a programming language geek, having worked in most of the major industry languages (e.g., C, C++, Java, C#, Perl) but also other languages that are used less for mainstream development (e.g., Scheme, Erlang), although for my day-to-day research I tend to use Matlab and Python. I want it to work natively in C or C++ because then I know I can always interface it to things like Lua, Guile or Python without having to perform any magic. I want to be able to have my language geekery cake and eat it too.
• I need to be able to easily use Makefiles and Emacs. It's just the way I roll.
• It needs to be documented so that I can actually use it.

So, having identified these criteria, I can get on with the business of identifying what engines might be fit my needs. I've spent the last three days looking at a zillion of these things, trying to figure out how to make them all work. My path went roughly like this: Ogre -> Irrlicht -> Unity3D -> Ogre -> GLUT -> SDL.

Ogre

Pros: It uses C++ and has a large user and developer base, with active forums. It seems to be the most complete open source graphics engine, with the most bells and whistles.

Cons: Trying to get it to work on my Mac was very difficult. There are installation instructions for past versions, but nothing about Mac OSX for the current version. It requires CMake and has hard-coded version dependencies for the Mac build. It doesn't play nice with MacPorts. The developers are uninterested in supporting Makefiles on Mac OSX. After several hours of searching Google, I was finally able to get the samples to compile, but I could never get my own project to build with a Makefile.

Irrlicht

Pros: Has a reputation for being fast and lightweight. I was able to get up and running very quickly with some sample code. I had an animated person on screen literally within minutes, using C++ with a Makefile. I was very impressed.

Cons: There seems to only be one developer and he's not very interested in the Apple platform. After getting things up and running, I could not figure out how to get the application to see keyboard input. I tried lots of things and couldn't get it to work. It turns out that I am not the only person with this problem, but the developer shrugs and says "works for me". That's his right, of course, but games are pretty boring if inputs cannot be received from the user.

Unity

Pros: Absolutely stunning graphics, backed by a real company with real support. It enables development for many different targets, but is focused on Mac OSX as the development platform. It comes with a nice GUI.

Cons: It is more of a "game engine" than a graphics engine. You seem very far away from the guts of things, and it's not clear if you can get beneath their scripting languages. It looks like it involves a lot of hand-holding and there doesn't seem to be a way to get down to the nitty gritty with a UNIX-style development environment. That is, this seems more like a big scripting system than a library.

OpenGL Utility Toolkit (GLUT)

Pros: Cross-platform and very mature. Really down to the low-level API of OpenGL. I had it running on my Mac without even having to download anything new. It works perfectly with C++ and Makefiles, as it got its start on UNIX-like platforms.

Cons: This is basically at the opposite end of the spectrum from tools like Unity in that you need to do all the work yourself with OpenGL. That's fine, but GLUT actually does handcuff you a bit in terms of the game loop, etc. It would be nice to have a bit more functionality built in, without having absolutely everything driven by callbacks that I don't have direct control over. Also, it looks like GLUT has been considered deprecated since about 1999.

Simple DirectMedia Layer (SDL)

Pros: Cross-platform and widely-used. It was even used for Angry Birds! It was very easy to get going - even on Mac it was configure, make and make install. You can even use MacPorts to install the current release. It works as advertised and seems like "GLUT++" from my point of view. This is what I'm messing around with right. We'll see how much I wind up missing all the features of tools like Ogre...

Cons: One main developer and he's just left. It is suggested that everyone be using the 1.3 development branch, but since the main guy is leaving, it's unclear when it will make it to a full release. It's definitely going through major transitions as a community right now.

Game Development as Hobby

I like to play games. Sometimes it is for the escapism, but it is often for the artistic and intellectual aspect. In a game, one is participating in art. This can take the form of amazing visual design, as in a Mirror's Edge, Borderlands, or Bioshock. It can also take the form of innovative gameplay, as in the amazing mutable world of Minecraft. Minecraft is amazing, not because of the game itself as a creative endeavour, but because of what it enables for the players. I go through phases of playing the game, but I actually spend more time browsing the amazing things that other people make and post on reddit.

What inspires me to want to create games is not that I can impose my vision on other people, but that one can use a game to create a shared world in which people can express their own creative visions. This blog is about my periodic spare-time explorations in creating such a game.