Anything you need me to do right now?
Offline
Rub0Gameton wrote:
Count me in!
What is minecraft about?
I have seen the website and stuff but I have never played it.
I know absolutely everything on Scratch, from MESH to 3D to Infinite Scrolling
Minecraft=awesomeness!
I just bought the game

Offline
Sunrise-Moon wrote:
technoguyx wrote:
I was going to see if I could add something but apparently you're not accepting more programmers.
Oh well, I never understood the project too well anyway.
![]()
Anyway, if you need music made specifically for it let me know, I'm very good at composing simplistic stuff and maybe some ambient (I've only composed creepy ambient but I can give some relaxing loops a la C418 a try)
Actually, we can make an exception if you want to program (and make music)
.
Okay then, thanks
I might add some concepts whenever I can.
One thing I'd like to discuss here though is replacing the way blocks are stored right now. A huuuuuuuge list might do the trick I guess but I think it'll cause lag. Still I think we need something much less restricting than the 6 lists we're using right now.
Let's see... The Scratch stage is 480*360. The tiles are 10*10, so 48*36 = 1728 items. Way too much. I don't know if splitting it into, say, 4 sections of the screen would cause a bit less lag.
Or maybe, make the terrain generate from below up to say, half the map. That'd be 48*18= 864 initial items without counting for possible caves and trees, considerably less but still a lot.
Or, we could just be lazy and increase the tile size, I find it too tiny right now anyway.
15*15 tiles would give us 768 total blocks, and 20*20 432 blocks. That combined with the idea mentioned above would considerably reduce list size and therefore, lag, while making the engine much less limiting.
If you guys didn't understand something in this post, I might rush a demo of a brand new engine tomorrow.
EDIT: Also an idea: A simple mining minigame. Will elaborate on that later, maybe along with the engine tomorrow.
Last edited by technoguyx (2011-02-15 21:41:34)
Offline
technoguyx wrote:
Sunrise-Moon wrote:
technoguyx wrote:
I was going to see if I could add something but apparently you're not accepting more programmers.
Oh well, I never understood the project too well anyway.
![]()
Anyway, if you need music made specifically for it let me know, I'm very good at composing simplistic stuff and maybe some ambient (I've only composed creepy ambient but I can give some relaxing loops a la C418 a try)
Actually, we can make an exception if you want to program (and make music)
.
Okay then, thanks
I might add some concepts whenever I can.
One thing I'd like to discuss here though is replacing the way blocks are stored right now. A huuuuuuuge list might do the trick I guess but I think it'll cause lag. Still I think we need something much less restricting than the 6 lists we're using right now.
Let's see... The Scratch stage is 480*360. The tiles are 10*10, so 48*36 = 1728 items. Way too much. I don't know if splitting it into, say, 4 sections of the screen would cause a bit less lag.
Or maybe, make the terrain generate from below up to say, half the map. That'd be 48*18= 864 initial items without counting for possible caves and trees, considerably less but still a lot.
Or, we could just be lazy and increase the tile size, I find it too tiny right now anyway.15*15 tiles would give us 768 total blocks, and 20*20 432 blocks. That combined with the idea mentioned above would considerably reduce list size and therefore, lag, while making the engine much less limiting.
![]()
If you guys didn't understand something in this post, I might rush a demo of a brand new engine tomorrow.
EDIT: Also an idea: A simple mining minigame. Will elaborate on that later, maybe along with the engine tomorrow.![]()
It might be better with four lists- right now, if you had a lot of items, it might take a while for a level that's far away from the spawn to...wait, maybe not. But it might cause lag, like you said. Though if we want saving to be simple, we want to use only one list so people can export it and import it (long lists take forever to save, so exporting would make it go faster).
Offline
Sunrise-Moon wrote:
It might be better with four lists- right now, if you had a lot of items, it might take a while for a level that's far away from the spawn to...wait, maybe not. But it might cause lag, like you said. Though if we want saving to be simple, we want to use only one list so people can export it and import it (long lists take forever to save, so exporting would make it go faster).
Yeah... Anyways I think we should combine the last two ideas. 15*15 or 20*20 tiles + a list that gets bigger only with tall builds. With 20*20 the map would only start out with about 250 items.
Last edited by technoguyx (2011-02-15 22:13:21)
Offline
I'm not going to quote that because it is too huge. Anyway, that makes sense. I think splitting might help.
Or making more than one sprite draw. Is that what you mean by splitting?
Offline
technoguyx wrote:
Sunrise-Moon wrote:
It might be better with four lists- right now, if you had a lot of items, it might take a while for a level that's far away from the spawn to...wait, maybe not. But it might cause lag, like you said. Though if we want saving to be simple, we want to use only one list so people can export it and import it (long lists take forever to save, so exporting would make it go faster).
Yeah... Anyways I think we should combine the last two ideas. 15*15 or 20*20 tiles + a list that gets bigger only with tall builds. With 20*20 the map would only start out with about 250 items.
I like how small the images are though- it makes it so you have to play in presentation mode.
Offline
Necromaster wrote:
Or making more than one sprite draw.
Yeah, that'd be good. But I meant splitting it in lists. Still multiple stamper sprites might be necessary for fast rendering.
Offline
technoguyx wrote:
Necromaster wrote:
Or making more than one sprite draw.
Yeah, that'd be good. But I meant splitting it in lists. Still multiple stamper sprites might be necessary for fast rendering.
Multiple sprites are necessary. Otherwise, whenever you go to a new chunk, it'll be like waiting for a level to generate (i.e. 10-20 seconds).
Also, would anyone like to refine the generator? It doesn't generate hills, and generates grass at about two to three blocks above the normal ground (we want it to generate two to three blocks above ground, but it needs some blocks beside it so you can still jump over these parts).
Last edited by Sunrise-Moon (2011-02-15 22:28:00)
Offline
I don't know about hills, because as far as I know minecraft is block based.
EDIT: About multiple sprite drawing, I think we should have 4 different sprites for 4 sections. Input?
Last edited by Necromaster (2011-02-15 22:46:10)
Offline
Necromaster wrote:
I don't know about hills, because as far as I know minecraft is block based.
![]()
EDIT: About multiple sprite drawing, I think we should have 4 different sprites for 4 sections. Input?
Block hills. You know:
I was thinking 18 sprites drawing two rows each (18 + 18 = 36 rows). That'd make loading a flash.
Offline
Sunrise-Moon wrote:
Necromaster wrote:
I don't know about hills, because as far as I know minecraft is block based.
![]()
EDIT: About multiple sprite drawing, I think we should have 4 different sprites for 4 sections. Input?Block hills. You know:
http://us.123rf.com/400wm/400/400/hixso … g-rows.jpg
I was thinking 18 sprites drawing two rows each (18 + 18 = 36 rows). That'd make loading a flash.
Oh. I'll try working on that.
Offline
Necromaster wrote:
Sunrise-Moon wrote:
Necromaster wrote:
I don't know about hills, because as far as I know minecraft is block based.
![]()
EDIT: About multiple sprite drawing, I think we should have 4 different sprites for 4 sections. Input?Block hills. You know:
http://us.123rf.com/400wm/400/400/hixso … g-rows.jpg
I was thinking 18 sprites drawing two rows each (18 + 18 = 36 rows). That'd make loading a flash.Oh. I'll try working on that.
No! Don't! Let me upload my updated version merged with yours, first!
Offline
Sunrise-Moon wrote:
Necromaster wrote:
Sunrise-Moon wrote:
Block hills. You know:
http://us.123rf.com/400wm/400/400/hixso … g-rows.jpg
I was thinking 18 sprites drawing two rows each (18 + 18 = 36 rows). That'd make loading a flash.Oh. I'll try working on that.
No! Don't! Let me upload my updated version merged with yours, first!
Sure. By the way, is my character movement good?
Last edited by Necromaster (2011-02-15 23:17:15)
Offline
Necromaster wrote:
Sunrise-Moon wrote:
Necromaster wrote:
Oh. I'll try working on that.No! Don't! Let me upload my updated version merged with yours, first!
Sure. By the way, is my character movement good?
It's pretty good, but you can still sort of jump while in walls. By the way, great job to fix the going-through walls glitch! I can't believe I didn't think of it
.
Offline
Sunrise-Moon wrote:
Necromaster wrote:
Sunrise-Moon wrote:
No! Don't! Let me upload my updated version merged with yours, first!Sure. By the way, is my character movement good?
It's pretty good, but you can still sort of jump while in walls. By the way, great job to fix the going-through walls glitch! I can't believe I didn't think of it
.
We could be lazy and just make separate sensor sprites... But it isn't as impressive or powerful.
Offline
Necromaster wrote:
Sunrise-Moon wrote:
Necromaster wrote:
Sure. By the way, is my character movement good?It's pretty good, but you can still sort of jump while in walls. By the way, great job to fix the going-through walls glitch! I can't believe I didn't think of it
.
We could be lazy and just make separate sensor sprites... But it isn't as impressive or powerful.
Actually, I find it much easier to merge the sensor sprite with the character sprite- no need to use variables to say "move x -1" and everything always does the same thing (because it's not offsync).
Offline
Sunrise-Moon wrote:
Necromaster wrote:
Sunrise-Moon wrote:
It's pretty good, but you can still sort of jump while in walls. By the way, great job to fix the going-through walls glitch! I can't believe I didn't think of it.
We could be lazy and just make separate sensor sprites... But it isn't as impressive or powerful.
Actually, I find it much easier to merge the sensor sprite with the character sprite- no need to use variables to say "move x -1" and everything always does the same thing (because it's not offsync).
It is much simpler and easier to debug though.
Offline
Hey, should we add caves? I'd say no, but it might add some depth to the game. Maybe they could be generated if you go to the bottom edge of a level/chunk? (Like, go to the bottom, and it acts like you just went further underground). Also, should we allow generation of chunks in the sky as well as below ground, or just left and right?
Offline
dam i really wanted to be a part fo this
Offline
Dang. Could you let me be part of the collab
Pwetty please?
Offline
Sunrise-Moon wrote:
Hey, should we add caves? I'd say no, but it might add some depth to the game. Maybe they could be generated if you go to the bottom edge of a level/chunk? (Like, go to the bottom, and it acts like you just went further underground). Also, should we allow generation of chunks in the sky as well as below ground, or just left and right?
Chunks in the sky. I played one version of minecraft were I had to jump from block to block lest I fall in lava.
Offline
Sunrise-Moon wrote:
technoguyx wrote:
Sunrise-Moon wrote:
It might be better with four lists- right now, if you had a lot of items, it might take a while for a level that's far away from the spawn to...wait, maybe not. But it might cause lag, like you said. Though if we want saving to be simple, we want to use only one list so people can export it and import it (long lists take forever to save, so exporting would make it go faster).
Yeah... Anyways I think we should combine the last two ideas. 15*15 or 20*20 tiles + a list that gets bigger only with tall builds. With 20*20 the map would only start out with about 250 items.
I like how small the images are though- it makes it so you have to play in presentation mode.
Well, I wouldn't like to force anyone to do anything.
Increasing the size to 15*15 shouldn't be an huge difference... To 20*20 maybe it'd be but remember, we want it to be as fast and versatile as possible.
Anyway I'll see if I can improve the generating speed by implementing my suggestions to Necro's last version.
Last edited by technoguyx (2011-02-16 12:13:58)
Offline
technoguyx wrote:
Sunrise-Moon wrote:
technoguyx wrote:
Yeah... Anyways I think we should combine the last two ideas. 15*15 or 20*20 tiles + a list that gets bigger only with tall builds. With 20*20 the map would only start out with about 250 items.I like how small the images are though- it makes it so you have to play in presentation mode.
Well, I wouldn't like to force anyone to do anything.
Increasing the size to 15*15 shouldn't be an huge difference... To 20*20 maybe it'd be but remember, we want it to be as fast and versatile as possible.
Anyway I'll see if I can improve the generating speed by implementing my suggestions to Necro's last version.
No wait! Let me update now!
Offline
Ok, it's updated.
Here.
I think I just made improvements to the movement or something, nothing big.
technoguyx wrote:
Sunrise-Moon wrote:
technoguyx wrote:
Yeah... Anyways I think we should combine the last two ideas. 15*15 or 20*20 tiles + a list that gets bigger only with tall builds. With 20*20 the map would only start out with about 250 items.I like how small the images are though- it makes it so you have to play in presentation mode.
Well, I wouldn't like to force anyone to do anything.
Increasing the size to 15*15 shouldn't be an huge difference... To 20*20 maybe it'd be but remember, we want it to be as fast and versatile as possible.
Anyway I'll see if I can improve the generating speed by implementing my suggestions to Necro's last version.
I made a 20*20 grass block, and it looked too big. I'll see what 15*15 is like.
SeptimusHeap wrote:
Dang. Could you let me be part of the collab
![]()
Pwetty please?
Agh. I don't want to have too many people in this collab, but you're awesome at Scratch...
Fine, but you're the final person. Everyone hold me to it if someone else tries to join, ok?
Offline