I wrote a custom-made script parser... knowing full-well there were many libraries available. (For a goofy program I wrote available at cycell2d.com) Why? Because I enjoyed it!
This sort of nonsense is a good example of how some projects die due to absurd feature creep that no one at all can possibly justify. Who in their right mind would ever want to embed a full blown scripting language if your usecase is... Open a file and input data?
If you want to input data following a document format, you parse the document format. That's it.
Because embedding a mature, well written dependency that fully satisfies all your requirements might well be easier from a technical standpoint. It's certainly likely to reduce your comparative future maintenance burden given that the upstream community is healthy and functional.
What? Are there no mature well written parsers?
Don't be ridiculous.
Granted that in this particular case the point seems to have been the exercise of implementing the parser itself so embedding a dependency wasn't a valid approach to begin with.
S-expressions are a widely used standard data format and are not exclusive to Lisps. If this is just to read in configuration files, and the resulting data structures never change after they're read in, he can get away with using calloc instead of a garbage collector, and null-terminated char * C-style strings.
Lisps (including Scheme) have more heavyweight implementations of strings and symbols than Ben has here, with an extra level of indirection: a symbol's name slot points to a string struct, which contains a pointer into an array of chars and a length. He can get away with a null-terminated char * and a struct containing an enum to distinguish them. For Lisp programming, the extra complexity is essential but for reading a config file into a game written in C, it's accidental. I don't know what kind of game he's writing but presumably it isn't anything like Abuse or Crash Bandicoot.
In the first paragraph, he writes, "I turned away from XML because I'd rather be as library independent as possible." This implies that he might have considered embedding a Lisp but decided against it for the same reason.
Sometimes a purpose-built module that addresses the need and maintains simplicity is preferable over complexity in the interest of some future potential feature that nobody has asked for yet, and may never ask for.
I can guarantee you that a game will need a scripting language. Better get that done already.
That's if you prefer Scheme. You could use Lua too.
Myself and thousands of people before and after me have written games without a scripting language.
However, if every single time you want to change any piece of logic in your game, you have to do the edit/compile cycle, your development will be extremely slow. Especially if you compare with the ability to change code while the game is running.
Not having all the game logic in C or what have you makes the game easier to mod too.
1. I'm working on a game in Unity right now that takes about 10 seconds to compile and reload the assemblies for the scripting language (only about 2 seconds of that is actual compilation, the rest is time that would be applicable to an interpreted scripting language).
2. I've built games in C where the entire project took 4 seconds to compile. Incremental compilation and modular architecture can get that down to near instantaneous for most changes.
>Especially if you compare with the ability to change code while the game is running.
Take a look at handmade hero for an example of an architecture that allows you to hot-reload C code while the game is running.
>Not having all the game logic in C or what have you makes the game easier to mod too.
That's completely architecturally dependent. You can make a game easy to mod for non programmers by storing data in a human readable/editable format. If you want to make it easy for players to write code there's a lot more work that needs to be done than just using a scripting language. For most games worrying about allowing modders to easily edit code is premature optimization.
I was involved in a game project that died extremely quickly a few years ago. The project lead made every decision re: architecture, tooling, etc. somehow involve worrying about modding. As a result, we ended up with nothing to show since everything got derailed by a bizarre obsession by one person with modding before we even had anything to mod. I believe that person doesn't take lead roles on projects any longer...
An excellent example most with OpenGL experience may be familiar with is supporting hot reloading of GLSL for fast vfx development iteration. It's a compiled language, it gets compiled at runtime without significant delay, and most of us making games have created simple tools to support live editing of GLSL, maybe even supporting it in-game for dev builds.
The demoscene has even turned it into a form of competitive performance art:
https://github.com/Gargaj/Bonzomatic
Edit:
Forgot to mention Casey also goes through support of hot-reloading game logic using C in the Handmade Hero series on YouTube.
Is that really so certain?
Embedding a scripting language (e.g. Lua) seemed to be very common around 2010, but I get the feeling that it's much less common today.
Has the use of embedded scripting languages in games declined over the last 10 years? Any particular reasons?
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
Once you are no longer dealing with data, but with actual Scheme code that is no longer the case and it becomes virtually impossible to do anything with the code other than directly editing it in a text editor. It's extremely inflexible and every tiny API change will break everything with no automatic way to fix it.
> I'd rather be as library independent as possible, ideally with my SDL being my only cross-platform dependency to worry about.
I agree. I just thought the goal of the author was to produce a game, not to parse S expressions. It’s possible that parsing S expressions is the most direct route to get there. But there may be more direct and simple ways to get there.
I thought you had to restart a scheme’s REPL. Is that just a limitation of Racket?
Really, if you're wanting to learn Scheme, just pick one and run with it. For learning purposes they're mostly equivalent if you stick to the more popular ones, but be aware of your learning material and the version of Scheme that they're using.
If you're familiar with other programming languages, it's somewhat like the relationship between different compilers. Though usually they adhere a bit more strictly to the same standards. Since Scheme is such a small language, there's more room for differences between implementations. This mostly doesn't affect you as a learner (most learning materials focus on the core parts of the language which all implementations should be consistent on).
Where they will differ the most is things like the packaging system (if they have packages, not all Scheme implementations will), as well as their main use-case.
If you are interested, just pick one and start to learn Scheme, using any implementation. Their differences will become apparent quickly.
emacs + evil (optional) + paredit + SLIME/SLY + SBCL + Quicklisp
That said, you might not always need such large runtimes and other lisps can fit the bill. For example, I usually program in CL (with C FFI) for most projects, but for embedding lisps into existing C programs, Guile can be a joy. Once I was programming servo motor controllers that offered C as one of the programming languages, and I embedded a single C file that gave me a tiny little scheme interpreter and I was then able to prototype motor control algorithms and setting in way less time than before. It's just a game changer for learning about a system when you can get a REPL on it and start rapidly digging and experimenting.
If we are parsing S-expressions... why not embed Scheme already? This way, not only you get an S-expression parser for 'free', you can easily manipulate S-expressions, you can add macros and so on. And you also get your scripting language out of this deal!
Something like Racket or Chicken (and possibly others) would work nicely. Chicken specifically has a very nice FFI - which you don't even have to use. As an experiment, I have asked Chicken's compiler to stop at the C code generation, added the generated code to my XCode project, and deployed the whole package to iPhone. Not even cross compilation shenanigans were required, since this was handled by XCode.
As a bonus*2, with a few lines of code, I opened a TCP listener, and fed straight to the REPL. Which meant that I could telnet and have a REPL, which could be used to replace functions on the fly and observe the results immediately, while the app was running.
They would have to rename the project at this point, though :)