Composer, External Modules, OOP & Code Design. Beginner needing advice.

Hi there Corona community,

——————————————————————————————————————————————————————————

I’m creating a game using composer & trying to implement OOP practices. I’m a beginner programmer and this will be my first app.

——————————————————————————————————————————————————————————

In my game, any objects that have complex behaviours are created & handled in separate classes/modules.

 

When the levels are first created these objects are instantiated in scene:show but when they are destroyed they are recreated by their own class modules.

When these objects are recreated by their own modules they go through transitions & timers which change things like scale & position & setFrame, etc.

 

When I leave the gameplay scene my transitions & timers from the modules are still running & cause runtime errors.

So I’m wondering if the whole layout of my game & code is completely wrong.

 

I’m after some general guidelines for what I can put in the classes (modules) & what has to go in the composer scenes. 

——————————————————————————————————————————————————————————

Q1). I’ve been passing the sceneGroup as a parameter from the composer level to any module that instantiates an object itself. Is this OK?

 

Q2). Is it simply that all timers,transitions & replacement of objects has to occur in the composer scene? 

 

Q3). Should classes & modules only contain object attributes & simple object methods/functions that are not based on timers or transitions?

 

Here are 3 good links to checkout about OOP with lua/corona:

http://theindiestone.com/forums/index.php/topic/8023-simple-lua-oop-without-metatables/

http://coronalabs.com/blog/coronageek/corona-geek-103/

http://coronalabs.com/blog/coronageek/corona-geek-107/

The first link is OOP as simple as it gets.  The other 2 links are about 30log OOP, and are discussed on corona geek podcast.  

As far as the timers and transitions.  Each transition and timer you start during that composer scene, should have a handle, that you can call when you destroy the scene and cancel all those timers or transitions for any objects effected by them.  

Answers to your questions:

A1. I do not pass the sceneGroup to the module/object.  I get the image from the module via the object I created, and insert that into the sceneGroup in the ‘show’ function or ‘create’ function of the composer scene module… depending on what I am doing.  I think there are ups and downs to either way. I like the way I do it. This way works for me. Please review the links above and opinions of others, to get a better understanding of what will work best for you.

A2. They do not ‘have to’ all be done in the composer module. But, when you destroy the composer scene module, you should make sure any of these objects are all ‘cleaned-up’.  Display objects created by those modules need to be removed and nil, etc…

A3. IMHO no.  I think the ideal way is that the module/class handle as much of itself as it can. But, depending on what you are doing, you may find it easier to create the transition in the composer scene; just use the object’s image in the transition call. Both ways can work. 

I am not sure, how the class/objects are being re-created when they are being destroyed …  you may have to post you code sample or explain that further to get an answer to that issue.

Good luck

Bob

Thanks for the great reply Bob, much appreciated.

I’ve just woken up here in sunny Western Australia, but will look into those links as soon as I have time.

Object re-creation. When an object has been destroyed (but before I removeSelf and nil) I grab it’s object num and starting locations and use those to call the object constructor. The object num allows me to reference a table of data with graphic, speed, health, etc.

i.e.   -   spaceShip:new(shipToReplace.num, shipToReplace.locX, shipToReplace.locY, sceneGroup)

This is the same constructor used by my composer scene when it calls for creation of a spaceShip, only difference is in name of params where shipToReplace is shipToCreate.

Was that the code line you needed to see ?


I’m not sure if this should be a new post but I have a couple of other questions if you can point me in the right direction.

Q4). In my game there is multiple items to collect and multiple enemies all moving around and quite a lot going on at all times. There can be 50 -100 objects doing their own thing in each level. It’s working relatively well (minus a few bugs), but could you offer any advice or point me to some resources on how to save everything in a level (including all object’s status and position and direction of travel) so that a level can be resumed following a user interruption (phone call, flat battery, etc).

Q5). In a level that is not in space but on a planet I have 3 streets the ship can fly on horizontally across the screen. Roughly splitting the screen in quarters horizontally. When the ship leaves the edge of the screen (R or LHS) it randomly emerges on another road. There are various height buildings on each street. A building may be on the 1st road closest to the player but reach almost to the top of the screen thus obscuring the 2 streets behind.  I’ve struggled finding anything on this type of graphic layering problem other than_ object:toFront( ) . _This doesn’t help me as there can be multiple ships and multiple buildings and they need their own level of depth in the z-layer. Is there a way to handle z-layering of the spaceShip so that when it emerges on road 1 it will travel in front of the building on road 1 but when it later traverses roads 2 or 3 it will travel behind the tall building on road 1?

Thanks again :slight_smile:

bana7474,

I would need to see a larger segment of the code to understand what exactly is going on, and properly comment on it.  It sounds like  you have a table that I guess holds information about each ship.  You use that information to create the ship objects; calling the ship module with spaceShip:new( …).  But, it is really hard to analyze with out all the spaceShip module and the composer scene module code.

I am not sure if you are creating a ‘replacement’ ship as the composer scene is being closed out(destroy function), or when that is happening.  When is the ‘data table’ you mention created and what is it’s scope? Is it local to the show function? Is it a global table? All this could make a difference.  Although, if you have 50-100 objects all interacting on a level with little to no issue, it seems to me you have something going right. 

I think once you check out those links, some of these things will answer themselves.

regarding your last 2 questions:

A4: I use a module called ggdata  (here is a link to that :  https://github.com/GlitchGames/GGData) … Glitch Games has been kind enough to share that with the corona community for some time now.  But there are several other options on saving level data you can find on the corona forums as well.

I usually create a table called gameData and that table holds all the flags and fields I want to save for the game and the level. When a game starts I pull in from the GGData (json)files that are saved on the device; all the data goes into the gameData table.  I then update that gameData table as the game evolves. When a level ends or just before a level begins, I save all that gameData table stuff back to the ggdata (json)files on the device.  So, if the game does crash or the users device goes kaput… they can at least possibly resume a future game at the last completed level.

Also, search the forum/blog on corona, as Rob Miracle recently posted a tutorial on saving level data; that is likely to be very helpful.

A5: I have never done any of the 2.5d stuff.  Which sounds like what you are doing. The graphics 2.0 of corona has the ability to do some of that, but I have not played with that stuff.  Search the forum/blog again as I recall seeing some stuff (maybe tutorials) on just that kind of issue. Sorry I can’t help on that.

Good luck… sound like you are creating a solid game.

Bob

Hi Bob, sorry was called away for a few days. 

Thanks so much for your help again, I think you’ve solved my main problem; I’ll move my transitions and timers into the composer scene.

That alone will take me quite a few days of refactoring. The game has gotten quite large & I can only work on it in my spare time, which is not a lot. But from your answer & a response I also had from Dr Burton, this seems to be the plan.

Thank you for your help with all my other questions as well, you’ve given me plenty of ideas and resources to start looking through.

Appreciate your time.

Matt. 

Here are 3 good links to checkout about OOP with lua/corona:

http://theindiestone.com/forums/index.php/topic/8023-simple-lua-oop-without-metatables/

http://coronalabs.com/blog/coronageek/corona-geek-103/

http://coronalabs.com/blog/coronageek/corona-geek-107/

The first link is OOP as simple as it gets.  The other 2 links are about 30log OOP, and are discussed on corona geek podcast.  

As far as the timers and transitions.  Each transition and timer you start during that composer scene, should have a handle, that you can call when you destroy the scene and cancel all those timers or transitions for any objects effected by them.  

Answers to your questions:

A1. I do not pass the sceneGroup to the module/object.  I get the image from the module via the object I created, and insert that into the sceneGroup in the ‘show’ function or ‘create’ function of the composer scene module… depending on what I am doing.  I think there are ups and downs to either way. I like the way I do it. This way works for me. Please review the links above and opinions of others, to get a better understanding of what will work best for you.

A2. They do not ‘have to’ all be done in the composer module. But, when you destroy the composer scene module, you should make sure any of these objects are all ‘cleaned-up’.  Display objects created by those modules need to be removed and nil, etc…

A3. IMHO no.  I think the ideal way is that the module/class handle as much of itself as it can. But, depending on what you are doing, you may find it easier to create the transition in the composer scene; just use the object’s image in the transition call. Both ways can work. 

I am not sure, how the class/objects are being re-created when they are being destroyed …  you may have to post you code sample or explain that further to get an answer to that issue.

Good luck

Bob

Thanks for the great reply Bob, much appreciated.

I’ve just woken up here in sunny Western Australia, but will look into those links as soon as I have time.

Object re-creation. When an object has been destroyed (but before I removeSelf and nil) I grab it’s object num and starting locations and use those to call the object constructor. The object num allows me to reference a table of data with graphic, speed, health, etc.

i.e.   -   spaceShip:new(shipToReplace.num, shipToReplace.locX, shipToReplace.locY, sceneGroup)

This is the same constructor used by my composer scene when it calls for creation of a spaceShip, only difference is in name of params where shipToReplace is shipToCreate.

Was that the code line you needed to see ?


I’m not sure if this should be a new post but I have a couple of other questions if you can point me in the right direction.

Q4). In my game there is multiple items to collect and multiple enemies all moving around and quite a lot going on at all times. There can be 50 -100 objects doing their own thing in each level. It’s working relatively well (minus a few bugs), but could you offer any advice or point me to some resources on how to save everything in a level (including all object’s status and position and direction of travel) so that a level can be resumed following a user interruption (phone call, flat battery, etc).

Q5). In a level that is not in space but on a planet I have 3 streets the ship can fly on horizontally across the screen. Roughly splitting the screen in quarters horizontally. When the ship leaves the edge of the screen (R or LHS) it randomly emerges on another road. There are various height buildings on each street. A building may be on the 1st road closest to the player but reach almost to the top of the screen thus obscuring the 2 streets behind.  I’ve struggled finding anything on this type of graphic layering problem other than_ object:toFront( ) . _This doesn’t help me as there can be multiple ships and multiple buildings and they need their own level of depth in the z-layer. Is there a way to handle z-layering of the spaceShip so that when it emerges on road 1 it will travel in front of the building on road 1 but when it later traverses roads 2 or 3 it will travel behind the tall building on road 1?

Thanks again :slight_smile:

bana7474,

I would need to see a larger segment of the code to understand what exactly is going on, and properly comment on it.  It sounds like  you have a table that I guess holds information about each ship.  You use that information to create the ship objects; calling the ship module with spaceShip:new( …).  But, it is really hard to analyze with out all the spaceShip module and the composer scene module code.

I am not sure if you are creating a ‘replacement’ ship as the composer scene is being closed out(destroy function), or when that is happening.  When is the ‘data table’ you mention created and what is it’s scope? Is it local to the show function? Is it a global table? All this could make a difference.  Although, if you have 50-100 objects all interacting on a level with little to no issue, it seems to me you have something going right. 

I think once you check out those links, some of these things will answer themselves.

regarding your last 2 questions:

A4: I use a module called ggdata  (here is a link to that :  https://github.com/GlitchGames/GGData) … Glitch Games has been kind enough to share that with the corona community for some time now.  But there are several other options on saving level data you can find on the corona forums as well.

I usually create a table called gameData and that table holds all the flags and fields I want to save for the game and the level. When a game starts I pull in from the GGData (json)files that are saved on the device; all the data goes into the gameData table.  I then update that gameData table as the game evolves. When a level ends or just before a level begins, I save all that gameData table stuff back to the ggdata (json)files on the device.  So, if the game does crash or the users device goes kaput… they can at least possibly resume a future game at the last completed level.

Also, search the forum/blog on corona, as Rob Miracle recently posted a tutorial on saving level data; that is likely to be very helpful.

A5: I have never done any of the 2.5d stuff.  Which sounds like what you are doing. The graphics 2.0 of corona has the ability to do some of that, but I have not played with that stuff.  Search the forum/blog again as I recall seeing some stuff (maybe tutorials) on just that kind of issue. Sorry I can’t help on that.

Good luck… sound like you are creating a solid game.

Bob

Hi Bob, sorry was called away for a few days. 

Thanks so much for your help again, I think you’ve solved my main problem; I’ll move my transitions and timers into the composer scene.

That alone will take me quite a few days of refactoring. The game has gotten quite large & I can only work on it in my spare time, which is not a lot. But from your answer & a response I also had from Dr Burton, this seems to be the plan.

Thank you for your help with all my other questions as well, you’ve given me plenty of ideas and resources to start looking through.

Appreciate your time.

Matt.