Do you think that this project is possible, given the hardware limitations?
Absolutely!
 26%  [ 9 ]
Maybe?
 8%  [ 3 ]
Not a chance
 8%  [ 3 ]
Possibly, if you're willing to put in the time and effort
 47%  [ 16 ]
Why the hell not???
 8%  [ 3 ]
Total Votes : 34

beckadamtheinventor wrote:

It seems as though a few people on Cemetech are creating 2d minecraft clones for the TI-84+CE, so I decided to do my own! Laughing Smile
As many might expect, it would be similar to Terraria.
You would be wrong in that assumption Razz

This game will be 3d! Not in the traditional Minecraft way, however. It will use a series of chunks, very similarily to Minecraft, but these chunks will not be rendered in 3d, but instead from a "bird's eye" view, top down!

So with that method, I could make a 3d game, but rendered in 2d.
I would be using a tilemap engine, of my own design, that would remove the need for 'loading zones' between chunks, by loading 4 chunks at once, and reloading the chunks every time the player gets in visible range of the chunk boundary, similarily to how Minecraft does it, exept you would only need to load 4 at a time (the maximum number of chunks that are ever visible to the player, due to the game being top-down, and only rendering 5 or so blocks in every direction)

The game would be able to have some decently large worlds, and will feature superflat worlds, structures, creative mode, survival mode, cheats, and a plethora of other things, including modding!!! eventually

Already got screenies! Very Happy
https://drive.google.com/open?id=1uMCg28B9w4Z0U-chYKzl4GMuY6VuqSEq

I am open to any help on this project.
If i'm copycating, I apologize. I'm going to make this anyway. I have a lot of free time, a.k.a. no lifeFeel free to bug me if I don't finish this project punctually. Razz

beckadamtheinventor wrote:

This game is likely to change shape a lot soon, into more of a post-apocolypse game with a lot less generated world data.


This is going to be a Minecraft-based game, written in C.
I have decided to start work on this again, thanks to the FAT32 USB library coming soon. (hopefully)
Special thanks to MateoC and Jacobly! Without this library, I would not have been able to [reasonably] continue this project, given the memory limitations of the TI-84+CE.

I know that I change my mind a lot Razz
I think the question is not whether or not it is possible, but rather at what price. Aside from the large amount of work required to make something nice, you will have to make a trade-off between the amount of fidelity and the speed at which you want to be able to play the game.
Just to dispirit you, here is a minecraftish block game in ~1kb of js
mr womp womp wrote:
I think the question is not whether or not it is possible, but rather at what price. Aside from the large amount of work required to make something nice, you will have to make a trade-off between the amount of fidelity and the speed at which you want to be able to play the game.
Just to dispirit you, here is a minecraftish block game in ~1kb of js


1: It won't be rendered in 3d
2: It will be 'superflat' with some structures
3: It will only save 16*16*X (side*side*height) chunks of 256*X+4 bytes each. So, a world the size of the old Minecraft Pocket edition of 256*256 blocks could be saved at a maximum size of 4 megabytes. Minimum 2 megabytes. With the compression system I plan to implement, less than one megabyte. If I lower the world height to 32, ground height to 16, I could implement it in 1Mb without compression.
4: Each height unit is one player height.

But yea, I guess you're probably right...
You could also only store chunks as necessary, and use a sub-chunk system like Minecraft does to only store needed portions of that chunk (as the entire top part is air). That would probably keep the file size really low. Additionally, if you only have 16 blocks, you could store 2 blocks per byte.
Could be possible, perhaps treating every tile position in your map as a column of tiles with n-height? Kind of like a linked list I suppose.

I did some experiments on the CSE/CE a while back that did minecraft style from an isometric perspective. It was actually a 16x16 sprite test, hence why it was slow, but it looked nice and gives the idea some hope (I hope Smile).




Or were you not looking to go from an isometric tilemap perspective? Either way a dedicated engine should be able to do this pretty fast. Perhaps PT can help with his CEmpires engine?
tr1p1ea wrote:
Could be possible, perhaps treating every tile position in your map as a column of tiles with n-height? Kind of like a linked list I suppose.

I did some experiments on the CSE/CE a while back that did minecraft style from an isometric perspective. It was actually a 16x16 sprite test, hence why it was slow, but it looked nice and gives the idea some hope (I hope Smile).




Or were you not looking to go from an isometric tilemap perspective? Either way a dedicated engine should be able to do this pretty fast. Perhaps PT can help with his CEmpires engine?


I would like it to be an orthographic view, rather than isometric. Also I would need really good compression to do this at all. At the very least it could be about half a megabyte for a world, at maximum, 4.
And the world size: 256*256 blocks by 32 maximum height, similar to the original Minecraft Pocket Edition worlds.
256*256 blocks by 32 maximum height = 2.097152 megabytes, minimum. Where are you going to be storing that?
MateoConLechuga wrote:
256*256 blocks by 32 maximum height = 2.097152 megabytes, minimum. Where are you going to be storing that?


I will only be storing as many levels as are necessary; 16 at least.
Also: I know I will need to use compression.
What does compression have to do with anything.
MateoConLechuga wrote:
What does compression have to do with anything.

I could hypothetically store each collumn as four bytes, then convert that to binary when I need it for rendering. The layers would be pre-determined. Grass, dirt, the rest stone. Air would be zero, the solid blocks would be ones
"000000111111" would be 6*air, grass, dirt, and 5*stone. I could use this method to have 32 blocks in four bytes. Therefore: a 256*256*32 world, including metadata (4b for every kb) and world configurations (64b) could be stored at 263252 bytes.
The chunks that would not follow this method would be stored using a different compression system, as necessary. The chunk metadata would allow for different chunks to follow different methods of compression, or not at all.

The chunks would be decompressed and recompressed as they are used. Possibly slow, but a much lower data footprint.
Are you saying that it would be 1-bit per block? How would you differentiate between the different solid blocks if it's all the same state(set)?
tr1p1ea wrote:
Are you saying that it would be 1-bit per block? How would you differentiate between the different solid blocks if it's all the same state(set)?


Because the order of the blocks is always the same for that compression method.
So the first 1 would be grass, then dirt, then the rest of the ones would be stone.
I would use different metadata for different compression methods.
I was picturing this as a vertical column of blocks, or is that not correct? Will you be able to have blocks in different positions in the column if so?
With that compression style, there will always be some number of air blocks followed by some number of solid blocks, correct? If that is the case, you could compress it to 4 bits rather than 12 by storing the column height rather than the data in the column.
How many bits would you allocate to column height data?

I'm not sure you are going to be able to get the flexibility you want with only 1-bit per block in each column, that only gives you the choice between 2 blocks?
commandblockguy wrote:
With that compression style, there will always be some number of air blocks followed by some number of solid blocks, correct? If that is the case, you could compress it to 4 bits rather than 12 by storing the column height rather than the data in the column.

I could do that, but there are going to be caves, so there will be breaks in the collumn.
tr1p1ea wrote:
How many bits would you allocate to column height data?

I'm not sure you are going to be able to get the flexibility you want with only 1-bit per block in each column, that only gives you the choice between 2 blocks?

Like I said before, the order of the blocks in the collumn is always the same. I will use different chunk metadata to differenciate between different compression methods.
I would use 32 bits for each collumn; the height of the world.
Wouldn't that mean in order to make it possible to have any block at any bit position you would need the full 32-bit range of column metadata?
Ok, so after a month or two of postponing this project, I am pleased to announce it is back in development! Very Happy
A game like this would not have been possible before, but now it is! Thanks to the FAT and MSD libraries (coming soon) I will be able to continue this project!

This game will be written in C, and will allow for as much world data as the flash drive can store.
I plan to allow texture modding, behavior modding, etc.

This brings me to an important question: would anyone like to help with textures?
I'm not the greatest at pixel art Razz
If this project could get even one texture pack, that would help a lot Smile

Texture appvar format is as follows:

Code:

"data", 0x00,
"icycraft/txp",0x0000
X, Y, (X*Y bytes sprite data) //repeat as needed
0x0000 //null sprite, tells program to stop getting sprite pointers

This format may or may not change slightly in the future.
The header structure can be as long as you like, allowing for more meta info, like title and author; as long as it is ended with two null bytes. (0x0000)
This is the same format that I came up with for BOSshell Razz
I have been really working on this in recent days, and I now have a tile engine which can have the character move around without needing to transition between map areas at all

I will post screenshots soon, to show what I mean by this.

ICYcraft will be done in ICE, for now. Idk if I'll do it in C, maybe I'll just wait until ICE adopts the USB-FAT and MSD libraries. (iirc they are working atm?)

I've been working on a default texture pack, and I plan to add behavior pack functionality in the near future.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement