Not needing release mode

Issue #579 resolved
hahawoo
created an issue

So I was thinking...

Maybe release mode is a bit... presuming? And adds some unnecessary complexity to configuration?

Release mode seems to assume your game is either in one of two modes; either it's in testing mode, or it's in release mode. I wouldn't be surprised if this often isn't the case though. Perhaps you also want a mode for the demo version, and/or a mode for testers, or something else.

Also, if it wasn't for release mode, the author and url configuration settings wouldn't be necessary, and title wouldn't have two different uses. And the release mode error handler only uses the title, author and url, perhaps the lover might also want to have an email address in the error message, or something different entirely. Surely creating a custom error message with whatever text they want is not too time consuming.

Having the save directory not be in the LOVE subdirectory is restricted to games which are in release mode and are also fused. Perhaps this could simply be a configuration option?

Having separate error handlers for different modes could simply be done by reassigning the name of a single error handler to whatever error handling function the lover chooses:

love.errhand = my_error_handler_for_testers

Basically I think it assumes too much and doesn't "do more with less".

So what I currently think could be a good idea is...

  • Adding a configuration option for using a save directory not in the LOVE subdirectory.
  • Removing release, author and url from the configuration options.
  • Renaming title to caption or maybe screen.caption to be consistent with love.graphics.setCaption.

Comments (8)

  1. hahawoo reporter
    • changed status to open

    (I'mma reopen this for discussion if that's cool!)

    I think there a few issues here.

    But first, here's what I think is good about how things are right now:

    • .love files are guaranteed to not pollute the appdata directory because the save directory is in the love subdirectory.
    • It's easy to change the error handler from something for debugging to something for users.
    • It's easy to change the error message seen by users (albeit in a very limited way).

    And here are the problems as I see it:

    • Setting the game to save directly in the appdata directory is a bit weird. It has to be fused, and in release mode. What if you don't want everything else that release mode entails, i.e. the release error message?
    • The title configuration setting sets the caption, and changes the error message for users. If this is desired, this is great, but if not, then it's not so great.
    • The Mad Libs style error message for users. It creates a purpose for otherwise needless configuration settings, and I don't think everyone would want an automatically generated error message for users. I'd suggest that if someone wants a custom error message, they might want to create it themselves.
    • The error message for users don't contain useful information about what caused the error. Who is an error message which basically says "an error has occurred, contact the author" useful for?

    Here are some proposals for solutions to the problems while keeping the good stuff:

    Have the save directory be in the love subdirectory for .love files, and in the appdata directory for fused games. This is simpler, and I'm not sure why anyone would want their fused game to save to the love subdirectory. But if they did, they could of course do love.filesystem.setIdentity('love/game').

    Have a configuration setting for a custom error message which is displayed above the standard error message. Something like t.errormessage = "Hey, this isn't supposed to happen. Could you email a screenshot of this error message to dev@example.com?", and the normal debug error message would follow. This would be a neat because it's customisable, gives important information and it's easy to toggle by commenting out the line.

    But really, I'm not sure even this is necessary, but I suggest it because it keeps the "simple to change" benefit of how things are currently. If you've made a game for which the normal debug error isn't good enough, wouldn't you'd want to put the time into making an error message which suits it, maybe by matching the graphical style of your game, or saving a log file, or automatically emailing you the error message, etc.?

    With those two changes, you wouldn't need release mode, t.author or t.url, and t.title would only do one thing, and dare I say things would be simpler and more useful. I'm sure my proposals aren't perfect, but hopefully it's clear what I'm trying to get at here.

  2. Bart van Strien

    Yes the release error handler is useless, but it's not meant to be used. The idea is that setting/unsetting the flag toggles between a useful error message and one shown to normal users. That said, I'm not sure about the distinction fused/release, maybe they should be.. fused, if you excuse the pun(?).

  3. hahawoo reporter

    :D

    But the thing is, the release error handler is useless to everyone.

    It's useless for the user, "oh hey, the game errored and reminded me of the name of the game and who the author is to contact", but I guess if it gives an email address or something that's pretty nice.

    But more importantly, it's also useless for the game developer. "Oh, an error occurred in my game? What happened?" "I don't know, it just said there was an error." "Oh... well... great."

  4. hahawoo reporter

    But if the default is not intended to be used, isn't putting the game in "release mode" as simple as:

    function love.errhand(msg)
        -- Insert useful error message for users here.
    end
    

    And if the purpose for release mode is to quickly toggle between the two different error messages, isn't it even simpler to have "release mode"...

    love.errhand = my_error_message
    

    ... and "debug mode"...

    -- love.errhand = my_error_message
    

    ?

  5. Minh Ngo

    I'm just gonna repeat what hahawoo has said.

    Have one mode only. One would just set "love/game" as a subfolder which would mimic non-release mode. If one mode can do what the other mode can, why bother to make it complex?

    Remove all configs related to release error message. Have one error callback and leave it completely up the developer to customize it however they want. This would be approriate with the "mechanism" and not "policy".

  6. Alex Szpakowski

    Removed 'release mode' and love.releaseerrhand, and added love.filesystem.isFused (resolves issue #579).

    Games which are fused (either via appending the .love to the executable or with --fused) automatically have the changes which previously only applied to fused games in release mode.

    → <<cset ac20c9bb4be0>>

  7. Log in to comment