GS has a SERIOUS memory flaw - a show stopper for devs - PLEASE PROVE ME WRONG!
synthesis
Member Posts: 1,693
So we have gotten Toxic Roach - our new app to a point of significant functionality and testing. Upon doing this...we have uncovered (and perhaps proven) a MASSIVE flaw in GS that is apparently something that there is no way to overcome unless you are Gendai.
So here it is...After some initial testing...here is what we found:
First the premise:
Toxic Roach is intended to be a strong title and not a 5 minute tapper. It is light weight on its gameplay concept but rich in experience. We are not using heavy logic and trying to keep things tight and well optimized by limiting constraints and physics processing. In other words...its not a "sloppy" build. Its lean and efficient.
Here is the online BETA demo: http://gamesalad.com/game/play/70409
So we began testing with a somewhat functional demo build. The demo has 10 active roach actors. They have 3 parts. The first part is a controller (remains locked) - the second is the actual roach art (unlocked and linked to the controller - also functions as the tap kill sensor) - the 3rd part is the death effect (also unlocked and linked to controller and roach switches - which produces the death art such as the green splat slime).
The ONLY spawning that occurs is during bomb and gas placements. All other actor reside at scene start. We are using resolution independence currently.
Soooo...that said...
As we began testing (on an iPod 2G), the initial front end peaked at about 25 MB with about 2/3 of that in the game engine (GE). When we opened the game screen for smashing roaches, the overall RAM usage jumped to about 40-42MB with about 25-28MB being game engine. For about the first 2 minutes that clocked up to peak at about 50MB with about 36MB in the GE (all others stayed steady). We assume that this ramp us is due to assets being processed (and/or loaded) into the physics engine. Eventually it leveled out and didn't change.
So we exit to the main menu via a scene change and all Memory demands dropped EXCEPT for the GE memory load. It remained elevated above the original main menu GE loads. This led us to believe that very little of the physics RAM was dumped on exit.
So we re-entered the game scene and the RAM once again clocked up to nearly the same peak benchmark as before...not a show stopper yet.
So we used the "RESTART" scene button (which is connected to the restart scene behavior) and the scene restarted as instructed. HOWEVER - the RAM remained at a higher elevation point and the scene began running again. This time the Peak RAM loads increased by about 20%. So our new RAM benchmark is 20% higher putting the overall RAM being used for the same exact scene to around 60-62MB. The only thing that increased in the memory reporting was the GE. It increased to about 36-38MB (up from 25-28MB). The EXACT same thing happened if we used a Change Scene to [same scene name] behavior in lieu of the restart scene.
So we played a while on that and then went back to main menu. Overall loads dropped once again but the GE for the main menu remained at its higher benchmark...leading us to believe that MEMORY IS NOT BEING RELEASED FROM THE PHYSICS ENGINE....EVER!!!
So we re-entered the game scene a 3rd time...played the scene again and the RAM benchmark started at an the previous higher level and leveled out at its previous elevated point. We tried a second restart and the scene restarted but its initial starting point was a higher RAM load and began clocking up EVEN HIGHER. It was not until the overall RAM achieved a 65MB threshold that it crashed the app. And 65MB of RAM allowance for an iPod 2G is DAMN GOOD! Average is about 45MB.
SOOOOO...In summary...
It appears that Gendai's beloved GS has a GameEngine that pays NO ATTENTION to memory management. THIS IS A HUGE PROBLEM.
If a game engine won't release memory...then how the hell are you supposed to build a physics game without anymore than 1 game scene that loops and never builds? How are you supposed to create a good game that has maybe 15 moving and colliding assets and never crashes after 2 minutes or after 3 scene restarts? Why is the GE using 60-70% of the RAM load...AND ASKING FOR MORE IN EVERY SCENE THAT IS EXECUTED...AS IF THERE IS AN UNLIMITED SUPPLY?
Again...I pray to God that I am wrong here. But this is the 2nd major game that I have begun that has been snafu'd by the game engine. The graphics in this one are static and the moving image loads to the renderer are small. Actor counts are not out of control and spawning is extremely limited.
IT APPEARS THAT THERE ARE STILL SOME MAJOR MEMORY MANAGEMENT PROBLEMS WITH GS AND IF ANYONE PLANS TO BUILD ANY SIGNIFICANT TITLE WITH IT...THEN IT APPEARS IT WILL BE A WASTED OF YOUR TIME.
PLEASE FOR THE LOVE OF GOD...SOMEBODY (GENDAI MAYBE) PLEASE PROVE ME WRONG. I WANT TO USE GAME SALAD BUT NOT TO MAKE PICK YOUR NOSE GAMES THAT DON'T SELL. TELL ME HOW THE HELL TO USE THIS GAME ENGINE TO MAKE A TITLE THAT PLAYS FOR LONGER THAN 5 MINUTES.
PLEASE HELP THIS COMPLETELY FRUSTRATED DEV THAT WANTS TO PROVE WHAT GS IS CAPABLE OF DOING...BUT APPEARS TO HAVE A COMPLETE SHAM OF A PHYSICS GAME ENGINE WASTING HIS TIME. GOD I HOPE I'M WRONG...BUT PLEASE TELL ME HOW I AM WRONG...AS THE RAM NUMBERS APPEAR TO SUGGEST THAT THE PHYSICS ENGINE IS TOTAL GARBAGE AS IS IN ITS CURRENT STATE REGARDING MEMORY USAGE...WHICH IMO SHOULD BE AT THE TOP OF ITS LIST IN CONCERNS.
PLEASE PROVE ME WRONG SO THAT I CAN FINISH MY PROJECT AND I WILL TAKE BACK THE "TOTAL GARBAGE" STATEMENT...BUT AS IT LOOKS RIGHT NOW...I DON'T THINK THAT IS A MIS-GUIDED STATEMENT. I THINK THIS IS MORE THAN JUST A LITTLE MEMORY LEAK...IT APPEARS THE GAME ENGINE IS IGNORING ANY MEMORY MANAGEMENT ISSUES OF ANY KIND...AND FOR MICRO DEVICE DEVELOPMENT PLATFORMS...THIS APPROACH IS COMPLETELY OUT OF THE QUESTION AND UNACCEPTABLE...IF IT IS INDEED THE CASE...AGAIN...PLEASE PROVE ME WRONG.
So here it is...After some initial testing...here is what we found:
First the premise:
Toxic Roach is intended to be a strong title and not a 5 minute tapper. It is light weight on its gameplay concept but rich in experience. We are not using heavy logic and trying to keep things tight and well optimized by limiting constraints and physics processing. In other words...its not a "sloppy" build. Its lean and efficient.
Here is the online BETA demo: http://gamesalad.com/game/play/70409
So we began testing with a somewhat functional demo build. The demo has 10 active roach actors. They have 3 parts. The first part is a controller (remains locked) - the second is the actual roach art (unlocked and linked to the controller - also functions as the tap kill sensor) - the 3rd part is the death effect (also unlocked and linked to controller and roach switches - which produces the death art such as the green splat slime).
The ONLY spawning that occurs is during bomb and gas placements. All other actor reside at scene start. We are using resolution independence currently.
Soooo...that said...
As we began testing (on an iPod 2G), the initial front end peaked at about 25 MB with about 2/3 of that in the game engine (GE). When we opened the game screen for smashing roaches, the overall RAM usage jumped to about 40-42MB with about 25-28MB being game engine. For about the first 2 minutes that clocked up to peak at about 50MB with about 36MB in the GE (all others stayed steady). We assume that this ramp us is due to assets being processed (and/or loaded) into the physics engine. Eventually it leveled out and didn't change.
So we exit to the main menu via a scene change and all Memory demands dropped EXCEPT for the GE memory load. It remained elevated above the original main menu GE loads. This led us to believe that very little of the physics RAM was dumped on exit.
So we re-entered the game scene and the RAM once again clocked up to nearly the same peak benchmark as before...not a show stopper yet.
So we used the "RESTART" scene button (which is connected to the restart scene behavior) and the scene restarted as instructed. HOWEVER - the RAM remained at a higher elevation point and the scene began running again. This time the Peak RAM loads increased by about 20%. So our new RAM benchmark is 20% higher putting the overall RAM being used for the same exact scene to around 60-62MB. The only thing that increased in the memory reporting was the GE. It increased to about 36-38MB (up from 25-28MB). The EXACT same thing happened if we used a Change Scene to [same scene name] behavior in lieu of the restart scene.
So we played a while on that and then went back to main menu. Overall loads dropped once again but the GE for the main menu remained at its higher benchmark...leading us to believe that MEMORY IS NOT BEING RELEASED FROM THE PHYSICS ENGINE....EVER!!!
So we re-entered the game scene a 3rd time...played the scene again and the RAM benchmark started at an the previous higher level and leveled out at its previous elevated point. We tried a second restart and the scene restarted but its initial starting point was a higher RAM load and began clocking up EVEN HIGHER. It was not until the overall RAM achieved a 65MB threshold that it crashed the app. And 65MB of RAM allowance for an iPod 2G is DAMN GOOD! Average is about 45MB.
SOOOOO...In summary...
It appears that Gendai's beloved GS has a GameEngine that pays NO ATTENTION to memory management. THIS IS A HUGE PROBLEM.
If a game engine won't release memory...then how the hell are you supposed to build a physics game without anymore than 1 game scene that loops and never builds? How are you supposed to create a good game that has maybe 15 moving and colliding assets and never crashes after 2 minutes or after 3 scene restarts? Why is the GE using 60-70% of the RAM load...AND ASKING FOR MORE IN EVERY SCENE THAT IS EXECUTED...AS IF THERE IS AN UNLIMITED SUPPLY?
Again...I pray to God that I am wrong here. But this is the 2nd major game that I have begun that has been snafu'd by the game engine. The graphics in this one are static and the moving image loads to the renderer are small. Actor counts are not out of control and spawning is extremely limited.
IT APPEARS THAT THERE ARE STILL SOME MAJOR MEMORY MANAGEMENT PROBLEMS WITH GS AND IF ANYONE PLANS TO BUILD ANY SIGNIFICANT TITLE WITH IT...THEN IT APPEARS IT WILL BE A WASTED OF YOUR TIME.
PLEASE FOR THE LOVE OF GOD...SOMEBODY (GENDAI MAYBE) PLEASE PROVE ME WRONG. I WANT TO USE GAME SALAD BUT NOT TO MAKE PICK YOUR NOSE GAMES THAT DON'T SELL. TELL ME HOW THE HELL TO USE THIS GAME ENGINE TO MAKE A TITLE THAT PLAYS FOR LONGER THAN 5 MINUTES.
PLEASE HELP THIS COMPLETELY FRUSTRATED DEV THAT WANTS TO PROVE WHAT GS IS CAPABLE OF DOING...BUT APPEARS TO HAVE A COMPLETE SHAM OF A PHYSICS GAME ENGINE WASTING HIS TIME. GOD I HOPE I'M WRONG...BUT PLEASE TELL ME HOW I AM WRONG...AS THE RAM NUMBERS APPEAR TO SUGGEST THAT THE PHYSICS ENGINE IS TOTAL GARBAGE AS IS IN ITS CURRENT STATE REGARDING MEMORY USAGE...WHICH IMO SHOULD BE AT THE TOP OF ITS LIST IN CONCERNS.
PLEASE PROVE ME WRONG SO THAT I CAN FINISH MY PROJECT AND I WILL TAKE BACK THE "TOTAL GARBAGE" STATEMENT...BUT AS IT LOOKS RIGHT NOW...I DON'T THINK THAT IS A MIS-GUIDED STATEMENT. I THINK THIS IS MORE THAN JUST A LITTLE MEMORY LEAK...IT APPEARS THE GAME ENGINE IS IGNORING ANY MEMORY MANAGEMENT ISSUES OF ANY KIND...AND FOR MICRO DEVICE DEVELOPMENT PLATFORMS...THIS APPROACH IS COMPLETELY OUT OF THE QUESTION AND UNACCEPTABLE...IF IT IS INDEED THE CASE...AGAIN...PLEASE PROVE ME WRONG.
Comments
The game doesn't crash until the memory runs out...not because of my logic. All crashes happen at the same RAM threshold of around 65MB on our testing device.
Its looking VERY MUCH like a GE MEMORY MANAGEMENT problem and nothing more. Again...I hope I'm wrong...but it doesn't look that way.
Just don't rely on it for distribution builds.
After you get everything lined up the way you want it, re-build your app in XCode and use proper memory management.
PS: Out of curiosity, what physics features are you using in GameSalad that are required for your gameplay? I tried your web game and did not observe anything that would be difficult to program in XCode, but maybe it's because I only played for a few minutes and am not very good at your game...
Mostly just using collide, move and interpolations.
I'm convinced now that GS is just not worth the time...its wayyyyy too unreliable.
I think we are going native from here on out as you suggest...or perhaps switch to Corona once their Game Builder is released.
GS has simply wasted too much of my time. I hope Gendai tells me something I am missing soon...otherwise...I'll be moving on.
The GameSalad Viewer makes it worthwhile as a prototyping tool. It is very convenient and can build a rapid POC. Definitely worth your while to stick with Express.
This game is static and the physics are very simple. And I was hoping that Gendai might address the memory issues over the last several months.
Apparently not even though they claim to have some. I believe Gendai is fully aware that their GE is a memory resource hog...but I'm not sure if everyone else completely understands that.
So this post is as much a heads up as it is a plea for Gendai to address the issue sooner than later. Memory management is an extremely fundamental issue. And with all the memory leaks running rampant in their software as well as apparently their physics engine...it appears that memory control is not a top priority to them...which is a blasted shame and inexcusable IMO.
For months everyone has been screaming iPad, iAds, Pause, Game Center...etc. and I have been standing alone for the most part screaming Game Engine, Optimizations, Memory Leaks, etc. My type of message is evidently being ignored and as a result...don't expect to do much more than bubble popping apps with GS until they decide to focus on this.
In the meantime...Corona is looking much better now to me...and is looking to launch their game builder any day now. We've begun the porting process for Toxic Roach already. If the timing works out...I think TR is going to be a Corona title and not GS.
Also whats Coronas Game Builder, I know they have a regular code program, but is Game Builder a GS competitor? IE GUI programming?
No GUI (yet)...but they (Corona) claims to be able to drop a box and have it bounce on the floor with about 8 lines of (intuitive) scripting vs. about 300 lines of complex syntax code and mathematics in Obj C.
Its a scripting engine...but may possibly have a GUI down the road. They apparently are approaching it differently and building a solid GE first and then build the GUI.
It has TONS of capability and does more than games...its has database support, arrays, video, and more...and with the game builder...will have Box2D physics in it (same as GS). Plus it ports to Android.
Its a stiff competitor to GS and well out in front in capability. I think GS has a lot of work to do to match it. And if the GE is sub-par to others...then what's the point of it.
I really wanted Toxic Roach to be a success with GS...but it appears that its just not possible. Again...this thread is a request to prove me wrong...because I just can't see a solution. I feel I know the software as good as anyone...but the GE is just underdeveloped and completely resource intensive and EXTREMELY limiting in regards to optimization and performance.
To compare...Coronas default GE uses 300KB. GS uses about 15-25MB. Pro features in Corona are included for $250. $2000 with GS. Its apples and oranges IMO.
I am trying to get into serious coding, if theres some tutorials for corona could you post them? I honestly have no idea where to start. I have no previous coding experience so the very first things I need to learn would be very helpful! Thanks!
-Will
There must be something happening with the physics somewhere.
FMGs' 'There must be something happening with the physics somewhere' seems to ring true...
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Would it be Instance vs prototype problem?
Corona....everything is included $49 -$99
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
By the time you're comfortable with it the Game Edition should be free of any serious bugs and ready to go. Android deployment too.
Does Corona have GameCentre etc yet?
I think we need stability, better memory management, speed and DOCS!!! All of that well before Aids and GayCentre, thanks. ;-) I think Gendai feel the same way too... they seem to be working on the stability side of things at least.
http://anscamobile.com/corona/roadmap/
Please note I'm not pushing Corona over GS here. I'm happy enough using both, but GS's pros (ease of use/no coding) will always be pulled back by certain cons. For me GS is (or should soon be) the ideal prototyping software, and capable of creating 'certain' full apps. My needs go beyond that though and Corona looks to be the app for my, shall we say, more complicated game structures.