Yep, yet another Minecraft clone. I've been hard at work on this for the past few weeks, and I'm come along pretty far already:



What I have now:
- Left/Right to move, Up to jump
- 360° cursor sweeping through numpad
- Hold down 2nd to break blocks
- Press Alpha to place blocks

What I'm going to add:

Worlds in Chunks: The world will be saved in mulitple 36x21 block chunks, saved in Appvars. The game always has nine chunks in RAM: the one you're in plus the eight surrounding it. Once you get a good distance out of the center chunk, the game will load nine new chunks. If the game tries to load a chunk that doesn't exist, it creates a new one.
- Because X ranges from 0-65535, the world can be up to 227 chunks wide before it wraps around.
- For now, the world will be 5 chunks high, and each chunk represents a different strata of the game world (all sky, maximum terrain height, average terrain height, sea level, all underground). This means that the world will be 105 blocks high.
- I've determined that each of these chunks take up 770 bytes (756 + VAT entry). Thus, all 1135 chunks can take up to 873950 bytes, which fits into the archive of an 84 Plus Silver Edition.
- Block Types: I can have up to 255 block types. Zero represents no block exists at that point.
- Inventory: You can store up to 5 ready-use items on your Graph buttons, and up to 30 more in your inventory. You can also have chests, each of which support 30 more.
- Mobs: Mobs do show up: animals and monsters. Aiming and 2nd can be used to attack them. Monsters (such as Creepers, Zombies, and Skeleton Archers) will attack you, and animals (such as Sheep, Pigs, and Cows) will run when you attack them. All mobs drop spoils.
- Spoils: It would be too much to keep track of spoils on the ground, so destroying a block or mob automatically awards the spoils to you.
- Day and Night: As time passes, the sun and moon will cycle into day and night phases that last 10 minutes each. In the daytime, all blocks that are exposed to the sun will be lit, in a certain angle depending on the time of day. At night, the moon lights nothing. Things can also be lit with torches, attached to walls and ceilings. Grayscale will be used to show lighting.

Please give me comments and feedback about my plans and from what you see.

I also need some help on this project: Because the frame rate is going to change drastically, I'm want the program to read from the calculator's crystal timers, basically to determine how long a frame has taken and how far the day has advanced. Since Axe doesn't have crystal timer commands, could I please have some ASM code that can do this so I can build an Axiom? Thanks.[/list]

This looks a lot better than all of the "Minecraft" calculator games (I can't bring myself to call them clones) that I've seen thus far. Will you be giving it some sort of clever name? It sounds to me as if you have your chunk design well-thought-out, and I like the look-and-feel so far. I'd certainly be happy to help you understand how to use the crystal timers and/or interrupts to get good "tick" equalization; BenRyves uses an interrupt trick in his Nostromo game for the same reason. IS there a particular set of logic behind using the crystal timers instead of interrupts, thus locking out your TI-83+-using brethren?

Firstly, that looks awesome! Nice job with the game mechanics.

For timers, you can look here: http://wikiti.brandonw.net/index.php?title=83Plus:Ports:30 An example is given at the bottom. Ask away if they fail to work on-calc (wabbitemu doesn't always handle the timers correctly, unless it has been fixed)

Thanks for the feedback. For the clever name, a friend of mine suggested "CalCraft" or "CalcCraft", but what I really want to do is talk to Mojang, the company that makes Minecraft, to see if this could be branded as the official Minecraft with his feedback.
As for the Crystal timers, I'm already using full speed, so the 83 Plus is locked out anyway. I'd like to use timers because you don't need interrupts to check them (which I've had problems with before, in Eitrix), and I can keep two timers: one for the time passed per frame, and one to keep the Day/Night cycle.

A little update: I'm almost done adding chunk support. Right now, you can move across the chunks, creating a wrapping 8192x50 game world. I changed my chunk allocation plan from having 5 short chunks on the vertical axis to 1 tall chunk on the vertical axis, which simplifies terrain generation and eases the load on the VAT. I also made chunks 32 blocks wide so that all 65536 values for X can be used for movement. Now, all I need to do for chunk generation is actually generate terrain.

* bump *

I'm still at work on this, and I've added somewhat working terrain generation. I've also added a general save file, under the appvar MCFILE, that keeps track of all of the game variables, such as position. If this file does not exist at startup, all chunks are deleted as well, and then a new game begins. (BTW, the chunks are named with "MC", then two characters in the 0x80 to 0x8F range (small numbers and accented A's) to represent the chunk's position. This way, any legitimate files beginning with MC, such as custom saves or Notefolio documents, don't get overwritten).

Right now, the terrain generates as discrete plateaus that can have a giant difference between chunks, which is unplayable. I tried developing a solution that uses a system of equations to generate a cubic equation that passes through two points on each side of the chunk, but not only did I realize how inaccurate that is with 16-bit percision, I also saw how bland it was. Since it doesn't appear that I can add a poll, tell me what you think I should use to generate the terrain curve:
- A cubic equation passing through both points
- A simple line between the points
- A random line that moves from left to right, tending to move towards the right-side point at the end.
- Predefined structures or variations of the same
- Anything else you can think of

Also, thinking about interrupts: I think that would actually be more workable than crystal timers, because Axe has easy to use built-in routines for handling interrupts (simply use [tt]fnInt(SUB, 6)[/tt] to set up an interrupt that calls subroutine SUB 110 times per second).

I think that you should make your terrain as procedurally-generated as possible, so that if the player walks far left and back far right without actually placing or breaking any blocks, that you won't have to store chunks that weren't modified. I believe that Minecraft might do something along these lines; the chunks are certainly procedurally-generated terrain-wise.

Great idea, Kerm! That will also allow me to generate smooth terrain without having to reference adjacent chunks, which wastes time. I can think of two ways to implement this:
- Using the sine curve as a base, generate a f(x) that determines terrain height at x.
- Set region boundaries, alternating between sea and an island type (desert, forest, lowland, arctic mountain, etc.), and use sine curves to generate the terrain of each island.

Either way, using that terrain height, I would fill everything below that with blocks, using a formula to determine which ones.

* bump *

I've been working hard on this. I just added a constant terrain curve based on sine alone. Since I've found the world incredibly difficult to navigate like this, I decided to add water logic. I don't have a screenie, but I'm happy with it as it is.
Additionally, I'm interested in making two-layered chunks: each chunk has a foreground and background layer, and independent flags control which one you're standing in, which one you're aiming in, and which one the camera is facing. This would allow the player to build staircases and the like without destorying blocks.
I also am working on a good method of compression for my chunks so that I can have more memory available to the user and perhaps to metadata. However, I'm unaware of any lossless compression methods other than horizontal and vertical RLE, and I don't know how effective they will be with richly detailed chunks. Does anyone else know of any good lossless compression methods I can use?

*double bump*

Just about done adding fluid logic, all I need to do is add source block creation. One thing that I will say is that the Minecraft Wiki has been my best friend for the past few weeks.
Again, sorry about the lack of screenie - I've been very busy lately and haven't had the time to make one. I will most definitely add a screenie when the game goes public.
And speaking of which, all I have left to add before releasing on ticalc.org is multiple block types and inventory, which shouldn't take very long.

(Releasing on ticalc.org and in the Cemetech File Archives, I hope you mean ). Great job on all the progress you've been making; I'm not sure how I missed the previous two bumps. Do you still need help with your compression methods, or did you figure it out? If you figured it out, what did you end up doing?

Yes, I almost forgot the Cemetech archives. In fact, I might even release my beta exclusively to Cemetech so that the public doesn't judge me by my betas.
Additionally, now that I think about it, I'm not so concerned with compression algorithims right now. The compression methods I've tried (RLE and bit layering) don't work well for complex chunks, especially if they have ore veins and the like inside. And since my compressed chunks might well be larger than my uncompressed chunks, I am not going to rely on compression to have all of my chunks fit on the calc - if I do it at all, I'll do it to be nice to my customers. I will, however, be researching good, fast compression methods.

Minecraft Update:

I'm pretty much done with fluid, but I'll leave it as it is for now until I release. Right now, I'm working on inventory (perhaps the most important concept), and I'm trying to add a block to the player's inventory when he destroys it. This is my code:


Code:

Basically, my inventory is stored as a series of words, with the item type in the MSB and the item amount in the LSB. However, when I call this code, I can see that after a block destruction, the inventory remains empty - not one slot is added. Could you please tell me what is wrong?

EDIT: I just realized that I never used its return value for anything - I'll check that.

No argument from me! Good luck and go to it. As far as your bug, I don't really use Axe nor read it particularly well, but perhaps none of the r5's are true in your conditional blocks there?

r1-r6 are all 2-byte integer variables. When a subroutine with arguments is called, the arguments are loaded into r1 through r6 in order, so that those variables in a subroutine refer to the arguments. However, I just realized that the call to RDTL changes the values of r1 and r2 from the inventory pointer and size to the mining target coordinates, which caused ADDIT to attempt to write to flash memory, which doesn't work. I used the recursive variant of subroutine calling just now (which saves r1-r6 to the call stack, then pops them off afterwards), and fixed the problem.

Superb! So does that complete the implementation of the inventory for now (what about removing items from inventory when placed?)? If so, what to-do items are still pending before a beta release?

Here's what I have left:
- Remove items from inventory when placed
- Select from top 5 items with Y= through GRAPH
- Add multiple block types (Dirt, Stone, Bedrock)
- Give blocks an update flag to indicate whether or not they should update (such as for water flows) to optimize updates.
- Fix an annoying bug that prevents you from placing a block immediately above you

And, planned for the next release:
- Inventory menu (press MODE to see 24 more items and rearrange all of them)
- Alternate item drops and drop probabilities (for example, Stone drops Cobblestone, Leaves have a chance of dropping Saplings)
- Trees (wood and leaves, as well as saplings)
- Seeded world generation

Have you put though into how you are going to store the contents of chests in the chunk appvar? And what about other blocks that will need to store data like say a door of somesort? I saw you wanted to have each chunk in a fixed sized appvar, but won't some chunks have more data than others due to some blocks needing to store extra data?

Dude, you might consider improving your guy. Otherwise it looks nice! I tried to learn Axe, but my head blew off (unfortunately).

As far as chests are concerned, I'm actually planning on storing those in a seperate appvar from the chunk, indexed by location. This is because, along with chests, I'm planning to also create similar objects called spoil caches, which holds spoils from destroyed blocks and mobs. Spoil caches act like actual spoils in Minecraft, but attempt to consolidate when they get close.
Additionally, all blocks not only have a byte for tile type, but also have a nybble (4 bits) for tile data that is also saved in the chunk. The lower 3 bits reflect state data (such as fluid level, door opening, and Redstone power state), and the upper bit is an update flag.
And another thing I'm planning on adding: Since the save files will be changing as I update, each version of Minecraft will have the ability to update the previous version's saves.

You know what I owe you guys? A screenie. This one demonstrates game start and stop, frames per second, inventory, water, and multiple block types. Feast your eyes!



In fact, you know what I really owe you guys? An alpha release! Feast your thumbs!
http://www.cemetech.net/programs/index.php?mode=file&id=743