I'm designing a C++ modding framework that stores ways to find game functions and field offsets. An entry might have a cached location and several byte patterns that can locate the same thing.
How would you structure the JSON so it's understandable, flexible, and usable by tools written in different languages?
Keep the top level simple: format version, module identity, and an array of entries. Give each entry a stable ID and a locations array, with each location having a kind that tells the reader which other fields to expect.
For example, a cached location could have a value, while a pattern location has a pattern and a result description. I'd make result an object consistently rather than allowing both a string and an object. A little extra JSON is easier to parse and document than multiple shorthand forms.
Reusing names like kind is fine when the surrounding object makes their meaning clear. Reusing value for several unrelated things is less helpful than naming those fields pattern, offset, or address.
Treat a cached address or offset as valid only for the module build it was derived from. Store enough build identity to check that before using it. A modification time alone can change without the binary changing, or be preserved when the binary does change.
A binary hash is one possible check. Also define what a cached value means: an absolute address, a module-relative address, or a field offset are not interchangeable. On a mismatch, the consumer can reject the cache and try a discovery method instead.
Write down the discovery rules as carefully as the JSON keys. What does a wildcard match? What happens if a pattern matches zero locations or several? Is an instruction offset measured from the start of the match, and is the operand index zero-based?
Those details matter more for interoperability than saving a few characters in the file. Validate each kind against a schema, reject missing required fields, and give errors that identify the entry and location that failed.
I'd start with the information exchange use case, not a promise that one framework will handle every game. A shared format for known locations could be useful while still leaving game-specific interpretation and tooling to each consumer.
Version the format separately from the game build, and decide how readers should handle unknown location kinds and future fields. That gives the format room to grow without pretending every tool supports every discovery method.
Answers are reviewed before publication.
e513~corkscrew_2:
It would also help to specify whether the locations array is ordered by priority or whether consumers can choose among the methods.