Game saving and loading

  • #1, by tall-story-gamesWednesday, 06. January, 14:51 3 months ago
    I don't know if this is something I'm doing wrong, but I have a couple of issues with game saving/loading.

    I have set up the savegame slots as per the tutorial, but the current game always saves in the next available slot, as opposed to the slot that is actually selected. For the most part this isn't really a problem, but it "feels" like a bug if you've chosen one particular slot (e.g. slot 6) and it saves within another (e.g. slot 3 as it is the next available slot). I have downloaded the original savegame tutorial files and they have the same issue too.

    Immediately after a saved game is loaded, the interfaces appear in the top left hand corner of the screen, then readjust themselves a moment later. Is there a fix for this?
    I wondered about setting a condition to true just before each game is saved, then immediately setting it to false again once the game has been saved (essentially meaning that any loaded game has this variable set to true) then doing something with the interface based on this condition before resetting it again...but this feels like a bit of a hack.



    42 Posts

  • #2, by afrlmeWednesday, 06. January, 18:23 3 months ago
    That's how the save system works. If you select an empty slot it will always save into the first available empty slot & not the one you selected unless a save exists in the slot before the one you selected.

    As for the interfaces, I'd possibly recommend hiding them before you execute the save. I don't know why they would appear out of position when you first load a save game.


    6948 Posts

  • #3, by i-c-gWednesday, 06. January, 19:44 3 months ago
    Heh, we stumbled onto the same issue this afternoon!

    Our solution is to actually highlight a selected slot only if there is a savegame in it.
    Clicking in an "empty" slot deselects all of them, so if the user clicks "SAVE" it is not misled into thinking there is a bug.
    If the user selects an already occupied slot the system behaves as expected instead, so we highlight it.

    Should be pretty easy to do, my mate is taking care of it but we "debuged" it together.
    If you need more info I can collect them tomorrow and provide our solution.



    19 Posts

  • #4, by tall-story-gamesWednesday, 06. January, 19:58 3 months ago
    Thanks, that sounds like a good plan. I wanted to check if I was missing something first. I'll work on it tonight and see what I can work out ??


    42 Posts

  • #5, by tall-story-gamesFriday, 08. January, 17:55 3 months ago
    @i-c-g I think I've managed to come up with a fairly elegant solution to this which checks which savegame files are present in the local app directory and shows/hides the appropriate savegame slots accordingly.

    This is what I've done.

    I  created a function in the main script tab which checks for a savegame file based on a single digit number. If you pass it a 1 it will check that savegame00.dat exists and so on.

    This will only work with savegame files up to 9 unless you take into account the additional zeros within the file names. I only have 6 savegame slots in my game, you could just as easily pass it for full filename or simply "01", "02" etc. as a string and adjust the structure of the path variable accordingly.

    Here's the function:

    function checkSavegame(n)
      local f, path
      path = localAppDir .. "Savegames\\savegame0" .. (n-1) .. ".dat"
      f =
      if f then
        return true 
        return false

    I also created a condition for each savegame slot which I can use to show/hide them within their "Condition" property (see screenshot 1). Note that the condition used for each slot is the one from the preceeding savegame i.e. the Condition used to display slot 4 is "Save game 3 exists" as you only want to display this slot if the one before it is already full.

    I then created an action which runs on a loop within the save/load menu and changes each condition based on the lua result from the function above (see screenshot 2).
    This action is called when the save/load menu begins, and quit when it ends.

    Using the above conditions, I've also added a few additional actions to show/hide the slots when the game initially loads so you don't end up with a useless slot displaying when it's either empty or you've not started a saveable game yet, but I won't go into detail about that here.

    I hope this helps smile


    42 Posts

  • #6, by i-c-gFriday, 08. January, 23:59 3 months ago
    Hi  @tall-story-games.

    I was about to write you a post today, but I ran out of time. I came to a similar conclusion after a bit of work this morning. I took another route from a user perspective, but I'm also checking that savegame files are there.

    Allow me some hours to come back to you with an explanation of what I did, as well as to properly check out your version! smile

    Thanks for sharing!

    EDIT: just noticed "if lua result" actionpart... how could I miss it?! It's life-changing stuff! Now I'll streamline my work before sharing it! WOW! grin


    19 Posts

  • #7, by tall-story-gamesSaturday, 09. January, 08:37 3 months ago
    Brilliant, would love to see how you solved the same issue.

    When I discovered the "If lua result" actionpart a couple of months ago, I was able to go back and cut out tonnes of unnecessary code and actions, I prefer to keep as much code as possible within the actions ??


    42 Posts

  • #8, by i-c-gFriday, 29. January, 09:37 2 months ago
    Hi @tall-story-games.

    Sorry for being so late to the party, I had a couple intense weeks and I ended up postpone this reply.

    As I told you, my solution basically relies on counting savegame files to understand what to do. To better explain what we did, it's better to look at the first screenshot.
    As you can see, a savegame is present and the picture is selected. We can load the savegame or save over it. Simple stuff.

    What is very baffling is that if you click on a different empty area (and it becomes highlighted), the next savegame will end up in the first free slot. Which, from a user's perspective, seems like a bug.
    Moreover, if you leave the area selected (and I didn't find a way to deselect it) and go on pressing the save button, more savegames will be queued, until you reach your selection. From there on, all the other clicks will create a savegame in your selected area.

    There are many workaro... solutions to this, but we thought the less odd for the user is that, when you click on an empty area, no matter which, the first free slot is selected and highlighted.
    This stil seems like a bug but at least it's clear to the user what will happen when "Save" button is clicked.

    To select the first empty slot, no matter which one you click, I created this script:

    local getFilesCommand
    local files = {}
    local tmpFile = localAppDir .. 'savegame.count.tmp'

    if package.config:sub(1,1) == '/' then
      -- We are on a Unix filesystem, use ls
      getFilesCommand = "ls -1 " .. localAppDir:gsub(" ", "\\ ") .. "Savegames/savegame*.dat" .. " >; '" .. tmpFile .. "'"
      -- We are on Windows (or non-unix at least), use dir
      getFilesCommand = "dir " .. localAppDir .. "Savegames/savegame*.dat" .. " >; " .. tmpFile


    -- Count the saved games
    local SavegameCount = 0
    for _ in io.lines(tmpFile) do
      SavegameCount = SavegameCount + 1


    -- Highlight the first empty savegame slot available
    Scenes['Menu - Savegame'].Values['selected_slot'].Int = SavegameCount + 1

    Lua has no way to list a folder's content (if not with external extensione that I can't use in Visionaire), so I had to rely on a command.

    Also, Visionaire doesn't seem to support popen(), which would have allowed me to read the output in a variable. So, redirecting the command output to a file, then opening the file and reading the content did the trick.

    Once I got the file count, I was able to do highlight the first free slot.

    Now, despite being  pretty proud of how we made it work, I still feel we had to choose between two different "WTF", decide which one was bigger and take the other road.

    We then spent the last couple weeks wrestling with Visionaire to create a barely decent set of menus and settings screens for the game. This experience really killed my buzz.
    Despite the first approaches with visionaire allowed us to set a game up very quickly, I experienced how limited it is on many aspects other than the bulk of the game management (scenes, animations, characters, etc). And this is scary, from a developer perspective. I feel that at some point I may stumble onto a limitation that will hinder my creativity.

    I totally understand that Visionare is a tool aimed towards creatives with little coding skills, so I may personally be out of target. But I also think that a creative with little coding skill may be not able to come up with something like the above. If such, the guy should reconsider his own coding skills and be less scared to get his hands dirty.

    Sorry for the little rant. Hope this script may be useful to someone else anyway!



    19 Posts

  • #9, by tall-story-gamesFriday, 29. January, 12:04 2 months ago

    That sounds like you've got a good solution, although I agree that there are some "quirks" to Visionaire that seem a bit inflexible and  counter-intuitive, requiring workarounds as opposed to being able to bend to the will of the designer/developer.

    Also, the documentation is very technical, so unless there's a specific tutorial/code snippet created for the exact thing you want to achieve it can be a very steep learning curve for designers.

    As the "wrong slot" issue only manifests the first time that the slots are filled, I found that hiding all empty slots and only revealing them one at a time when their time comes works quite well. Mine only has 6 slots, which all needed to be coded into the logic, so 12 slots would be more work - but certainly achieveable. - That said, I've not been able to test it on Linux or Mas OS yet!

    You can see an example of it working here:

    I'd be happy to share my code with you too if you think it would be helpful, but it sounds like your solution is working great too.

    Don't lose heart, the world needs more pixel art point and click! smile


    42 Posts

  • #10, by i-c-gFriday, 29. January, 15:26 2 months ago
    Ahah, of course we are anything but demoralized! smile

    We may just consider taking another route, technically speaking. I agree with what you said, there is a not-so-sweet spot in VS that seems to me too hard for designers and too limiting for devs.
    But again, VS proved to support award-winning titles, so my frustration does not make for a statistics grin

    That said, I took a look to your interaction and it's brilliant. Probably the best UX achievable given Visionaire limitations.
    Currently I'm not that inclined to spend more time on an ancillary interaction, so we may stick with what we have, but if we decide to stay on Visionaire, I may reconsider taking your route!

    Thanks for sharing and caring and keep up the great work!


    19 Posts

  • #11, by tall-story-gamesFriday, 29. January, 15:28 2 months ago
    Hmm, just tested mine on a Mac and it's not happy. Just debugging it now.
    Maybe stick with your route! grin


    42 Posts

Write post