Note: I might call it "Everything is better in quarantine." The goal would be to (not) go mad.
I would throw Ink (from Inkle, creators of 80 Days, Steve Jackson's Sorcery!, and Heaven's Vault) in the ring for the choice-driven variant of IF. It also publishes a playable webpage. I made a sort of unconventional portfolio-like page with it here: https://maxsond.github.io/
Take a look on ISTEAD - Simple Text Adventure Interpreter.[0]
It has JS-based version[1,2] and native versions (SDL-based in pure C) for Android[3,4], Windows and Unix-like platforms (including Linux, macOS/iOS, Maemo/MeeGo, Symbian 9.x, various consoles, etc.).[5]
Text adventures for INSTEAD could include Lua-scripts (text adventure itself & modules) and various media assets (images, sounds, fonts).[6]
There is repo with free games & demos for INSTEAD, which in most cases could be installed directly from INSTEAD clients.[7]
[0] https://github.com/instead-hub
[1] https://github.com/instead-hub/instead-js
[3] https://github.com/instead-hub/instead-android-ng
[4] https://apt.izzysoft.de/fdroid/index/apk/org.emunix.insteadl...
[5] https://github.com/instead-hub/instead/releases
OBJECT *obj;
par->tag = src;
par->distance = *src == '\0' ? distNoObjectSpecified : distUnknownObject;
forEachObject(obj)
...
Also function parseAndExecute (). The way he deal with invalid input is, epic:
static const COMMAND commands[] =
{
{executeQuit , "quit"},
{executeLookAround, "look"},
...
}
for (cmd = commands; !matchCommand(input, cmd->pattern); cmd++);
return (*cmd->function)();The array iteration code is also solid. Seems like a pretty good programmer, judging from the code you cite here at least.
While I personally like to put a few assertions just to find my typos quicker, adding additional fluff here is mostly detrimental. The kind of bugs that can happen with this sort of "dangerous" code are the ones that you basically just typos that you catch on the first run. I.e. it's not like there are any rarely occurring edge cases that are unhandled, since the code is extremely straightforward. The "complexity" is very low.
Shouldn't there be a NULL at the end of the array and do a null check in the iteration?
There are phases programmers go through. One phase occurs about after 10 years of professional programming. I call this the "no mercy" phase, where these newly-minted senior programmers think defensive programming is for noobs, and scrunch their C code down to the fewest number of lines and characters. And when someone objects, the reply is, paraphrased (as seen in the replies): "You're just not as good a programmer as me." Sadly, it takes another 10 years for this arrogance to dissipate.
Have you taken a look at some major C codebases? It's not justification but an appeal to authority seems pretty unnecessary :)
But then, why this tutorial? Why write an adventure game using a general-purpose programming language? Because doing so can be entertaining, challenging and educational. The programming language C may not be the most obvious choice for writing a text adventure; it's nothing like LISP-based languages like MDL and ZIL. But while writing my own humble text adventure, I learned that C fits the bill quite well.
The code generation looks interesting. I'll have to take another look later; can it not be done with the preprocessor?