create endless terrain randomly change at run time

Games
#1 
I want to create an endless terrain that randomly changes at run time. The width of the screen is 480px. I use 8 pictures 240 px width which i want them to randomly change.That is to say, 2 of the 8 images will be shown moving, at same time, on the screen and when one of them gets out of the screen, it will be randomly replaced with one of 6 rest.
that is what i have done until now: 





[code]
------------------ the imgs var:
local terrain1 = display.newImage("image/ground/ground1.png") -- add img to var terrain1
 ... -- etc.

----------------- add imgs on table:
local ground = { -- table name
{ img = terrain1, move = true }, -- add img var and bool var (to give permision to move or not)
{ img = terrain2, move = true }, -- etc. 
 ...
}

------------------ the function:
function terrainMove()

for a = 1, #ground, 1 do -- for all img on the table

if((ground[a].img.x) \< -120) then -- if the position of img is outside screen (img with = 240)
 (ground[a].img.x ) = 600 -- sets img to 600px
 ground[a].move = false -- set move var to false in order be posible to be chosen 

 if (ground[a].move) == false then -- if var is false then
 local num = math.random ( 1, 8 ) -- the random number
 ground[num].move= true -- choose img and set var to true to be used latter 
 end

 if (ground[a].move) == true then -- if var is true
 (ground[a].img):translate(speed \* -1, 0) -- move the img
 ground[a].move = true -- while is moving set move var to false in order not be posible to be chosen
 end

end

timer.performWithDelay(1,terrainMove, -1) -- call function
[/code]

If i use the choise from another example in the forum:

ground[#ground] = display.newImage( groupTerrain, "image/ground"..num..".png", ground[#ground-1].x + ground[#ground-1].contentWidth/2, 200 )

shall be a delay while loading img from file every time?

Thanx!
[import]uid: 182030 topic_id: 33959 reply_id: 333959[/import]

#2

Hi Gregory,
One question before I give you a more complete answer: does the ground/terrain need physical sensory capability (physics engine bodies) like the endless hills/terrain in “Tiny Wings”? Or is it only a background decorative aspect of the game? I can suggest 2 methods for your scenario, but which one I suggest depends on this collision issue.

Best regards,
Brent
[import]uid: 200026 topic_id: 33959 reply_id: 134976[/import]

#3

Hi Gregory

To solve the first issue, about loading delays. What you need to do, as the level is loading is to load each image and then hide the image from the user. You do not need to assign physics to these images, just load them and hide them. This way they are stored in the devices texture memory.

Now every time you try to load the image again it uses the one in memory instead of accessing the disk.

The second issue, the level generation. This needs some thought on your part to achieve something really useful. I would not use images the size of one set screen. Try make slice, say 128px or 256px wide so you can adjust for different setups.

The next step is to design connectors, that is I bet you were insuring that each start point and end point of an image lined up so you could texture seamlessly. You should design these sections where the connectors are say 50px, 100px, 150px etc… so different sections won’t in fact connect together. but thats not an issue. Just create lots of them.

The next step is to create a function that generates a section, applied physics etc… and knows about each section, the height of the start and endpoints etc…

You then extend this function so the next section is creates start point is at the same height as the pervious connectors end point. It can scan as array of all possible sizes and will only select one at random that matches the start/end point heights.

This will then create a level with a really random layout rather than with just 5 or 6 pieces repeating over and over which will become noticeable.

Matt [import]uid: 5354 topic_id: 33959 reply_id: 134979[/import]

#4

Brent Sorrentino and Matthew Pringle, thank you both for your replies.
Brent, the terrain i want to use it is only a background decorative aspect of the game, so i m waiting your suggestion according to that. Thank you in advance! [import]uid: 182030 topic_id: 33959 reply_id: 134997[/import]

#5

Hello Gregory,
Thanks for the update. In this case, instead of moving every terrain object in a loop, you should add all of them to a separate Display Group and move that group as a whole unit. This is far more efficient and easier to manage.

You should be able to manage this entire thing with just 3 or 4 terrain pieces. The process would go like this, basically:

  1. create and use an image sheet to store all 8 chunks of your terrain. Why? Because if you try to load individual image files in Runtime (when you swap out a terrain chunk), you might see a minor skip as Corona has to load that image into the texture memory cache. Using an image sheet effectively pre-loads all pieces into memory and Corona can access them much, much faster. You can see the basic image sheet setup in my blog post here: http://www.coronalabs.com/blog/2012/10/02/animated-sprites-and-methods/

  2. add 4 random terrain pieces to screen (picking from the sheet at random) and add them to a display group. The furthest LEFT chunk should actually be at x=-240 (not x=0). I recommend this because you might eventually deal with “wider” or “taller” screens like the iPad or iPhone5, if you’re using letterbox display, and there would be a thin letterbox bar that you need to fill with content.

  3. start moving the entire GROUP to the left, and start a Runtime listener that checks its X position. When it moves -240 pixels from the previous position (which you must keep track of), you delete the off-screen chunk and then add a new chunk at the end of the right-most side, again picking at random from the image sheet. You can calculate its X position easily enough because you know how many chunks are on the screen, and the size is consistently 240 in width.

That’s basically it. If you have further questions, let me know and I’ll try to help more.

Best regards,
Brent
[import]uid: 200026 topic_id: 33959 reply_id: 135025[/import]

#6

Hi Gregory,
One question before I give you a more complete answer: does the ground/terrain need physical sensory capability (physics engine bodies) like the endless hills/terrain in “Tiny Wings”? Or is it only a background decorative aspect of the game? I can suggest 2 methods for your scenario, but which one I suggest depends on this collision issue.

Best regards,
Brent
[import]uid: 200026 topic_id: 33959 reply_id: 134976[/import]

#7

Hi Gregory

To solve the first issue, about loading delays. What you need to do, as the level is loading is to load each image and then hide the image from the user. You do not need to assign physics to these images, just load them and hide them. This way they are stored in the devices texture memory.

Now every time you try to load the image again it uses the one in memory instead of accessing the disk.

The second issue, the level generation. This needs some thought on your part to achieve something really useful. I would not use images the size of one set screen. Try make slice, say 128px or 256px wide so you can adjust for different setups.

The next step is to design connectors, that is I bet you were insuring that each start point and end point of an image lined up so you could texture seamlessly. You should design these sections where the connectors are say 50px, 100px, 150px etc… so different sections won’t in fact connect together. but thats not an issue. Just create lots of them.

The next step is to create a function that generates a section, applied physics etc… and knows about each section, the height of the start and endpoints etc…

You then extend this function so the next section is creates start point is at the same height as the pervious connectors end point. It can scan as array of all possible sizes and will only select one at random that matches the start/end point heights.

This will then create a level with a really random layout rather than with just 5 or 6 pieces repeating over and over which will become noticeable.

Matt [import]uid: 5354 topic_id: 33959 reply_id: 134979[/import]

#8

Brent Sorrentino and Matthew Pringle, thank you both for your replies.
Brent, the terrain i want to use it is only a background decorative aspect of the game, so i m waiting your suggestion according to that. Thank you in advance! [import]uid: 182030 topic_id: 33959 reply_id: 134997[/import]

#9

Hello Gregory,
Thanks for the update. In this case, instead of moving every terrain object in a loop, you should add all of them to a separate Display Group and move that group as a whole unit. This is far more efficient and easier to manage.

You should be able to manage this entire thing with just 3 or 4 terrain pieces. The process would go like this, basically:

  1. create and use an image sheet to store all 8 chunks of your terrain. Why? Because if you try to load individual image files in Runtime (when you swap out a terrain chunk), you might see a minor skip as Corona has to load that image into the texture memory cache. Using an image sheet effectively pre-loads all pieces into memory and Corona can access them much, much faster. You can see the basic image sheet setup in my blog post here: http://www.coronalabs.com/blog/2012/10/02/animated-sprites-and-methods/

  2. add 4 random terrain pieces to screen (picking from the sheet at random) and add them to a display group. The furthest LEFT chunk should actually be at x=-240 (not x=0). I recommend this because you might eventually deal with “wider” or “taller” screens like the iPad or iPhone5, if you’re using letterbox display, and there would be a thin letterbox bar that you need to fill with content.

  3. start moving the entire GROUP to the left, and start a Runtime listener that checks its X position. When it moves -240 pixels from the previous position (which you must keep track of), you delete the off-screen chunk and then add a new chunk at the end of the right-most side, again picking at random from the image sheet. You can calculate its X position easily enough because you know how many chunks are on the screen, and the size is consistently 240 in width.

That’s basically it. If you have further questions, let me know and I’ll try to help more.

Best regards,
Brent
[import]uid: 200026 topic_id: 33959 reply_id: 135025[/import]