Configure a Single Scene vs. Multiple Scenes?

3itg

I couldnt seem to find the post I was looking for about this subject.
On my quest to make my game playable, I am looking to implement every performance enhancement I can find.

I have 14 scenes, all similar behavior (planet in the center, AI flying around and whatnot), the scene is selected by an attribute game.solarsystemID.
I have a map I use to travel from place to place. When a place is selected its ID becomes the game.destinationID.
When you "initiate hyperspace" the game changes some attributes to their defaults, sets the game.destinationID to game.solarsystemID and then changes scenes to the players destination based on that.

If I delete 13 systems, fade to black while changing attributes and load everything into a single scene and just make it seem like they have traveled...
Is this likely to be a performance increase or decrease?
I imagine this method to consume more RAM, but in the post I couldnt find I remember the OP saying it helped performance.
(I imagine in scene performance was better, load times were worse.)
Anyone have any idea on this one?

Mr Hanson

Hello

My thoughts are that if most of it is on the one scene the faster loading times you would get but the slower the scene is. Also if everything is on the one scene, as I found out in making my game, there is a lot more errors can occur as if something happens with one thing it can affect the whole game. Because everything is all link directly. That's just may opinion and properly not valid but it is what i have found.

All the best
JonApp

3itg

So I went through and decided which scenes could go and I ended up deleting 10 scenes.
For the scenes that stayed:
1 is the main "solar system"
the 2nd is the first level, which contains a tutorial.
The Other 2 systems I kept are secrets that can be unlocked via gameplay or IAP.
I however am NOT reconfiguring the scene, I am using change scene behavior, and having it reload that same scene, with some different attributes.

Deleting 10 scenes seems to make the game faster overall (in responsiveness and load times). RAM consumption is slightly less and it reduced my overall project size considerably (12%).
and because of the structure I used when initially built the game... the conversion was WAY easier to do than I expected.

The_Gamesalad_Guru

There have been much bigger games built with GS. I imagine the game lags because your code is not efficient. The key to building fast games is efficient code. Just because code works doesn't mean it's efficient. Most of the time when I'm designing complex code I may draft ten versions each one works but by the tenth version I've boiled down the amount of code. This requires a firm understanding of logic and a firm knowledge of GS. Keep studying and think in logic and look at your code and ask can I do this with less rules and such.

3itg

Ive been working on that and have been continuously polishing my code and omitting anything I find that I can do a better way now.
Having started the project 3 months ago, I find things I did near the start and my mind is boggled as to why I did things that way.
I have learned much in my 3 months.
@FryingBaconStudios Perhaps you have played with tables more than me.
While my tables are storing game data, Im not sure Im using the most efficient methods.
Would it be better to save and load game.attributes to tables?
Or
Would it be better to essentially play the game in a table, by changing and reading table data on the fly?

Like now, I have an actor, and he gets his speed from a table.
Change attribute self.speed to tablecellvalue(table,row,col)
then other rules I want to base on his speed look at the self.speed attribute...
Would it be an improvement to have each rule instead look to that table data directly and skip the step where I load the self.attrib?

I haven't been able to devise a heavy enough test to see if this makes a substantial difference. (it may not even be entirely possible, as some rules would need constant changing, haven't fully gotten my head around "game in a table" yet...