@Lovejoy said:
It is my understanding that a new RC will be out soon dressing certain issues. It was mentioned during the meet-up I'm sure. So lets see on Monday when the gs staff gets back on the hot seat.
The speed at which the GS team addresses 1) the now defunct support for Ipad2 and mini 2) allow the selection of IOS version when publishing, will be a determining factor for me. I'm assuming the GS team was under pressure to release a 64bit pipeline for iOS. Either way creator 12.20 = broken QA...this "stable build" should never have been released.
@Thunder_Child said:
"How about asking for current features to be fixed."
Haha. That is.... funny. Well, heartbreakingly true, unfortunately.
I just earnt the bade "Keeper of Knowledge" on the forums. Which is ironic, seeing as that knowledge seems to be something about coming to terms with the 7 stages of grief, as far as I can tell.
Rather than actually releasing my larger scale games I've learnt how to make in Game Salad, my crowning achievement might be to accept that those games will die, and be buried, and that all that work will never be seen by the public, and can never be monetized, and that all the money I've spent on Game Salad Pro will be washed down the drain in a murky pool.
Honestly, occasionally throughout my day, I remember something about all the hours of work that has gone into my game over the years, and I get this really horrible feeling in my stomach that there is nothing I can do to get that game finished and on the App Store.
Those hours of grueling effort have helped me, yes I have learnt things, yes I enjoyed many of those hours, yes they brought me satisfaction that my game had new systems in it, that the game worked... but I cannot continue work on my game, for reasons completely out of my control. And I'm paying $'s for that.
The thing is, this isn't an entirely new feature, it is just an approach to try to get something working properly.
To be honest, surely the CHANGE SCENE behaviour should do a memory cleanup all on it's own, thus not needing any sort of "MEMORY CLEANUP" behaviour. But it's just an attempt to try to get a result which has not come any other way so far. It may shed a light on something that they might realise is fairly easy to do, and useful for users. Who knows...
I hardly dare think about how I would feel if they suddenly added a feature that totally put my game projects back on the map for feasible development, and suddenly they just worked again.
As it stands, although I keep using Game Salad, and keep hoping it'll work for me, I dare not ever recommend it to anyone due to the extreme heartbreak and anguish it has caused me over the past 3 or 4 years.
The best and most advanced game projects I've ever worked on as an independent developer have been hamstrung and destroyed by the very tool which is designed to make game development as easy and accessible as possible.
Jeez my new word game runs perfectly on this release however I was not able to test it on 4s or the iPad mini 2 so I think I'll wait on releasing this thing.
@gattoman said:
I suspect some issues are unfixable without a huge redo of code. Hence Graphene.
I can totally appreciate the move to Graphene.
But it doesn't make the pain of using Game Salad and losing beloved projects and years of hard work any more pleasant or palatable.
I hope Graphene works out well for them, and I hope the Game Salad developers enjoy working with the new engine much more, because the Game Salad code-base much be a horrendously frustrating and un-optimal pile of garbage, as that is really the only good explanation for the frustrating amount of bugs and issues that seem to appear in pretty much every build that gets released.
For every good feature or bug fix that goes in, there seems to be another 12 bugs added. Whenever a new rendering engine goes in, or a change to the LUA implementation, these "optimisations" seem to result in my projects using more memory, and crashing out more.
As I recall, in 10.4, it used a different LUA implementation which used less memory - something about "real" numbers using 8 bytes instead of 16, or something. So some new LUA implemention - which went in for some reason or other, which I doubt did anything useful - meant projects used up much more memory. That was perhaps the beginning of the end for my project.
There doesn't seem to be anyone at GS who actually sits and opens the large game projects people sends in, and figures out how these games can run more efficiently and effectively, which seems a real shame, because that would help everyone. An efficient, lean, clean engine would help everyone.
And yes, I'm sure they hope Graphene will achieve some of these things.
But like I said, it doesn't make the years of work on Game Salad projects feel any more painful, as we get left behind with increasingly broken projects which will never see the light of day.
I started my game "B-Grade Renegade" in 2012. I then made 2 smaller games since, to learn about coding and stuff better, and returned to my project and kept working on it.
I've worked on it on and off since then, putting in perhaps 200 days work or so in total man hours. That game project loads a Main Menu, then loads into semi-randomly generated levels, then back to the Main Menu. It uses more memory every time you get back to the Main Menu. WHY? I've gone back to the Main Menu. The level scene isn't needed any more. Shouldn't it return back to the base level of memory each time I get back to the Main Menu? It gets bigger and bigger until it crashes. I can't control that. I can't control memory usage at that level.
If I was working with the engine programmer sitting next to me at my own studio, that guy would have fixed that issue for me 2 years ago.
The people at GS? For some reason, they can't do anything about that.
I've been working on another RPG project for a few years too, because I had to shelve B-Grade Renegade for about 1 year after giving up and waiting for fixes from GS.
In the latest SR 0.12.20, that game is also crashing when I start it up.
Hence my many words written here. Is Game Salad determined to kill all my game projects along with my remaining passion to actually make games at all? Is that what I'm paying $300 a year for?
I appreciate that Game Salad want to go make a new tool. Good-o.
But for Game Salad, and us users who still need to deal with it, and would love to get our games finished off, I urge the GS team to please just focus on stability and performance. forget new features, it's all just a distraction.
@Hymloe Graphene is a new tool being handled by a different team so it does not affect the current staff that work on Gamesalad.
It has also been said that Gamesalad will continue to support Gamesalad creator even after Graphene is out. No details on how long after though. So perhaps you will be able to finish your game at some point.(hopefully)
Regarding what the Gamesalad team is currently working on:
2014's priority was to squash bugs, 2015's is to implement features. Now, I'm sure they will continue to work on bugs, but if 2014's was bug squashing year and certain issues remain unfixed then i can see why there is a concern with bugs being fixed this year (feature request year).
@Figuromo said:
The speed at which the GS team addresses 1) the now defunct support for Ipad2 and mini 2) allow the selection of IOS version when publishing, will be a determining factor for me. I'm assuming the GS team was under pressure to release a 64bit pipeline for iOS. Either way creator 12.20 = broken QA...this "stable build" should never have been released.
Im not disagreeing with you on this issue. It has obviously made certain members project un-playable and forced to wait. And since time is money, it creates a truly saddening situation.
I have an RPG project that is just shy of 1GB installed adhoc. Lot's of textures, animations, particles etc. That being said this project is always being optimized to keep the memory within a safe limit. This is the project I tested with.
Devices:
iPad4 iOS v8.1
iPad Mini retina (1st) iOS v8.1
iPad Mini (1st) iOS v8.0
Performance:
I used xcode instruments for all of my testing.
iPad4: 40-60 FPS Memory maxed at about 350mb (512 is upper limit before crash)
iPad Mini Retina: 50-60 FPS Memory maxed at about 350mb (512 is upper limit before crash)
iPad Mini: 15-45 FPS **Memory gave multiple warnings and maxed at 270mb, crashed. ** (256mb is upper limit before crash)
Now as a point of reference, this project was getting 20-50FPS and the memory usage was about 200-210 before this on iPad mini 1st gen. So it looks like a bit of memory usage increase in GSC v12.20 caused it to go over the edge.
I can probably optimize a bit more, but honestly if the nightly (13) gets to stable point, it wont matter. The memory usage is waaayy down (75-150mb) with that, but man oh man it has so many bugs.
If not then I guess those devices won't be supported.
I've been developing on GS for a few years now, and as you can tell by the number of posts I've put up, I've been silent; absorbing all the craft and love this community puts into this forum and making Indi game devs like myself more informed and better game-makers. Like myself, GS is also typically silent and they let the forum inform the devs...and you all graciously do it and I'm amazed at all the subject matter covered by all of you. I don't attribute the strength of GS to its code or tool set. To me it's been this amazing community. So to make up for my years of silent absorption, here's a long-ass post
I've spoken to a few of my veteran game developer friends about what I'm going through with game salad memory issues and what my options are, and they gave me this important bit of wisdom in wanted to share with the community that's given me so much over the years. I've been told this is true for any game dev team working directly on target on day one (testing their games on the final hardware vs cheating on beefy systems):
After design, managing memory is one of the most important things you do when you develope games. The amount you have drives the quality and quantity of the content of your game. When a project takes a year or more to develop, what usually happens is the code starts dirty and hacky and innificient. The focus isn't on clean code, it's just to get things in and working asap to prove out the game design. If the game design is fun and a go, memory is partitioned to the game components (art, sound, animation, effects...). I make this memory allocation process sound like a clean process but apparently it's messy and filled with reality-tv worthy material. Anyway, allocation plan is done and this lets art and design produce assets that will fit in memory (or are at least in the right ballpark). Now here's the key: remember those hacks to get proof of concept...when production on art and design start, code gets busy doing proper implementation and gets cleaned up. So you end up with more optimal usage out of memory the further you get into production.
When everything goes right, you start with less memory and you end up with more later. That memory you get later lets you put more polish. That's why games sometimes look like ass at alpha and suddenly look so much better once they ship; team got more memory and better memory management out of the engine...as planned. That's also why first gen console games look so bad compared to 2nd and 3rd gen. Code has more time to implement memory saving features and techniques.
Sometimes the opposite happens: code didn't have time to do what devs had speced out or coders are lazy, or hardware isn't doing something you thought it would. Then you get games that looked so good in development and end up looking low resolution with bad frame rate.
So there we have it. The main issue many of us long-term-game-project-makers (aka dreamers) haven't caught on yet. Gamesalad doesn't make a game and they don't know what game you're making or how much memory you're at and where you've placed your allocations.
We make allocation calls based on the engine we have, but if GS decides one day to add a feature that'll eat into you're planned budget there's no communication or collaboration (or negotiating) so you're out of luck. If you spent a year making a game and it's been through 5-6 creator releases, your budget has bloated and changed on every release because there's no memory management directly liked to the YOUR game. The most important aspect of game production is a moving target...and we just get less of it on every release because it's not deemed as a priority by GS.
So, PRO users should demand that gamesalad INCREASE our memory pools and optimize on each release...clean up code as they go. No one wants to redo or throw away their work. That's not why we pay for this service. We need some level of stability...or this isn't the right service for a PRO.
Im sure memory optimization isn't fun code work and doesn't make for a nice press release. It's tedious and arduous and doesn't get the oos and ahhhs from your peers...working on Graphene will! But if GS management doesn't see this as an issue to take seriously, this amazing community of developers will go through the same cycle with the Graphene new shiny toy...and that amazing community will move and set up shop at that new company down the block that gets it.
Fix your memory issues GS or else you're not really collaborating with your PRO dev community...you're just catering to the weekend game projects with friends drinking a bear and playing around. I read your post @Hymloe. Thanks for sharing and I completely get where you're at. I also have a few projects which have been "memory-ed" and I don't want to think about those hundreds of hours and what I could have been doing or creating instead of pursuing a game that'll never be. I want to hope that GS can change that (after all, I'm one of those dreamer devs), but I fear their priorities are elsewhere.
@Figuromo said:
We should demand that gamesalad INCREASE memory and optimize on each release...clean up code as they go. It's not fun code work. It's tedious and arduous and doesn't get the oos and ahhhs from your peers...working on Graphene will! But if GS management doesn't see this as an issue to take seriously, this amazing community of developers will go through the same cycle with the Graphene new shiny toy...and they'll loose to that new company down the block that gets it.
Fix your memory issues GS or else you're not really collaborating with your PRO dev community...you're just catering to the weekend game projects with friends drinking a bear and playing around. I read your post Hymloe. Thanks for sharing and I completely get where you're at. I also have a few projects which have been "memory-ed" and I don't want to think about those hundreds of hours and what I could have been doing or creating instead of pursuing a game that'll never be. The GS can change that, but I fear their priorities are elsewhere.
Well said, striking at the very core of the problem!
@Figuromo said:
I read your post Hymloe. Thanks for sharing and I completely get where you're at. I also have a few projects which have been "memory-ed" and I don't want to think about those hundreds of hours and what I could have been doing or creating instead of pursuing a game that'll never be. I want to hope that GS can change that (after all, I'm one of those dreamer devs), but I fear their priorities are elsewhere.
Thanks @Figuromo it's somewhat comforting to know that others are out there suffering the same frustrations at being "memory-ed" out of being able to complete their game projects. It feels so hopeless as Game Salad seems to get more and more inefficient, and lots of effort seems to get spent on things that don't really work out as promised, when users with larger projects suddenly go from a project that works to one that crashes out due to some sort of memory allocations in the GS code, without the appropriate memory cleanups or memory management going on.
I'm home from work, and planning to sit down and do a more thorough testing of GS 0.12.20, write up some bugs and a request for some sort of better memory management control for us developers, and hopefully I'll have some links to post for anyone who wants to add their support and further info to any relevant bugs, etc.
Power on people, and here's to hoping that GS can put in some focussed work on the memory issues and get some of our beloved projects back to the land of the living.
I'd even buy another Pro license for another year if things came good, so I could give my two large projects the finishing phases they need to actually be good games.
@Figuromo I read your post and I suspect it is not as simple as some think. Fixing memory leaks in a massive poorly written code base is a huge task and might not even be possible. I suspect this is the biggest reason why they are creating Graphine. Creator is just not fixable and every new feature just makes it even harder to keep juggling all the balls so to speak. This is evidenced by their longevity (This has been going on for years) and the amount of time it takes to track and find some or most of the current crop. If it could be fixed permanently it would have been done.
@colander said:
Figuromo I read your post and I suspect it is not as simple as some think. Fixing memory leaks in a massive poorly written code base is a huge task and might not even be possible. I suspect this is the biggest reason why they are creating Graphine. Creator is just not fixable and every new feature just makes it even harder to keep juggling all the balls so to speak. This is evidenced by their longevity (This has been going on for years) and the amount of time it takes to track and find some or most of the current crop. If it could be fixed permanently it would have been done.
That is simply not true, blaming something like that on poorly written code that is not fixable is just plain lazy. It might be hard but of course it's not impossible. It comes down to how they prioritize and resource allocation.
I am now facing an interesting situation (dead end). I was working on the update of my game for the last 3 months and now I can't use 0.12.10 even 0.12.20.
0.12.10 - iOS binary rejected because of non 64 bit support (BTW working with GS 0.12.10 is disaster - it is really slow).
0.12.20 - Bug 688. iAds has to be on the bottom of the screen. I can't disable it. It generates negligible part of revenue. If I turn it off, I can't purchase next year subscription of GS because of unhandsome money drop (every $ is important in this though business). So now I can't update to 0.12.20 and I am scared that bug fix (688) will take another X months. Does exist any ETA? Please be focused on monetization options = money for GS subscriptions!
I have to say there are plenty of app stores and I understand that everything is changing every while so I am admire that you are handling it well. ;-) And I also have to confirm that there are random app crashes last few months (last time my game randomly crashed during hitting the Chartboost ad close button).
@colander said:
Figuromo I read your post and I suspect it is not as simple as some think. Fixing memory leaks in a massive poorly written code base is a huge task and might not even be possible. I suspect this is the biggest reason why they are creating Graphine. Creator is just not fixable and every new feature just makes it even harder to keep juggling all the balls so to speak. This is evidenced by their longevity (This has been going on for years) and the amount of time it takes to track and find some or most of the current crop. If it could be fixed permanently it would have been done.
I don't consider comments like this to be productive.
"Game Salad cannot be fixed. Accept that it is broken."
I've worked at game studios for 12 years, and a good programmer - against their sense of joy or sanity - can track down any and all memory leaks, using the right tools.
It takes time, it takes effort, it takes skill. But it can be done. And we deserve the respect, as paying customers, and passionate game developers, to have the tool that we pay for work correctly, without memory leaks, without crashes that destroy our hard work.
So please, I appreciate your sentiment, but try not to accept something as being difficult and therefore acceptable. It is not acceptable.
I worry that voices on here that accept it are the only thing that make it acceptable to the Game Salad management. They may not have people with the skills to do it quickly and effectively. But if they prioritise this as a very serious issue that is crippling (at least some sectors) of their user base in a debilitating way, that is the only way it'll get fixed.
THE MEMORY PROBLEMS CAN BE FIXED. It just needs to be a priority, and it needs to be tested properly, with the right test cases.
I'm sending in a bug now, with my project attached. I'm hoping that will give them at least one project to run through the debugger and profiler, to track down the memory problems in their own engine.
It's rather long winded, but I wanted to write it in detail, and try to explain the issue thoroughly, so it wouldn't be misunderstood.
I've sent them a private link to my project, which I hope will help them examine the issue, and hopefully find a solution.
Please add your own further details, or examples, or private links to your projects if you think you have a good test case for them to narrow down the issues.
My hope is that they will put someone good onto the task, and have them really hammer it out, and find where all the memory is going, and why it isn't being cleaned up during scene changes.
All the hard work that we have put into building our games, but yet bugs just keep getting into our way. This great!!, game community with beautiful! and remarkable! human beings (who will jump to the aid of each other ) are suffering from bugs. I could not believe it when iAds stop working properly (only the top )
Added the following comment: good description that outlines what I have observed too. Good that you sent a project to the GS team also for testing.
One thing I can add is that the memory leaking, with the eventual crash, occurs on one-scene games also when spawning, destroying, spawning destroying and so forth.
Completely agree with what everyone is saying. Many of us have been working on projects for months and years, hoping to achieve our dreams and put GS on the map, so it can be really discouraging to even think that so much work could potentially go to waste, and it makes it that much harder to be motivated when time and money are at stake every minute of the day. We certainly need to do something about this soon...
GS has made memory a priority, or so it seemed. I'm just not sure the system for mega-texturing is going to be stable, that's more my concern. If that system can get it's other flaws figured out, memory usage will be way down.
I agree about the whole testing with big projects. Sometimes QA seems very uninterested in helping and there have been multiple occasion throughout the years where i've been told "your project is too large"... really? They don't even address or acknowledge that this is a two way battle for developers (we can only do so much without the help of the engine).
Trust me when I say I spend the time optimizing my projects, please do the same with your engine for large projects.
So on the stable version prior to this, I am getting lots of reports of the game crashing after about 5 mins of gameplay. It's not due to any specific point and simply seems it is just occurring from too much memory usage piling up until the app crashes to dump it.
It appears that crashing issues are still in existence in this build? So my apps must endure a barrage of negative reviews simply because GS won't/can't fix it? Or are you guys just too busy with your other ventures (Graphene) to give a damn?
I'll be honest. I can't imagine many people will follow over from this GS creator to your new Graphene when you demonstrate your lack of competence in dealing with issues on this current system. You better hope there are a lot of naive people that will blow more money on another product from a company that can't seem to get this current software working. Right now you have a lot of people trapped with GS because its a software they are familiar with and already have a bunch of games developed with. When you release Graphene and further neglect the current Creator, I have a feeling people are going to leave GS in mass. Your company will go along with it.
Stop spreading out your resources, and get this current system fixed and stabilized so you stop wrecking our businesses. Then maybe people will be interested in your new software. It also wouldn't hurt to actually address these crashing issues with a response and maybe a timeline to fix it. The incompetence at GS is astounding. Fire your CEO or something, because someone is steering your company right off a cliff.
ForumNinjaKey Master, Head Chef, Member, PROPosts: 554
Hey everyone. It's my understanding that release 12.20 was just supposed to have iOS 64 support, account validation on Creator start, and some memory fixes for people using Mac Yosemite 10.10.
While there still appears to be some memory leak issues (check out bug 709 and bug 103).
@BenSawyer sheds some insight on what is causing the memory leak as well as a workaround you guys can use in the meantime while we work on fixing it (see comment 44 for bug 103).
@MarcMySalad@Hymloe when I say it is not fixable I mean with GS's current resources it is not possible. The amount of time it would take to do the task would be longer than starting from scratch and would be similar in practice as a rewrite but take much longer to achieve. I believe they had a review on this over a year ago and decided just that. This is why we are getting Graphine it is easier and quicker to start over.
@MarcMySalad saying the GS team is lazy is just not cool. From what I see they are very hard working. They work on projects outside of working hours for the benefit of the community and at times late into their evenings fixing Creator and publishing issues. They are not lazy it just that fixing the code base is an enormous and very difficult task.
My code writing experience is limited to VBA and I know first hand fixing some else's inefficient poorly written and commented code is a waste of time. It is just a patch which causes other problems. A rewrite it is always the quicker and best option.
They are dealing with thousands and thousands of lines of code so interconnected and poorly constructed that changes in one area create unintended problems elsewhere. This is self evident we can all see the results. Nearly every time an improvement is made to Creator a bunch of hard to fix bugs crop up and some have persisted for years.
I know this is difficult to understand if you code writing experience is limited to GS. But you must of come across other faulty things created by other people where it was easier and quicker to tear it down or through it away and start again. I believe this is one of those situations it certainly appears to what they are doing. Unfortunately for them they can't just through Creator in the bin, lots of people are using it. It would be akin to throwing their business in the bin. At some point in the future when they have migrated people over to Graphine, Creator will be quietly retired. Nothing else would make any sense.
I upgraded to Yosemite and Gamesalad was so sluggish it was impossible to scroll through code and everything was slow ... that never happened with Mavericks so I'm sadly reverting. Everything else runs flawlessly in Yosemite.
@AlchimiaStudios said:
GS has made memory a priority, or so it seemed. I'm just not sure the system for mega-texturing is going to be stable, that's more my concern. If that system can get it's other flaws figured out, memory usage will be way down.
I agree about the whole testing with big projects. Sometimes QA seems very uninterested in helping and there have been multiple occasion throughout the years where i've been told "your project is too large"... really? They don't even address or acknowledge that this is a two way battle for developers (we can only do so much without the help of the engine).
Trust me when I say I spend the time optimizing my projects, please do the same with your engine for large projects.
I agree. I think Game Salad are quick to suggest that someone's project just "has problems because it's too big", without really delving in and seeing what happens to memory and stuff in the normal process of running a big game.
Obviously, Game Salad users CAN crash Game Salad by simply putting in too many assets, etc.
But my game - for example - builds up and up and up between scene changes, and never goes back down, even when I Change Scene back to the Main Menu. I just want to dump out all the excess memory usage that I don't need anymore. That's what I'd do if I had my programmer sitting next to me, I'd get them to properly dump out everything that's not needed anymore when we go back to the Main Menu. That's just logical.
Game Salad needs to fix the memory clean-up processes at their end. And the only way I think they can deal with that issue at the source, is to run through some of these larger projects, make changes to the cleanup process, and test to see that their changes are working.
There's no point in just making some quick 3 actor game, and going, "Yep, it's all working fine, ship it out the door". That will not pickup or notice the memory problems.
We are relying on the Game Salad programmers to be OUR programmers, our ENGINE TEAM, they need to make Game Salad work properly, even on games that push things a bit.
Comments
The speed at which the GS team addresses 1) the now defunct support for Ipad2 and mini 2) allow the selection of IOS version when publishing, will be a determining factor for me. I'm assuming the GS team was under pressure to release a 64bit pipeline for iOS. Either way creator 12.20 = broken QA...this "stable build" should never have been released.
Haha. That is.... funny. Well, heartbreakingly true, unfortunately.
I just earnt the bade "Keeper of Knowledge" on the forums. Which is ironic, seeing as that knowledge seems to be something about coming to terms with the 7 stages of grief, as far as I can tell.
Rather than actually releasing my larger scale games I've learnt how to make in Game Salad, my crowning achievement might be to accept that those games will die, and be buried, and that all that work will never be seen by the public, and can never be monetized, and that all the money I've spent on Game Salad Pro will be washed down the drain in a murky pool.
Honestly, occasionally throughout my day, I remember something about all the hours of work that has gone into my game over the years, and I get this really horrible feeling in my stomach that there is nothing I can do to get that game finished and on the App Store.
Those hours of grueling effort have helped me, yes I have learnt things, yes I enjoyed many of those hours, yes they brought me satisfaction that my game had new systems in it, that the game worked... but I cannot continue work on my game, for reasons completely out of my control. And I'm paying $'s for that.
The thing is, this isn't an entirely new feature, it is just an approach to try to get something working properly.
To be honest, surely the CHANGE SCENE behaviour should do a memory cleanup all on it's own, thus not needing any sort of "MEMORY CLEANUP" behaviour. But it's just an attempt to try to get a result which has not come any other way so far. It may shed a light on something that they might realise is fairly easy to do, and useful for users. Who knows...
I hardly dare think about how I would feel if they suddenly added a feature that totally put my game projects back on the map for feasible development, and suddenly they just worked again.
As it stands, although I keep using Game Salad, and keep hoping it'll work for me, I dare not ever recommend it to anyone due to the extreme heartbreak and anguish it has caused me over the past 3 or 4 years.
The best and most advanced game projects I've ever worked on as an independent developer have been hamstrung and destroyed by the very tool which is designed to make game development as easy and accessible as possible.
Jeez my new word game runs perfectly on this release however I was not able to test it on 4s or the iPad mini 2 so I think I'll wait on releasing this thing.
www.appdore.com || appdore twitter || appdore facebook
I can totally appreciate the move to Graphene.
But it doesn't make the pain of using Game Salad and losing beloved projects and years of hard work any more pleasant or palatable.
I hope Graphene works out well for them, and I hope the Game Salad developers enjoy working with the new engine much more, because the Game Salad code-base much be a horrendously frustrating and un-optimal pile of garbage, as that is really the only good explanation for the frustrating amount of bugs and issues that seem to appear in pretty much every build that gets released.
For every good feature or bug fix that goes in, there seems to be another 12 bugs added. Whenever a new rendering engine goes in, or a change to the LUA implementation, these "optimisations" seem to result in my projects using more memory, and crashing out more.
As I recall, in 10.4, it used a different LUA implementation which used less memory - something about "real" numbers using 8 bytes instead of 16, or something. So some new LUA implemention - which went in for some reason or other, which I doubt did anything useful - meant projects used up much more memory. That was perhaps the beginning of the end for my project.
There doesn't seem to be anyone at GS who actually sits and opens the large game projects people sends in, and figures out how these games can run more efficiently and effectively, which seems a real shame, because that would help everyone. An efficient, lean, clean engine would help everyone.
And yes, I'm sure they hope Graphene will achieve some of these things.
But like I said, it doesn't make the years of work on Game Salad projects feel any more painful, as we get left behind with increasingly broken projects which will never see the light of day.
I started my game "B-Grade Renegade" in 2012. I then made 2 smaller games since, to learn about coding and stuff better, and returned to my project and kept working on it.
I've worked on it on and off since then, putting in perhaps 200 days work or so in total man hours. That game project loads a Main Menu, then loads into semi-randomly generated levels, then back to the Main Menu. It uses more memory every time you get back to the Main Menu. WHY? I've gone back to the Main Menu. The level scene isn't needed any more. Shouldn't it return back to the base level of memory each time I get back to the Main Menu? It gets bigger and bigger until it crashes. I can't control that. I can't control memory usage at that level.
If I was working with the engine programmer sitting next to me at my own studio, that guy would have fixed that issue for me 2 years ago.
The people at GS? For some reason, they can't do anything about that.
I've been working on another RPG project for a few years too, because I had to shelve B-Grade Renegade for about 1 year after giving up and waiting for fixes from GS.
In the latest SR 0.12.20, that game is also crashing when I start it up.
Hence my many words written here. Is Game Salad determined to kill all my game projects along with my remaining passion to actually make games at all? Is that what I'm paying $300 a year for?
I appreciate that Game Salad want to go make a new tool. Good-o.
But for Game Salad, and us users who still need to deal with it, and would love to get our games finished off, I urge the GS team to please just focus on stability and performance. forget new features, it's all just a distraction.
Stability and performance.
@Hymloe Graphene is a new tool being handled by a different team so it does not affect the current staff that work on Gamesalad.
It has also been said that Gamesalad will continue to support Gamesalad creator even after Graphene is out. No details on how long after though. So perhaps you will be able to finish your game at some point.(hopefully)
Regarding what the Gamesalad team is currently working on:
2014's priority was to squash bugs, 2015's is to implement features. Now, I'm sure they will continue to work on bugs, but if 2014's was bug squashing year and certain issues remain unfixed then i can see why there is a concern with bugs being fixed this year (feature request year).
Fortuna Infortuna Forti Una
Im not disagreeing with you on this issue. It has obviously made certain members project un-playable and forced to wait. And since time is money, it creates a truly saddening situation.
Fortuna Infortuna Forti Una
So Here is my test data so far:
I have an RPG project that is just shy of 1GB installed adhoc. Lot's of textures, animations, particles etc. That being said this project is always being optimized to keep the memory within a safe limit. This is the project I tested with.
Devices:
iPad4 iOS v8.1
iPad Mini retina (1st) iOS v8.1
iPad Mini (1st) iOS v8.0
Performance:
I used xcode instruments for all of my testing.
iPad4: 40-60 FPS Memory maxed at about 350mb (512 is upper limit before crash)
iPad Mini Retina: 50-60 FPS Memory maxed at about 350mb (512 is upper limit before crash)
iPad Mini: 15-45 FPS **Memory gave multiple warnings and maxed at 270mb, crashed. ** (256mb is upper limit before crash)
Now as a point of reference, this project was getting 20-50FPS and the memory usage was about 200-210 before this on iPad mini 1st gen. So it looks like a bit of memory usage increase in GSC v12.20 caused it to go over the edge.
I can probably optimize a bit more, but honestly if the nightly (13) gets to stable point, it wont matter. The memory usage is waaayy down (75-150mb) with that, but man oh man it has so many bugs.
If not then I guess those devices won't be supported.
Follow us: Twitter - Website
I've been developing on GS for a few years now, and as you can tell by the number of posts I've put up, I've been silent; absorbing all the craft and love this community puts into this forum and making Indi game devs like myself more informed and better game-makers. Like myself, GS is also typically silent and they let the forum inform the devs...and you all graciously do it and I'm amazed at all the subject matter covered by all of you. I don't attribute the strength of GS to its code or tool set. To me it's been this amazing community. So to make up for my years of silent absorption, here's a long-ass post
I've spoken to a few of my veteran game developer friends about what I'm going through with game salad memory issues and what my options are, and they gave me this important bit of wisdom in wanted to share with the community that's given me so much over the years. I've been told this is true for any game dev team working directly on target on day one (testing their games on the final hardware vs cheating on beefy systems):
After design, managing memory is one of the most important things you do when you develope games. The amount you have drives the quality and quantity of the content of your game. When a project takes a year or more to develop, what usually happens is the code starts dirty and hacky and innificient. The focus isn't on clean code, it's just to get things in and working asap to prove out the game design. If the game design is fun and a go, memory is partitioned to the game components (art, sound, animation, effects...). I make this memory allocation process sound like a clean process but apparently it's messy and filled with reality-tv worthy material. Anyway, allocation plan is done and this lets art and design produce assets that will fit in memory (or are at least in the right ballpark). Now here's the key: remember those hacks to get proof of concept...when production on art and design start, code gets busy doing proper implementation and gets cleaned up. So you end up with more optimal usage out of memory the further you get into production.
When everything goes right, you start with less memory and you end up with more later. That memory you get later lets you put more polish. That's why games sometimes look like ass at alpha and suddenly look so much better once they ship; team got more memory and better memory management out of the engine...as planned. That's also why first gen console games look so bad compared to 2nd and 3rd gen. Code has more time to implement memory saving features and techniques.
Sometimes the opposite happens: code didn't have time to do what devs had speced out or coders are lazy, or hardware isn't doing something you thought it would. Then you get games that looked so good in development and end up looking low resolution with bad frame rate.
So there we have it. The main issue many of us long-term-game-project-makers (aka dreamers) haven't caught on yet. Gamesalad doesn't make a game and they don't know what game you're making or how much memory you're at and where you've placed your allocations.
We make allocation calls based on the engine we have, but if GS decides one day to add a feature that'll eat into you're planned budget there's no communication or collaboration (or negotiating) so you're out of luck. If you spent a year making a game and it's been through 5-6 creator releases, your budget has bloated and changed on every release because there's no memory management directly liked to the YOUR game. The most important aspect of game production is a moving target...and we just get less of it on every release because it's not deemed as a priority by GS.
So, PRO users should demand that gamesalad INCREASE our memory pools and optimize on each release...clean up code as they go. No one wants to redo or throw away their work. That's not why we pay for this service. We need some level of stability...or this isn't the right service for a PRO.
Im sure memory optimization isn't fun code work and doesn't make for a nice press release. It's tedious and arduous and doesn't get the oos and ahhhs from your peers...working on Graphene will! But if GS management doesn't see this as an issue to take seriously, this amazing community of developers will go through the same cycle with the Graphene new shiny toy...and that amazing community will move and set up shop at that new company down the block that gets it.
Fix your memory issues GS or else you're not really collaborating with your PRO dev community...you're just catering to the weekend game projects with friends drinking a bear and playing around. I read your post @Hymloe. Thanks for sharing and I completely get where you're at. I also have a few projects which have been "memory-ed" and I don't want to think about those hundreds of hours and what I could have been doing or creating instead of pursuing a game that'll never be. I want to hope that GS can change that (after all, I'm one of those dreamer devs), but I fear their priorities are elsewhere.
OK, back to my silent absorbing
Well said, striking at the very core of the problem!
Thanks @Figuromo it's somewhat comforting to know that others are out there suffering the same frustrations at being "memory-ed" out of being able to complete their game projects. It feels so hopeless as Game Salad seems to get more and more inefficient, and lots of effort seems to get spent on things that don't really work out as promised, when users with larger projects suddenly go from a project that works to one that crashes out due to some sort of memory allocations in the GS code, without the appropriate memory cleanups or memory management going on.
I'm home from work, and planning to sit down and do a more thorough testing of GS 0.12.20, write up some bugs and a request for some sort of better memory management control for us developers, and hopefully I'll have some links to post for anyone who wants to add their support and further info to any relevant bugs, etc.
Power on people, and here's to hoping that GS can put in some focussed work on the memory issues and get some of our beloved projects back to the land of the living.
I'd even buy another Pro license for another year if things came good, so I could give my two large projects the finishing phases they need to actually be good games.
@Figuromo I read your post and I suspect it is not as simple as some think. Fixing memory leaks in a massive poorly written code base is a huge task and might not even be possible. I suspect this is the biggest reason why they are creating Graphine. Creator is just not fixable and every new feature just makes it even harder to keep juggling all the balls so to speak. This is evidenced by their longevity (This has been going on for years) and the amount of time it takes to track and find some or most of the current crop. If it could be fixed permanently it would have been done.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
That is simply not true, blaming something like that on poorly written code that is not fixable is just plain lazy. It might be hard but of course it's not impossible. It comes down to how they prioritize and resource allocation.
I am now facing an interesting situation (dead end). I was working on the update of my game for the last 3 months and now I can't use 0.12.10 even 0.12.20.
0.12.10 - iOS binary rejected because of non 64 bit support (BTW working with GS 0.12.10 is disaster - it is really slow).
0.12.20 - Bug 688. iAds has to be on the bottom of the screen. I can't disable it. It generates negligible part of revenue. If I turn it off, I can't purchase next year subscription of GS because of unhandsome money drop (every $ is important in this though business). So now I can't update to 0.12.20 and I am scared that bug fix (688) will take another X months. Does exist any ETA? Please be focused on monetization options = money for GS subscriptions!
I have to say there are plenty of app stores and I understand that everything is changing every while so I am admire that you are handling it well. ;-) And I also have to confirm that there are random app crashes last few months (last time my game randomly crashed during hitting the Chartboost ad close button).
Thank you for all effort but before add new feature, please fix important bugs, publish real 'stable build'
This is not a stable build, just we can say nighlty but not stable.
I hold trivia game because iads bug. I need iads on the bottom of the screen.
And another arcade game will waiting because people say that game crash ipad 4th. I can't test all devices,I just have ipad mini and iphone 5s.
I'll wait or I'll have to wait new real 'stable' realese^^
Check out my games on the App Store!
Wordgraphy / Polycolor / 20 Seconds / Minimal Maze
I don't consider comments like this to be productive.
"Game Salad cannot be fixed. Accept that it is broken."
I've worked at game studios for 12 years, and a good programmer - against their sense of joy or sanity - can track down any and all memory leaks, using the right tools.
It takes time, it takes effort, it takes skill. But it can be done. And we deserve the respect, as paying customers, and passionate game developers, to have the tool that we pay for work correctly, without memory leaks, without crashes that destroy our hard work.
So please, I appreciate your sentiment, but try not to accept something as being difficult and therefore acceptable. It is not acceptable.
I worry that voices on here that accept it are the only thing that make it acceptable to the Game Salad management. They may not have people with the skills to do it quickly and effectively. But if they prioritise this as a very serious issue that is crippling (at least some sectors) of their user base in a debilitating way, that is the only way it'll get fixed.
THE MEMORY PROBLEMS CAN BE FIXED. It just needs to be a priority, and it needs to be tested properly, with the right test cases.
I'm sending in a bug now, with my project attached. I'm hoping that will give them at least one project to run through the debugger and profiler, to track down the memory problems in their own engine.
Wow so I did not know how big the memory thing was until these last few posts since yesterday. I appreciate the answers provided by....users.
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
I've written up a bug report concerning the memory issues.
http://bugs.gamesalad.com/show_bug.cgi?id=729
It's rather long winded, but I wanted to write it in detail, and try to explain the issue thoroughly, so it wouldn't be misunderstood.
I've sent them a private link to my project, which I hope will help them examine the issue, and hopefully find a solution.
Please add your own further details, or examples, or private links to your projects if you think you have a good test case for them to narrow down the issues.
My hope is that they will put someone good onto the task, and have them really hammer it out, and find where all the memory is going, and why it isn't being cleaned up during scene changes.
Good luck and good night.
Also please vote for this bug if it's a concern for you. That could make a big difference.
http://bugs.gamesalad.com/page.cgi?id=voting/user.html&bug_id=729#vote_729
Just tick the Votes box, and click "Change my votes".
Gamesalad has 750,000 testers to test their software
The NASA Space Shuttle was Beta also...lol
It got shut down :-(
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
All the hard work that we have put into building our games, but yet bugs just keep getting into our way. This great!!, game community with beautiful! and remarkable! human beings (who will jump to the aid of each other ) are suffering from bugs. I could not believe it when iAds stop working properly (only the top )
Added the following comment: good description that outlines what I have observed too. Good that you sent a project to the GS team also for testing.
One thing I can add is that the memory leaking, with the eventual crash, occurs on one-scene games also when spawning, destroying, spawning destroying and so forth.
Maybe some smart people from the forums @Manto @Socks @Hopscotch @JSproject @Armelline @anyone-else can come together and pitch in by constructing some mini projects that demonstrate memory leakage leading to crashes?
Completely agree with what everyone is saying. Many of us have been working on projects for months and years, hoping to achieve our dreams and put GS on the map, so it can be really discouraging to even think that so much work could potentially go to waste, and it makes it that much harder to be motivated when time and money are at stake every minute of the day. We certainly need to do something about this soon...
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
GS has made memory a priority, or so it seemed. I'm just not sure the system for mega-texturing is going to be stable, that's more my concern. If that system can get it's other flaws figured out, memory usage will be way down.
I agree about the whole testing with big projects. Sometimes QA seems very uninterested in helping and there have been multiple occasion throughout the years where i've been told "your project is too large"... really? They don't even address or acknowledge that this is a two way battle for developers (we can only do so much without the help of the engine).
Trust me when I say I spend the time optimizing my projects, please do the same with your engine for large projects.
Follow us: Twitter - Website
So on the stable version prior to this, I am getting lots of reports of the game crashing after about 5 mins of gameplay. It's not due to any specific point and simply seems it is just occurring from too much memory usage piling up until the app crashes to dump it.
It appears that crashing issues are still in existence in this build? So my apps must endure a barrage of negative reviews simply because GS won't/can't fix it? Or are you guys just too busy with your other ventures (Graphene) to give a damn?
I'll be honest. I can't imagine many people will follow over from this GS creator to your new Graphene when you demonstrate your lack of competence in dealing with issues on this current system. You better hope there are a lot of naive people that will blow more money on another product from a company that can't seem to get this current software working. Right now you have a lot of people trapped with GS because its a software they are familiar with and already have a bunch of games developed with. When you release Graphene and further neglect the current Creator, I have a feeling people are going to leave GS in mass. Your company will go along with it.
Stop spreading out your resources, and get this current system fixed and stabilized so you stop wrecking our businesses. Then maybe people will be interested in your new software. It also wouldn't hurt to actually address these crashing issues with a response and maybe a timeline to fix it. The incompetence at GS is astounding. Fire your CEO or something, because someone is steering your company right off a cliff.
Hey everyone. It's my understanding that release 12.20 was just supposed to have iOS 64 support, account validation on Creator start, and some memory fixes for people using Mac Yosemite 10.10.
While there still appears to be some memory leak issues (check out bug 709 and bug 103).
@BenSawyer sheds some insight on what is causing the memory leak as well as a workaround you guys can use in the meantime while we work on fixing it (see comment 44 for bug 103).
@MarcMySalad @Hymloe when I say it is not fixable I mean with GS's current resources it is not possible. The amount of time it would take to do the task would be longer than starting from scratch and would be similar in practice as a rewrite but take much longer to achieve. I believe they had a review on this over a year ago and decided just that. This is why we are getting Graphine it is easier and quicker to start over.
@MarcMySalad saying the GS team is lazy is just not cool. From what I see they are very hard working. They work on projects outside of working hours for the benefit of the community and at times late into their evenings fixing Creator and publishing issues. They are not lazy it just that fixing the code base is an enormous and very difficult task.
My code writing experience is limited to VBA and I know first hand fixing some else's inefficient poorly written and commented code is a waste of time. It is just a patch which causes other problems. A rewrite it is always the quicker and best option.
They are dealing with thousands and thousands of lines of code so interconnected and poorly constructed that changes in one area create unintended problems elsewhere. This is self evident we can all see the results. Nearly every time an improvement is made to Creator a bunch of hard to fix bugs crop up and some have persisted for years.
I know this is difficult to understand if you code writing experience is limited to GS. But you must of come across other faulty things created by other people where it was easier and quicker to tear it down or through it away and start again. I believe this is one of those situations it certainly appears to what they are doing. Unfortunately for them they can't just through Creator in the bin, lots of people are using it. It would be akin to throwing their business in the bin. At some point in the future when they have migrated people over to Graphine, Creator will be quietly retired. Nothing else would make any sense.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I upgraded to Yosemite and Gamesalad was so sluggish
it was impossible to scroll through code and everything was slow ... that never happened with Mavericks so I'm sadly reverting. Everything else runs flawlessly in Yosemite.
I agree. I think Game Salad are quick to suggest that someone's project just "has problems because it's too big", without really delving in and seeing what happens to memory and stuff in the normal process of running a big game.
Obviously, Game Salad users CAN crash Game Salad by simply putting in too many assets, etc.
But my game - for example - builds up and up and up between scene changes, and never goes back down, even when I Change Scene back to the Main Menu. I just want to dump out all the excess memory usage that I don't need anymore. That's what I'd do if I had my programmer sitting next to me, I'd get them to properly dump out everything that's not needed anymore when we go back to the Main Menu. That's just logical.
Game Salad needs to fix the memory clean-up processes at their end. And the only way I think they can deal with that issue at the source, is to run through some of these larger projects, make changes to the cleanup process, and test to see that their changes are working.
There's no point in just making some quick 3 actor game, and going, "Yep, it's all working fine, ship it out the door". That will not pickup or notice the memory problems.
We are relying on the Game Salad programmers to be OUR programmers, our ENGINE TEAM, they need to make Game Salad work properly, even on games that push things a bit.