dMZX Forums: Exiting game state through code -> Archived Requests -> Tracker

A corollary to this request; one of the few things MZX still absolutely requires the original interface for is exiting a game. A method of exiting game state via Robotic, while potentially fraught with issues, might be desirable, as MZX has allowed more and more of the default gameplay interfaces to be replaced and ignored.

This might be one of the few instances where dipping into command space and issuing a new command is preferable. Perhaps a variant that autosaves a SAV file on exit would be helpful, as well.

We'd need a command to initiate the game state, too, to make it consistent. :q

edit: and that's been requested before. I don't remember what the final verdict on it was, but there would always be the potential for getting trapped in gameplay due to bad title screen programming...

Yeah, entering game state via Robotic is more problematic, which is why I didn't suggest it. It can have its uses (albeit limited), but I personally don't think it's quite worth it.

One way to handle the entering gameplay problem would be to (optionally) remove the concept of a first/title board from new worlds, with a world flag. This wouldn't preclude implementing a first board yourself, and wouldn't change anything unless it was enabled.

--ajs.

Another way would be to allow the world to enter the play state through robotic only when the user explicitly chooses it from the load world menu.

ajs; so basically, what would happen is loading the world would put it in gameplay mode immediately? Then, Escape in gameplay mode would do what? Open up a blank world and the load dialog? Exit MegaZeux altogether? Perhaps it could be a config option -- the latter would make it easier for authors to release their own copies of their game as stand-alone and have it be streamlined (by disabling the title screen and setting up the config for Escape to exit MZX), whereas the former would be pretty much required for typical MZX usage...

Combined with exiting the game state through robotic, this might be a very desirable thing.

edit: Old-Sckool; something about that doesn't seem right. I don't think it should be up to the user whether the author's game works properly or not... it could easily be accounted for, sure, but what's the point if users will just turn it off anyway. And how will that stop MZX from getting trapped in gameplay mode from a faulty title screen? I like ajs's solution better because it throws away the entire idea of robots initiating the gameplay state and lets MegaZeux handle it.

Actually, I think that config option could be made a build flag and expanded to cover several other alterations of MegaZeux that would be considered ideal in a stand-alone release. Just to make it clear, this thread seems to have become about three different things:

• Command to exit the game state through Robotic (2.85)
  
• World option to disable the title screen - exiting the gameplay will take the player back to the blank world load dialog (2.85)
  
• Config.sh option "standalone_release" that limits MegaZeux in several ways, not necessarily limited to: (2.84d could be a possibility, 2.85 otherwise)
  
  • Closes MZX immediately if a startup_world isn't specified,
    
  • because it also disables the world Load Menu entirely. Exiting gameplay on a titlescreen-disabled world would exit MZX completely.
    
  • Removes ":: Megazeux X.XXa (nnnnnnnn)" from the title bar
    
  • Also disables the Help File, Editor
    
  • In the "Standalone Release Kit" we release containing these builds there could be separate updater-enabled and updater-disabled versions -- I'm supposing this kit would be limited to just the Windows builds and the universal OS X build of the game.
    
  • I'm pretty sure there's already a thread for this!

edit: To really make this complete we might want to get the Escape dialog disabling counter in there too. Nobody would even know they were playing a MegaZeux game! *cough*

edit 2: Also the graphical fixes for the UI in SMZX mode. So we're looking at 2.85 for most of this.

Lach, what I meant was something along the lines of disabling the enter play state functionality based on what UI caused the world to load, so if you successfully opened a world through the Load World screen the world would be allowed to enter the play state, while if you escaped out of the world, you wouldn't be able to (at least when not in this standalone_release state).

I understand what you meant. The problem is that letting Robotic initialize the game state is a horrible idea

Having a (reversible) config option which enables standalone behaviour sounds like a good idea, but I think we can tweak it a bit to be more friendly to tinkerers. This is just my 2c.

Firstly, I don't see the point in auto-closing megazeux/mzxrun if startup_world isn't specified or is non-loadable. I can't see any problem at all with letting mzxrun revert back to its original state if the game file is deleted. It makes the MegaZeux engine more discoverable and might bring people to the community if they figure out what the game was made with. Why hide it? So I'd instead propose that the "standalone mode" is automatically disabled if the startup_world can't be loaded.

The help file, editor and updater are already disabled by MZXRun. If you want to keep the updater, you ship MegaZeux proper instead. The standalone flag could soft-disable the help file and editor in non-MZXRun builds.

I don't quite understand what you mean by "Standalone Release Kit" but if it's some kind of custom build of MZX, I don't recommend it. It's difficult enough maintaining the MZXRun and MegaZeux executables without adding more configurations. Also, I don't think any of your suggested features require it. Really this "kit" should be as simple as the regular MZX distribution, with the MegaZeux.exe, editor.dll, some of the charsets and help file deleted, and a small config.txt tweak.

When this has come up before, I've mentioned the following to dissuade going overboard with "standalone" builds:

• If you ship "game binaries", you make it more difficult to keep MZX up to date. Especially if you disable the updater. This won't be a problem initially, but even unmaintained Windows binaries age pretty quickly, and compatibility will be a concern before long.
  
• You limit the portability of your game by choosing an arbitrary platform binary. A MZX game file itself is actually very portable and has no such restrictions.
  
• By shipping standalones, you make MegaZeux less discoverable and arguably make it more difficult to attract new people to the community.
  
• BUT: the counter argument is that by shipping binaries, it's easier to start play MZX games and that might bring more people.

I think the most important thing about the above is to curb any enthusiasm about embedding a game or its assets into the MZX executable (I know you didn't suggest it, but every time this idea comes up, it's suggested). Such embedding might look cool, but it definitely detracts from MZX's ability to open other people's games and learn about them. And I think if you strip all identifying features from the engine, you will discourage people from investigating MegaZeux further.

--ajs.

This post has been edited by ajs: 06 September 2013 - 04:09 AM

I suggested that MZX close immediately when confronted with a situation that would require the world load menu to appear because 1) it would allow games with the title screen disabled to exit MegaZeux directly by using the new command to leave the game state 2) if there is a bug that is causing the game to not be loaded for some reason, it seems like it would be more obviously a bug to Joe User if it just refused to start up than if it popped up a mysterious load menu.

To answer your points:

• That's why you'd leave the updater enabled. You're right, though. The idea behind having a separate class of builds was to cut out some of the unnecessary features like the Editor and Help File without requiring some sort of soft disable while leaving the updater accessible. It's infinitely more work though. A new config file option is probably the best way to go.
  
• I think 99.99% of the people you'd be getting to play your MZX game as a standalone release would be Windows and Mac OS X users who would give up the second they saw MegaZeux start up with some kind of text mode load screen
  
• Agreed. Arguably the targets of standalone builds would be people that wouldn't have touched MegaZeux otherwise. On the other hand, Game Maker never seemed to have issues attracting new people and it can create standalone executables. I take back the part about changing the title bar; maybe that would be enough to make someone go "What's a MegaZeux?" and look it up.
  
• Yes. Precisely that
  
• I agree. Embedding games into the executable is a horrible idea.

To address your updater point, I don't think it would a problem adding the updater back into MZXRun. It was removed (fairly arbitrarily) to reduce the size of the MZXRun executable since the updater is not embedded in core.dll. We've got feature requests like MZXNet which would necessitate moving most of that code back into core.dll already. Hence enabling the updater in MZXRun is no big deal in the longer term.

I'm not really convinced by your 99.99% statistic. If we look at the download counter for MegaZeux 2.84c itself, it's pretty Windows biased, but not quite as much as 99%:

MegaZeux 2.84c (Windows x64)    425
MegaZeux 2.84c (Ubuntu i386)    66
MegaZeux 2.84c (Windows x86)    363
MegaZeux 2.84c (Mac OSX)        71
MegaZeux 2.84c (Ubuntu AMD64)   75

Total                           1000
MegaZeux 2.84c (Source Code)	111

Windows is 78% of all downloads, Ubuntu is 14% and OS X is 7%. I guess the target market of a standalone game is different, but the style of MZX games probably broadly appeals to the same group as MegaZeux itself does. So IMO we should be considerate of the idea that making games standalone shouldn't preclude playing them with a non-standalone installation of MegaZeux.

(BTW, these numbers would suggest that OS X is really not worth worrying about since it's even more marginal than Ubuntu Linux. Biggest WTF here is the number of source package downloads!)

I agree it's valid to assume 99% of people would "give up the second they saw MegaZeux start up with some kind of text mode load screen", but I'd say the remaining 1% might care to investigate MegaZeux more if it did show such a screen, than if the executable just appeared to crash. I know I would. I think it's a fallacy to assume handling errors like a deleted game engine with zero feedback is better than showing the original interface.

--ajs.

By the way, I don't fully understand why the "new command" for quitting a game couldn't always close the MegaZeux executable if the world was started with startup_world and standalone mode was enabled. It doesn't obviously have anything to do with the failure in an error condition (such as missing startup_world) or the title screen world flag.

--ajs.

That's probably not a bad idea. I was trying to think of any reasons why the updater might not be enabled in MZXRun in the first place and that was the only thing I came up with.

I feel like the problem with those numbers is that they represent the current demographic of MegaZeux use and people who have been interested in it as-is; the goal of a standalone release would be to expand awareness to people who would be turned off by the idea of downloading MZX and the game separately and navigating a UI to load it, or for distribution to non-enthusiast people who might have some other interest in the game (family members, friends, co-workers; basically what RyanThunder did with his game Ryan Thunder). Inevitably I think you'll end up hitting far more Windows/Mac than you would Linux users, and I have a feeling that any Linux user might be slightly more willing to install MZX separately anyway. Maybe not quite 99.99% but surely more than 85%. It would be interesting to see the results, in any case.

Re: source downloads, it seems reasonable to think that there may be many non-Ubuntu Linux users running MZX. Look at all of those downloads games like Ruin Diver III, &, Bloodlands, and Forgotten have gotten from being featured on people's blogs.

And with the "new command" exiting the gameplay state; I'm sorry, I think I was speaking more in my idea of what implementation would be and less in how the user would perceive it in the end. Yes, we would always want MegaZeux to close in that condition.

Updating status to: Approved
Updating severity to: 2 - Fair

EXIT_GAME counter implemented in GIT 24e8441.

Updating status to: Implemented
Updating version to: 2.85
Issue fixed in: GIT

Moving to: Archived Requests