Hi! I was wondering how to make an infinite 2D tile grid with multiple layers for an extended version of shapez.io in Snap. does anyone have some ideas?
Normally you would store a grid list containing ids for every grid space, but if you want it infinite, you only need to have a list of all the objects and their positions (not necessarily in order). As for multiple layers, just add a layer value in the list. Here's an example of what that could look like.
Then when an objects gets on screen, just display it. When it's off-screen don't.
I'm assuming you know how to make a scrolling game, if not, you can watch a griffpatch video about it, then adapt it to this infinite scrolling grid, and in snap (preferably using snap features to make life easier and less complicated).
Ah, i'll try to make that!
uhm, is it supposed to be getting this laggy?
project
I really would like to learn more about these things.
same
i think i can prototype something, give me a min
ok
i think it's because of the number of stamps it has to create. make it so it only makes stamps for the squares visible.
yes, but even with less then a full screen of squares, its super laggy.
that's snap for you
it doesn't work very well with games
you really have to optimize your code to get a smooth-running game. a lot of optimization.
To be fair, we just had a con with a lot of very skilled people doing some absolutely impressive things with snap and no obvious slow-downs.
The thing with snap, is it's not an engine, neither is scratch to be honest, what they are is educational toolkits designed to teach the framework needed so you you can look at other engines and understand what they are doing.
An equivalent to Griffpatch in snap! would be extremely useful for a lot of people and also raise the profile of snap as well, because a lot of what he does is workarounds for scratch limitations and everything he can do in scratch would be dwarfed by what snap can do, by an absolute long shot.
I've been trying to do this myself, but because I'm old and focused on games I grew up with, Quake in particular, I get lost trying to translate source code designed to make 486's do exactly what they shouldn't be able to do, and a significant amount of John Carmack's code is designed to speak to or thwart those limitations, limitations that Snap! abstracts away.
Snap! is right to do so, but I'd still love to be able to use snap's stepping system on that code. As I've said here before and in a disastrous presentation myself at snapcon! (I mean it might not have been, but my brain is telling me I bombed. Brains can be great at lying(Not in this case imo)) Is I can't read text code... or more accurately, when I have a tool like Snap! why do I have to use text, why can't I drag and drop text into snap and have it work?
As my previous post says, that's not the goal of Snap! Nor should it be, but it is MY goal.... but I'm nowhere near as capable as my ambitions LOL. sigh
i think you could reduce the lag by first making sure that the tile is on screen before using its data by using (keep items < > from (list) ) and this boolean
In this custom block, you could replace the loop by [set |a| to (get |layer1| in (grid) ) ]
You could also set the backround color to grey so you don't have to fill it every time
do you have a project link for the rectangle collision?
https://snap.berkeley.edu/project?username=poussin&projectname=infinite%20grid%20remix i remixed the project to make sure tat only te tiles in the screen are "printed"
This feels slower to me, also feels like it slows down much quicker. Nice idea tho.
As a counter point, do you need an infinite grid or just a way to move within a grid that's larger than the stage? Because setting a max-size and/or a wrap function might be a better option.
What do you call a "wrap function" ?
Here's my stab at creating an infinite scrolling engine. I might have made it in a very complicated way, but at least it works. It's also a bit laggy, but that's because I'm using clones instead of stamping.
Here's how it works (there's an explanation in the project).
- There's an objects list, which is similar to my first example, but a little different.
- We start by dealing with movement, which is just camera based.
- If the camera was moved, broadcast "update objects"
- In the object sprite, we check for, when I receive "update objects"
- Check if the object info variable is empty, if so, it's the original sprite.
- Create a list of all the currently on screen objects, aka object info from all the clones.
- Filter out all the currently on screen objects from the objects list, aka, find the new objects.
- Discard the objects that are off screen
- Loop through the new list, set the object info variable, then create a clone.
- Reset the object info variable to continue in the next loop.
- As a clone, next we run the object code, positioning and extra things (in this project, set the pen color).
- Check if clone if off screen, or no longer exists in the objects list. If so, it will delete the clone.