I'm building a modding framework for C++ games that stores information needed to discover functions, class instances, and field offsets after reverse engineering. Since updates can change addresses, the format needs to support several ways of locating the same item, such as cached addresses, exported names, byte patterns, and searches based on identifiers and instruction arguments.
The current design has a header containing a format version, file type, target module, and modification information, followed by a data array. Each data item has an ID and one or more possible locations. A location can use a shared property such as "kind", with additional fields like "value", "result", or nested operations. Some properties have both compact and expanded forms, and I am considering allowing custom locator kinds in the future.
My goals are to create a flexible, extensible information-exchange format that mod makers can use across different frameworks and games, support multiple files with different data types, and allow the format to evolve without frequent breaking changes. I would appreciate feedback on the overall structure, whether reusing names such as "kind" in different contexts is sensible, whether a file-type field is a good approach, how to handle compact versus expanded result definitions, whether kebab-case or camelCase is preferable, and any long-term maintainability concerns you notice. I also want the data to remain practical to edit both manually and through tools.
2 Answers
JSON is portable and convenient for tooling, but it is not necessarily the best authoring format for a heavily repetitive schema. It is hierarchical, has no built-in reuse or templating, and may become difficult to maintain when many entries share the same patterns and operations. Templates or named reusable definitions could reduce duplication, especially if the format eventually describes types, layouts, methods, relationships, and associated locators.
Whether JSON is appropriate depends on who the primary consumer is. If programs generate and consume the files, readability matters less than having a precise schema and good documentation. If people are expected to edit them directly, consider a more concise authoring format or provide tooling that validates, generates, and migrates the JSON. Event-driven parsing, often called SAX parsing, is a way to process JSON incrementally without loading the entire document into memory; it affects parser implementation more than the design of the file itself.
The format can still work if it clearly helps users reach the end goal. Document the semantics thoroughly, define the accepted locator and resolution operations, and consider modeling the underlying types and relationships explicitly rather than treating everything as isolated IDs and locator arrays.
The use case is clearer if this is presented as an information-exchange format for reverse-engineering tools rather than as a universal modding solution. A shared locator format could be useful, but it should probably stay focused and avoid trying to describe every kind of game or engine. The current structure is quite verbose, so consider whether every nested object and repeated property is necessary.
A version field is useful when you explicitly want to permit format changes, but it does not by itself guarantee compatibility. You may want a clear compatibility policy, such as supported versions, migration rules, or capability flags. Be cautious about putting several substantially different schemas behind a generic file-type field, since that can turn one format into a collection of loosely related formats.
Reusing a name like "kind" is fine when it has a consistent meaning within its immediate context, but do not force identical names where more precise names would make the data easier to understand. Also, camelCase will generally be less awkward for programmers to consume than names containing hyphens, since hyphens are inconvenient in many languages.
The intended problem is helping modders resolve functions and fields whose addresses change between game updates. The framework would combine cached values, exports, patterns, and more advanced searches so users do not have to build every part of that pipeline themselves. I agree that reducing verbosity and clarifying the format's scope are important, and I have already started separating a target module from the locator definitions.
I would like the data to be editable by hand as well as generated or modified by tools, so reusable definitions and validation could be useful. I was initially unsure whether SAX referred to an alternative file format, but it makes sense as a parsing strategy rather than a replacement for JSON.