@epicurus101 - In general, it’s OK to create a mess first time through while you are solving the problem (especially for us hobbyists). Then you “refactor” to clean up.
Some suggestions on your map code
Avoid hard coding
You’ve hard coded a lot of numbers, eg the loop start and end values like
for y=16,35 do
Better is to (say) create a Settings function where you define variables for all these numbers. Then if you ever want to redesign or tweak the numbers, it’s dead easy to do.
Avoid duplication
Your tablegen function has a lot of duplication of this code, only the x and y items in square brackets change
if math.random(1,100) <= consolprob then
bigmap[x][y+1] = 3
elseif math.random(1,100) <= (branchprob/2) then
bigmap[x][y+1] = 2
else
bigmap[x][y+1] = 1
end
Then there is a variation on this code that only uses consolgen.
This leads me to suggest this function, which works for the first set of cases that use branchprob and consolprob, and the second set, which depend only on consolprob.
function AddNode(X,Y,consolprob,branchprob)
if math.random(1,100) <= consolprob then
bigmap[X][Y] = 3
else
if branchprob and math.random(1,100) <= (branchprob/2) then
bigmap[X][Y] = 2 --only used if branchprob provided
else
bigmap[X][Y] = 1
end
end
end
which means you can reduce that section of tablegen to [unchecked]
for y=16,35 do
for x=1,61 do
local consolprob = (math.abs(x-31) * 3) + (2 *y) + (branchprob*1.5)
if bigmap[x][y] == 1 then AddNode(x,y+1,consolprob,branchprob)
elseif bigmap[x][y] == 2 then
AddNode(x-1,y+1,consolprob,branchprob)
AddNode(x+1,y+1,consolprob,branchprob)
elseif bigmap[x][y] ==3 then
if x>31 then AddNode(x-1,y+1,consolprob)
elseif x<31 then AddNode(x+1,y+1,consolprob)
else bigmap[x][y+1] = 1
end
end
end
end
end
(check I didn’t make a mistake)
You can see that by doing this, your code becomes much more readable and it is much easier to make changes. And all I’ve done is look for repetitive patterns of code, and figured out a function that handles them.
As you’ve noted, if you use local variables with other functions, you have to pass them through as parameters, as I’ve done above.
But don’t get too hung up on local variables. Most of the time, speed is not crucial, after all, you aren’t generating maps 60 times a second, are you? But there is a second reason for local variables, and that is to avoid accidentally using the same global variables twice and overwriting them. A good way to avoid this is to wrap all your maze code (including functions) in a table, like so
Map={}
--run this to set the map up
function Map.Setup(--list all the setup parameters in here--)
--now define global variables within the Map library
--these can be seen and used by *any* code in this project
--but because of the Map prefix they won't collide with
--any variable names used elsewhere
Map.Width = w or 50 --assuming w is a parameter
Map.MaxLength=m or 100
-- etc
Map.tablegen()
end
function Map.tablegen()
--code ---
Map.branchprob= --formula here
--(this is a bit long, so you might use a shorter local name inside tablegen,
--but define Map.branchprob as above, so other functions can get the
--value without having to pass it as a parameter)
--code--
AddNode(x,y) --no need to pass consolprob!
--code--
end
--now AddNode can use the "global" value of consolprob
function AddNode(X,Y)
if math.random(1,100) <= Map.consolprob then
end
EDIT - I meant to include a link to this post, which explains the value of wrapping things like map code in tables
https://coolcodea.wordpress.com/2013/04/12/31-a-lesson-from-the-roller-coaster-demo/
it’s one of those obscurities in code I’m sure many forget about
