4 ms·
This is fun and interesting, and I'm not sure what to think of it. There's an old saying in game dev, which is often good advice for business as well: "Build t
by unoti 6y ago
This is fun and interesting, and I'm not sure what to think of it.
There's an old saying in game dev, which is often good advice for business as well: "Build the game, not a library"[1].
Or as applied to this case, that might mean trying to shoot straight for what you need in the game. Arguably, S-expressions might be the smallest possible thing you can do.
But another approach that is often used: Have your game process a binary file format, and build tools that read text files and compile them into the binary format. It's very common in games to have a tools pipeline that prepares assets for production use. Those tools can safely and easily take whatever dependencies help you get the job done, such as a JSON or YAML parser, or even real LISP if that feels right. This kind of approach also fulfills the laudible goal of keeping the dependencies down (for the production game).
The output of the tool chain could be binary files. Or, depending on your situation, the toolchain could produce code which is then run through your compiler, and then it's ready for direct execution, skipping a parsing step entirely.
[1] https://geometrian.com/programming/tutorials/write-games-not-engines/ https://geometrian.com/programming/tutorials/write-games-not...
- f00zz 6y agoFor what it's worth, I once wrote a game that had a configuration file parser written in bison/flex (I actually finished that game).