I really miss "World Limits" in Corona

Coming from Torque2D previous to using Corona, I find myself suddenly missing an awesome feature that Torque2D had, primarily useful for game developers:

World Limits!

To summarize for those who never used Torque2D, “World Limits” are basically a user-defined region: this could be the exact border of the screen, or it could extend beyond the visible limits of the screen, in any direction. All other objects, physical bodies or not, could then be set to interact with these bounding limits. Upon contact with a world limit, objects could then be handled in a myriad of ways: “Kill” to destroy it, “Bounce”, “Stick”, or “Slide”… or even a custom function call.

World Limits, while perhaps trivial to some developers, were incredibly useful for game designers. Assume you have a scrolling game like “Tilt Monster”. Instead of manually checking each object’s Y position as it scrolls across and off the screen, Torque2D would have allowed Jon to simply say (in code) “When this object hits the top world limit, I want to move it back to the bottom, off the screen, and resume its scrolling.”

Another example would be a game where objects (bullets, balls, platforms, enemies, whatever) scrolled around and occasionally off the screen. World limits could be set as 100+ pixels larger than the screen in all directions, and when any object hit those limits, it would be deleted… far easier for the game to clean up after itself!

Currently, Corona doesn’t have anything to match this in ease or simplicity. I know there are dozens of higher priorities than this, and we have a couple “workarounds” (i.e. Runtime listener checking each object’s location, or even invisible collision boxes on all 4 sides, etc.). Just thought I’d put my feedback in for this, as an eventual addition to Corona.

Brent
[import]uid: 9747 topic_id: 5840 reply_id: 305840[/import]

Instead of manually checking each object’s Y position as it scrolls across and off the screen, Torque2D would have allowed

what do you think Torque2D is doing underneath the hood?

[import]uid: 6645 topic_id: 5840 reply_id: 20055[/import]

True, it’s doing the exact same thing. But I would guess that anything “under the hood” is considerably faster than something done via scripting/Lua functions. Whether or not this results in a noticeable performance increase for the user is open for debate, and would largely depend on the game, number of objects, etc. Torque2D just implemented all of this in a very cool way. Still, it’s somewhat like comparing apples and oranges, and Corona does alot of things better than Torque2D ever did.

Speaking of which (to anybody who came from Torque) it looks like the company is back in business after their former owners “closed up shop” last November or so. Another company bought them up and it looks like development on their core products will resume. Regardless, I am now dedicated to Corona and I can’t see much reason to return to T2D, except for World Limits! (just kidding)
[import]uid: 9747 topic_id: 5840 reply_id: 20064[/import]

i wasn’t going to mention that…shh :wink:

well yes under the hood is always better true, but then it ties the system into one method that may not be needed.

however we are pushing for some kind of offscreen auto-culling etc. maybe your feature could be tied into the physics engine? (not sure if you can set Box2D world limits?) and then an event fires when an object reached the boundaries?

I think it’s always a good idea to draft out a proposal along with commands you imagine it would make available

eg

[lua]physics.setWorldLimits(-1000,-1000,1000,1000)[/lua] etc

[lua]if(event.type==“limit”) etc etc[/lua]

[import]uid: 6645 topic_id: 5840 reply_id: 20070[/import]

oh cool feature

can you write up a spec document and send it to me and see what we can do. no promises but i would like to have it as a feature that we may be able to implement …

send me a detail spec (sample code, etc) and i will add to our feature pile or if you have google docs add it to a google doc place so we can add notes etc then add it as a formal feature request.

c. [import]uid: 24 topic_id: 5840 reply_id: 20071[/import]

Excellent idea jmp909, tying my suggestion into the physics engine! This would cover 95% of the instances where it would matter, omitting only non-physical objects from the culling (and I’m not sure that would even matter much in the overall scheme of game design).

Then, similar to the collision functionality…

local function collideFunction( self, event )  
 --[handle collision]  
end  

…“self” would be the object that “collided” with the World Limits. This would be useful for ensuring complete removal of the object from other areas, i.e. if the user included them in another table for look-up purposes or whatever, or if the object had a Listener applied. In these instances, “self” could theoretically be used as an object handle to remove it from all other tables and ensure proper garbage collection. [import]uid: 9747 topic_id: 5840 reply_id: 20075[/import]

If the objects you want to track are physical you can already easily place 4 simple rectangle objects in the world to create your “World Limits”, then use collision events on the objects to do whatever you want when anything touches one of the boundaries. It might be a few extra lines of code to setup than with Torque, but it’s not that bad. Oh, all right, I’ll do it for you:

  
borderBody = { friction=0.4, bounce=0.8, bodyType="static" }  
  
local borderTop = display.newRect( 0, 0, 320, 1 )  
physics.addBody( borderTop, borderBody )  
   
local borderBottom = display.newRect( 0, 479, 320, 1 )  
physics.addBody( borderBottom, borderBody )  
   
local borderLeft = display.newRect( 0, 1, 1, 480 )  
physics.addBody( borderLeft, borderBody )  
   
local borderRight = display.newRect( 319, 1, 1, 480 )  
physics.addBody( borderRight, borderBody )  

That sets up 4 physical walls surrounding the boundaries of an original iPhone screen. Change the numbers to be whatever size world you want. You could also try just making one single rectangle as big as the world, make it a sensor, and then handle the event when an object stops colliding with the sensor. You’ll still need to write code to handle collision events, but I’m sure Torque requires that as well.

Ok, I cheated. The above code came straight outta Ansca’s docs section of this website. [import]uid: 9422 topic_id: 5840 reply_id: 20083[/import]