Game architecture

[IndieEnthusiast]

Could the experts in the forum talk a bit about game code architecture which should be followed for an optimized game? I am interested to know about design patterns.

• Let me be a bit more specific, how are popups introduced in game architecture ?

• Texts added in a file then depending on certain conditions, popup framework is called with specific text pulled from a file?

• or have different lua files for each overlay popup?

• I know it is kind of a vague question, but I would like to learn about optimized way, optimized architecture so that the coding can be done more efficiently.

• What is a good modular approach to coding? I know lua is not really an object oriented language, but functions can be reused with different parameters

Thanks!

[agramonte]

This is how my apps are structured. I have a set of what I call domain objects. But they are just tables and properties in a file. A player and all the properties for example.

Then I have other sets of objects that do work and yet other objects I call factories but you guessed it they are just methods in table. So based on the config these tables are created and then domain objects are passed in to do work.

A concrete example: At start up the app looks at the config and sees that we are using Vungle and Admob. Calls the adFactory with the two keys Admob and Vungle. The factory uses those two keys to load to files based on the path in the config for those keys. Calls the init method for those two files and stuffs them in an array. The factory also attaches the callback of those two files to itself.

Now at some point we need an ad. We call the controller and tell it to show an ad of type x. The manager iterates through the collection and calls the show method of every file.

I use this pattern for everything or almost everything. The domain objects are passed in when required. Even the UI is built this way. I call the controller to build the navigation bar. It looks at the configuration loads a file based on a path and calls known methods for that factory. When a person clicks on a button. I send the button tag to the nav manager.

This is why most of my apps look sort of the same and why usually one update targets multiple apps.

So Back to your question. A manager needs a pop-up. Maybe it got an event that the level is over. Looks at the config when I get event x fire event y. In this case the event is showGoodJobOverlay. The overlay manager listens to that event pulls the config calls the factory with the property and then calls the show method.

If our pop-up has a button again fire an events a manager somewhere will be listening will create something in a factory or call one or more methods in a collections.

Most of my apps have either 1 or 2 scenes. When you click on the UI element I am just destroying and creating items. Even the managers are created this way. I can switch the config of a few users to try overlayManager2. At startup instead of the managerFactory creating v1 it would create v2. Hope this helps I can give you details if interested other people probably have better way to do this.

Sorry for the formating. Sadly in a hospital bed today with only my phone.

[rob]

This is a great set of questions, but I suspect that even though you’ve listed specific questions, they may be still too broad to answer in the forums.

As for popup’s there are generally two types: native dialog boxes and scene overlays. I would think most people would, for stylistic purposes use an overlay. Generically speaking they are just a display.newGroup() or display.newContainer() that contains the various display objects needed to show the overlay. If you’re using Composer, it supports overlay scenes, so if you’re comfortable working with Composer, then you might go that way.

For the second question on texts in a single module or different lua files, you need to learn DRY: Don’t Repeat Yourself. Don’t write the same code over and over. It’s almost always better to use conditional tests and a singular set of code for this. This is also a practical example of the MVC pattern (Model View Controller).

With MVC, your model is your data. The View displays your data. Neither should know or care about the other. That is later you may want to change how the data displays, but you don’t want to re-engineer your data. Your data should track the information that it needs to track and not be designed around how the data will be displayed. The Controller is the bridge that reads the data and communicates that data to the view.

For the last question, perhaps you should look at the sample projects from Ponywolf, like Endless Skateborder (You can find them in the Marketplace or on the Getting Started Guide) and study how they are organized and laid out. 

Rob

[IndieEnthusiast]

I am sorry to hear you are in hospital bed, I hope it is nothing serious. Do not worry about the formatting, it looks better than my initial post. Thanks a billion for a very thorough post, loved the feedback, will try to implement on my own game.

[IndieEnthusiast]

Thank you @Rob for the response. I did realize after I posted that this is a broad topic of disucssion and cannot be covered in one thread. I will study examples you mentioned. I am happy to be part of such a vibrant forum.

[XeduR]

Rob’s “Don’t repeat yourself” is a great piece of advice, and you should take it beyond individual projects.
 

Consider scenes like level select, options, in-app currency store or credits.

What’s the one thing that they all have in common? People don’t really care about any of them. Often not even the developers!

Level select is only a means of getting to the actual game and so it needs to be as smooth and as effortless as possible for the player, so that it doesn’t annoy them. If a player goes to the options or credits scene, they’ll probably do so only once or perhaps they are just lost, etc.

The point in all of this is that you should reuse as much code as you can.

For instance, we at Spyric have several custom scenes and overlays scenes that we just copy from one project to another. One such overlay scene is our “store.lua” file. The overlay scene itself doesn’t contain any hardcoded values, but it gets its information from two associated files: translations.lua and settings.lua. The first file simply contains the strings for all text, buttons, etc. and the second file contains all display object specifications, such as how many buttons, what graphics do they use, where they are, their functions and id’s, etc. The scene also contains special functions like watching ads to get currency or checking time from our server to get a daily reward.

When we started, we used to create the iap and store systems from the ground up for every project, which always took a few days and some more to squash all the bugs and test everything as well as set up all integration, etc. but these days we just copy this file from one project to another, change a few lines of code in the settings.lua file and call a custom scene. To be completely honest, the reason why programming these IAPs/stores always took us to long is because no one wanted to do them as they were so boring. So, now we can just cut a few days of boring work and possible bugs by calling just calling a scene that we know works.

Since we’ve got similar modules/scenes for options, credits, some types of level selects, etc. we are able to cut down a lot of development time and keep everyone working on more interesting tasks that actually matter.

[agramonte]

This is how my apps are structured. I have a set of what I call domain objects. But they are just tables and properties in a file. A player and all the properties for example.

Then I have other sets of objects that do work and yet other objects I call factories but you guessed it they are just methods in table. So based on the config these tables are created and then domain objects are passed in to do work.

A concrete example: At start up the app looks at the config and sees that we are using Vungle and Admob. Calls the adFactory with the two keys Admob and Vungle. The factory uses those two keys to load to files based on the path in the config for those keys. Calls the init method for those two files and stuffs them in an array. The factory also attaches the callback of those two files to itself.

Now at some point we need an ad. We call the controller and tell it to show an ad of type x. The manager iterates through the collection and calls the show method of every file.

I use this pattern for everything or almost everything. The domain objects are passed in when required. Even the UI is built this way. I call the controller to build the navigation bar. It looks at the configuration loads a file based on a path and calls known methods for that factory. When a person clicks on a button. I send the button tag to the nav manager.

This is why most of my apps look sort of the same and why usually one update targets multiple apps.

So Back to your question. A manager needs a pop-up. Maybe it got an event that the level is over. Looks at the config when I get event x fire event y. In this case the event is showGoodJobOverlay. The overlay manager listens to that event pulls the config calls the factory with the property and then calls the show method.

If our pop-up has a button again fire an events a manager somewhere will be listening will create something in a factory or call one or more methods in a collections.

Most of my apps have either 1 or 2 scenes. When you click on the UI element I am just destroying and creating items. Even the managers are created this way. I can switch the config of a few users to try overlayManager2. At startup instead of the managerFactory creating v1 it would create v2. Hope this helps I can give you details if interested other people probably have better way to do this.

Sorry for the formating. Sadly in a hospital bed today with only my phone.

[rob]

This is a great set of questions, but I suspect that even though you’ve listed specific questions, they may be still too broad to answer in the forums.

As for popup’s there are generally two types: native dialog boxes and scene overlays. I would think most people would, for stylistic purposes use an overlay. Generically speaking they are just a display.newGroup() or display.newContainer() that contains the various display objects needed to show the overlay. If you’re using Composer, it supports overlay scenes, so if you’re comfortable working with Composer, then you might go that way.

For the second question on texts in a single module or different lua files, you need to learn DRY: Don’t Repeat Yourself. Don’t write the same code over and over. It’s almost always better to use conditional tests and a singular set of code for this. This is also a practical example of the MVC pattern (Model View Controller).

With MVC, your model is your data. The View displays your data. Neither should know or care about the other. That is later you may want to change how the data displays, but you don’t want to re-engineer your data. Your data should track the information that it needs to track and not be designed around how the data will be displayed. The Controller is the bridge that reads the data and communicates that data to the view.

For the last question, perhaps you should look at the sample projects from Ponywolf, like Endless Skateborder (You can find them in the Marketplace or on the Getting Started Guide) and study how they are organized and laid out. 

Rob

[IndieEnthusiast]

I am sorry to hear you are in hospital bed, I hope it is nothing serious. Do not worry about the formatting, it looks better than my initial post. Thanks a billion for a very thorough post, loved the feedback, will try to implement on my own game.

[IndieEnthusiast]

Thank you @Rob for the response. I did realize after I posted that this is a broad topic of disucssion and cannot be covered in one thread. I will study examples you mentioned. I am happy to be part of such a vibrant forum.

[XeduR]

Rob’s “Don’t repeat yourself” is a great piece of advice, and you should take it beyond individual projects.
 

Consider scenes like level select, options, in-app currency store or credits.

What’s the one thing that they all have in common? People don’t really care about any of them. Often not even the developers!

Level select is only a means of getting to the actual game and so it needs to be as smooth and as effortless as possible for the player, so that it doesn’t annoy them. If a player goes to the options or credits scene, they’ll probably do so only once or perhaps they are just lost, etc.

The point in all of this is that you should reuse as much code as you can.

For instance, we at Spyric have several custom scenes and overlays scenes that we just copy from one project to another. One such overlay scene is our “store.lua” file. The overlay scene itself doesn’t contain any hardcoded values, but it gets its information from two associated files: translations.lua and settings.lua. The first file simply contains the strings for all text, buttons, etc. and the second file contains all display object specifications, such as how many buttons, what graphics do they use, where they are, their functions and id’s, etc. The scene also contains special functions like watching ads to get currency or checking time from our server to get a daily reward.

When we started, we used to create the iap and store systems from the ground up for every project, which always took a few days and some more to squash all the bugs and test everything as well as set up all integration, etc. but these days we just copy this file from one project to another, change a few lines of code in the settings.lua file and call a custom scene. To be completely honest, the reason why programming these IAPs/stores always took us to long is because no one wanted to do them as they were so boring. So, now we can just cut a few days of boring work and possible bugs by calling just calling a scene that we know works.

Since we’ve got similar modules/scenes for options, credits, some types of level selects, etc. we are able to cut down a lot of development time and keep everyone working on more interesting tasks that actually matter.