@Hopscotch said:
I agree Lovejoy, but do you want to go through all your projects now and add loading animations for every scene change after the fact?
I use the loading wheel so please don't remove it, maybe add an option to use or not use it.
I'd like a stable version with 64 bit support too, I'd like the Amazon submission issues to be fixed as well. Expansion apks should also exist, but at least for now I found a workaround though it took even more work. It's already hard enough making money, we don't need to be losing possible income.
I worked 1.5 years on my game to get to this point. I don't want to put in any more work to get around fundamental bugs that shouldn't be happening. It's a really complicated game and any change affects everything else.
The reason I loved GS was because of the ease to create games, to make it so hard in the end to publish though is kind of counter-productive.
dgackeyAustin, TXInactive, PRO, Chef EmeritusPosts: 699
@Hopscotch not the case at all, my point was specifically directed at the notion that someone could get "in trouble" for saying they had issues with our decisions.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
When I said in trouble...I meant in the forums. I was put in jail once for using the forum rukes to the T...not keeping in mind they can AND do get amended on the fly. Im not looking to get banned either for what happens. You say you dont squash for criticism about GS...but you can get squashed by a moderator if they dont like it. Ever since I was jailed for posting an image "banner" above my signature...which shoukd be allowed...I STILL cannot post images, files in a post. So I will post my video on youtube with all my issues and complaints. This is where I coukd get "in trouble". Im pretty sure I would.
dgackeyAustin, TXInactive, PRO, Chef EmeritusPosts: 699
The mods enforce the rules as written and do their best to be objective is there is a judgment call.
We have not "amended on the fly" as far as I'm aware, and anyone who is familiar with my stance since I arrived at GS is that I'm big on transparency, so that wouldn't really be my style.
As fellow human beings, the mods aren't perfect. They do their best to keep the forums free of spam and commercial postings so that the signal to noise ratio is high. And we should all be grateful to them for the time they contribute to those ends.
I understand that not everyone will agree with every decision they make, but in the limited cases where individuals here have had repeated problems, they most often come down to someone actively seeking to find "loopholes" or bend the rules rather than simply making a good faith effort to abide by them.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
@dgackey , of course I understood what you were referring to.
My comment was a dig at the fact that in a 9 page thread where people are crying for a stable version, the only comment we get from the GS top is in reference to forum behaviour.
You have our back, we need to know that you have ours.
Tell us that you are committed to tying up the current loose ends and give us a stable version we can fall back on while we are experimenting with exciting future stuff like the Fire TV.
Don't implement features like the new iAP system and then leave it unfinished. Not giving us a simple attribute signifying the language/country the user is in, renders this system totally useless in an international market. This is a necessity and should have been part of the change. Not a feature request at the mercy of popular vote. Here is an ice cream, if enough people ask for it we'll see if we can accommodate a cone to go with it. Just an example.
dgackeyAustin, TXInactive, PRO, Chef EmeritusPosts: 699
edited February 2015
@BlackCloakGS has stated many times that we are working on the memory leak issues. Certainly I could repeat that ad nauseum in this thread, but it won't make the build more stable any faster.
The ultimate issue here is that no matter what development choices we make, some faction will be upset. For every feature you list as a necessity, someone else will find irrelevant and demand we focus on something else.
Feature voting is an improvement based on (wait for it) user request. I'm sorry if you dislike that method of prioritization, but we feel it's the most fair way to accommodate a massive pile of (often conflicting) user requests.
When you make a statement like "Don't implement a feature like IAP and then leave it unfinished", it both (incorrectly) implies that we don't care about delivering finished products and trivializes the magnitude of the actual work being referred to.
"IAP" isn't just IAP. It's separate systems for Apple, Google, Amazon, Tizen, Mac store, etc. It's a separate implementation for the Mac Creator and the Windows Creator. It's functionality that changes over time at the whim of platform owners like Apple, who may or may not inform us ahead of time. It's functionality that is often subject to review by human reviewers at said platforms who may choose to enforce the rules one way or another. It's support functionality, like the locale stuff you're referring to, which may have its hooks in a number of different areas in the code.
As @CodeWizard has documented in painful detail, there were a lot of architecture decisions made years ago in the Creator codebase that slow us down and limit us today. That's a key part of the motivation behind the development of Graphene. And a reason why "just implement IAP" (or any other feature request) isn't as simple as it sounds.
And all of this exists in the same context as all the other features being requested, optimizations and refactoring, customer support, R&D and QA.
So to the degree that I can make a statement that will put everyone at ease, let me state formally and for the record that everyone at GameSalad is highly committed to the products, working hard to deliver the best quality tools that we can, and continuing to deliver on the mission of Game Creation for Everyone.
Cheers,
Dan
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
Braydon_SFXMember, Sous Chef, Bowlboy SidekickPosts: 9,273
edited February 2015
Boom. What an awesome post by Dan. Well said, @dgackey!
@dgackey said: everyone at GameSalad is highly committed to the products, working hard to deliver the best quality tools that we can, and continuing to deliver on the mission of Game Creation for Everyone.
I never doubted this in the least!
And I do appreciate the work involved, being a developer in the mobile field since 2002. This is why I choose and love GS for certain projects.
So unless "what we've got here is failure to communicate", I am looking forward to some stable 64bit version very soon.
@dgackey said:
So to the degree that I can make a statement that will put everyone at ease, let me state formally and for the record that everyone at GameSalad is highly committed to the products, working hard to deliver the best quality tools that we can, and continuing to deliver on the mission of Game Creation for Everyone.
I didn't know you were aiming for Josh Earnest's job
@8bitninja said:
Is apple not accepting builds from 0.12.10?
Not for new apps. 64-bit binaries are required for new apps and 12.20 is the version with it.
Fortuna Infortuna Forti Una
dgackeyAustin, TXInactive, PRO, Chef EmeritusPosts: 699
@Hopscotch -- the analytics solution you developed made it pretty clear that you've been working in the field for a while. I've always found you to be reasonable and appreciate your point of view.
With that said, nothing prepared me for the codebase here. It's a Cthulhu-level, saving throw-vs-insanity thing.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
There is no doubt that the GS team is working hard to make everyone happy and I appreciate it very much. However, there are certain decisions that may not be popular (few user votes) or very sexy (boring search for memory leaks) that just have to be done on a regular basis to keep GS a functional tool. Sometimes you have to ignore the squeaky wheel users asking for new features and just clean up what you already have. I hate looking for bugs in my own code (which is my own mess) so I can understand how you guys feel, but it just has to be done.
@viking said:
There is no doubt that the GS team is working hard to make everyone happy and I appreciate it very much. However, there are certain decisions that may not be popular (few user votes) or very sexy (boring search for memory leaks) that just have to be done on a regular basis to keep GS a functional tool. Sometimes you have to ignore the squeaky wheel users asking for new features and just clean up what you already have. I hate looking for bugs in my own code (which is my own mess) so I can understand how you guys feel, but it just has to be done.
Agreed, anything that causes games to crash or be rejected should be prioritized before any new features are rolled out regardless of votes. Everyone is going to have different needs and fancy toys on their wishlist, but there's no denying a stable, smooth-running build without major memory issues would make everyone happy! but like everyone else, I do appreciate the hard work
@viking said:
There is no doubt that the GS team is working hard to make everyone happy and I appreciate it very much. However, there are certain decisions that may not be popular (few user votes) or very sexy (boring search for memory leaks) that just have to be done on a regular basis to keep GS a functional tool. Sometimes you have to ignore the squeaky wheel users asking for new features and just clean up what you already have. I hate looking for bugs in my own code (which is my own mess) so I can understand how you guys feel, but it just has to be done.
@dgackey
Viking's comment above pretty much nails what I believe most long term members would agree upon. It's an evolving ecosystem and some changes are forced by external forces (Apple's new iap system, 64-bit requirement etc.) and as such the GS team are required by 3rd parties to implement such changes or GS would be no more.
The GS team has done a great job implementing such requirements rather promptly.
Then on the other hand there are internal issues (memory leaks) within the engine that are just as important to have fixed for the survival of the engine in the long run. When our published apps crash due to issues that are out of our control (memory leaks etc) then that not only cause issues for us developers (bad reviews, unhappy end users, lost income, bad reputation) but also cause issues for the GS team in the long run (loss of faith in the tool, lost income, bad reputation, less users).
This is something the GS team have the potential to prevent from happening.
I'm sure that the GS team have people working on the engine memory leaks that cause our apps to crash but this to me does not look like any task that is suitable for just one or two devs. from the GS team but rather a task that should involve the top debugging/coding people of the GS team and @CodeWizard / Graphene team too. It's currently a game killer. By devoting the resources required the GS team can solve this.
@JSproject said: Viking's comment above pretty much nails what I believe most long term members would agree upon. It's an evolving ecosystem and some changes are forced by external forces (Apple's new iap system, 64-bit requirement etc.) and as such the GS team are required by 3rd parties to implement such changes or GS would be no more.
The GS team has done a great job implementing such requirements rather promptly.
Then on the other hand there are internal issues (memory leaks) within the engine that are just as important to have fixed for the survival of the engine in the long run. When our published apps crash due to issues that are out of our control (memory leaks etc) then that not only cause issues for us developers (bad reviews, unhappy end users, lost income, bad reputation) but also cause issues for the GS team in the long run (loss of faith in the tool, lost income, bad reputation, less users).
This is something the GS team have the potential to prevent from happening.
I'm sure that the GS team have people working on the engine memory leaks that cause our apps to crash but this to me does not look like any task that is suitable for just one or two devs. from the GS team but rather a task that should involve the top debugging/coding people of the GS team and @CodeWizard / Graphene team too. It's currently a game killer. By devoting the resources required the GS team can solve this.
If it can be solved then your statements are correct if it isn't or would take so long and still be a piece of crud then it isn't, hence Graphine.
Dan said it when he posted;
@dgackey said: With that said, nothing prepared me for the codebase here. It's a Cthulhu-level, saving throw-vs-insanity thing.
I think people have to stop assuming this can be fixed without a rewrite. This problem and others have been around for years. Simple logic tells us if it could have been fixed it would have been done long ago. If it were a simple matter of chucking more people at it they would do it. Having had some experience writing code the number of people you could put on it would depend on how it is structured. And we know it is structured poorly because dgackey told us.
This is the reality we all have to face it is always going to have memory leaks. This patch (It's not a fix) when it comes will just be the next one in a long line of past patches and future patches to come. For God's sake don't take anyone off Graphine that is the fix.
@dgackey I get what you are saying. Yes people rant often about what you guys are or aren't doing. There will always be some beef... sure.
Yea @BlackCloakGS did stop by at some point in the past and say that you guys are looking into it. If the past is any indication of the future, we have all learned that when you guys say "we are working on it", it's worth peanuts.
Notice the thread usually slows down when you inform us of current status. Like when he mentioned you are working on it. A few days... then weeks go by and still no update. That's when threads and rants rise. You guys frequently go MIA. You say you are working on it, but then leave us wondering. We start to question if you really are working on it, or if maybe you are out at a bar partying. Who knows... no updates.
The solution is so simple. Keep us in the loop. If you really are looking at it, I'm sure within a day or two you should have something to mention. It doesn't have to be, "oh we fixed it". Even simply notifying us that you have tracked some aspect of it down helps alleviate tension. Proof that you actually are working on it. Pulling disappearing acts just leaves us to our imaginations running wild with what you actually are doing instead of fixing this problem.
As for people voting up what is important. That is nice and all... but functionality should trump new features every damn time. What good are new features if the damn product doesn't work? ... Or in this case... crashes every 5 minutes.
I'd also like to mention, you popped in when someone mentions possibly getting banned for what they say. Obviously you are reading the thread. Too much to ask for an update. Any update. F**k it... I'll take a: "We made some coffee this morning, took a dump, and just cracked open the tables to look into the memory leak." It may not be fixed, but it's something!
GS say they're going to look at the memory issues, with tables or whatever.
But that's been going on for months and months. On the same issue.
Would be good to think it's really being looked at. And really gonna be fixed. Definitely. For sure.
It's not about asking for a feature.
It's about making a core feature of GS work properly, instead of crashing out games, making those projects dead in the water.
It can be unclear after a while, whether or not GS have actually noticed and acknowledged recent updates or new information, or confirmation of their next move, such as the table memory tests.
Common sense says that yes, these will be noticed, looked at, and the issue will be fixed.
But common sense is not something that we seem to be able to take for granted at all times here.
This table issue has ham-strung my project for about 1 year now, with no fixes. So sitting back and waiting for it to be fixed (after it's been clearly described, and a sample project has been provided) is plainly NOT the way to assume it's being looked at, or is going to be fixed.
@Hymloe said: The right programmer can fix this problem, properly, for good.
No ifs, no buts.
That's my point the right programmer is fixing it, his forum name is CodeWizard. Him and his team are hard at it rewriting the whole thing. They had an evaluation of the software some time ago and determined a complete rewrite was the best and probably the only realistic option and that is what is happening.
In most languages there are a number of ways to write statements/lines of code and to structure the code. Some of these ways are terrible and can cause huge problems elsewhere and are hard to track down. In a lot of cases they will compile but not work as expected so the compiler is no help, the programmer has to track it down. If these problems exist everywhere in the code base and it sounds like it does it will end up being a rewrite anyway that takes 5, 10, 50 hell maybe a hundred times longer to do.
@colander said:
In most languages there are a number of ways to write statements/lines of code and to structure the code. Some of these ways are terrible and can cause huge problems elsewhere and are hard to track down. In a lot of cases they will compile but not work as expected so the compiler is no help, the programmer has to track it down. If these problems exist everywhere in the code base and it sounds like it does it will end up being a rewrite anyway that takes 5, 10, 50 hell maybe a hundred times longer to do.
Game Salad can be fixed.
Your acceptance of mediocrity and failure is bewildering to me, @colander.
I feel extremely frustrated and confused by your posts in support of acceptance of a broken memory situation.
You keep popping up and saying, "Oh, why is everyone wanting these memory problems fixed? Too hard basket. Please give up."
I am very much against your framing of this situation @colander.
@Hymloe you are assuming I like it or something, I don't and wish it were otherwise but that doesn't mean I don't understand why it is so. You now say the people at GS are mediocre when their resumes say different. I am assuming they are highly competent and would fix it if they could. I have reasoned that they are being pragmatic and don't intend to waste a lot of time and money and maybe put GS's long term viability at risk trying to fix what is essentially a pig and most likely unfixable. I define unfixable as taking longer than rewriting it.
My opinions won't change anything at GS so attacking me for them just appears to be another waste of your time.
@colander said:
Hymloe you are assuming I like it or something, I don't and wish it were otherwise but that doesn't mean I don't understand why it is so. You now say the people at GS are mediocre when their resumes say different. I am assuming they are highly competent and would fix it if they could. I have reasoned that they are being pragmatic and don't intend to waste a lot of time and money and maybe put GS's long term viability at risk trying to fix what is essentially a pig and most likely unfixable. I define unfixable as taking longer than rewriting it.
My opinions won't change anything at GS so attacking me for them just appears to be another waste of your time.
I'm not attacking you... or at least, I'm trying as hard as I can not to... it's just...
I'm at a loss for words trying to figure out what you're trying to achieve by proclaiming some definite statement about the state of the GS codebase, when we really have nothing to go on.
I know that sounds hypocritical, because I am trying to proclaim something also... that the table related memory problems can be fixed in a relatively timely manner. And that you are simply saying the opposite.
Well, fair enough.
It's just that, after over a decade's experience working with programmers, and at game development studios, when I weigh up all the evidence, I'd wager that the table-related memory problems can be fixed, and it's just programmers making excuses at this point. And that if someone is simply put on the job, and works at it with skill and zeal, it'd be fixed within 2 days of work.
Programmers like to say "it's a mess, it is hard to fix, it's impossible!"
But this needs to be interpreted as "man, I really don't want to do it."
Mark my words, I don't doubt that things might be a bit complex, and a bit of a mess.
Frankly, I can see that as the only plausible reason that being a Game Salad user is so insanely frustrating.
But ultimately, saying things like "the code is a mess, it's really hard to find these problems" is in the category of fluff and opinion, it's on a sliding scale.
One thing I've heard at conferences - that I rather like is - "at the end of the day, the player doesn't care how your game was made, whether it was easy or hard to make, simple or complex - they just care if it works, and if it's fun".
With regards to Game Salad... "as a Game Salad user, I don't care if it's easy or hard to fix this problem... it just needs to be fixed".
I've worked in game development for about 15 years. I've been a Quality Assurance Lead, a Game Designer and a Producer, and I've worked with many programmers across many projects, with game titles being developed for multiple platforms at once, (eg: Windows, PS2, Xbox, Gamecube)... and there's always problems, and it may be with middleware or other code that is a bit out of reach, it can be complex and hard to track the final issues down...
But the fact is, sometimes people are just looking in the wrong spot. Sometimes a programmer just needs a better description of the problem or the steps to reproduce it. Sometimes they just need the right case to examine.
And I think this is the case here. The right person with the right test case could have this solved in a reasonable amount of time.
It's old-wives tales and superstition to say this cannot be fixed. It's smoke and mirrors. It's perhaps a sense of helplessness and confusion at GS. But it can be fixed, which is why I'm so pleased that @Hopscotch created a good test project to help them squash the problem.
Some coders are not very good at finding and fixing bugs in a robust way. I've worked with them. Others will just delve, find and smash bugs, with thoroughness and accuracy, and perform tests to be sure it is fixed.
I'm just not sure whether GS has any of these, and whether they are being tasked with fixing this memory problem. If they had such a person, I would wager they could fix this problem within 2 working days.
To believe anything else is to short-change everyone with any involvement whatsoever with Game Salad.
Comments
Good point.
Fortuna Infortuna Forti Una
I use the loading wheel so please don't remove it, maybe add an option to use or not use it.
I'd like a stable version with 64 bit support too, I'd like the Amazon submission issues to be fixed as well. Expansion apks should also exist, but at least for now I found a workaround though it took even more work. It's already hard enough making money, we don't need to be losing possible income.
I worked 1.5 years on my game to get to this point. I don't want to put in any more work to get around fundamental bugs that shouldn't be happening. It's a really complicated game and any change affects everything else.
The reason I loved GS was because of the ease to create games, to make it so hard in the end to publish though is kind of counter-productive.
@Hopscotch not the case at all, my point was specifically directed at the notion that someone could get "in trouble" for saying they had issues with our decisions.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
And so I clarify what I meant @dgackey .
When I said in trouble...I meant in the forums. I was put in jail once for using the forum rukes to the T...not keeping in mind they can AND do get amended on the fly. Im not looking to get banned either for what happens. You say you dont squash for criticism about GS...but you can get squashed by a moderator if they dont like it. Ever since I was jailed for posting an image "banner" above my signature...which shoukd be allowed...I STILL cannot post images, files in a post. So I will post my video on youtube with all my issues and complaints. This is where I coukd get "in trouble". Im pretty sure I would.
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
The mods enforce the rules as written and do their best to be objective is there is a judgment call.
We have not "amended on the fly" as far as I'm aware, and anyone who is familiar with my stance since I arrived at GS is that I'm big on transparency, so that wouldn't really be my style.
As fellow human beings, the mods aren't perfect. They do their best to keep the forums free of spam and commercial postings so that the signal to noise ratio is high. And we should all be grateful to them for the time they contribute to those ends.
I understand that not everyone will agree with every decision they make, but in the limited cases where individuals here have had repeated problems, they most often come down to someone actively seeking to find "loopholes" or bend the rules rather than simply making a good faith effort to abide by them.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
Fortuna Infortuna Forti Una
@dgackey , of course I understood what you were referring to.
My comment was a dig at the fact that in a 9 page thread where people are crying for a stable version, the only comment we get from the GS top is in reference to forum behaviour.
You have our back, we need to know that you have ours.
Tell us that you are committed to tying up the current loose ends and give us a stable version we can fall back on while we are experimenting with exciting future stuff like the Fire TV.
Don't implement features like the new iAP system and then leave it unfinished. Not giving us a simple attribute signifying the language/country the user is in, renders this system totally useless in an international market. This is a necessity and should have been part of the change. Not a feature request at the mercy of popular vote. Here is an ice cream, if enough people ask for it we'll see if we can accommodate a cone to go with it. Just an example.
Pheew, Hopscotch ranted!
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@BlackCloakGS has stated many times that we are working on the memory leak issues. Certainly I could repeat that ad nauseum in this thread, but it won't make the build more stable any faster.
The ultimate issue here is that no matter what development choices we make, some faction will be upset. For every feature you list as a necessity, someone else will find irrelevant and demand we focus on something else.
Feature voting is an improvement based on (wait for it) user request. I'm sorry if you dislike that method of prioritization, but we feel it's the most fair way to accommodate a massive pile of (often conflicting) user requests.
When you make a statement like "Don't implement a feature like IAP and then leave it unfinished", it both (incorrectly) implies that we don't care about delivering finished products and trivializes the magnitude of the actual work being referred to.
"IAP" isn't just IAP. It's separate systems for Apple, Google, Amazon, Tizen, Mac store, etc. It's a separate implementation for the Mac Creator and the Windows Creator. It's functionality that changes over time at the whim of platform owners like Apple, who may or may not inform us ahead of time. It's functionality that is often subject to review by human reviewers at said platforms who may choose to enforce the rules one way or another. It's support functionality, like the locale stuff you're referring to, which may have its hooks in a number of different areas in the code.
As @CodeWizard has documented in painful detail, there were a lot of architecture decisions made years ago in the Creator codebase that slow us down and limit us today. That's a key part of the motivation behind the development of Graphene. And a reason why "just implement IAP" (or any other feature request) isn't as simple as it sounds.
And all of this exists in the same context as all the other features being requested, optimizations and refactoring, customer support, R&D and QA.
So to the degree that I can make a statement that will put everyone at ease, let me state formally and for the record that everyone at GameSalad is highly committed to the products, working hard to deliver the best quality tools that we can, and continuing to deliver on the mission of Game Creation for Everyone.
Cheers,
Dan
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
Boom. What an awesome post by Dan. Well said, @dgackey!
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
Is apple not accepting builds from 0.12.10?
BRUNKT.com
Follow me at: Twitter - Instagram
Games and Templates
Appstore
Thanks you for the response
I never doubted this in the least!
And I do appreciate the work involved, being a developer in the mobile field since 2002. This is why I choose and love GS for certain projects.
So unless "what we've got here is failure to communicate", I am looking forward to some stable 64bit version very soon.
Regards,
Roland
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
I didn't know you were aiming for Josh Earnest's job
Fortuna Infortuna Forti Una
Not for new apps. 64-bit binaries are required for new apps and 12.20 is the version with it.
Fortuna Infortuna Forti Una
@Hopscotch -- the analytics solution you developed made it pretty clear that you've been working in the field for a while. I've always found you to be reasonable and appreciate your point of view.
With that said, nothing prepared me for the codebase here.
It's a Cthulhu-level, saving throw-vs-insanity thing.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
That's very disappointing. Thank you for the response though @Lovejoy
BRUNKT.com
Follow me at: Twitter - Instagram
Games and Templates
Appstore
There is no doubt that the GS team is working hard to make everyone happy and I appreciate it very much. However, there are certain decisions that may not be popular (few user votes) or very sexy (boring search for memory leaks) that just have to be done on a regular basis to keep GS a functional tool. Sometimes you have to ignore the squeaky wheel users asking for new features and just clean up what you already have. I hate looking for bugs in my own code (which is my own mess) so I can understand how you guys feel, but it just has to be done.
Agreed, anything that causes games to crash or be rejected should be prioritized before any new features are rolled out regardless of votes. Everyone is going to have different needs and fancy toys on their wishlist, but there's no denying a stable, smooth-running build without major memory issues would make everyone happy!
but like everyone else, I do appreciate the hard work
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
@dgackey
Viking's comment above pretty much nails what I believe most long term members would agree upon. It's an evolving ecosystem and some changes are forced by external forces (Apple's new iap system, 64-bit requirement etc.) and as such the GS team are required by 3rd parties to implement such changes or GS would be no more.
The GS team has done a great job implementing such requirements rather promptly.
Then on the other hand there are internal issues (memory leaks) within the engine that are just as important to have fixed for the survival of the engine in the long run. When our published apps crash due to issues that are out of our control (memory leaks etc) then that not only cause issues for us developers (bad reviews, unhappy end users, lost income, bad reputation) but also cause issues for the GS team in the long run (loss of faith in the tool, lost income, bad reputation, less users).
This is something the GS team have the potential to prevent from happening.
I'm sure that the GS team have people working on the engine memory leaks that cause our apps to crash but this to me does not look like any task that is suitable for just one or two devs. from the GS team but rather a task that should involve the top debugging/coding people of the GS team and @CodeWizard / Graphene team too. It's currently a game killer. By devoting the resources required the GS team can solve this.
Probably something like this
If it can be solved then your statements are correct if it isn't or would take so long and still be a piece of crud then it isn't, hence Graphine.
Dan said it when he posted;
I think people have to stop assuming this can be fixed without a rewrite. This problem and others have been around for years. Simple logic tells us if it could have been fixed it would have been done long ago. If it were a simple matter of chucking more people at it they would do it. Having had some experience writing code the number of people you could put on it would depend on how it is structured. And we know it is structured poorly because dgackey told us.
This is the reality we all have to face it is always going to have memory leaks. This patch (It's not a fix) when it comes will just be the next one in a long line of past patches and future patches to come. For God's sake don't take anyone off Graphine that is the fix.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
No. Just no.
They'll patch it and it will run some what better until next time. I wish it were different
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
@dgackey I get what you are saying. Yes people rant often about what you guys are or aren't doing. There will always be some beef... sure.
Yea @BlackCloakGS did stop by at some point in the past and say that you guys are looking into it. If the past is any indication of the future, we have all learned that when you guys say "we are working on it", it's worth peanuts.
Notice the thread usually slows down when you inform us of current status. Like when he mentioned you are working on it. A few days... then weeks go by and still no update. That's when threads and rants rise. You guys frequently go MIA. You say you are working on it, but then leave us wondering. We start to question if you really are working on it, or if maybe you are out at a bar partying. Who knows... no updates.
The solution is so simple. Keep us in the loop. If you really are looking at it, I'm sure within a day or two you should have something to mention. It doesn't have to be, "oh we fixed it". Even simply notifying us that you have tracked some aspect of it down helps alleviate tension. Proof that you actually are working on it. Pulling disappearing acts just leaves us to our imaginations running wild with what you actually are doing instead of fixing this problem.
As for people voting up what is important. That is nice and all... but functionality should trump new features every damn time. What good are new features if the damn product doesn't work? ... Or in this case... crashes every 5 minutes.
I'd also like to mention, you popped in when someone mentions possibly getting banned for what they say. Obviously you are reading the thread. Too much to ask for an update. Any update. F**k it... I'll take a: "We made some coffee this morning, took a dump, and just cracked open the tables to look into the memory leak." It may not be fixed, but it's something!
Agree.
GS say they're going to look at the memory issues, with tables or whatever.
But that's been going on for months and months. On the same issue.
Would be good to think it's really being looked at. And really gonna be fixed. Definitely. For sure.
It's not about asking for a feature.
It's about making a core feature of GS work properly, instead of crashing out games, making those projects dead in the water.
It can be unclear after a while, whether or not GS have actually noticed and acknowledged recent updates or new information, or confirmation of their next move, such as the table memory tests.
Common sense says that yes, these will be noticed, looked at, and the issue will be fixed.
But common sense is not something that we seem to be able to take for granted at all times here.
This table issue has ham-strung my project for about 1 year now, with no fixes. So sitting back and waiting for it to be fixed (after it's been clearly described, and a sample project has been provided) is plainly NOT the way to assume it's being looked at, or is going to be fixed.
The right programmer can fix this problem, properly, for good.
No ifs, no buts.
That's my point the right programmer is fixing it, his forum name is CodeWizard. Him and his team are hard at it rewriting the whole thing. They had an evaluation of the software some time ago and determined a complete rewrite was the best and probably the only realistic option and that is what is happening.
In most languages there are a number of ways to write statements/lines of code and to structure the code. Some of these ways are terrible and can cause huge problems elsewhere and are hard to track down. In a lot of cases they will compile but not work as expected so the compiler is no help, the programmer has to track it down. If these problems exist everywhere in the code base and it sounds like it does it will end up being a rewrite anyway that takes 5, 10, 50 hell maybe a hundred times longer to do.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
Game Salad can be fixed.
Your acceptance of mediocrity and failure is bewildering to me, @colander.
I feel extremely frustrated and confused by your posts in support of acceptance of a broken memory situation.
You keep popping up and saying, "Oh, why is everyone wanting these memory problems fixed? Too hard basket. Please give up."
I am very much against your framing of this situation @colander.
@Hymloe you are assuming I like it or something, I don't and wish it were otherwise but that doesn't mean I don't understand why it is so. You now say the people at GS are mediocre when their resumes say different. I am assuming they are highly competent and would fix it if they could. I have reasoned that they are being pragmatic and don't intend to waste a lot of time and money and maybe put GS's long term viability at risk trying to fix what is essentially a pig and most likely unfixable. I define unfixable as taking longer than rewriting it.
My opinions won't change anything at GS so attacking me for them just appears to be another waste of your time.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I'm not attacking you... or at least, I'm trying as hard as I can not to... it's just...
I'm at a loss for words trying to figure out what you're trying to achieve by proclaiming some definite statement about the state of the GS codebase, when we really have nothing to go on.
I know that sounds hypocritical, because I am trying to proclaim something also... that the table related memory problems can be fixed in a relatively timely manner. And that you are simply saying the opposite.
Well, fair enough.
It's just that, after over a decade's experience working with programmers, and at game development studios, when I weigh up all the evidence, I'd wager that the table-related memory problems can be fixed, and it's just programmers making excuses at this point. And that if someone is simply put on the job, and works at it with skill and zeal, it'd be fixed within 2 days of work.
Programmers like to say "it's a mess, it is hard to fix, it's impossible!"
But this needs to be interpreted as "man, I really don't want to do it."
Mark my words, I don't doubt that things might be a bit complex, and a bit of a mess.
Frankly, I can see that as the only plausible reason that being a Game Salad user is so insanely frustrating.
But ultimately, saying things like "the code is a mess, it's really hard to find these problems" is in the category of fluff and opinion, it's on a sliding scale.
One thing I've heard at conferences - that I rather like is - "at the end of the day, the player doesn't care how your game was made, whether it was easy or hard to make, simple or complex - they just care if it works, and if it's fun".
With regards to Game Salad... "as a Game Salad user, I don't care if it's easy or hard to fix this problem... it just needs to be fixed".
I've worked in game development for about 15 years. I've been a Quality Assurance Lead, a Game Designer and a Producer, and I've worked with many programmers across many projects, with game titles being developed for multiple platforms at once, (eg: Windows, PS2, Xbox, Gamecube)... and there's always problems, and it may be with middleware or other code that is a bit out of reach, it can be complex and hard to track the final issues down...
But the fact is, sometimes people are just looking in the wrong spot. Sometimes a programmer just needs a better description of the problem or the steps to reproduce it. Sometimes they just need the right case to examine.
And I think this is the case here. The right person with the right test case could have this solved in a reasonable amount of time.
It's old-wives tales and superstition to say this cannot be fixed. It's smoke and mirrors. It's perhaps a sense of helplessness and confusion at GS. But it can be fixed, which is why I'm so pleased that @Hopscotch created a good test project to help them squash the problem.
Some coders are not very good at finding and fixing bugs in a robust way. I've worked with them. Others will just delve, find and smash bugs, with thoroughness and accuracy, and perform tests to be sure it is fixed.
I'm just not sure whether GS has any of these, and whether they are being tasked with fixing this memory problem. If they had such a person, I would wager they could fix this problem within 2 working days.
To believe anything else is to short-change everyone with any involvement whatsoever with Game Salad.
The pressure is building on Graphene.