@ThoPel said:
It is also a strategy question to implement autosave. Wants GameSalad be a tool for everyone or only for an elite?
AutoSave is a standard in many well-known software products such as Microsoft Office ... Products which knows everyone around the world. It is a de facto standard. I wouldn't make autosave to complex, just save in the same file.
I have some multiple Gbyte software python-projects in JetBrains Pycharm and Eclipse. I had never corrupt files from a autosave. The UIs aren't slowing down during autosave.
I'd hate the idea of experimental changes being written to a file I didn't want them written to. If auto-save was only to the same file, I'd 100% definitely not use it.
@Armelline said:
I'd hate the idea of experimental changes being written to a file I didn't want them written to. If auto-save was only to the same file, I'd 100% definitely not use it.
Agreed, it would be a disaster for most people if it wrote to the same file.
Who are the most people? I think 99% of the newbies would love it.
But as I said, it is also strategy question. Every product manager has to decide sometime for the elite user or against them - that is the way it goes. Autosave is a newbie feature.
@ThoPel said:
Why would it be a disaster? Could you please explain how you work with GS. Are you saving every version manuel with "Save as..."?
One reason being that a project can become corrupted and if that happens on your "only" project that has been saved over and over, how happy do you think you would be then?
@ThoPel said:
Who are the most people? I think 99% of the newbies would love it.
Up until their project that has been saved over and over becomes corrupted. I can only imagine the outcry then.
It is really not that hard to save yourself and if you do not save as a new version then be prepared to redo all work since you last did when project corruption occurs. Or try to fix your corrupted project which is something that 99% of the people will not be able to do themselves.
Let me just clarify something here: is your standard workflow is to make a change, preview, and if you're not happy with it, reload the file to the last version? Or do you typically just try another change and preview again?
You would be at constant risk of writing over your file with mistakes, experiments you didn't intend to save or errors within the GameSalad project itself - have you ever been using GameSalad and for some inexplicable reason your collision detection simply stops working ? Or a Change attribute behaviour simply won't change X to X+1, or a hundred other strange errors you come across from time to time, what do you do in a situation like this if - as you were looking at the screen wondering why X wouldn't work - this error was just written over your working file ? You can't revert to saved, you cannot close and reopen to go back to when it was working, you cannot dive into the rule and start to tear it apart, changing values, deleting rules until you find the culprit, as all this could also be written over your working file . . . of course you can experiment, and test, and pick rules apart, but you'd have to be much more cautious about what you are doing, you'd always need to do some extra preparation and/or a Save As before starting to play around with code like this.
Have you ever played around with an idea, scene, character (etc) for 20 minutes just to realise you've wondered up a dead and your idea of making the high score spin around to the new number - instead of simply changing - looks crap and you were better off with how it already was ? Unfortunately this new spinning mess has been written over your original clean high score design, how do you go about getting the original back, there's no Undo, no closing the file and reopening or otherwise reverting - like I say, you'd need to approach each and every experiment or test (the majority of game design work) with some caution/preparation, making a duplicate actor or making duplicate rules and switching them all off / Saving As, before starting to experiment / test ideas.
And as has been mentioned outside of corruption during processing (in RAM) the majority of corruption happens when reading, writing or moving files - which isn't of course risky per sa, corruption is fairly rare with a healthy disk/computer, but it is more likely than if you were writing incremental files, if your incremental file save screws up for whatever reason just open the previous version, if your write-over-the-same-file screws up, then there's no previous file to go back to.
@ThoPel said:
Could you please explain how you work with GS.
Literally red wine and some rudimentary trigonometry, occasionally I'll wear clothes.
@ThoPel said:
Are you saving every version manuel with "Save as..."?
@WebWarrior said:
Let me just clarify something here: is your standard workflow is to make a change, preview, and if you're not happy with it, reload the file to the last version?
You've got to have a lot of spare time on your hands for this to be your standard workflow process...
@WebWarrior said:
Let me just clarify something here: is your standard workflow is to make a change, preview, and if you're not happy with it, reload the file to the last version? Or do you typically just try another change and preview again?
My workflow is essentially this:
I'll make changes to a project, saving every 5-10 mins. If I'm going to preview a project, I'll either save it or not depending on what changes I've made. For small changes "progression" changes, I'll just save it. For big changes that replace big chunks of logic, or "substitution" changes, I'll save a new file. If I'm doing lots of small changes and need quick feedback, I'll preview without saving at all.
It's not uncommon for me to go "Okay, that method isn't as fast as I'd like. I'm going to try a completely new method, disabling/changing the old method." In these circumstances an auto-save over the existing file would be disastrous. I'd lose the old method, and not be able to roll back to it if the new method turned out to not be as good. Ideally, I'd remember to save a new version manually before starting the big changes, but I often forget. Auto-saving would be very destructive in those circumstances, as in these circumstances I would reload to the last file.
@MarcMySalad said:
One reason being that a project can become corrupted.
We should distinguish between two things, once autosave and versioning.
What is the difference between saving all the time to the same project manuel and saving all the time to the same project via autosaving. Nothing - so both could corrupt a project.
When you want to have a running copy of a project and the option to fall back to older versions you need a versioning system - like GIT, SVN, ...
Okay, you are making a manuel versioning. Why don't you use a GIT or SVN project for you GS folder? Then you could check out/in files and cool other features.
@WebWarrior I would prefer option 2 (Or do you typically just try another change and preview again?)
Some older JetBrains products saved only a file / object, when you closed the file in the editor. So a process like:
Edit actor
Preview
Edit actor
Preview
....
wouldn't safe anything. It would only be saved, when you open another actor / object / table.
@WebWarrior said:
Let me just clarify something here: is your standard workflow is to make a change, preview, and if you're not happy with it, reload the file to the last version? Or do you typically just try another change and preview again?
I'd imagine that if there is such a thing as a "standard" of doing things it would be:
save over the current version - for smaller changes
regularly save a copy of the project, project name version 1.00 -> 1.01 and so on, maybe doing this once per hour or so - done to be able to go back to a working version if project corruption occurs or if a major change was made to the project that we regret doing.
make a change, preview, save if one is happy
make some other change, preview, regret the change/experiment some more, not save - and in this case not wanting to save either
@WebWarrior said:
Let me just clarify something here: is your standard workflow is to make a change, preview, and if you're not happy with it, reload the file to the last version?
I'd think that'd be a pretty slow way of woking, but as others have said there is probably not a single generalised way of working, not only will people work differently to each other, but I suspect individuals will even work differently depending on the project.
@WebWarrior said:
Or do you typically just try another change and preview again?
@ThoPel said:
Okay, you are making a manuel versioning. Why don't you use a GIT or SVN project for you GS folder? Then you could check out/in files and cool other features.
I've honestly no need for GIT or SVN (and also I haven't got a clue what they are ! lol ), saving a file is a pretty straightforward affair, I've never been troubled by it, it's never been problematic in the slightest, it's about the most basic function in any program, I can't really see a real need for an autosave system at all as I don't feel that there is actually a problem with saving files manually (as a concept) - the fact that some people forget to do something shouldn't really be a reason to change how that thing works - there is even scope for infinite regress here, if someone forgets to save a file (a really really basic part of using software) they might forget to switch autosave on - so we should have a system that automatically switches autosave on for those who forget to do so, and of course this extra system should be optional, you should have the choice as to whether it switches autosave on for you or not, but of course some people might forget get to switch this system on, so we really needed an automated way to do that for them, which of course should be optional . . .
But being a little more serious, for those who forget to save their work, I'd suggest a little (@Armelline - optional ) alert that you can set to remind you when you've not saved for a while, it would be the least invasive method, and would allow people to save and organise their files in a way which suits their own working methods / workflow.
so to summarize what you are saying: you would want a save after every single change/preview and preferably to the same project file and after every change you close the project down and load it up again
@JSproject said:
so to summarize what you are saying: you would want a save after every single change/preview and preferably to the same project file and after every change you close the project down and load it up again
Exactly !
I was even thinking of a magnitude type system based on mouse movements, every time you move your mouse more than 50 pixels or so (from the last recorded coordinate) the system should save your file for you, over your current file, close down GameSalad, delete some random system files and then restart your computer.
This should of course be optional, the options would be:
1) I want this to happen all the time, always.
2) I want this to happen only when I am using my computer.
@Socks said:
I was even thinking of a magnitude type system based on mouse movements, every time you move your mouse more than 50 pixels or so (from the last recorded coordinate) the system should save your file for you
That's great, however as an alternative I would suggest the auto save to happen if you drag an actor to a scene and the actor happens to land on a position that is not an integer value.
delete some random system files
Now it gets interesting! That's a great feature to implement to get people to do more regular backups via Time Machine or similar.
and then restart your computer.
I think you're going to far on this one, think about it... if the computer rebooted you might get a reminder that you need to go do the laundry, get groceries or something awful like that which would distract you from doing important work in front of the computer like fixing a corrupt project, doing a restore or some actual important work (God forbid).
@Socks said:
I was even thinking of a magnitude type system based on mouse movements, every time you move your mouse more than 50 pixels or so (from the last recorded coordinate) the system should save your file for you, over your current file, close down GameSalad, delete some random system files and then restart your computer.
This is too hilarious haha
I think what we need, is being able to undo and redo "AFTER" the preview. Why on earth would you save your file every time you want to preview, and not being able to redo your changes, it just doesn't add up to me.
I think gamesalad should work the way adobe does. For example, you create a new project. Along with the new project, gamesalad also creates a separate folder where the auto saves can be stored. Then in gamesalad you can say, save a maximum X amount of auto save files. Lets say it can save to a maximum 10, this is to prevent to overload your hardrive, or taking too much unnecessary disk space. Every time it auto saves, it overwrights the autosaves in chronological order. So when it auto saved 10 times, the next time it will overwright the first auto save, etc.
Getting an auto save feature that constantly overwrights the original project file, would be very, very dumb. Autosaves are usually not meant to save your work automatically to make life easier, they're usually there to recover your work after a crash. However, you do see overwrightinging autosave features in text edit applications and such, but those applications are far less complex to revert any accidental changes. I guess thats why people think this will work with gamesalad too, because they're used to it.
Just keep the master file separate from the auto saves, then everyone is happy.
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
This thread is becoming tiresome and repetitive. As long as any auto save feature is user selectable, as suggested by many users on the first page of this thread, I'd be happy.
GS has given nothing me but frustration. I keep losing work - just went to save and got the spinning beachball. Despite using source control and saving every few minutes, I am still losing work and time with all the crashes and hangs. I agree that auto-save might not work for everyone- and would rather see an end to the crashes, but having paid for GS PRO and seeing "Stable" in the release name, I expect GS not to be so... unstable. @#$&#!
Comments
I'd hate the idea of experimental changes being written to a file I didn't want them written to. If auto-save was only to the same file, I'd 100% definitely not use it.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
That would be an absolute nightmare !
Agreed, it would be a disaster for most people if it wrote to the same file.
Why would it be a disaster? Could you please explain how you work with GS. Are you saving every version manuel with "Save as..."?
Who are the most people? I think 99% of the newbies would love it.
But as I said, it is also strategy question. Every product manager has to decide sometime for the elite user or against them - that is the way it goes. Autosave is a newbie feature.
One reason being that a project can become corrupted and if that happens on your "only" project that has been saved over and over, how happy do you think you would be then?
Up until their project that has been saved over and over becomes corrupted. I can only imagine the outcry then.
It is really not that hard to save yourself and if you do not save as a new version then be prepared to redo all work since you last did when project corruption occurs. Or try to fix your corrupted project which is something that 99% of the people will not be able to do themselves.
Let me just clarify something here: is your standard workflow is to make a change, preview, and if you're not happy with it, reload the file to the last version? Or do you typically just try another change and preview again?
You would be at constant risk of writing over your file with mistakes, experiments you didn't intend to save or errors within the GameSalad project itself - have you ever been using GameSalad and for some inexplicable reason your collision detection simply stops working ? Or a Change attribute behaviour simply won't change X to X+1, or a hundred other strange errors you come across from time to time, what do you do in a situation like this if - as you were looking at the screen wondering why X wouldn't work - this error was just written over your working file ? You can't revert to saved, you cannot close and reopen to go back to when it was working, you cannot dive into the rule and start to tear it apart, changing values, deleting rules until you find the culprit, as all this could also be written over your working file . . . of course you can experiment, and test, and pick rules apart, but you'd have to be much more cautious about what you are doing, you'd always need to do some extra preparation and/or a Save As before starting to play around with code like this.
Have you ever played around with an idea, scene, character (etc) for 20 minutes just to realise you've wondered up a dead and your idea of making the high score spin around to the new number - instead of simply changing - looks crap and you were better off with how it already was ? Unfortunately this new spinning mess has been written over your original clean high score design, how do you go about getting the original back, there's no Undo, no closing the file and reopening or otherwise reverting - like I say, you'd need to approach each and every experiment or test (the majority of game design work) with some caution/preparation, making a duplicate actor or making duplicate rules and switching them all off / Saving As, before starting to experiment / test ideas.
And as has been mentioned outside of corruption during processing (in RAM) the majority of corruption happens when reading, writing or moving files - which isn't of course risky per sa, corruption is fairly rare with a healthy disk/computer, but it is more likely than if you were writing incremental files, if your incremental file save screws up for whatever reason just open the previous version, if your write-over-the-same-file screws up, then there's no previous file to go back to.
Literally red wine and some rudimentary trigonometry, occasionally I'll wear clothes.
Yes, it's a 2 second process:
You've got to have a lot of spare time on your hands for this to be your standard workflow process...
My workflow is essentially this:
I'll make changes to a project, saving every 5-10 mins. If I'm going to preview a project, I'll either save it or not depending on what changes I've made. For small changes "progression" changes, I'll just save it. For big changes that replace big chunks of logic, or "substitution" changes, I'll save a new file. If I'm doing lots of small changes and need quick feedback, I'll preview without saving at all.
It's not uncommon for me to go "Okay, that method isn't as fast as I'd like. I'm going to try a completely new method, disabling/changing the old method." In these circumstances an auto-save over the existing file would be disastrous. I'd lose the old method, and not be able to roll back to it if the new method turned out to not be as good. Ideally, I'd remember to save a new version manually before starting the big changes, but I often forget. Auto-saving would be very destructive in those circumstances, as in these circumstances I would reload to the last file.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
We should distinguish between two things, once autosave and versioning.
What is the difference between saving all the time to the same project manuel and saving all the time to the same project via autosaving. Nothing - so both could corrupt a project.
When you want to have a running copy of a project and the option to fall back to older versions you need a versioning system - like GIT, SVN, ...
Okay, you are making a manuel versioning. Why don't you use a GIT or SVN project for you GS folder? Then you could check out/in files and cool other features.
@WebWarrior I would prefer option 2 (Or do you typically just try another change and preview again?)
Some older JetBrains products saved only a file / object, when you closed the file in the editor. So a process like:
wouldn't safe anything. It would only be saved, when you open another actor / object / table.
I'd imagine that if there is such a thing as a "standard" of doing things it would be:
save over the current version - for smaller changes
regularly save a copy of the project, project name version 1.00 -> 1.01 and so on, maybe doing this once per hour or so - done to be able to go back to a working version if project corruption occurs or if a major change was made to the project that we regret doing.
make a change, preview, save if one is happy
make some other change, preview, regret the change/experiment some more, not save - and in this case not wanting to save either
repeat the process
I'd think that'd be a pretty slow way of woking, but as others have said there is probably not a single generalised way of working, not only will people work differently to each other, but I suspect individuals will even work differently depending on the project.
Yes, pretty much.
File: ChineseDeathSquirrel 004
(self.L SineValue *60) *sin(game.Time * 6000)+180+self.offset
Preview . . . Mmmmm, looks a bit shaky . . .
(self.L SineValue *60) *sin(game.Time * 3000)+180+self.offset
Preview . . . Mmmmm, looks slow now . . .
(self.L SineValue *60) *sin(game.Time * 4000)+180+self.offset
Preview . . . Mmmmm, still looks slow . . .
(self.L SineValue *60) *sin(game.Time * 5000)+180+self.offset
Preview . . . not bad, speed looks ok, but it's still not there, maybe it's the angle . .
(self.L SineValue *120) *sin(game.Time * 5000)+180+self.offset
Preview . . . Whooa! That's crazy, I need to be reducing the value, not increasing it . .
(self.L SineValue * 50) *sin(game.Time * 5000)+180+self.offset
Preview . . . Mmmm, even more . . .
(self.L SineValue * 30) *sin(game.Time * 5000)+180+self.offset
Preview . . . Ok, maybe that's a little to much of a reduction . . .
(self.L SineValue * 45) *sin(game.Time * 5000)+180+self.offset
Preview . . . Mmmm . . . not bad, this is starting work for me . . .
Save As ChineseDeathSquirrel005
I've honestly no need for GIT or SVN (and also I haven't got a clue what they are ! lol
), saving a file is a pretty straightforward affair, I've never been troubled by it, it's never been problematic in the slightest, it's about the most basic function in any program, I can't really see a real need for an autosave system at all as I don't feel that there is actually a problem with saving files manually (as a concept) - the fact that some people forget to do something shouldn't really be a reason to change how that thing works - there is even scope for infinite regress here, if someone forgets to save a file (a really really basic part of using software) they might forget to switch autosave on - so we should have a system that automatically switches autosave on for those who forget to do so, and of course this extra system should be optional, you should have the choice as to whether it switches autosave on for you or not, but of course some people might forget get to switch this system on, so we really needed an automated way to do that for them, which of course should be optional . . . 
But being a little more serious, for those who forget to save their work, I'd suggest a little (@Armelline - optional
) alert that you can set to remind you when you've not saved for a while, it would be the least invasive method, and would allow people to save and organise their files in a way which suits their own working methods / workflow.
so to summarize what you are saying: you would want a save after every single change/preview and preferably to the same project file and after every change you close the project down and load it up again
Exactly !
I was even thinking of a magnitude type system based on mouse movements, every time you move your mouse more than 50 pixels or so (from the last recorded coordinate) the system should save your file for you, over your current file, close down GameSalad, delete some random system files and then restart your computer.
This should of course be optional, the options would be:
1) I want this to happen all the time, always.
2) I want this to happen only when I am using my computer.
That's great, however as an alternative I would suggest the auto save to happen if you drag an actor to a scene and the actor happens to land on a position that is not an integer value.
Now it gets interesting! That's a great feature to implement to get people to do more regular backups via Time Machine or similar.
I think you're going to far on this one, think about it... if the computer rebooted you might get a reminder that you need to go do the laundry, get groceries or something awful like that which would distract you from doing important work in front of the computer like fixing a corrupt project, doing a restore or some actual important work (God forbid).
This is too hilarious haha
I think what we need, is being able to undo and redo "AFTER" the preview. Why on earth would you save your file every time you want to preview, and not being able to redo your changes, it just doesn't add up to me.
I think gamesalad should work the way adobe does. For example, you create a new project. Along with the new project, gamesalad also creates a separate folder where the auto saves can be stored. Then in gamesalad you can say, save a maximum X amount of auto save files. Lets say it can save to a maximum 10, this is to prevent to overload your hardrive, or taking too much unnecessary disk space. Every time it auto saves, it overwrights the autosaves in chronological order. So when it auto saved 10 times, the next time it will overwright the first auto save, etc.
Getting an auto save feature that constantly overwrights the original project file, would be very, very dumb. Autosaves are usually not meant to save your work automatically to make life easier, they're usually there to recover your work after a crash. However, you do see overwrightinging autosave features in text edit applications and such, but those applications are far less complex to revert any accidental changes. I guess thats why people think this will work with gamesalad too, because they're used to it.
Just keep the master file separate from the auto saves, then everyone is happy.
This thread is becoming tiresome and repetitive. As long as any auto save feature is user selectable, as suggested by many users on the first page of this thread, I'd be happy.
I don't want to be "that guy" but since I've updated to 0.13.20, Gamesalad continues to crash unexpectedly.
I'd say, it crashed about 9 to 10 times, within the past 2 hours...
GS has given nothing me but frustration. I keep losing work - just went to save and got the spinning beachball. Despite using source control and saving every few minutes, I am still losing work and time with all the crashes and hangs. I agree that auto-save might not work for everyone- and would rather see an end to the crashes, but having paid for GS PRO and seeing "Stable" in the release name, I expect GS not to be so... unstable. @#$&#!