Can't change layout without having all assets loaded in?

So I think I've ranted about this before maybe about 5-10 times or so, but here I go again.

So I've noticed that when my game boots, far from all the assets in the game are loaded in when the loading bar reaches 100% (and why does the whole game need to be loaded in, isn't that what storing the game assets on the HDD is for?!?!). I see disk peaking at 100 % long after, and on some computers it can take several minutes before the game can proceed from the bootup loading game layout (yes two loading screens) to the actually game menu. I just had an indiecade judge reply to me being unable to play the game because of s**t like this. I'm really fed up with how Construct/Chromium/NWjs handles assets in memory. Even when 2gb is dedicated to caching assets, there's still frikkin loading times in-game, nothing can be streamed in the background without lagspikes etc. I need to know if there's any way to work around this? What can I do to make sure 100 % on the loading bar means 100 % loaded and playable? Do I need to optimize my game you say? Every layout in the game has on avarage maybe 200-300mb worth of assets in on avarage, yet they all have to be held back by the weight of the entire game. Not only has that severely limited me in what I can put into every scene, but also hampered the scope of the game. Every slight iteration takes 1min of loading in preview just to see if it worked, making new features a nightmare in practice. It's claimed that construct only loads needed assets into memory, but I've done enough tests on all browsers both in preview and export to verify that it's BULL***T! Blank layout with nothing loaded in with all audio cut from the game... 1.8 gb memory used?! WTF?!

At this rate I'll be forced to port the game to unity or something. I can't believe I've spent 2,5 years of my life on this thing only to have it break down so close to the end... I guess I should've known better when I saw the first signs of trouble few weeks into development. Construct's a prototype tool. It was never made for big projects I get that, but I just can't fathom some of the design decisions behind this engine... Keeping it simple is good for the beginners sure, but taking measures to ensure better stability, iteration times and control over assets also greatly benefits the smaller projects as well. I guess when not even the official plugins can be kept up to date and stable (greenworks, local storage looking at you), this is obviously too much to ask.

I don't mean to sound like that thankless noob that whines over why a 100 buck engine isn't perfect, but I took a chance on it, and have spent thousands of hours making a game, and touring it around the world with my own savings to have a chance at making a name for myself. That the tool I chose is the biggest reason I loose sleep every night is just extremely frustrating, and I need to vent a bit. Every issue I've had with the engine has been gradually fixed over time, but I'm afraid if this specific one isn't fixed reeeeal soon, Klang might never be launched as a C2 game.

Since it's not the first time I hear someone complaining about big projects in C2, I'm really interested in what the Scirra Team has to say about this. I'd love to see this engine handle such projects as Klang without problems.

This wont help with the loading times, but i read a trick somewhere someone suggested about waiting for the game to be "playable" before going to the layout.

Basically you add a check that watches the frame rate of the game. (while its loading its going to be really low), but once everything is loaded and the game starts to run smoothly, THEN you hide the fake 100% loading screen.

So its loading everything behind it, and only once its ready to play smoothly you show the player the game and begin.

Basically you add a check that watches the frame rate of the game. (while its loading its going to be really low), but once everything is loaded and the game starts to run smoothly, THEN you hide the fake 100% loading screen.

But if a player who has a very old computer tries your game and can run it only at 10FPS will never see your levels, just the loading screen.

This is what I'm doing already... a fake loading screen. This is what the Indiecade judge never got past. It's also just unfathomably slow. A game iike witcher loads almost instantly on my computer, but a game that's waaay smaller proves too much for a lot of setups. Construct has loading issues, period. Local storage is also unstable.

Could this be an engine bug? I think this topic got too little attention. Ashley did you experience anything similar with big projects?

Try to replicate the issue.

Make a dummy project and fill it with objects using the method you used.

Post it if you find something, so that others can confirm.

newt I would if I had the time. There can be so many things affecting this, that I would have to put some real effort into the dummy project. I know that rants like this is unhelpful because I don't post concrete evidence, but it's simply because I'm stretched for time, and I won't share Klang's source at this point. It's too complete for it to be shared publicly.

yes scirra answer ? because a lot of us have this issue

(my game right now have a force close issue on android) in preview i have no issue no error no problem but in mobile it get force close when player playing it for awhile

DON'T say its a 100$ engine because unity is free !

I was on holiday when this was first posted, sorry for missing it.

So I've noticed that when my game boots, far from all the assets in the game are loaded in when the loading bar reaches 100% (and why does the whole game need to be loaded in, isn't that what storing the game assets on the HDD is for?!?!).

In a HTML5 game, the loading bar corresponds to download progress. None of the assets are actually loaded decompressed in to memory at that point. So of course, not all assets are loaded by the 100% mark - that's the point of the layout-by-layout loading system: nothing is loaded, until you go to a layout, at which point only that layout's assets are decompressed in to memory. In NW.js I guess I'm not actually sure what it has to do; if you are using package.nw (i.e. zipped assets) then it will be extracting from the zip, but if you pre-extract the zip it should just figure out there's a resource on disk so it doesn't need to do anything. I guess it might load the asset (compressed) in to RAM so it can be quickly decompressed later, which might be unsuitable for a very large game (although it would help speed up layout loading times). So, are you using package.nw and have you tried pre-extracting it?

[quote:2u9g5k4f]Every slight iteration takes 1min of loading in preview just to see if it worked, making new features a nightmare in practice.

It's normal that large projects take a long time to build. I've heard Chrome itself can take several hours to build. Perhaps we could investigate features to do a more minimal rebuild though.

[quote:2u9g5k4f]Blank layout with nothing loaded in with all audio cut from the game... 1.8 gb memory used?! WTF?!

Memory is complicated. If you have say 4 GB of RAM free, and the system has 1.8 GB of files in RAM it might need later, it may well decide to leave them there. RAM is there to be used.

It also depends on your project settings, e.g. if you have set audio to be preloaded, you've told Construct 2 to decompress all audio content to RAM on startup.

[quote:2u9g5k4f]I guess I should've known better when I saw the first signs of trouble few weeks into development.

The sooner you can report issues, the more time we have to do something about them. I think it is unreasonable to expect us or any other developers to make deep changes to the engine in a few weeks. We can look in to issues, but we need time to do that.

[quote:2u9g5k4f]Construct's a prototype tool. It was never made for big projects I get that

We do design the engine to scale to large projects, but it sounds like you've made one of the biggest projects ever in Construct 2. I definitely intend for Construct 2 to be able to handle such large games, but we might need to make a few tweaks to make it work better

[quote:2u9g5k4f]I guess when not even the official plugins can be kept up to date and stable (greenworks, local storage looking at you), this is obviously too much to ask.

This doesn't appear to be related to the main point of this thread, but I'm not aware of any outstanding bug reports for local storage, AFAIK it works fine for the vast majority of users. Also Greenworks has been clearly marked as an experimental plugin for some time, but as it happens, we just released two updates for it this week.

Try to replicate the issue.

Make a dummy project and fill it with objects using the method you used.

[quote:2u9g5k4f]I would if I had the time

Sorry, but this is by far the best way for anyone to make progress on this. As it stands, this post is the equivalent of "my car's broken, please fix it!" - "can you bring your car to the garage?" - "no!"

Sure the mechanic can try and fix it by telephone or something, but you wouldn't expect that to get very far.

I don't normally do this, but if you want to send your full project to , I'll (obviously keep it secret and) look in to any memory-related issues, but if you can reproduce it just by stuffing loads of dummy content in to a new project, that's better.

newt I would if I had the time. There can be so many things affecting this, that I would have to put some real effort into the dummy project. I know that rants like this is unhelpful because I don't post concrete evidence, but it's simply because I'm stretched for time, and I won't share Klang's source at this point. It's too complete for it to be shared publicly.

Mechanics aren't the issue, content is.

Just download a bunch of public domain assets, and add them to a dummy project.

Just use the same distribution method you used in your game.

Opengameart.org

Kenney.nl

In a HTML5 game, the loading bar corresponds to download progress. None of the assets are actually loaded decompressed in to memory at that point. So of course, not all assets are loaded by the 100% mark - that's the point of the layout-by-layout loading system: nothing is loaded, until you go to a layout, at which point only that layout's assets are decompressed in to memory. In NW.js I guess I'm not actually sure what it has to do; if you are using package.nw (i.e. zipped assets) then it will be extracting from the zip, but if you pre-extract the zip it should just figure out there's a resource on disk so it doesn't need to do anything. I guess it might load the asset (compressed) in to RAM so it can be quickly decompressed later, which might be unsuitable for a very large game (although it would help speed up layout loading times). So, are you using package.nw and have you tried pre-extracting it?

I have tried both methods (the pre unzip is a lifesaver btw!), but I don't see any change in memory use. The boot time's way faster though. I'm just trying to get a good understanding of what the massive process in the task manager really is. The only pattern I've seen is that it grows bigger with the project as it gets more assets.

[quote:3d7lusot]If you have say 4 GB of RAM free, and the system has 1.8 GB of files in RAM it might need later, it may well decide to leave them there. RAM is there to be used.

Which is definately nice in theory, but it's proven to be undynamic, as I've seen 32bit versions of the game crash due to this, and it doesn't seem to scale down when memory use peaks. The game can't boot on setups with less than 2gb. Also I did try turning off the sounds loading on startup, and it only made a few hundred MB of difference, it wasn't the source to the problem.

[quote:3d7lusot]The sooner you can report issues, the more time we have to do something about them. I think it is unreasonable to expect us or any other developers to make deep changes to the engine in a few weeks. We can look in to issues, but we need time to do that.

Well I have raged about these issues frequently throughout the soon 3 year development. I get it's a risk changing priorities based on one dev who may or may not amount to a finished game (or know what they're doing), but I will stand by that the current solution is hostile towards big projects.

[quote:3d7lusot]We do design the engine to scale to large projects, but it sounds like you've made one of the biggest projects ever in Construct 2. I definitely intend for Construct 2 to be able to handle such large games, but we might need to make a few tweaks to make it work better

The editor scales pretty well, apart from that the event sheet interaction becomes laggy over time, but that might be that my sheets are too big over that it's weighed down by the full project?

The biggest optimization to iteration I would propose is that the preview can dynamically read an updated sheet (which often is just one value changed) without the need or reloading. This would probably save me up to 2-4 hours daily of just waiting. 1 min for every time I implement a new asset is fair, but just a small value like the spray rate of a particle or a change of variable to debugging the options menu shouldn't have to suffer from this. This one flaw has probably cut Klang's scope by half.

Another potentially big save could be to make a feature to make "reference projects". Lets say I wanna make a new feature. I can make it wicked fast in an empty project, but implementing it in the main project takes ages. I was sort of able to do this with the event sheets when making the final boss. I made assets with identical names and just copied the game logic over. This was a hassle though, and dedicated tools towards this could make a power user work with the efficiency of a clean project even when working on a big project.

[quote:3d7lusot]

This doesn't appear to be related to the main point of this thread, but I'm not aware of any outstanding bug reports for local storage, AFAIK it works fine for the vast majority of users. Also Greenworks has been clearly marked as an experimental plugin for some time, but as it happens, we just released two updates for it this week.

I'll have to check out greenworks then. The local storage thing was more of a rant, as I'm experiencing problems with it without being able to reproduce the issue consistently.

If you're willing to look at the Klang source it would mean a lot to me. I might send a new build by the day's end. Is there any documentation I should prepare ahead?

Since it's not the first time I hear someone complaining about big projects in C2, I'm really interested in what the Scirra Team has to say about this. I'd love to see this engine handle such projects as Klang without problems.

Since it's not the first time I hear someone complaining about big projects in C2, I'm really interested in what the Scirra Team has to say about this. I'd love to see this engine handle such projects as Klang without problems.

No way, we wrote the same thing. What are the odds.

But seriously, I'm glad that Ashley took the time and looked into this. I hope he can help you Tinimations and both your project and the engine profits from that.

glerikud

There are no odds, it's a fake post. Likely to be edited later to set up spam links.

glerikud

There are no odds, it's a fake post. Likely to be edited later to set up spam links.

I was just joking about the odds, but I didn't know that bots use this technique. Thanks for informing me.