Is is possible to run only part of main.lua?

Hi,

Is it possible to run only part of the main.lua file? For instance, is it possible to highlight only the top part of the main.lua or the part of the code that’s under modification?

Thanks,

David

Hi David, You can enclose your different parts of code in functions and comment out the calls that you don’t want to execute Cheers Atanas

You can use the multi-line comment code to block out a large block of code:

print ("this executes") --[[    print("this won't print")     print("nor will this") --]]  

Rob

Thanks, atanas and Rob. These are good ideas. I have been using Command + / to comment/uncomment large block of highlighted codes, but the multi-line comment looks like a good alternative. Enclosing codes in functions and comment out the lines that call the functions definitely works for functions that are already defined without any additional works. I should getting more codes into functions.

Now that I know main.lua has to run as a whole, I am thinking of breaking main.lua into multiple lua files and the main.lua will contains only minimal lines of codes calling the various lua files.I think the editing and testing will become easier this way.

In  your experience, is this approach practical or will it create more maintenance headache? Also from the performance point of view, is calling multiple lua files from main.lua less efficient than executing one main.lua file?

Hi David,

Definitely break it up - it will help you long term for maintaining the code, while the performance penalty is negligible

Cheers,

  Atanas

Thanks, Atanas.   -David

Hi David. You’re definitely on the right track. For more complex apps, most devs keep very little gameplay specific logic in their main, given that main.lua is unique in that it gets called first (before any other app code executes), and because it also gets called in special circumstances (such as local and remote notifications).

Given these special aspects of main lua, more complex games primarily use it to:

  • Load custom fonts first/once, before app gets going

  • Load frequently used sfx / music first/once, before app gets going

  • Setup local / remote notification handlers

  • Hold application globals / flags (like a debug flag app code checks)

  • Finally, after initialization, call an app UI module to get the UI / game going on screen

There’s plenty of other things devs like / need to setup / initialize in main (depending on the app), but that’s usually the idea. Load up frequently used stuff (once, at startup to prevent lag time later), setup any global vars / subsytems the app uses, and then hand off control to a module that manages the app logic / UI.

1 Like

Thanks a lot for the insightful info, mpappas. Knowing how experienced developers organize the codes is very helpful.  -David 

Hi David, You can enclose your different parts of code in functions and comment out the calls that you don’t want to execute Cheers Atanas

You can use the multi-line comment code to block out a large block of code:

print ("this executes") --[[    print("this won't print")     print("nor will this") --]]  

Rob

Thanks, atanas and Rob. These are good ideas. I have been using Command + / to comment/uncomment large block of highlighted codes, but the multi-line comment looks like a good alternative. Enclosing codes in functions and comment out the lines that call the functions definitely works for functions that are already defined without any additional works. I should getting more codes into functions.

Now that I know main.lua has to run as a whole, I am thinking of breaking main.lua into multiple lua files and the main.lua will contains only minimal lines of codes calling the various lua files.I think the editing and testing will become easier this way.

In  your experience, is this approach practical or will it create more maintenance headache? Also from the performance point of view, is calling multiple lua files from main.lua less efficient than executing one main.lua file?

Hi David,

Definitely break it up - it will help you long term for maintaining the code, while the performance penalty is negligible

Cheers,

  Atanas

Thanks, Atanas.   -David

Hi David. You’re definitely on the right track. For more complex apps, most devs keep very little gameplay specific logic in their main, given that main.lua is unique in that it gets called first (before any other app code executes), and because it also gets called in special circumstances (such as local and remote notifications).

Given these special aspects of main lua, more complex games primarily use it to:

  • Load custom fonts first/once, before app gets going

  • Load frequently used sfx / music first/once, before app gets going

  • Setup local / remote notification handlers

  • Hold application globals / flags (like a debug flag app code checks)

  • Finally, after initialization, call an app UI module to get the UI / game going on screen

There’s plenty of other things devs like / need to setup / initialize in main (depending on the app), but that’s usually the idea. Load up frequently used stuff (once, at startup to prevent lag time later), setup any global vars / subsytems the app uses, and then hand off control to a module that manages the app logic / UI.

Thanks a lot for the insightful info, mpappas. Knowing how experienced developers organize the codes is very helpful.  -David