I'm more concerned about how it generates areas and pieces them together (so you don't have scattered desert in the middle of a forest, etc.)

That's what I'm interested in, too, but I haven't really deciphered all of that yet >.< He uses a lot of calculations and no comments of any kind, making it quite a challenge to figure out what he's doing for much of it.

It's the source Notch released himself

What do you think about this disposition of the menu item (crafting+inventory) :

Don't worry I tested it before : big blacks squares are sprite of the item, others rectangles are letters.

I do see saintrunner's point from before about having a predefined map. I think that would be fine for now while we're developing it, just to get all the other stuff working. That way as long as we define a format for the map/level data, we can have people working on the level generation code while others are working on the rest of the gameplay instead of having to wait until we decipher this level generation algorithm to get started on that.

Exactly. We clearly wouldn't be releasing the game with a predefined map, but we can set one up to get everything else working and then we can tack on the generator. Also it should be noted that the game has 5 different levels generated. One sky level (with the Air Wizard and a bunch of clouds), one top world level, and three underground levels.

Quote from: leafiness0 on January 06, 2012, 01:59:47 pm

Actually, you could transfer the map in RAM to an appvar in archive, so changes would be persistent. Keep in mind that we also need to save object data as well (furnaces, workbench, etc.)

Yes but first archiving a huge map is slow but also, when you want to make a new game, you can only play on the edited map (except if the game recreates it but then the executable will be huge). This is why I thought of an archived and non permanently editable map

Personally, I don't see why you don't go for the best of both worlds: No statically defined worlds and nothing to save unless the user modifies things. I've thought a bit about this particular problem before and one of the best ideas I came up with was to generate the world in such a way that from any particular point (x,y), one can recover the underlying terrain in any direction. This is actually possible through something known as a reversible RNG. Additionally, as it turns out, you can use something called a fractal algorithm to generate somewhat realistic terrain from such random numbers.

Admittedly, I never got around to actually porting the algorithm to Axe, but I probably could if you wanted to do so. As for the "othing to save unless the user modifies things" claim, remember that for most people, the number of things in the world that will be modified is almost certain to be fairly small. Keeping a list of changes in the world would probably be suitable. The McRegion format used by minecraft would be an excellent format to keep track of these changes with some minor modifications.