What's the best way of Randomizing an 'infinite' map

I’m trying to achieve a (possibly) infinitely generating obby, using pre-built modules the code takes from Replicated storage and places in front of the current module the player is on. (player triggers the need through a Remote Event)

My problem is how do I go about coding it the best way…

Server-side problems:
I’m placing the modules into a table on the server-side code, but It’s not allowing me a lot of control for what SHOULDn’t come next (so it’s not repetitive or boring) And I’m at a loss on how to make sure the Map Modules don’t repeat…

local prevP = prevmod:GetPrimaryPartCFrame()
local prevEnd = prevmod.Other.Endbase
local lastmods = lastchoice:GetDescendants()
local prevEndP = prevEnd.Position
   prevEnd.ActiveorNot.Value = false
		index = math.random(1,#mods)
		print(index)
		local originmod = mods[index]
		mod = originmod:Clone()		mod:SetPrimaryPartCFrame(CFrame.new(prevP.X,prevEndP.Y,prevEndP.Z+30))
		mod.Parent = nodes
		originmod.Parent = lastchoice
		prevmod = mod
 --			return mods[index].name
	if count >= 2 then
		lastmods.Parent = lastchoice.Parent.nodes
		count = 0
	else
		count = count + 1
			print(count)
		end
 	end

Player(Client)-side problems
At the moment I simply have the player send a Ray-cast down (and when it hits a certain part) sends a event to the server.
How should I secure this so a Client wouldn’t be able to spam the Remote-Event?
Or should I use another system for deciding when to add another module to the world?

 if part and part.Name == "Endbase" and part.ActiveorNot.Value == true then
				print("READY GEN _ "..part.name)
			RemEve:FireServer()
 			else

One other issue
Also, I need a good way to destroy the old modules behind the player… This is both for performance and a specific game-play feature I have in mind.
Would it be best to send a ray-cast to decide which module to destroy?

I’m coding this mostly by myself as a beginner coder, and so probably make all sort of horrid coding mistakes, so please forgive any eye-sores.

Thanks for any help, I might figure some of the things out myself, but Any and All help is appreciated!

5 Likes

Well, you need some repetition if you have a finite pool of modules, so the question is really how many steps before a repetition is acceptable. There are simple ways to do this. The most trivial is rejection sampling: you remember the last N modules used, and randomly pick a new one until it’s not in the recently-used queue.

If you have a lot of modules, and you want them all to be used before any repeats occur (called random exhaustive usage), you would randomly shuffle the pool and completely consume it. When you reshuffle, you don’t want the first element of the new shuffle to be the last element of the previous, so you have to special-case that. Typically, you would pick a few modules from the early-to-middle of the last shuffle at put them at the start of the new shuffle, then randomize the rest.

1 Like

That’s what I meant about ‘no repetition’. So thanks!

How would you go about reshuffling them?

Currently I’ve tried taking the modules out of the “current choices” folder and calling the table function again to ‘refresh’ the list, but it’s been a bit buggy…
the code not stopping and putting them back into the table when the pool is exhausted)

Thanks again for your help.

EDIT:
Ok, I’ve pretty much done for the various issues.
The Randomizer is a simple system similar to above but more complex :stuck_out_tongue:
The Security problem is solved by a check on Server with a ray.
And the last one is exactly what I’ve said.

Ok, I see now that I could have wrote this post a bit better. It’s not completely clear what I want to know…
I’ll edit it. but first!

Player(Client)-side problems
At the moment I simply have the player send a Ray-cast down (and when it hits a certain part) sends a event to the server.

The question about the player-sided code was intended to ask HOW WOULD I MAKE THIS MORE SECURE, because at the moment a player could spam the remote-event and the server-side code would just continue to add more modules to the map without stopping.

The last ‘issue’ will probably use a part that sends a ray and decides to destroy the module from the server.

I’m not sure what your plans are to make this into a full-fledged marketable game or if it’s just a project to showcase your skills, however I think a very simple and efficient mode of securing the game in this case would be just to simply have the servers set to single player. It would remove the incentive to exploit that particular remote. However if you need to have larger servers or intend to tie this generating obstacle course into another game, I apologize for this reply.

1 Like

My plans are in flux :stuck_out_tongue:
Actually It’s definitely going to be more the project at first, but it might be later expanded to a fully fledged title.
As for the suggestion, that would be one way. But, I have sorta wanted it to be a multiplayer experience (As in playing with friends or whoever). So…

Thanks for the reply and suggestion though!

1 Like