TinyCraft [Axe]

[saintrunner]

Ok I get where you are coming from.

[ZippyDee]

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.

[Builderboy]

Is it a decompiled source?  Or source Notch released himself?  Because if it is decompiled it wouldn't have comments

[leafy]

It's the source Notch released himself

[ZippyDee]

Source he released himself. How do I know? Because it contained this line:

Code: Select All | Copy To Clipboard

1 2 3

/* * for (int i = 0; i < w * h / 2800; i++) { int xs = random.nextInt(w); int ys = random.nextInt(h); for (int k = 0; k < 10; k++) { int x = xs + random.nextInt(21) - 10; int y = ys + random.nextInt(21) - 10; for (int j = 0; j < 100; j++) { int xo = x + random.nextInt(5) - random.nextInt(5); int yo = y + random.nextInt(5) - random.nextInt(5); for (int yy = yo - 1; yy <= yo + 1; yy++) for (int xx = xo - 1; xx <= xo + 1; xx++) if (xx >= 0 && yy >= 0 && xx < w && yy < h) { if (map[xx + yy * w] == Tile.grass.id) { map[xx + yy * w] = Tile.dirt.id; } } } } } */

That's just about all we have in terms of comments (at least in this class).

Edit: wait! No, we also have

Code: Select All | Copy To Clipboard

1 2	// byte[] map = LevelGen.createAndValidateUndergroundMap(w, h, (d++ % 3) + 1)[0]; // byte[] map = LevelGen.createAndValidateSkyMap(w, h)[0];

[kindermoumoute]

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

[saintrunner]

OOOH that looks nice I like that! How easy will it be to implement the sprites for the crafting section? You can find them above, Are the black squares under crafting 8x8 cause that is what I made my sprites for that stuff as

[kindermoumoute]

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

[saintrunner]

Ok cool The less changes I have to make to my sprites, the happier I am!

[ZippyDee]

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.

[saintrunner]

even if for right now all we get is one calc screen worth that we can walk around on and check out crafting

[ZippyDee]

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.

[saintrunner]

I do understand why it has to have a generator, for the replay value. but lets say we have a kid who found this game, put it on his calc, but can't fully enjoy it because every time he gets somewhere, the bell rings and he has to go to a new class and end his run of Tiny Calc. How about  the menu has a continue and New game option, new game restarting the generator, That way you can have fun on a level for more time, and the if you get tired of it, you can do a new game and the fun never ends! What do you all think?

[AngelFish]

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.

[ZippyDee]

I had thought of that, too, Qwerty, but since I've never actually looked into such methods (I only know they exist) I don't know how feasible that is to implement and execute on the calculator. The only algorithm I know of that we might be able to use for terrain generation would be a plasma fractal, which is usually used to generate mountainous terrain... http://www.ic.sunysb.edu/Stu/jseyster/plasma/