Modularity and Scenes

[jaye_b]

I’ve written my code extremely modular. The only coding on the scene page are calls to functions to create the display objects,  a call to a function to initialize the game during willEnterScene, and a call to a function to start the game in enterScene. After that, everything is driven by changes in the display objects’ property values ( via Jon Beebe’s owl.lua.) I also can reuse the same scene page for every level. I just need to direct the json read to the current level’s data. 

Note: Am still coding, so some objects are blocked out and I haven’t written the exit cleanup yet.

I guess I have a best practices question, because it will work either way. It may seem a bit trivial, but in my fervor to move coding off the scene page, it’s kind of stuck in my mind now. The simplest example is a control object that acts as super to the other objects.

Current coding:

level_000.lua

    local group = self.view

– ********************************************************************************************     Control    

    local cb = o_000.create_Cb(); group.cb = cb        

objects_000.lua

local create_Cb = function()    

    local obJ = i_Ctl.getControl()                                   – get control    

    return obJ                                                                 – return control

end

obj_000.create_Cb = create_Cb

Alternate coding:

level_000.lua

    local group = self.view

– ********************************************************************************************     Control    

    local cb = o_000.create_Cb()

objects_000.lua

local create_Cb = function()    

    local scene_ = storyboard.getScene( storyboard.getCurrentSceneName() )   – get current scene

    local group = scene_.view                                                                                    – local group

    local obJ = i_Ctl.getControl()                                                                               – get control    

    group.cb = obJ                                                                             – add object to scene view (group)

    return obJ                                                                                                             – return control

end

obj_000.create_Cb = create_Cb

As I said, it may seem trivial, especially in the above case. However, with subsequent display objects, I pass cb (super to attach objects to) along with the parameters required for the creation of the object.

level_000.lua

– ********************************************************************************************           Anchors

    local anchors = {}; cb, anchors = o_000.create_Anc{ ctrl = cb, dta = d_dta["_anc"], fclr = frg_clr }

    for i = 1, #anchors do group:insert( anchors[i].raw ); end

Alternate:

    local anchors = o_000.create_Anc{ dta = d_dta["_anc"], fclr = frg_clr }

Instead of passing cb, I could

local create_Anc = function()    

    local scene_ = storyboard.getScene( storyboard.getCurrentSceneName() )   – get current scene

    local group = scene_.view                                                                                    – local group

    local cb_ = group.cb

   …

I’ve attached a .pdf of my level_000.lua page. The formatting gets all messed up when I try to load it elsewhere. 

[Develephant]

It’s always good to balance readability, portability, and update-ability in your code.  While I too love to abstract the heck out of my code, it can sometimes backfire and make it harder to work on at a later date.

I try to stick close to an MVC type of structure in my Corona projects.  I use the current “scene” as the controller, and build out modules for the “model” and “view” and then sprinkle in a needed dose of custom events to pass the info between them.

Just something to think about.

Cheers.

[jaye_b]

@develephant

Thanks for your insight. It is definitely something to consider. I think that this game is my stab at embracing OOP. It took me ages to “get” OOP (procedural dinosaur here.) Each piece in the game has a job and I just let them go to it.

You have made me rethink my controller object. No, not the MVC model. I really need to go back and study that more. We didn’t study it back in the Triassic Era. 

[Develephant]

 - It took me ages to get OOP so you’re in good company.  I was sadly stuck on static classes.  Another great thing to look into is event driven practices, it’s another of those OOP “ah-ha” moments in my book.

http://www.coronalabs.com/blog/2012/06/26/how-to-use-custom-events-in-corona/

Best of luck.

Cheers.

[Develephant]

It’s always good to balance readability, portability, and update-ability in your code.  While I too love to abstract the heck out of my code, it can sometimes backfire and make it harder to work on at a later date.

I try to stick close to an MVC type of structure in my Corona projects.  I use the current “scene” as the controller, and build out modules for the “model” and “view” and then sprinkle in a needed dose of custom events to pass the info between them.

Just something to think about.

Cheers.

[jaye_b]

@develephant

Thanks for your insight. It is definitely something to consider. I think that this game is my stab at embracing OOP. It took me ages to “get” OOP (procedural dinosaur here.) Each piece in the game has a job and I just let them go to it.

You have made me rethink my controller object. No, not the MVC model. I really need to go back and study that more. We didn’t study it back in the Triassic Era. 

[Develephant]

 - It took me ages to get OOP so you’re in good company.  I was sadly stuck on static classes.  Another great thing to look into is event driven practices, it’s another of those OOP “ah-ha” moments in my book.

http://www.coronalabs.com/blog/2012/06/26/how-to-use-custom-events-in-corona/

Best of luck.

Cheers.