Inform 7 supports stats if you code them or get code for them. Kerkegrip is a complete roguelike and is something I can't consistently spell. The reliques of tolti-aph is another, intended in this latter case as an intermediate to advanced programming example. There are extensions for floating point and decimal math if you need it.
The z-machine is interesting. Back in the day, (I believe) Infocom released Zork. I can never remember the company names for a certainty. But this was before X86 and, if you wanted to get a wide userbase, you had to port your stuff to tens of different platforms. So they decided to invent their own computer. But speed didn't matter because these weren't realtime, so they didn't have an actual need to implement it in hardware. instead, they coded a software simulation of it and ported that simulation to all the platforms they wanted to support. The stuff in .z5 files and which is produced by at least half the IF development systems is z-code, a type of assembly language that runs on this platform.
Now, that probably seems like a big digression. But it's not. They handle saving in exactly the same way that Windows handles hybernating: spitting out a copy of the simulated RAM and simulated registers and simulated everything to disk. Modern z-code and glulx are the same way, but provide some more stuff for multimedia--you can get sounds and graphics in the game to some extent if you want. The save command is implemented in the interpreter and is another thing you get completely for free.
As for the parser, no, no you can't. This is something that is hard and it is also something that is hard to explain to new programmers. Even something on the order of what modern Lpmuds provide is difficult, and interactive fiction goes a lot further. You have to be smarter about it-you have to write your program to know what a verb is and what a noun is and to have rules for figuring out when the first and second noun ends. most verbs do not need 3, fortunately. The way I'd do it is build a struct containing a verb, a noun, and a second noun; build a function which splits a string in that manner; build a function which tries to convert a noun to an object; build a group of functions that take completely resolved action structs, one for each verb; and then use an associative array to look them up. An associative array is just an array of structs with a key and a value conceptually, though in practice most languages which provide them implement them as a hash table or a tree of some sort. The total amount of code for this functionality alone, however, is going to top 500 lines. Otherwise it is going to be pretty pathetic in comparison with an actual IF parser. But how you are doing it now simply will not scale.
I hate to go here because everyone decides to jump in with "no you don't" when I do, but you almost certainly will have an easier time with a language supporting inheritance. In such a language, coding rooms to handle commands that happen in them is easier, and you can make special locations that check for things. This is probably the simplest (as in least complex and least lines of code) way to get an approximation of the kinds of things you are going to need to be able to do. If you really want to do this in a general purpose programming language, you need something that can handle special cases without requiring you to wade through a hundreds-of-lines function to find the specific one you're interested in, etc. Implementing inheritance in Purebasic can actually be done at least to some extent, but it's not something I'd suggest trying to figure out as a learning project, and it's going to be pretty ugly to use. The reason that Purebasic works for other types of games at all is because those other types of games have maybe 5 or 10 types of objects and few to no special cases, so the fact that you don't have the compiler on your side with class and inheritance support doesn't hurt as much. But interactive fiction is almost completely special cases. That's basically the whole point. And when you get stuff like that where you need one object to be just slightly different from every other object of its type, inheritance comes into its own; it replaces what will be hundreds of if statements.
As for Python, yes, you have to indent. But you should be indenting anyway, at least if you don't want sighted people to look at your code and declare it unreadable. And there will quite possibly come a day when you'll be doing it anyway because it helps you with those functions that nest five or six levels deep. Everyone considers it an odorous thing at first, even myself. But then you do it and it becomes automatic. You can choose something else if you want to look at leaving PB, but I promise that indenting is not anywhere near the big deal you think it is at the moment. The rule that most blind people use is indent by one tab wherever you'd usually put a left brace and unindent by one tab wherever you'd usually put a right brace; Python is not prescribing an indentation scheme so long as the one you use is consistent. You can also find editors that will remove the burden of manually pressing tab all the time; in such a case, it becomes press tab instead of left brace, press shift+tab instead of right brace, and otherwise just type normally.
And finally, have you played any interactive fiction? I feel like you're not understanding what it actually is. Counterfeit monkey is good if you like clever plays on words, and I'm sure that you can find other games. Curses is interesting, but only if you have a walkthrough on hand. The thing is that interactive fiction is not usually about the programming. It's usually about the writing-people like Emily Short are spending maybe 80% of the time writing and planning and the other 20% programming whatever few game mechanics are unique to the game.
I mention this because it looks to me like you are thinking along the lines of a single-player mud. Your generalizations are tending in the direction of what I see in mud codebases, which are ironically much easier in a lot of ways than what you need for a high quality interactive fiction title. The only thing that carries a single-player text game is the story and the quality of writing, with a secondary emphasis on having a super clever game mechanic (Kerkegrip, which I can at least spell consistently if incorrectly, shows this latter point). Counterfeit monkey has both. But nothing else carries your game. Nothing. Inform 7 is close to art because Inform 7 is about writing an interactive fiction title, not coding the quite frankly huge codebase needed to write an interactive fiction title. The entire language of I7 is about coding special cases. New game mechanics just happen to be special cases that apply everywhere. The entirety of every other language we're discussing here is about abstracting special cases into general cases, because that's what typical programming is about if you do it right. And this is why I say use I7. Stats aren't anywhere near as important to an interactive fiction game as good fiction and puzzles, and good luck with either of those while you figure out your engine. Just about the only way to do this is to essentially build your own I7, or at least an I6 (I6 looks like a more traditional programming language, but has a really huge standard library aimed specifically at IF development).
My BlogTwitter: @ajhicks1992