• Advertisement

Recommended Posts

Hi

Im using binary files to save and load savegames. But when you list your savegames for the user you want some metadata such as date/time, gameday, difficulty, map name etc so the user more easily can identify which savegame they want to load.

What is the prefered way of doing it?

1. When saving, save metadata first in the file. Then do a function "scanSaveFiles()" before showing the available savefiles for the user. This will read each "header" of each file (reads the first section of the binary file without actually loading that game) and can then show the info to the user.

2. When saving, update a table of savegame-metadata held by the "gameMaster" that holds other stuff like user options, progress etc. However this seems bad since if the user manually moves or modifies the savefiles the table of savegame-metadata will no longer sync with the actual save files.

Or any other smarter way of doing it?

Edited by suliman

Share this post


Link to post
Share on other sites
Advertisement

Yes agree, first option. Also when dealing with save game files, especially binary ones, make sure it has some sort of future proof about it.  I.e. you'll probably want to add things to your save game in future versions of the game (after release), Will your game handle loading old versions of your game save data..
 

Share this post


Link to post
Share on other sites

Version compatibility is always a topic not just for savegames but also for anything that is serialized/deserialized. A text or property file format could help here so unknown properties will be skipped while new ones will be held empty.

The option to have some kind of header in your save files is currently the best one for your situation because a save file is the main entity you need to maintain, when storing metadata, you need to know if a file has moved, was replaced or renamed what may become a huge management overhead while you just want to "simply show some information".

On the other hand you then will have file access every time you just want to see what your last save files are so the "database" solution has the advantage of keeping disk access as small as possible. Some games prefer this solution when for example the player has made his own character you would like to show as seen here

ddo_3.jpg

 

A middle course solution would be to gather a players save files at startup of the game or as a background task when you are sure your player wont have access to the save game area for a few seconds to generate your meta database at this point from disk until you update it next time

Share this post


Link to post
Share on other sites

I like the 1st method.  It also directly allows your players to move save files either for backup purposes, or to other machines, or in most cases if you let them choose save locations, to something like a Dropbox folder.

I understand wanting to "gather" all the information in a single place...but I think a few milliseconds to do that when you hit the "load" button is fine.  Even a spinning hard drive shouldn't have trouble reading several headers of savegame files really quick, especially if they are binary files(which you are currently discussing).  Even if it were a couple of seconds I think it would be an acceptable amount of time for a player to wait, especially since it let's them easily select the file they want, without having to go search for it, remember what it was called, or anything like that.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By mister345
      Hi, can someone please explain why this is giving an assertion EyePosition!=0 exception?
       
      _lightBufferVS->viewMatrix = DirectX::XMMatrixLookAtLH(XMLoadFloat3(&_lightBufferVS->position), XMLoadFloat3(&_lookAt), XMLoadFloat3(&up));
      It looks like DirectX doesnt want the 2nd parameter to be a zero vector in the assertion, but I passed in a zero vector with this exact same code in another program and it ran just fine. (Here is the version of the code that worked - note XMLoadFloat3(&m_lookAt) parameter value is (0,0,0) at runtime - I debugged it - but it throws no exceptions.
          m_viewMatrix = DirectX::XMMatrixLookAtLH(XMLoadFloat3(&m_position), XMLoadFloat3(&m_lookAt), XMLoadFloat3(&up)); Here is the repo for the broken code (See LightClass) https://github.com/mister51213/DirectX11Engine/blob/master/DirectX11Engine/LightClass.cpp
      and here is the repo with the alternative version of the code that is working with a value of (0,0,0) for the second parameter.
      https://github.com/mister51213/DX11Port_SoftShadows/blob/master/Engine/lightclass.cpp
    • By Rannion
      Hi, I am sending data to peers and those data need to be retreived from a scenegraph with a mutex to lock the data.
      The process of gathering the data is taking a bit less than a ms. I'm starting the thread every time I want to gather the data. If I'm running at 60 fps, I'm starting the thread 60 times per second so is that a performance or design problem?
      Would it be much better to have the thread always running and some kind of mechanism to ask him to perform the task whenever it's needed, so around 60 or 120fps?
      Also, does starting a thread creates some memory alloc/dealloc and then produce on the long run some kind of fragmentation?
      Thank you all.
    • By stream775
      Hello!
                I wrote a simple bones system that renders a 3D model with bones using software vertex processing. The model is loaded perfectly, but I can't see any colors on it. For illustration, you can see the 3D lines list, the bones ( 32 bones ) are in correct position ( bind pose ).
       
      Now, here's the problem. When I try to render the mesh with transformations applied then I see this:
      As you can see the 3D lines are disappearing, I'm guessing the model is rendered, but the colors are not visible for whatever reason. I tried moving my camera around the line list, but all I can see is some lines disappearing due to the black color of vertices? I'm not loading any textures, am I suppose to load them?
      However, if I render the vertices without applying ANY bone transformations, then I can see it, but it's a mess, obviously. If you're wondering why it's red, I have set color of these vertices ( only half of them ) to red and the rest half is white.
      First of all, my apologies for the messy code, but here it is:
      I'm not sure if vertices are suppose to have weights in them for software vertex processing. I'm storing them in a container, so you don't see them here.
      #define CUSTOMFVF ( D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_DIFFUSE ) struct CUSTOMVERTEX { D3DXVECTOR3 Position; D3DXVECTOR3 Normal; DWORD Color; }; This is how I store the vertices in container and give them red and white color:
      This is how I create the device:
      For every frame:
      This is the UpdateSkinnedMesh method:
      I have debugged bone weights and bone indices. They are okay. Bone weights add up to 1.0f, so I'm really wondering why I can't see the model with colors on it?
    • By komires
      We are pleased to announce the release of Matali Physics 4.0, the fourth major version of Matali Physics engine.
      What is Matali Physics?
      Matali Physics is an advanced, multi-platform, high-performance 3d physics engine intended for games, virtual reality and physics-based simulations. Matali Physics and add-ons form physics environment which provides complex physical simulation and physics-based modeling of objects both real and imagined. The engine is available across multiple platforms:
              Android         *BSD         iOS         Linux         OS X         SteamOS         Windows 10 UAP/UWP         Windows 7/8/8.1/10         Windows XP/Vista What's new in version 4.0?
               One extended edition of Matali Physics engine          Support for Android 8.0 Oreo, iOS 11.x and macOS High Sierra (version 10.13.x) as well as support for the latest IDEs          Matali Render 3.0 add-on with physically-based rendering (PBR), screen space ambient occlusion (SSAO) and support for Vulkan API          Matali Games add-on  
      Main benefits of using Matali Physics:
              Stable, high-performance solution supplied together with the rich set of add-ons for all major mobile and desktop platforms (both 32 and 64 bit)         Advanced samples ready to use in your own games         New features on request         Dedicated technical support         Regular updates and fixes
      The engine history in a nutshell
      Matali Physics was built in 2009 as a dedicated solution for XNA. The first complete version of the engine was released in November 2010, and it was further developed to July 2014 forming multi-platform, fully manage solution for .NET and Mono. In the meantime, from October 2013 to July 2014, was introduced simultaneous support for C++. A significant change occurred in July 2014 together with the release of version 3.0. Managed version of the engine has been abandoned, and the engine was released solely with a new native core written entirely in modern C++. Currently the engine is intensively developed as an advanced, cross-platform, high-performance 3d physics solution.
       
      If you have questions related to the latest update or use of Matali Physics engine as a stable physics solution in your projects, please don't hesitate to contact us.

      View full story
    • By JoshKlint_34394
      Today we are pleased to announce the release of Leadwerks Game Engine 4.5.
      Version 4.5 introduces support for VR headsets including the HTC Vive, Oculus Rift, and all OSVR-based hardware, allowing developers to create both room-scale and seated VR experiences. The Leadwerks virtual reality command set is robust yet incredibly simple allowing you to easily convert your existing 3D games into VR titles. To help get you started the source code for our Asteroids3D game has been updated for VR and is now freely available in the Leadwerks Games Showcase.
      Leadwerks Game Engine is uniquely well-suited for VR because of its fast performance, ease of use, and the availability of C++ programming for demanding VR games. Several optimizations for VR have been made including combining the rendering of both eyes into a single culling step. The stability and accuracy of Newton Game Dynamics means we can have in-depth physics interactions in VR.

      A new VR game template has been added to provide common VR features including teleportation locomotion and the ability to pick up and interact with objects in the environment.
      Visual Studio 2017
      We've also upgraded Leadwerks Professional Edition to build with Visual Studio 2017 so you can take advantage of the very latest Visual Studio features. Instructions for upgrading C++ projects from version 4.4 to 4.5 are available here.
      Other Improvements
      Added fog settings in editor and into map file format. New joint scripts and enhancements. Updated to Steamworks 1.41 You can pick up Leadwerks Game Engine with a discount during the Steam Winter Sale.
      About Leadwerks Software
      Leadwerks Software was founded in 2006 to make game development easy and fun. The company launched Leadwerks Game Engine on Steam in January 2014 and has experienced steady growth, now with over 20,000 paid users.  Leadwerks Game Launcher was released as an early access title in September 2015, allowing developers to publish games to Steam Workshop with no submission fee.

      View full story
  • Advertisement