18 ms·

A simple adventure with a rudimentary VERB NOUN grammar can be done as a modest BASIC program, as for example in the Usborne Adventure Programs book https://usb

• PaulHoule 4mo ago
  That's a good example of what I'm talking about! You can't write out a "script" for how the game works out the way most of those BASIC games are written. Rather that kind of game is table-driven and complicated by the fact that BASIC doesn't support structures so you can't write those tables in the "array-of-structures" system but rather have to write in the slightly awkward "structures-of-array". In a normal language you would have pointers, in BASIC everything has to be an index into an array. A game like that is "object oriented" in the sense that there are rooms and items that share a lot of common attributes that could fit into an ontology. For the most part these things behave the same (pick something up and it goes into your inventory) with a few exceptions (you need to be holding the cage and not holding the rod to pick up the bird) A game like that can have a few if-then-else ladders in it there are keyed by magic numbers. It is maintenance hell (in a world without unit tests!) though you can take the cope that it is hard for somebody to look at the source code to cheat. Scott Adams put the exceptions entirely into the tables with a very simple and specialized interpreter which was easy to implement in BASIC and also in assembly -- then he went on to make a huge number of games https://en.wikipedia.org/wiki/List_of_Scott_Adams_Adventure_video_games https://en.wikipedia.org/wiki/List_of_Scott_Adams_Adventure_... where the interpreter is the same and the table is different. BTW, the "orginal adventure" was written in an old version of FORTRAN with awkward string handling and arrays but no pointers and uses similar techniques https://en.wikipedia.org/wiki/Colossal_Cave_Adventure https://en.wikipedia.org/wiki/Colossal_Cave_Adventure