Author Topic: Proposed Save Game Update  (Read 2332 times)

Offline BadgerBadger

  • Global Moderator
  • Hero Member Mark II
  • *****
  • Posts: 920
  • BadgerBadgerBadgerBadger
Proposed Save Game Update
« on: June 13, 2017, 07:15:01 PM »
So I'm really tired of having to just roll with the "click on NewSave_X" buttons and trying to remember which save game I was using. I now have something better for consideration! I'm sure Keith or Chris can do a better job, but I think this is a significant usability improvement for the moment.

Here is a picture and a diff that implements it. Y'all are welcome to include it in the game.

Offline Draco18s

  • Resident Velociraptor
  • Core Member Mark V
  • *****
  • Posts: 4,088
Re: Proposed Save Game Update
« Reply #1 on: June 13, 2017, 09:03:20 PM »
+1 from me

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,504
Re: Proposed Save Game Update
« Reply #2 on: June 13, 2017, 09:32:30 PM »
I suppose "one of the players got to the point of implementing it themselves" is a suitable indicator that it's time to implement it ;)

Thanks, I'l aim to plug that in before I finish batch #7.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline TheVampire100

  • Master Member
  • *****
  • Posts: 1,376
  • Ordinary Vampire
Re: Proposed Save Game Update
« Reply #3 on: June 14, 2017, 02:46:52 PM »
While we're at it, could you make it that the game makes a screenshot and adds it as thumbnail to save games for reference purposes?

Offline BadgerBadger

  • Global Moderator
  • Hero Member Mark II
  • *****
  • Posts: 920
  • BadgerBadgerBadgerBadger
Re: Proposed Save Game Update
« Reply #4 on: June 14, 2017, 03:11:19 PM »
A thumbnail of what? I have opened mantis 0019101 for at least an analagous request (how to put useful metadata on a save to remind me what game it was and what was happening).

Offline TheVampire100

  • Master Member
  • *****
  • Posts: 1,376
  • Ordinary Vampire
Re: Proposed Save Game Update
« Reply #5 on: June 14, 2017, 03:34:12 PM »
Either Galaxy Map or simply just what you are looking at when you make the save game (like other games do).

Offline x4000

  • Chris Park, Arcen Games Founder and Lead Designer
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,225
Re: Proposed Save Game Update
« Reply #6 on: June 22, 2017, 10:04:26 AM »
I will happily apply this, but I can't get figure out how to do this with WinMerge, and TortoiseSVN does not recognize it as a valid patch file if I try to use it (extension changed or not, it just fails).  I can't use TortoiseGit on the folder since it's not versioned with Git.

I need to focus on other things right now in order to make sure this release gets out today.  But if someone else is able to google-fu this up, then I'd be grateful. :)
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline BadgerBadger

  • Global Moderator
  • Hero Member Mark II
  • *****
  • Posts: 920
  • BadgerBadgerBadgerBadger
Re: Proposed Save Game Update
« Reply #7 on: June 25, 2017, 02:23:43 PM »
I have some other ideas for how to enhance the Save/Load Game menus that I'm interested in exploring. I'm intrigued by trying to encode information "about" the game as part of what is displayed for a given save game to make it more uniquely identifiable. I have included the "last save time" in the load game menu as an example.   

I am also wondering if I could include things about the game (in game clock, difficulty, map type, etc) to make it more unique as well. However, the code to extract information about a Save Game all seems to be in various Arcen-specific DLLs, so I'm struggling to figure out how. I could just write my own "parse the Save Game" function (it looks like all the data in the Save game itself is just in a large comma separated list), but if that code already exists, it would be much more efficient to use it.

Offline x4000

  • Chris Park, Arcen Games Founder and Lead Designer
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,225
Re: Proposed Save Game Update
« Reply #8 on: June 26, 2017, 10:29:33 AM »
We use a really specific sort of character buffer that Keith created, so it's not quite just a comma-separated list, though that's certainly a big part of it.  Ints and floats and so forth are stored with pretty different sorts of data from what a pure text file would do.  There are serialization and deserialization classes that you can call, but one of the key tenets of them is that no metadata is stored and so you have to know exactly what order to pull things out in, and if anything is even slightly out of place then the entire file is unreadable.  This is a very efficient way of storing the data, because metadata about what each piece of data is is incredibly space-consuming when you're talking about that much data.

Granted, having some sort of "header area" that works differently would in theory be possible, but that's something Keith would have to come up with and make a callback for.  That's worth a mantis request, for basically being able to insert arbitrary data in a certain subsection of the start of the savegame.  A centrally-controlled callback for then passing you that data back as a string (or something) would then be something he'd need to create.  The balance between efficiency and usability-for-modders is something he'd need to carefully engineer, so it's not a quick thing (unless it is, heh).

The other point I'd like to make in general is that including things like screenshot thumbnails is in general not a great idea in my opinion.  To do a screenshot requires a screenshot to be taken (of course), which in itself is a pretty sizeable hitch in unity, and then you need to scale that down, which requires System.Drawing to work properly, and that creates a lot of garbage as well as more data.  You then have to encode the data in some fashion, whether that's jpeg or png or whatnot, to make it not absolutely monstrous in size in the savegame itself.  Embedding that isn't a problem, but the amount of a visual hitch you introduce any time there's an autosave is going to be notable.

If you're trying to get a screenshot of a specific thing (like the galaxy map), then you first have to switch the game to viewing that at the correct zoom, let it sit for at least one frame, then take a screenshot, then return everything to the way it was before you did that.  Think of it like photography.  I can't photograph the layout of your house without going to your house, taking off the roof, renting a helicopter, and actually taking the photo.  Then I need to put the house back together, return the helicopter, go back to whatever I was doing before, and probably explain myself to you and the police. ;)

There are some ways that we could make things like that easier if we wanted to, but there are a lot of complexities with that having to do with bounding boxes, field of view, offscreen cameras, and object active/inactive states.  It would get rid of the worst of the "now we have to put things back" problem, but it would still cause a visual hiccup as well as a literal flash of some other part of the game.  There are STILL other ways around that, but then we're talking offscreen cameras and render buffers and such... and that certainly would be more tractable and could avoid the visual hitching, etc.    But you run into that potentially taking a week or more to figure out all the details of.

And at the end you have a tiny screenshot that probably looks pretty much like all the other screenshots, and the load game scene loads really slowly because of having to extract all that metadata, convert it to jpeg, then convert it to the unity Image format with DTX1 or DXT5 compression, and so on.  That part would be wiiiiicked slow.

Anyhow, metadata is a lot easier to handle than the screenshots bit. ;)  Usually for screenshots it's easier if the screenshot is saved next to the savegame as its own file, and if you don't have too many savegames.  I did this in Shattered Haven, for instance.  It worked well there, partly because there was no autosave, but also because each screen was visually pretty different.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline BadgerBadger

  • Global Moderator
  • Hero Member Mark II
  • *****
  • Posts: 920
  • BadgerBadgerBadgerBadger
Re: Proposed Save Game Update
« Reply #9 on: June 26, 2017, 11:00:56 AM »
Yeah, I don't think a picture is really optimal.

 I'm trying to come up with a better UI mechanism for organizing save games. I think it would be cool to present the user with blocks of saved games, saying "These are your saved games from a Cluster Map, seed XXX, AI difficulty YYY", then show all those saved games, then a new block of saved games. Then organize each block by wall clock time. This way the user gets much more useful information about their saved games, and there's no need to alter the information being saved, we just need to run a few read operations and then present stuff to the user. It's possible that if a user has hundreds and hundreds of save files this might be a bit of a performance overhead depending on how costly the "Read save game" function is, but that would require experimentation to check on.

Example: lets say I saved games from X active campaigns. I'm imagining presenting the user with X separate columns of saved games (sorted by wall clock time), with text over each one saying which campaign it was. Then it would sort the columns by wall clock time, so I would always know which campaign I've been working on most recently.

The information I'm interested in is stuff that hopefully can't change (one does not change map type or game seed mid game), and I'd be trying to only do read operations, so hopefully I would be unable to corrupt things.

Offline x4000

  • Chris Park, Arcen Games Founder and Lead Designer
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,225
Re: Proposed Save Game Update
« Reply #10 on: June 26, 2017, 11:41:31 AM »
My suggestion is to encode that into the name of the savegame itself, not into the file data.  Then when showing savegames, cut off the metadata and just show the user-entered data.  The metadata is thus incredibly fast to read, and can be based off of abbreviations for map types, etc.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline BadgerBadger

  • Global Moderator
  • Hero Member Mark II
  • *****
  • Posts: 920
  • BadgerBadgerBadgerBadger
Re: Proposed Save Game Update
« Reply #11 on: June 26, 2017, 12:09:22 PM »
So my file name would be "mySave.METADATA:<fields here>.save" or something to that effect? I considered doing something similar with Extended Attributes, but didn't want to try to use those cross platforms (and I'm not sure if all file systems support them). If anyone wants to look at the file names they will be a bit messy, but that said I really like the idea.

I'll figure out how to extract the necessary information (I think most of that data is in the World_AIW2.Instance , or a member of that object, like World_AIW2.Instance.Setup.MapType.InternalName) and give this a try later.

Offline x4000

  • Chris Park, Arcen Games Founder and Lead Designer
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,225
Re: Proposed Save Game Update
« Reply #12 on: June 27, 2017, 09:32:05 AM »
Generally speaking, I'd suggest a few changes, but that's the general idea.  Notes:

1. Bear in mind that on Windows and I think also OSX the file path limit is once again 256 characters.  They changed this back sometime in the last couple of years because it allows for faster file lookups.  To me that's just asking for trouble, because I remember well what FAT32 was like, but still.  So keeping everything as brief as possible is good.

2. Additionally, not using period as a separator is good, because that's going to change the type of file that many OSes see it as -- depends on the config.

3. I'd use an initial separator to split the thing into two parts -- the player's part, and then the metadata part.  Something brief, in ASCII, that wouldn't be otherwise be present in a filename.  I'd suggest a mult-character thing like ~# as the thing.  That combination is unlikely to be in someone's filename in that order.

4. So at this point you have mySave~#<datahere>.save.

5. When it comes to the data, it needs to be brief as can be thanks to the aforementioned filesystem limits.  That means no identifies, for one, and for two having a single-character separator for items in the list.  Then doing a split operation on that metadata string using that single character, and getting the results by index in the resulting array.  So for instance, mySave~#thing1_thing2_int3_bool1_etc.save.

6. When it comes to the metadata itself, it's then a matter of trying to compress it as much as possible into as few characters as possible. 

- So for instance, rather than writing out Clusters in the first index as the map type, having little abbreviations like CL or whatever would be good. 

- If you have a number that will always be less than 256 in value but might be more than 9, then cast that to a char and just append that instead (though there are some special characters for various OSes, and those create enough landmines that they wouldn't be a good idea in a filename.  Inside a file it's fine, but you can't use something like * in a filename on windows, and on certain other OSes, too.)  Then cast back from the char to an int to get the data back later.  You then always use one character for those numbers rather than 1-3.  Savings!

- If it's always going to be 9 or fewer, then just put the number.  For a bool, use a 0 or 1 rather than writing out the text.  Etc.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline BadgerBadger

  • Global Moderator
  • Hero Member Mark II
  • *****
  • Posts: 920
  • BadgerBadgerBadgerBadger
Re: Proposed Save Game Update
« Reply #13 on: June 29, 2017, 07:37:25 PM »
I have a super-early first pass design of what I'm imagining the Save Game screen could look like. This is not a mock up, the code is working fine in my sandbox.  In this regime, you give a game a "Campaign Name" (ie a Game name) and then can save as many times as your want. If you don't use a Campaign name, it will use "Map Type.Seed", which hopefully will also be unique.   Saves under a campaign are sorted with the highest in-game clock at the top (ie your most recent save). So for this screenshot, I started a new game and named the campaign moddedArk. Then I saved at various points ("Taken first ARS", "Got a Golem", etc). I might rework it again later, but I wanted to get this concept out for feedback as I continue to think on things.

I also modified the game so that it would pause as soon as you entered the "Save Game" Screen and unpause as soon as you left. I feel like that makes things much safer the player, so nothing bad happens while you are naming your game.
« Last Edit: June 30, 2017, 08:26:10 AM by BadgerBadger »

Offline Draco18s

  • Resident Velociraptor
  • Core Member Mark V
  • *****
  • Posts: 4,088
Re: Proposed Save Game Update
« Reply #14 on: June 29, 2017, 07:51:22 PM »
Oh that's kinda neat.