Game Desing Best Practices

Solar2D General Questions/Discussion
#1

I wrote a reply to a post in the GS thread with some general tips on Lua programming and game design, but before posting it I thought it could become a good thread trigger, for other people to talk about their points of view on the subject too.

So, how do you mates design your games? How do you organize specific jobs, memory management and the game flow? Everything in 1-2 modules? Several top-down modules? MVC layers? Something else?

What would you advise a Lua/Corona starter for building a rigid project? [import]uid: 7356 topic_id: 3686 reply_id: 303686[/import]

#2

Bellow are my tips for a newcomer, non-programmer, on learning Lua and efficiently designing a project. I am still learning and reconsidering things every day. But somehow, the discussion must be started :slight_smile:

  1. Make small steps, one at a time. First, work 2-3 days in Lua live demo and make some practice on Lua tables and functions. Then try simple things in Corona and master the concepts before going to the next levels.

  2. Make sure you really understand how memory management works in Lua. It is easier to spend some hours understanding these concepts than spend days on debugging bad-practices.

  3. Don’t put inside your project a piece of code others have written, unless you fully understand what exactly it does. Otherwise, you will find yourself reworking the others’ code many times for just making it really efficient and compatible with the rest of your project.

  4. Every time you enrich your project with new functionalities, check to see if you leave memory garbages when you change this “scene” and proceed to a blank one.

  5. Organize your code in modules. When you see that you write something 2 times, consider implementing a generic function for this job. When you see that some functions do similar things, put them on a module. Each module has to have only functions inside, not raw code.

  6. After some days of practice, try to get used to a MVC style of programming. I am implementing a variant of MVC like this:

Call your helper modules from within main and assign them to a global variable. Then you can call them from everywhere. Try to not have require statements inside your other modules. Inside main.lua, after module calls, call a “controller” module which will be responsible for calling your “scene” modules. For best results, don’t have helper modules calls directly from within scene modules. Instead make get functions inside the controller and call these ones from scenes. Similarly, build a Datakeeper module (a “model”) and keep everything you need to recreate a full scene when resuming/restoring after pause and suspend. Keep what you need for resume only in memory. Write, batched on the fly, what you need for restore a scene inside a file (eg with json). Implement set/get functions in the “controller” for scene to access the info of “model”. A scene has to be ignorant about the model. The model only knows in theory about the scenes (their number, the module names and things like level difficulty and such). Any scene-model transaction has to go through the controller.

  1. Implement all the above steps in a generic style, not project-specific. The MVC implementation should contain only the “model”, the “controller” and some helper modules. Everything “view”-related is project-specific. Don’t make views during MVC implementation. Just temporary ones for testing purposes. The final code should be a “template”, missing just the views and some scene description/setting information that goes inside the model. You can also outsource this info to a file too, and keep your model 100% reusable.

  2. Give everything to support generic solutions to problems and best practices on doing things (eg work with spritesheets from the start, use proportional coordinates, gather text strings inside a single place …)
    WHY TO USE SUCH A STYLE?

  3. You will gain absolute control on game flow.

  4. Your debbuging sessions will decrease from hours to seconds/minutes.

  5. You will need much less code for a new level

  6. Every time you want to change something (it’s going to be hundreds of times) you will only have to change it in one single place!

  7. Used memory will be minimized and memory management will become more transparent.

  8. You will have a 20-50% of your next game’s code already written, debugged and fully reusable for next projects.
    [import]uid: 7356 topic_id: 3686 reply_id: 11221[/import]

#3

Magenda, thanks for your tips! They are very useful. I hope you can guide me on a simple design question:

I call some modules (level1.lua, level2.lua, etc) from my main.lua to change scenes. However, every module needs to perform a particular task (construct the same building, for example). So I would like to put the function that constructs the building into its own module (building.lua). However, I cannot successfully get the ‘level’ modules to call the function in the ‘building’ module.

Can modules call functions in other modules? If so, can you show a simple example? It would be much appreciated. Thanks! [import]uid: 31874 topic_id: 3686 reply_id: 33236[/import]

#4

@MonDrew

Yes, you can always call functions from other modules by following these steps:

  1. At the top of your utility modules put this:
    [lua]module(…, package.seeall)[/lua]
    In my project all of my .lua files are talking with others so I have the prior statement at the top of every file.
  2. Make “global” all the utility functions that you want to be callable from other modules. You do this by just not stating “local” in front of a function declaration.
  3. You have to assign the utility module to a variable before using it. You can do this right before calling the function you need, inside your level code, but a better way is to assign every module you need to a global variable at the very top inside your main.lua file. This way you will have access to them from everywhere in your code, since the main.lua is the first to be loaded in memory. So, for example you are including something like this in the first lines of main.lua :
    [lua]grabber=require(“SpriteGrabber”)
    printer=require(“Printer”)
    funcs=require(“MathFuncs”)[/lua]

The name inside quotes are the filenames of your lua utility modules.

Then, you can call any function you like from your levels’ code just like this:

[lua]local xx = funcs.calculate(7,11,44)
local myHeroSheet = grabber.grabSheet(“heroSheet”)
printer.printWithSprites(“This is an example!”)[/lua]

If you still have problems with this, feel free to post some code or upload your project somewhere so you can get a hint on how to proceed.

Cheers
[import]uid: 7356 topic_id: 3686 reply_id: 33263[/import]

#5


Bellow are my tips for a newcomer, non-programmer, on learning Lua and efficiently designing a project. I am still learning and reconsidering things every day. But somehow, the discussion must be started :slight_smile:

1) Make small steps, one at a time. First, work 2-3 days in Lua live demo and make some practice on Lua tables and functions. Then try simple things in Corona and master the concepts before going to the next levels.
…

@Magenda:

Thanks for this - this is exactly what I was looking for to help me organize my project. This kind of architecture can really improve things, and I can definitely see how it would achieve the benefits you mention.

There’s a few things I don’t understand, though…


For best results, don’t have helper modules calls directly from within scene modules. Instead make get functions inside the controller and call these ones from scenes.


I’m not familiar with get function, how would this actually work?


Similarly, build a Datakeeper module (a “model”) and keep everything you need to recreate a full scene when resuming/restoring after pause and suspend. Keep what you need for resume only in memory. Write, batched on the fly, what you need for restore a scene inside a file (eg with json). Implement set/get functions in the “controller” for scene to access the info of “model”. A scene has to be ignorant about the model. The model only knows in theory about the scenes (their number, the module names and things like level difficulty and such). Any scene-model transaction has to go through the controller.


This seems like a great idea but I can’t really see how that would happen in practice. I’m not sure what a datakeeper module would actually look like - just a table with a bunch of properties (like score, numberEnemies, etc.)? Same with the rest of the suggestions…

Do you have some kind of template for this? Even without any actual game code (just comments such as “implement touch handler here”), etc. These suggestions seem really good, but I can’t seem to figure out how they would be implemented. Some samples would be a huge help, since you seem to have a good grasp on architectures…
[import]uid: 49372 topic_id: 3686 reply_id: 33935[/import]