game data

gistfile1.txt

I tried to make a thing once that could ingest a folder of json/xml/whatever files, infer
a type schema from them, and then give you a spreadsheet style table editor.

The idea was it would infer a schema from the data, or from analyzing your game's source 
code (like running reflection over C# assemblies, or parsing C++ headers), and then you 
could use that do really complex and wide-reaching "data refactoring."

I didn't move past prototyping because I didn't have enough brainergy after work, but I
think something like this could be made that feels has the good stuff spreadsheets have:

- manipulating cell ranges
- cascading formulas
- filtering
- arbitrarily different views of items (transposable view, supporting references & nesting)

But it would also be smart about common game data types (like Vector2/Vector3, collision
bounds, etc.), and even allow people to plug in rudimentary constraints and visualizers 
for their own custom data types. Kinda like constraints in a database, but with a beautiful
UI. I guess a better pitch would be "like Twine, but a game item database, and better 
UX than CastleDB."

I initially started because the way we managed items on a previous game I worked on involved
somebody writing a bunch of spreadsheets in a special format, and then running that through 
an importer I wrote that does all that type checking and then generates json files and inserts 
rows into the live database on build. This was a Unity project, so I'd initially made
ScriptableObject assets, but the designer just started using spreadsheets, so I figured might
as well make the spreadsheet the source data.

Sadly, the fact that OpenOffice didn't know anything about our game data meant the designer
basically had to deal with a crappy edit, compile, fix, recompile workflow just to tweak stats
using the crappy syntax I invented that optimized for writing that importer quickly.

Then I started a new job where the systems designers makes wide sweeping changes to itemization 
by writing a bunch of perl scripts (editing by hand isn't feasible because of the sheer volume
of items in the game), and I became even more convinced that this kind of tool is sorely
needed by game designers. Even if it just lets you easily visualize all the game data that
your perl scripts are munging :P

I'm adding an image of the thing I was working on, it's fiddly an ugly, but it's interesting
because it's working with rando data from a Community fan game. You can kind of see the type
descriptors it would generate (the multiple files listed to the left are sources whose inferred
types were merged together). It would need a bunch of work making heuristics for when to
merge the inferred types if it doesn't have source code to work with, but I don't think it
would be that much work for someone who had the opportunity to work on a tool like you described
full time.

prototype_tool_screenshot.png