What is the best practice?

I would like to know what is more interesting...

Put the objects that will appear only with the 'create object' action in a separated layout, or just put outside the layout that it will appear?

Thanks.

I think it's more organized to have it all in one layout dedicated to just having those objects, but it's up to you

I would like to know what is more interesting...

Put the objects that will appear only with the 'create object' action in a separated layout, or just put outside the layout that it will appear?

Thanks.

The best practice would be is to put everything that the Layout needs including the objects that will be created using "System ->Create Object(X,Y)". And on start of layout, if the object is not needed yet , destroy it.

Because if you don't have the object in the layout and create it using "System ->Create Object(X,Y)" it will make a laggy pause because the object isn't preloaded.

Only the objects present in the layout during editing will be preloaded. It is still okay if you put it outside the Layout White Paper as long it is on the Layout Page.

Note: Do not put your objects in a separate layout that isn't run during gameplay.

(Example of a bad practice!!! is to make a Layout where the game happens and make a separate layout for storage of the objects that will be created by "System ->Create Object(X,Y)" for the reason of not making the Main Game Layout look messy. ) - Wrong! The objects will not be preloaded and plus a Layout that is not used and made a storage for objects makes it worse.

For more info, read Ashley's Optimization tips below:

Ashley's posts:

https://www.scirra.com/blog/83/optimisa ... -your-time

https://www.scirra.com/tutorials/298/pe ... bile-games

> I would like to know what is more interesting...

> Put the objects that will appear only with the 'create object' action in a separated layout, or just put outside the layout that it will appear?

> Thanks.

>

The best practice would be is to put everything that the Layout needs including the objects that will be created using "System ->Create Object(X,Y)". And on start of layout, if the object is not needed yet , destroy it.

Because if you don't have the object in the layout and create it using "System ->Create Object(X,Y)" it will make a laggy pause because the object isn't preloaded.

Only the objects present in the layout during editing will be preloaded. It is still okay if you put it outside the Layout White Paper as long it is on the Layout Page.

Note: Do not put your objects in a separate layout that isn't run during gameplay.

(Example of a bad practice!!! is to make a Layout where the game happens and make a separate layout for storage of the objects that will be created by "System ->Create Object(X,Y)" for the reason of not making the Main Game Layout look messy. ) - Wrong! The objects will not be preloaded and plus a Layout that is not used and made a storage for objects makes it worse.

For more info, read Ashley's Optimization tips below:

Ashley's posts:

https://www.scirra.com/blog/83/optimisa ... -your-time

https://www.scirra.com/tutorials/298/pe ... bile-games

Wow, are you sure that the objects stored in a separated layout are not preloaded? I was almost sure that they are... and it would be much more organized.

How do you know that they aren't?

I am sure they are. Try to put a lot of assets to the second layout and try to switch between them with System -> go to layout. You will notice that the first time you go to layout 2 takes time, but already second time is very fast (at least on the devices which have enough RAM to hold the data).

I think it's pretty good practice to put the assets on the first layout because it's the only one layout where you can implement the progressbar, so player at least see that something is being loaded.

But! It obviously depends on the project size. I think it's a good practice only in a medium size projects. For small projects there is no point since there are usually few small assets. ,

Now in big projects you might have really a lot of stuff which would be really a pain for user to wait for all of them being loaded. In such case you should have it organized on the layouts that use them.

Wow, are you sure that the objects stored in a separated layout are not preloaded? I was almost sure that they are... and it would be much more organized.

How do you know that they aren't?

I exactly did what you did. I made a Separate layout to put all my objects and load them secretly on startup (loader layout) but when I tested it, it was very poor in performance. That was in my previous game and it became a complete fail. And I then realized my mistake when I read Ashley's optimization posts.

Hm... Well, I like the organization of making a layout for these objects, but if it isn't the best practice here, I will not do this hehe

Thank you!

—

This is quite an important information to me, so I need to be 100% sure about it. I've read the posts from Ashley at least 3 times in the past, and I just re-read them just now, and I don't see anything in them that would make me think it is a bad idea to create a layout dedicated to stocking objects. Could you quote the part of the articles which make you think it is?

I myself am using such a layout in all my project and didn't have had any problem until now. Of course, if it turns out that it is really bad practice, I will change that.

Actually I already asked the exact same questions nearly one year ago, and the globally admitted reply is that such layouts were good practice.

(second paragraph is the question)

Thanks for the information!

—

Could you quote the part of the articles which make you think it is?

https://www.scirra.com/manual/134/performance-tips

Ashley said:

(Not placing all used objects in the layout)

If objects are not placed in a layout but are created by events, Construct 2 will load the textures for those objects the moment you create them. This can cause a momentary pause or "jank" and make the game feel less responsive. This can be avoided by placing any used objects in the layout. They can be placed off-screen and destroyed on startup to avoid interfering with the gameplay. Then Construct 2 will preload all their textures when the layout starts, avoiding any "jank" as they are created and destroyed at runtime.

—

I don't see anything in them that would make me think it is a bad idea to create a layout dedicated to stocking objects.

Stocking objects is not bad when you are still editing and it is the first instance per object that you are putting there and this should only be temporary because this is only used to make construct 2 familiar with the size, opacity and other properties of your object / sprite and later on you will have to move it to the layout that is going to need it afterwards. And this is only applicable for games with many layouts. And every optimization freaks out there that is concerned with code optimization knows that you shouldn't leave something in your program that is not going to be needed. So if you think about it, if you want to have a more optimized game then you should delete that object layout on export.

"NOTE: When a game leaves the layout. It releases images from memory that is not going to be needed in the next layout to make space for the new images for the next layout. This is necessary for optimization of games. Think about it, if you don't flush it for the next layout and keeps adding more images. Sooner or later it's gonna overload and crash or have fps spike and etc."

If you think I am wrong, please correct me. Btw, I did not made this statement based on my observation only, I made a lot of test on this before just to prove this and this is also based on my experience. I had a game before that became so slow because of misunderstanding how ram memory works and by not reading the manual. And I learned my mistakes the hard way.

Rable

Maybe something has changed since last year - I haven't tested it recently. However last year when I was releasing my trivia game I clearly noticed that every layout first loading took on my mobile approx 2s. Then every layout second (and n-th) loading took about 0.5s. So the difference was clerly noticable.

Now regarding RAM. It depends on how the program is written. I am not sure how C2 works atm. But system does not clear any RAM data "by default". Clearing RAM takes time as well so data usually stays there even if it is not used and then some GC (Garbage Collector) clears it periodically. Or you can do it manually by coding as well ofc.

And let's say I have an app exported to desktop. My laptop has 16GB of RAM. It is "strong enough" to keep in RAM whole game even if it is not being used. But access to the RAM memory is much faster than HDD read so the game would be much more optimised if all the data would remain in RAM rather then be cleared and loaded everytime the layout changes.

For mobile devices it is a bit different story cause we usually have 1-3GB of RAM which is not that much and indeed sometimes RAM might be not big enough. In such cases unused data will be overriden by the new data.

I am not an expert, just saying how I see it based on my knowledge and experience.

Now the last thing to say here is that putting all objects in one layout is not a good practice when you think from the perspective of being a good coder. Good code is semantic and hermetised code, which means (in short) that every "thing" should be where it belongs and nowhere else.

But loading everything on first layout is acceptable even for good developers in C2 simply because of performace.

But then again if for some reason data is cleared when you swich to other layout... then there is absolutely no point doing so. It requires testing on various platforms and various mobiles to be sure how it works I believe. Nice topic tho!

Maybe something has changed since last year - I haven't tested it recently. However last year when I was releasing my trivia game I clearly noticed that every layout first loading took on my mobile approx 2s. Then every layout second (and n-th) loading took about 0.5s. So the difference was clerly noticable.

Now regarding RAM. It depends on how the program is written. I am not sure how C2 works atm. But system does not clear any RAM data "by default". Clearing RAM takes time as well so data usually stays there even if it is not used and then some GC (Garbage Collector) clears it periodically. Or you can do it manually by coding as well ofc.

And let's say I have an app exported to desktop. My laptop has 16GB of RAM. It is "strong enough" to keep in RAM whole game even if it is not being used. But access to the RAM memory is much faster than HDD read so the game would be much more optimised if all the data would remain in RAM rather then be cleared and loaded everytime the layout changes.

For mobile devices it is a bit different story cause we usually have 1-3GB of RAM which is not that much and indeed sometimes RAM might be not big enough. In such cases unused data will be overriden by the new data.

I am not an expert, just saying how I see it based on my knowledge and experience.

Now the last thing to say here is that putting all objects in one layout is not a good practice when you think from the perspective of being a good coder. Good code is semantic and hermetised code, which means (in short) that every "thing" should be where it belongs and nowhere else.

But loading everything on first layout is acceptable even for good developers in C2 simply because of performace.

But then again if for some reason data is cleared when you swich to other layout... then there is absolutely no point doing so. It requires testing on various platforms and various mobiles to be sure how it works I believe. Nice topic tho!

Yeah. I agree, this really depends on what you are exporting to. For I make mobile games, I focus more on cordova exports and less on PC exports. And If I sum up what — said, I would say that since PC's has greater Rams then it would be better if you would preload it on startup because PC's doesn't require a lot of resources that makes clearing of Ram unnecessary, therefore making it faster. But If you use mobile exports then it is better to put each objects that is going to be needed in the layout into that layout for mobile ram's are very limited at the moment. But if you have the time, I really recommend to put the objects in the layout you are using because of unexpected Ram cuts and clearing just to make sure. But these might not be accurate yet, so testing for yourselves will be much better. I will also test this myself on other platforms if I have the time. I also think this is a great topic too.

—

I don't think you are wrong at all! This makes perfect sense and I will have to keep that in mind when designing games.

Now my current (big) game has only one layout for every fights, so I will have to choose in either having a longer loading time before each fight or having a very slight loading delay when a new object is appearing. At least now I know what are the flaws of each solutions.

Thanks a lot, this was very interesting and important!

—

I'm quite confident that the memory is cleared at the beginning of each layout. This has been somewhat hinted by Ashley in this post :

And as he suggest, you can see it for yourself. Start your game in debugger and look at memory usage. You'll notice that when you switch from one layout to another, memory usage decrease drastically. I learned that the hard way when I needed to optimize my previous mobile game (now I develop for desktop and life is soooooo easier!)

I guess this indeed implies that putting all the objects on a loader layout is pointless, even harmful as it will delay your loading screen with no purpose.

Rable thnx for the link! That clears everything.

Let me quote Ashley again here [quote:8k49ccl3]"In Construct 2, images are loaded layout-by-layout. This means when a layout starts, every object on the layout is loaded in to memory immediately. This is to avoid mid-game pauses as textures are loaded on the fly. When the layout ends, it will free all the images in memory not used by the next layout, and load any new images the next layout uses."

So it is totally pointless to store all images in one layout. And a good practice is to stick to semantic rules - which is also a good news .