Working on the S.A.L.A.D. games has given me a lot of Thoughts about Scott Adams format and what it is and is not good at/for. One thing that leaps out in the former column is that it is very, very well-suited for short burst projects because it is easy to get frameworks up and running, there are tight constraints on what you can do with narrative, and it’s difficult to shoot yourself in the foot. So if you’re looking to create a parser SpeedIF game and are bored with your usual language, may I recommend making an Adams format game?
Easy framework: I know that most modern systems have roughly equivalently simple approaches to describing a room and specifying its exits, but it might surprise you to learn just how easy it is in a format designed in 1978. You get very strong support for the basics of N/S/E/W/U/D, taking and dropping items, and very little else. Fast, neat, and tidy.
Tight constraints: There’s valid discussion about the 99 message limit not being strictly enforced on modern SA interpreters, but for ease of use and maximum compatibility, it’s best to impose that limit on yourself. Apart from parser default messages, you can have 99 unique strings displayed to the player. You can reuse them “for free” but you still gotta be careful with them. This will help you limit your ambition, become a 99-message storytelling savant, or find clever ways to expand your narrative with other text delivery like item and room descriptions.
Safe feet: In no way, shape, or form does the SA system ever try to simulate reality. Apart from a very limited number of native parser actions, pretty much every verb/noun combination is a special case you’re deliberately coding for. Frustrating to play? You bet, for all the reasons that have been documented over the past four decades! But as a designer you never run the risk of tripping over some arcane set of resource rules that results in confusing buggy output like
>BREAK WINDOW
(assuming you mean the windshield)
You can't break something with a fish!