Heh, no worries, I totally understand where you're coming from and for the record consider you objectively correct. The following paragraphs are a description of a personal challenge I set myself for this project and not what I consider 'good practice' in general. In short, this is not intended as an 'argument in favor' of doing things the way I did them, but instead just an 'explanation of why' I did.

Looking back at my initial post, I didn't make it as clear as I should have that a lot of my poor design decisions are intentional as part of my goal for this project. Since I'm not making this professionally, I can get away with doing things the "wrong" way for experience/learning purposes (to paraphrase a quote I can't quite remember off the top of my head, you build things from the ground up when you're learning so that you know how things work, then use off-the-shelf stuff in practice to save time). I do want this to be as usable for people as I can make it within these parameters, but part of my goal is to have built as much of it as possible myself (with SDL being a compromise for portability).

I did consider using Lua, before deciding that writing my own language would be simple enough that I should do it in accordance with the last paragraph, but decided against it for two mostly philosophical rather than practical reasons. The first is that I already knew I was going to need SDL to realistically make the engine portable, and so I already had to both learn how to use/debug SDL, learn how to program a game engine, and integrate my engine with SDL to complete the project, and adding Lua to that would mean that I would have to also learn how to use/debug Lua, learn how to interface Lua with SDL, and integrate my engine with Lua. Making my own scripting language on the other hand I would just need to... make my own scripting language, it would necessarily fit into my engine 'for free' and since it wouldn't have its own subsystem running in the background as it were it wouldn't be able to conflict with SDL in any way. Also, using Lua inherently limits the design space of the engine. Again, I didn't spend enough time learning it to know how significant the impact would actually be, but I definitely both don't need all the power that Lua offers and might want extremely specific things that Lua cannot (easily) provide. Off the top of my head, some things I was concerned about were a means for customizing text display via randomly varying font (which isn't something the game currently uses but that I have ideas for down the line) and how easily it would interface with SDL to update config variables. Again, not something I know Lua *can't* do easily, but something that I do know is a non-issue with my own engine. Concerns I'd have about switching now (admittedly colored by what I've already accomplished) are how it would handle the dynamic background system and time-based scripts.

TLDR, it all comes down to opportunity cost of time spent learning how to do things. If I were already familiar with Lua I quite possibly would have made a different decision, but in the end I wanted this to be a project for learning 'how to make a game engine' rather than 'how to integrate Lua into a game engine', and I will save that project for another day.

Also, just for the record, you may be overestimating the complexity of the scripting portion of the engine based on your suggestions. It's not meant to be a fully-featured programming language in-and-of itself, but just a simple human-read/writeable way to encode game-specific logic independent of the engine as a whole. Since I don't think there are any in the project as is currently available, here are a few example scripts, that (assuming the player is in a location called "roomA" with exits left to "roomB" and right to "roomC") plays a crashing sound, and blocks the player from moving left until they've moved right to investigate:

crash:{playSE(crash, 100, 100) wait(50)}_Huh? What was that noise?@I think it came from the right.{setlocscript(roomA, left, nowait, 0) setlocscript(roomB, loc, checksound, 0)}

nowait:Hold on, I should see what happened to the right.

checksound:Oh, looks like a lamp just fell over.{setlocscript(roomC,loc,none,0) setlocdest(roomA, left, roomC, 1)}

'@' means 'wait for player input, then clear the textbox and continue', '_' represents an ellipses, and the part left of the ':' is the name of each of the three scripts. playSE plays a sound effect, modifying the speed and volume of playback, and setlocscript/setlocdest change what happens when you try to go in a direction at a given location to either running the given script or moving to the given location.