One should implement Writer & Reader classes to generate game snapshots as a closed system.
This should generate file(s) snapshotting the game system. Initially, this files may be written as plain binary files and/or json file. The writer would output the files as the game goes, while the reader will be used independently (within python library) to retrieve that information.
For general organization, I was thinking in something like that:
A master file written as a .json, containing initial game information and general data), such as:
Ball
Cars
World parameters (stiffness, damping, timestep, game duration, ...)
Models employed (normal, tangential, ...)
History files containing snapshots of periodic times (e.g. every 0.5s, 1s, 10s, etc). The period of snapshot will be a solver/game input parameter.
As a suggestion, for json write/handling in C++, I suggest use the library JSON for Modern C++ or Boost JSON. For history binary files, the std::fstream should do just fine.
This will primarily serve as a feeding mechanism for the visual toolkit being developed in #6.
In the future, this may become a replay saver/retriever mechanism. We may also evaluate in the future the usage of binary HDF files format.
@mrsmatos This is a good first issue, if you want to. We've briefly discussed it before. If you are interested, let me know so we can talk and I can explain you the general idea.
One should implement Writer & Reader classes to generate game snapshots as a closed system.
This should generate file(s) snapshotting the game system. Initially, this files may be written as plain binary files and/or json file. The writer would output the files as the game goes, while the reader will be used independently (within python library) to retrieve that information.
For general organization, I was thinking in something like that:
As a suggestion, for json write/handling in C++, I suggest use the library JSON for Modern C++ or Boost JSON. For history binary files, the
std::fstream
should do just fine.This will primarily serve as a feeding mechanism for the visual toolkit being developed in #6.
In the future, this may become a replay saver/retriever mechanism. We may also evaluate in the future the usage of binary HDF files format.