I want the player to able to move horizontally infinitely.
And I want it to be interactable. then a ship could go through the Pacific ocean, we can also build some structures.
It seems I should move tiles that are too far away from the camera, to the opposite side of the map, Every camera move…
So that’s the problem, How can I move those bunch of tiles,
and how do I detect tiles that need to move to the opposite side of map?
Thanks for reading this, any help would be appreciated!
Make a map that is two maps side by side… When you hit the end of the map to the right you jump the view back to the map on the left. Basic scrolling trick. Same for scrolling left, in reverse.
You’ll find a smooth scroll is hard to get for horizontal. It’s always been like that due to the way the screen is displayed. Mega demo scrollers were made by a computer called the Amiga. No other computer has ever done it better. So you can’t be too picky when it come to totally smooth with horizontal scrolling.
In my opinion, it will be too laggy if I make a map copy on each side…
But I just made this,
Pretty cool, but it’s not continuous.
And there might have been a misunderstanding because of the image I uploaded, but it’s not necessary to show the entire world map. For example, if Alaska is on the far right of the map, there’s no need to have another Alaska on the far left.
So I think it is best (for now) to move tiles that are on opposite side from the camera, to the another side of the map, when the camera moves. because It’s more performant and interactive.
But I don’t even know how to start this!!
If you know how to achieve this, or if you have any ideas, please let me know!
Around how many parts are in your map? If the view size is no larger than the map, then only a small portion of the map would need to be wrapped around at a time. In my testing it took a little less than 3ms to move 10k parts. Welding them together makes moves a lot faster.
Also, does the map need to have physics or is it a purely visual effect?
Are parts required to achieve this? There is a whole lot of GPS data (ESRI shape files, bathymetry datasets, etc.) that contain continuous pointsets that could easily be drawn on a GUI.
I mean, don’t get me wrong, it looks neat already, and hats off to you for getting this far with it. But there could be more efficient drawing methods to achieve this without using tile sets.
This isn’t fully solved yet but I think you’re close. I would think you can just move tiles that go too far from the camera to the opposite side.
Rough idea of how I would think about this:
local WRAP_THRESHOLD = 512 -- change this based on your map width
for _, tile in ipairs(tilesFolder:GetChildren()) do
local offsetX = tile.Position.X - camera.CFrame.Position.X
if offsetX > WRAP_THRESHOLD then
tile.Position -= Vector3.new(WRAP_THRESHOLD * 2, 0, 0)
elseif offsetX < -WRAP_THRESHOLD then
tile.Position += Vector3.new(WRAP_THRESHOLD * 2, 0, 0)
end
end
Just make sure the camera is moving and not the player if you’re doing a fixed-map setup. You could run this every frame with RunService.RenderStepped, but that’s probably not the most optimized way if you’re dealing with a lot of tiles.
A better way would be to check when the camera moves far enough with RunService.Heartbeat.
It’s a lot more performant than cloning full maps or relying on textures if you want stuff like interactions and collisions.
let’s see
it seems there are a little more than 10k parts… well, but it’s okay.
And welding, isn’t that for unanchored parts as far as I know?
Also, does the map need to have physics or is it a purely visual effect?
No, It will need only a purely visual effect. They are all anchored. No need physic effects.
I think yes, because the parts are easy to edit. I also thought about using editableImage, but I have no ID to verify. And thank you for the compliment!
In that case, I can see why you don’t want to be moving parts around!
I’m guessing you need to set the color of a region (many parts) all at once. If that’s the case, you could try grouping parts within a region into a union (or use one mesh per region). If there are too many regions in the map though, draw calls could become a problem.
Using EditableImages, you could avoid the draw call issue by splitting the whole map into just a few meshes. The meshes’ UVs could be assigned based on region, so that only one texel needs to be set to change the color of an entire region.
If you do end up needing to duplicate parts (without moving any), you wouldn’t need more than double the amount you have (400k). But then you would have to set the colors of twice as many parts, and 200k is already quite a lot…
