Execute action before quitting game

#1, by i-c-gTuesday, 05. January, 18:44 3 months ago

Here we go again with a "silly" thing I can't get: in the game properties I can register actions to execute at game starts, but I can't get how to execute actions BEFORE game ends.

Basically I want to hook into the "Quit game" event, no matter how it is triggered, to save an autosave file right before the user exits the game, but I can't get where to register such and action.

EDIT: I'd like to do the same to show a confirmation message, BTW, so I really hope there are options for this.

I'm not afraid coding Lua scripts, should it be the only way to achieve my goal; actually I enjoy it more than using native actions...

Ready to discover this can't be done... but I have the best hopes for this.
Thanks in advance for any help guys!
i-c-g

Newbie

19 Posts

#2, by afrlmeTuesday, 05. January, 20:11 3 months ago

There is no event for listening out for when game is being quit. Best thing to do would be to add the autosave at the beginning of each scene & just before changing scene, that way if they go to a menu then it will have saved on the previous scene.

As soon as you tell the game to quit with the quit game action part or use the os.exit() Lua function the game is going to end immediately.
afrlme

Imperator

6948 Posts
#3, by i-c-gTuesday, 05. January, 22:08 3 months ago

So to my understanding, if - playing in a window - I press alt-F4 or the X button to close the window, there is no chance to ask the user if it's ok to really quit the game?

This seems a bit of a flaw to me, pretty dangerous...
i-c-g

Newbie

19 Posts
#4, by afrlmeWednesday, 06. January, 12:02 3 months ago

Err, not many things will ask you to confirm when you press alt + f4 as that's a windows thing. Try it, you will see that almost - if not - everything you try it on will immediately close without asking you to confirm.

If someone presses alt + f4 together, then they obviously did it on purpose. As for clicking on the X button, I don't see anything in the luadocs page to popup a confirmation box, but maybe Simon knows of a method to catch it before it closes the application?

Most people play games in fullscreen mode or fullscreen borderless window mode, so the min, max, close buttons are not usually visible to most people.
afrlme

Imperator

6948 Posts
#5, by i-c-gWednesday, 06. January, 19:39 3 months ago

Not trying to build up a case for this, but I think that being able to hook into the game shutdown (for waterver reason, related to user or to automate specific procedures), would be almost a must for an advanced engine like Visionaire.

That said, not a big deal, as you said.
It would have been great to provide an autosave on close, but I did it hooking into the game loop and checking both scene changes and configurable intervals. Not wonderful but better than nothing.

Thanks for your kind help!
Cheers
i-c-g

Newbie

19 Posts
#6, by thomas-tSaturday, 13. February, 15:57 2 months ago

Alright, I have to chime in here. (I've been an indie software developer for 40 years.)

I am currently playing a game built with Visionaire Studio.

I play on a Mac.

On a Mac, it's very normal to quit any program with cmd-Q. Yes, maybe Alt-F4 is not the usual way to do that on Windows (however, I do that there often as well).

But on a Mac, it's what nearly everyone does to quit an app.

Imagine my surprise when I learned that the game lost many hours of progress (because it didn't autosave either).

So I look here, search the forum for "quit" and find this. Where the developer(s?) do not even understand the need for catching cmd-Q and providing a hook for it, even though users ask for it.

Let me give you some reasons why being able to catch an app quit event is needed:

Windows or MacOS may decide to restart the computer, e.g. to perform an Update. Then the OS will ask every app to quit - and the app gets the opportunity to save their data or even cancel the quit if necessary. This engine doesn't do either, it seems.

Or imagine that the user put the game into background, or video call came in and the game ends up in the background. If this takes a while before the user goes back to playing, now the user may have even forgotten that the game still runs in the background. And maybe the computer says it wants to install an update or that the memory gets low and some programs should be quit to free memory. And boom, once the OS asks the game to quit, again all progress in the game is lost.

This leads to frustrated users and eventually to angry, negative, reports, which will hurt both the game and this engine.

So, please add proper quit events ASAP. Or, even better, also add a "Should save now" event, which you invoke whenever the app goes into background or is quit, in order to GUIDE programmer who do not expect this, into learning to do their autosave when they get this event. Because that way, you control when the app should save its state and the user of your engine doesn't have to think about all the cases where it's probably a good idea to save.

The fact that even you, the designer of the engine, didn't think of providing a hook for save-on-quit is a good example of the unexperiedness that exists here - and if you couldn't even think why that's necessary, then the game devs might even less think of it - so please remind them by adding approriate hooks and document why they should use them, please.

If you need help specifically with macOS - I can perhaps assist you. You have my email.
thomas-t

Newbie

2 Posts
#7, by afrlmeSaturday, 13. February, 19:57 2 months ago

I'm not the developer, but I can forward Simon to this thread. As for autosave/saving, that's entirely up to the person developing their game with the engine to implement. They have to setup autosaving every x minutes passed, or have it save at the start of each scene, or before changing scene, etc. That's nothing to do with us at all.

In regards to catching the app on quit/close, Simon could probably implement that, but the save system will still have to handled by the person developing the game.
afrlme

Imperator

6948 Posts

#8, by i-c-gSunday, 14. February, 11:41 2 months ago

@AFRLme, the point here is not to have the game saved automatically. It is about the engine to expose sensible events in which the developer can hook into to execute his logic.

Currently, on this side, VS is very limited compared to other even less modern solutions.

@thomas-t's point is correct, a good developer doesn't code by blind faith, for his perceived 99% of users: it does its best to create the conditions for errors not to occur.

I totally understand VS is targeted towards non-devs and it's obvious it can be used for high-quality games, so I'm not trying to raise a flame here.
Indeed, I'll start acknowledging that great games have been produced with VS, it's a perfectly suited engine for the genre and it empowers non-devs to create solid stuff.

I just think, creating a tool suitable for non-devs doesn't mean you have to punish devs, right?

This "quit hook" falls straight into the dev-punishment category to me, as many other oddities about the savegame system, the inability to reference every game-object property in scripting, etc. Basically everything outside the base point'n'click game mechanic is awkward at best and I strongly believe it shouldn't be so hard for coders to work with a game engine.

Add to this that VS is a closed-source product (so you can't fix it) and from my personal point of view, the author is way too absent from this channel and well, I didn' feel like investing on it anymore. The risk to hit a dead-end, to have an idea that I can't implement, not even with the most tricky workaround, totally dampened my enthusiasm.

Personally I decided to move away from Visionare, to Unity, where I found a pretty new tool in the Unity scene which is incredibly well supported by its author, aimed towards developers, released under MIT license. The author produces actual games with it and despite it still has some rough edges, you can fix things instead of working them around with black Lua magic and other voodoo. I'm not going to advertise other tools on this forum, anyone who's curious can PM me.

If it wasn't for @AFRLme who's almost everywhere here, supporting everyone, everyday, I would have jumped off the boat earlier.
i-c-g

Newbie

19 Posts
#9, by thomas-tSunday, 14. February, 11:51 2 months ago

I don't know this tool, but I'd imagine that it offers its own environment for everything, i.e. it manages and stores (in memory) the state of the game, and has full control over it, like a virtual machine.

And if it does this, then the solution to these "unexpected quit" problems I listed in my previous post would be even easier:

Whenever ther app quits, it should simply save the entire game's state, i.e. all its variables and its current program location (and stack) to a file, and reload that when restarting the game - then the user would be just where he left off. Just like if the game was not quit but simply put into background and later brought back.

And if the user wants to quit "normally", so that the next time he relaunches the app, he gets back to the Main screen? Well, he can do that if the game programmer puts a "Quit" menu into his program.

This design would make it much easier for the lazy game developer because (s)he does not even have to think about all the menus for quitting, saving etc, because, as long as there's no need to have individual saved games that one can reload, the game can just do its game thing, as if it was always running. I.e, the game would not even notice that it was quit and relaunched later, because it just continues as if nothing happens.

THAT would be a truly easy solution for a non-developer to use, I think.

Of course, it depends on how the game engine was designed whether it's able to save and restore the entire game state to disk. But if that's only a few days' work, I'd certainly want to put the effort in, because that would make the game truly stand out in regards to easy handling for a non-dev - this way, the dev can start focusing on the game dynamics itself and worry about things like load/save and other otpions later.
thomas-t

Newbie

2 Posts
#10, by afrlmeSunday, 14. February, 13:19 2 months ago
I just tried 9 games (mix of indie & triple-A) & an app that I have installed on Steam. All of them are made using various public engines (unity, unreal, etc) or custom engines. Every single one of them - bar the app - force quit without popping anything up when I used Alt+F4.

The thing you are wanting is not for the engine to autosave, because that's nothing to do with Visionaire itself - because as I said, it's entirely up to the people working on the game to implement the save system however they see fit - but for the engine to popup a warning box with a are you sure you want to quit box with a yes/no option.

For apps where the person using it can draw/create things it makes a lot of sense to catch the app being quit out if it knows changes have been made since the last save.

Personally I only alt+f4 when a game/app is frozen & doesn't unfreeze after x time passed. Other than that I will close via the games menu, or the X button of the window form if it's an app.
In regards to windows updates forcing your pc to restart, that's more of a you/them/whoever problem for not disabling OS auto-updates & setting it to ask first or never.

P.S: here's a list of what I currently have installed on Steam. I tried alt+f4 on all of them just to see what would happen.

vigil the longest night (force quits)
death's gambit (force quits)
salt & sanctuary (force quits)
mordhau (force quits)
among us (force quits)
sekiro (force quits)
final fantasy vii (force quits)
final fantasy viii [remastered] (force quits)
rust (force quits)
fortify (popup warning, but it's an app not a game)

Actually a bunch of the games in my list don't even have autosave implemented into them. You have to manually save & if you don't save at all you would have to start the game over again from the beginning.
afrlme

Imperator

6948 Posts
#11, by SimonSMonday, 15. February, 16:36 A month ago

@i-c-g Well judging by what I'm reading you would've changed engine even if I added some hooks there and I can understand that. For anyone's needs there's an engine. For some the lack of low level code interaction is limiting, for other's it's about right. And I'm trying to better the possibilities that can be achieved with coding and plugins.

The recommended use has always been autosave on every scene. The problem is that often in the event of closing the app you don't get the option to show a dialog asking if the user is sure, I can't guarantee it at least. So I think the autosave way is the best way to go. Either way I can see if I add some events on close for the future.

But even then, the devs of the particular game need to implement it. I won't force it on everyone. For my taste if I press quit, via alt+f4 or cmd+q I want it to close. If the game in question didn't have autosave, I'm sure it won't have a hook on close.
SimonS

Thread Captain

1425 Posts