@gandalf (Michael) posted a new topic, subject "Most appealing game navigation". It read:

   I am a programmer about to write an IF game from scratch. I will be using c++, php, html,css,javascript,etc.  
    I am trying to understand what is the most appealing game navigation . . .
    
      1. Simple links: “click here to enter the cave”
      2. ImageMaps: You click on a picture of a scene to go somewhere
      3. NLP: you say “go north”
      4. Automatic : computer changes rooms, based on what you do. “Cut the rope” – you fall down the cliff.  
    The reason I am not using Twine and other tools, is because I have huge computing power in several rack servers, and I am a very experienced programmer.
    
    
    
    My main weakness is in story telling (its so right brained !) , and knowing what would be most interesting in a 2022 version of the Infocom games.

So @fos1 replied

    I am good with 3. type in the directions.

After which, @tundish added

    gandalf:
    
    > I am a very experienced programmer.  
    >  My main weakness is in story telling
    
    Me too. I have discovered that an excess of one does not compensate for the lack of the other

To which @dfabulich (Dan Fabulich) replied

    gandalf:
    
    > I am a programmer about to write an IF game from scratch.
    
    I, ah, probably can't dissuade you from doing this, but I generally do like to _try_ to dissuade folks from doing it this way.
    
    Modern IF is normally implemented in a “development system,” e.g. Inform or Twine. What you're doing, by building a game from scratch, is forcing yourself to _both_ develop your own dev system _and_ write a game, all on your own.
    
    By analogy, what you're describing is like saying, “I want to write a book, so I'm going to mill my own paper.”
    
    (Or, maybe more accurately, “I know C++, so I'm going to write a web site in C++, without using _any_ libraries; I'm going to write _all_ of the code myself. I'll write my own threading library, my own HTTP library, my own TLS implementation, my own forms parser, etc. etc. Maybe I'll even design my own programming language to write it in!”)
    
    You _can_ do that, if it's fun for you to do so, but that's not going to be the best way to make your thing.
    
    Instead, learn the dev system that your favorite games use. It sounds like you like Infocom games. You can learn to implement them in Inform, or in the language they originally used, ZIL. Try some of the top-rated games on IFDB and see what you like. https://ifdb.org/search?browse
    
    If your goal is to develop your own IF game, but you're struggling to come up with story ideas, your best bet is just to play a lot of games, taking notes about what you like and don't like. Puzzle ideas will come to you. (“What if I started with the puzzle from X but made it act more like this puzzle from Y…?”) A story idea will probably emerge, too. Then, try implementing a puzzle as part of a game jam or IntroComp.
    
    But, if you insist on starting from scratch…
    
    Generally speaking, for coders who want to develop their own dev system but who lack the storytelling experience to write their own game, I don't recommend that you start by implementing your own game at all, but instead _port_ an existing game from its original source into the dev system you want to make. Emily Short's Bronze is licensed under a Creative Commons license, and Bronze's source code is available online. You could port that to a dev system you designed, to prove your system.
    
    That's how I got started designing my own first game. I first ported Alter Ego to a modern programming language, then, on the basis of that, I wrote my first game, Choice of the Dragon, in my own dev system, with friends, who were stronger creatively.

So @tundish replied

    dfabulich:
    
    > _port_ an existing game from its original source into the dev system you want to make
    
    That's excellent advice.

@tobiasvl (Tobias) replied

    If your weakness is story telling, why do you want to make an IF game? I don't mean any offense by that, but do you actually want to make a game, or do you want to make a game engine? Your motivation isn't clear from your post (having a lot of computing power isn't really a motivation, and compiling an IF game isn't likely to require several rack servers).
    
    But, of course, making a game engine can be fun in itself! For sure. I hang around in other hobbyist communities for regular “video games”, and what @dfabulich is saying is often repeated there, in different ways. A common one I've heard is “If you want to make games, use an existing game engine. If you want to make game engines, make a game engine.”
    
    Making a game engine and making a game are two very different disciplines. Of course, if you do end up rolling your own (which is harder than it sounds like, even for interactive fiction), be sure to make it reusable (as a library, a full fledged development system, or something) so you can create multiple games in it, or so other people can use it too. To show it off, eating your own dog food, ie. making a game in your own system, is important (but for that you can port an existing game, as @dfabulich said).
    
    Just be aware that it's going to take a lot of polishing to have your own engine support all the features people have come to expect from established engines. If it's missing stuff, doing common things in idiosyncratic ways, or require lots of hoops to install (as we've seen with recent homebaked Python entries in IF competitions), players are likely to be very frustrated.

To which @gandalf (Michael) replied

    Thanks All ! Great suggestions. You are right, a ‘normal person' would either create a game with an existing game engine, or just write a game engine. But I'm just doing it for fun. I have programmed for 57 years, and now retired (finally), I wanted to create a story, then create an engine customized specifically for the game. It more an exercise in keeping my brain working, by making a great challenge, for myself.  
    For me, its the path, not the arrival.  
    This is a great forum ! Thanks.

So @AmandaB replied

    The most appealing way to navigate really depends on the format. Would you want to make a choice game? Parser? A combination?
    
    I know a lot of people who would play more parser-based IF if it weren't for the directions. And it's true that this is one of the least immersive features of parser-based games. After all, nobody IRL thinks, “I'll go north!” when they want to go to the bedroom. A neat trick would be to have a parser game with a clickable compass that had room names instead of cardinal points. So you could click on the top compass point to go to the bedroom, the bottom one to go to the kitchen, etc.

Then @gandalf (Michael) said

    Thanks AmandaB, great suggestion. Its a big help to talk to people who play/create games. I have just emerged from corporate business programming, and the only games I've ever played were the InfoCom games, when they came out.

To which @ramstrong (Harry Hardjono) replied

    dfabulich:
    
    > By analogy, what you're describing is like saying, “I want to write a book, so I'm going to mill my own paper.”
    
    Oh, this again? Is that how you did CoG? Because it was much easier than that when I did it.

After which, @tundish added

    tobiasvl:
    
    > as we've seen with recent homebaked Python entries in IF competitions
    
    Sorry that's been a bother for you. But this is how progress happens.

@AmandaB replied

    I suggest you play a smorgasbord of newer games, then, to see what other folks are doing, since things have definitely evolved since Infocom. An excellent place to start would be picking games of different formats from the 2021 IFComp.
    
    I particularly recommend @nilsf 's _The Libonotus Cup_ (5th place), as it's a custom engine that incorporates both choice and parser, and is really elizabeth03@example.com.

@dfabulich (Dan Fabulich) replied

    AmandaB:
    
    > I know a lot of people who would play more parser-based IF if it weren't for the directions.
    
    Getting back onto the actual topic of this thread, IMO not enough people have played Blue Lacuna, and I'd love to see more parser games like that.
    
    IFDB
    
    ### Blue Lacuna
    
    You have always been different. One in a trillion have your gift, your curse: to move between worlds, never settling, always alone. To Wayfare. Yet there are others like you, and something stronger than coincidence binds you together, bumps your...
    
    For most of the intro section of Blue Lacuna, it plays more like a Twine game, with words highlighted in blue that the player just types, without a verb. Instead of `examine nightstand`, you'd just type `nightstand`. Instead of `go west` or even `go doorway`, the doorway is highlighted in green, and you'd type `doorway`.
    
    Only after a few dozen turns does the game even tell you that you _can_ use verbs, and the game never mentions compass directions until you pick up a compass in Chapter Two. (But the compass directions work just fine, if you guess them. You can `go west` from the starting room, and it works fine, just as if you'd typed `doorway`.)

@DeusIrae (Mike Russo) replied

    tundish:
    
    > tobiasvl:
    >
    >> as we've seen with recent homebaked Python entries in IF competitions
    > 
    > Sorry that's been a bother for you. But this is how progress happens.
    
    You seem to have interpreted this as snark, but I'm not sure it was intended that way and I think this is a really, really critical point. I've seen you and others make the case for Python as a significant part of the future of IF, and putting on my author's hat, I can very much see the appeal. But putting on my player's hat, things look much less sunny, because for much of the current IF audience experience of setting up and running a bespoke Python game right now is slightly-irritating at best and a potentially-insurmountable barrier at worst (look at the number of votes the very fine Walking Into It got in last year's IFComp compared to its similarly-placing and similarly-reviewed peers).
    
    For those of us old enough to remember wrestling with HIMEM.SYS files it's easy enough to discount these issues, and there are definitely enough good Python games trickling out to be worth the annoyance. But until it's as easy to play them as it is an Inform or Twine game, I fear any progress Python makes towards a preeminent position in IF is likely to be elizabeth03@example.com.
    
    Back on the topic of most appealing navigation systems, I guess it's hard for me to assess in the abstract? To my mind, the main question is whether the navigation approach fits with the rest of the game. This plays out both in terms of gameplay – should it be possible to zoom between locations, or is it important for the player to walk through the path to see time-sensitive events or changes, for example? – and also interface – hopefully what I need to do to move around is sufficiently similar to what I need to do once I'm where I need to be so that switching between these modes doesn't feel clunky. So I wouldn't start my design process here.

After which, @dfabulich (Dan Fabulich) added

    ramstrong:
    
    > dfabulich:
    >
    >> By analogy, what you're describing is like saying, “I want to write a book, so I'm going to mill my own paper.”
    > 
    > Oh, this again? Is that how you did CoG? Because it was much easier than that when I did it. 
    
    Making your own paper out of wood isn't even all _that_ hard. https://www.ehow.com/how_4480942_make-paper-from-wood.html
    
    But I'd especially caution someone from saying, “I'm a competent baker who wants to write a book. Paper milling is basically just crushing and blending wood chips, and screening them out into a baking pan. So, I'll start by milling my own paper. Even though I've never milled paper before, it can't be that different from sifting flour and baking a cake.”
    
    I mean, I get it, it's just for fun, so do what's fun for you. But I think you'll find that most of the fun of making IF is having an audience enjoy your work. Designing your own dev system just delays your rewards, making it harder to stay motivated to finish.
    
    (Writing a book is challenging enough even _without_ milling your own paper!)

So @DeusIrae (Mike Russo) replied

    I definitely agree that keyword-navigation can make IF more accessible, but I think it's also important to keep in mind the degree of spatial complexity if you take this route. For example, I enjoyed Beneath Fenwick in last year's Comp, which had a fun choice-based interface over more parser-y gameplay that I thought worked well, except when it came to exploring the large boarding-house: because there were so many connections, and it wasn't always clear which locations were next to which other ones, I found it really disorienting in a way that I don't think the author intended.
    
    This is an easier problem to solve than making the traditional Infocom-derived parser more newbie-friendly, of course! Beyond ensuring the map doesn't get too complex, it's easy to have compass directions as optional information, or a visual map or other aid to understanding how the pieces fit together. But just wanted to flag that keyword navigation isn't necessarily a panacea to this issue if the rest of the design doesn't support it.

So @DeusIrae (Mike Russo) replied

    AmandaB:
    
    > After all, nobody IRL thinks, “I'll go north!” when they want to go to the bedroom.
    
    My sister and I actually once got in a fight because we were trying to meet up – this was in pre-smartphone days, actually we were going to see Return of the King together – and I kept saying “I'm on the north side of the street just by the subway exit at the southeastern corner of the park, where are you?” while she was saying “I took a left by the bagel place and I'm right by the CVS, where are you?”
    
    (We missed the movie)

Then @jkj_yuio (jkj yuio) said

    Firstly, i don't think there's anything wrong with writing your own engine. I don't disagree with anyone's points here against doing that, but i would say; how else are we going to get to the future of IF. 
    
    Regarding the questions, here are my thoughts:
    
      1. I've tried mapping navigation onto choices. It works quite well, although the drawback is that if you're using choices for other things, you can wind up with quite a few choices appearing at the same time. So then you have to have a way to prioritise them.
    
      2. Is what everyone really wants. Although there are several usability problems with visual maps. Especially on small screens, you can't have both the map and the text at the same time. You'll find you'll be switching between them all the time and this gets annoying. I had the idea of building a “mini-map” that overlays a corner of the text. Maybe that could work. On large desktop screens maybe you can have both windows open.
    
      3. This means you have to mention in your game text the exits and their compass points. For modern stories, this looks very unnatural. If the compass direction can be inferred from, say a visual map, then why not just use (2). Also die-hards will always want (3) in addition to whatever other mechanism you have.
    
      4. Can work well in certain circumstances, but is not a general solution.

@ramstrong (Harry Hardjono) replied

    dfabulich:
    
    > But I think you'll find that most of the fun of making IF is having an audience enjoy your work.
    
    My “for fun” games are basically niche. I think you mean “commercial” games, but that's not fun for me. Everyone is different.

After which, @ramstrong (Harry Hardjono) added

    1 & 2 are the same, except one is textual; the other, graphical.  
    3 & 4 are parser, with automatic action on certain player's action.
    
    It depends whether you're trying to build Choice (1), PNC(2), or Parser(3&4).
    
    I suggest #1, unless you or someone you know are good at making pictures. If so, #2. We need hypercard like engine, since hypercard went out of style.

To which @HanonO (Hanon Ondricek) replied

    Since you're programming it, could you use multiple navigation methods and let the player choose?
    
    If you have an image, they could click on the image map but you could also include links to click like ‘go north' or ‘enter the castle'. They could be simultaneously available, or you could let the player choose in settings whether they click on a map or have the directions spelled out in choices.

To which @AmandaB replied

    DeusIrae:
    
    > (We missed the movie)
    
    This is exactly why I saw all 3 LOTR movies alone. I had waited since I was 8 years old for them, and I was not going to have anybody eff it up for me.

Then @jkj_yuio (jkj yuio) said

    for (2) it's not actually making the map that's the problem - there's a whole bunch of map drawing software out there that you don't have to be a (good) artist to use.
    
    Unless you have a game where you're prepared to give the player the whole map upfront, you need a way to make the map appear _as you explore_. This means it's not just a simple picture with box click regions.
    
    I tried making some maps like from pictures and, unless the layout is very regular indeed, you wind up needing to cut the picture into polygonal areas. Then you need a way to draw a polygon at a time and do polygonal click-region testing. None of this is too difficult, but it's there.
    
    Then there's whether you'll need to zoom the map. Does it mean you just draw a _really_ big picture, or perhaps a vector image. This is another thing to decide.
    
    I agree, option (1) is a good start.

To which @kamineko (Drew Cook) replied

    So far as parser games go, _Hadean Lands_ is the best traversal I've seen.
    
      * Explore the map one room at a time as in traditional IF.
      * Return to already-seen locations, items, and features with “go to.” Being able to recall locations and objects makes this amazing.
      * If there is drudgery–for instance manipulating a complex lock each time the player visits a room–the game handles it automatically once a problem is solved.
      * Also: going in the wrong direction gives feedback about valid exits.
    
    
    
    It's really, really good.
    
    I have no real opinion on graphical games. It seems if that approach is well-developed, it begins to feel like a hybrid, p&c, or even a walking simulator.
    
    All of which can be great, I just haven't given the subject enough thought.

To which @FriendOfFred replied

    I really _don't_ think “commercial games” is what was meant - commercial IF is itself a tiny (in fact barely existing) niche, but it's true for almost all IF authors that audience response and engagement is a crucial motivation. That's why IFComp gets so many entries, some of which aren't really suitable for IFComp: it's the best way to find an audience.

So @FriendOfFred replied

    The best game navigation system can't be chosen in a vacuum; it depends what kind of game/story you want.
    
    gandalf:
    
    > Simple links: “click here to enter the cave”
    
    This is really good for games that are primarily about exploring a _story_ space rather than a _physical_ space, if that makes sense. Most games like this don't have elaborate inventory systems or open-ended areas where many different actions are plausible.
    
    > ImageMaps: You click on a picture of a scene to go somewhere
    
    I wouldn't do this unless you're equally as passionate about the artwork/visual design end of things as the programming. If creating all those images sounds tedious (which I would sympathize with!), better to skip it.
    
    > NLP: you say “go north”
    
    As others have said, creating a text parser from scratch with all the features players of modern IF expect would be a _lot_ of work. But perhaps you can think of interesting ways to use a more limited parser. There have been many experiments along these lines. I'm curious to see what would happen if you tried developing one independently.
    
    > Automatic : computer changes rooms, based on what you do. “Cut the rope” – you fall down the cliff.
    
    I'm not sure I fully understand this one - it sounds like navigation would be out of the player's direct control, and the player would try doing various things to move around, but perhaps not know the exact result in advance? That could be either really interesting or really frustrating to play.

After which, @ramstrong (Harry Hardjono) added

    FriendOfFred:
    
    > I really _don't_ think “commercial games”
    
    Will it help you to understand what I mean if you think of it as _art house_ vs. _blockbuster_ movies? The shifting emphasis just means you misunderstand.
    
    I'm not going to explain it to you. Either you get it or you don't. We have had some discussions about this, where people are seeking outlet for Fringe IF, and finding none.

Then @FriendOfFred said

    No, I think I understand you - I just think you're wrong. Niche games have a smaller and more specific audience, but, usually, the authors still need their games to find that audience to make the whole process satisfying. That's true for art house movies as well. Lots of films are made with no expectation of making a hundred million dollars at the box office, but all films are made in the hope of finding _something_ from the audience - some kind of critical apprecation or pleasure.

So @tobiasvl (Tobias) replied

    DeusIrae:
    
    > tundish:
    >
    >> tobiasvl:
    >>
    >>> as we've seen with recent homebaked Python entries in IF competitions
    >> 
    >> Sorry that's been a bother for you. But this is how progress happens.
    > 
    > You seem to have interpreted this as snark, but I'm not sure it was intended that way and I think this is a really, really critical point.
    
    Definitely not meant as snark! Sorry for being unclear and/or snarky, @tundish – it was just a recent example of what I was talking about.
    
    And yes, progress often requires growing pains, and submitting games made in WIP engines is a good way to stress test the engine as well as the game, but I think beta testing before submission is important in those cases. (Not saying you didn't do that, speaking generally here.)

Then @StJohnLimbo said

    “ **tl;dr** ” for my post: provide for compass directions with abbreviations (N, NW, …). GO TO as optional addition.
    
    * * *
    
    DeusIrae:
    
    > interface – hopefully what I need to do to move around is sufficiently similar to what I need to do once I'm where I need to be so that switching between these modes doesn't feel clunky
    
    I'd like to emphasize Mike's point here.
    
    If you want to make “a 2022 version of the Infocom games”, as you said, that sounds as if you're aiming for parser-based gameplay.  
    That implies that the players will enter at the very least the _non_ -movement commands on an input line, their hands not leaving the keyboard. (Unless you are building an entire textual point-and-click UI, or a UI like the Legend Entertainment games where you can choose between direct typing and building your commands by clicking on menus.)
    
    Since the players will spend much of their time on the keyboard, it would be clunky to force them to use the mouse for movement.
    
    So, assuming now that movement by typed commands is the expected default, the question arises which form it takes: compass directions or location names.
    
    If you want to leave out the compass directions in your game for artistic reasons, that's of course a valid choice; and I've seen it work well in some games, where it did seem to contribute a bit to the immersiveness of the prose.  
    But since you're also designing an engine, I'd recommend to build in the facilities for the standard compass commands.
    
    For adjacent and nearby locations, it is quicker and easier to type “N” or “SW” (be sure to provide those abbreviations!) than to type “CONSERVATORY”, “CHAMPS-ÉLYSÉES”, “AN(A)ESTHESIOLOGY” (department).
    
    Plus, the compass makes it easier for many people to build a mental map, as Mike already hinted at.
    
    GO TO is a very nice and useful addition when the map is large and the player wants to get to a far room, as in _Hadean Lands_ mentioned above, or in Eric Eve's games like _Nightfall_.
    
    Here's what _Nightfall_ provides, quoting from the help text:
    
    > "Nightfall takes place in a city the Player Character knows well; he's lived there all his life and so has a far better knowledge of the local geography than the player begins with. To help bridge this knowledge gap you can use the command GO TO X or FIND X (these mean the same thing) to go either to a named destination or an object the player knows about. This command will take the player character towards his destination one step at a time. To continue towards the destination, use the CONTINUE command (which you can abbreviate to C). Note that the CONTINUE command can be used after any number of intervening commands, including explicit compass-movement commands.
    > 
    > The exit lister in the status line shows a list of directions you can go in from your current location. Any directions in upper case indicate directions to locations you haven't yet visited."

@gandalf (Michael) replied

    Great thoughtful response thanks.  
    Item 4: **computer changes rooms.** means that in addition to the normal game navigation, conditions in the game (ie. FSM) can change Room description, links, or automatically transport to a location that normal navigation can't get you there. (ie. If you are in the cellar, and drop your candle, and the floor is covered in gasoline, the current room is deleted, and you end up in ‘heaven'?
    
    Great ideas here:
    
      1. Use more than one NAV strategy
      2. Use different NAV for different situations, as needed
    
    
      * Note: my effort is just for me, my family and relatives - I'm not planning on selling it.
      * I plan on creating a complete story, with outlines, maps, story boards,etc. BEFORE doing any coding. Although many functions will be reusable in other games, I'm not trying to program a general purpose engine.
      * I need to play some of the games and read some of the stories you've mentioned. That will help me a lot !

Then @gandalf (Michael) said

    For text entry, I plan on having a Lexicon, consisting (for one thing), a huge synonym table. take= pickup, acquire, grab, , , ,etc.  
    (I realize this will be a huge effort, but for me thats fun).

@ramstrong (Harry Hardjono) replied

    gandalf:
    
    > I plan on creating a complete story, with outlines, maps, story boards,etc. BEFORE doing any coding.
    
    Wow. You really are an expert programmer, aren't you? Glad to see another one who knows the value of Design Document. Most people just point at the code and say “There's your documentation!”, which is false, even in Python!
    
    Thank you for saying it. And you're right. We artists create things because we **need** to. Not because we want to be popular. Or, at least, I do, lest I go insane. Please put me in as beta tester, assuming your program runs on Raspberry Pi. Thanks.

To which @gandalf (Michael) replied

    I just checked out ‘Blue Lacuna', its demonstrates the value of well written narrative vs images. The imagination is powerful, if the author is good.

@gandalf (Michael) replied

    Good Point !

So @HanonO (Hanon Ondricek) replied

    StJohnLimbo:
    
    > Since the players will spend much of their time on the keyboard, it would be clunky to force them to use the mouse for movement.
    
    That's a great point. Switching between keyboard and mouse can be a bummer. I think I have played games with text input and a compass rose to click on for directional navigation, and once I'm on the keyboard I ignore the compass rose completely, opting to type N, NW, etc.
    
    Dialog has a mode where the game can be played by clicking or typing, and it always works best with one or the other instead of switching back and forth.

To which @tundish replied

    @tobiasvl No snark intended or detected over here 
    
    DeusIrae:
    
    > I fear any progress Python makes towards a preeminent position in IF is likely to be elizabeth03@example.com.
    
    I'm not wishing necessarily for _preeminent_. Right now I'd like to claim _credible_ and hope we can incrementally achieve _popular_ by about 2030

After which, @fos1 added

    Until Python can be credibly compiled, it will always be inferior in this domain, particularly in education. Public school administrators (Admin and IT) will always be very restrictive with apps that can be installed on general use school computers. Having to include Python with an IF story complicates that a lot. I was able to circumvent that policy somewhat by providing computers that were not tied into the school network in any way.
    
    The indentation function delimiting among other things including dynamic typing make Python difficult to write code with. I guess it is better than BASIC and Pascal…
    
    YMMV

After which, @tundish added

    I feel like I'm banging my drum too much, so I will step back from the forum for a while…  
    This is to articulate my current thinking. After that I will shut up for a bit.
    
    Ponder for a moment the physical phases; solid, liquid, and gas.  
    Oh, and also recognise that's an incomplete model. Glass feels like a solid but ancient church windows are witness to the fact that it flows under gravity.
    
    What's solid in IF is the Z-machine VM. Built from that is Inform 7. There is a community of very dedicated conservators who preserve the operation of that paradigm in the face of the 21st century forced march of tech gimmickry.
    
    In liquid form flow Twine and Ren'Py. They are flexible; they can adapt. They twinkle. That appeals to young authors, who seek fun in offers of wordy happiness.
    
    Billowing overhead is the type of thing I seem to be doing right now. A way of bringing stories to the web, and interactivity to a screenplay.
    
    My thing is a gas. It's nuts. I am not at all qualified to attempt it. But that's how I am spending my time.  
    Imagine Bandersnatch on a Raspberry Pi, with the best text parser ever implemented.
    
    I'll be back when I have something to show you.

@HanonO (Hanon Ondricek) replied

    2 posts were split to a new topic: The States of Matter

After which, @smwhr (Ju/) added

    This is probably a question for another topic, and I may be missing something, but Ren'py has been distributing python apps for years without making anyone install any external library. Isn't this something you can leverage ? (Not that I believe that python can change anything to the future of anything anyway)

To which @Alianora_La_Canta (Alianora La Canta) replied

    Ren'Py currently runs on Python 2. Unfortunately, even though the code apparently exists to put in significant Python 2 programs into Ren'Py, I'm not yet good enough at Ren'Py to actually make the process work.
    
    (It's completely useless for native Python 3 until a version is released that is based on Python 3. That's been in development for a long time - it will be called Re'Py 8 when it's done - but for now, anything on the current version of Python would have to be downgraded before attempting to put it into Ren'Py.)

@billmaya (Bill Maya) replied

    @gandalf As someone with 25+ years of software development experience, some who has flirted too long with custom engine development (Storytron), and someone who just wrote their first interactive fiction game for Parsercomp 2021, I would recommend that you take another look at Inform 7 (you did mention “a 2022 version of the Infocom games” in your original post).
    
    I think you will find Inform 7 is a very powerful programming language that will provide you with a great deal of technical satisfaction. While its natural language syntax and grammar can seem strange at first you will find the familiar data and control structures like If/Then/Else, While/EndWhile, etc. underneath.
    
    My own experience with Inform 7 over the past year and a half has provided me with a variety of technical challenges and much personal satisfaction.
    
    While rooted in the parser-based world there are numerous Inform 7 extensions, written in the language itself, that let you modify how it looks, behaves, and operates. I am currently working with Eric Eve's Conversation Framework and Jon Ingold's Flexible Windows (see screenshot below).
    
    I'm so captivated by Inform 7 right now that I'm considering one of two side projects—an updated version of @Ron_Newcomb's Inform 7 For Programmers or a refactor of @DavidC's FyreVM (haven't decided which yet or reached out to either individual).
    
    The upcoming open source of Inform 7 also offers the exciting possibility of using Inform 7 as a narrative engine. I find that idea very exciting.
    
    Of course, for a software developer, the allure of writing your own game engine is a powerful one (I still feel it myself from time to time). If you decide to go that route I wish you the best of luck.
    
    But I hope you give Inform 7 another look.
    
    image2294×2596 425 KB

So @gandalf (Michael) replied

    Thanks Bill, Good advice, I will definitely check it out. I'm always open to suggestions, because programming is ‘like a box of chocolates' !!
    
    YES !! You are right ! (for me) Inform 7 is a perfect place to start. I spent a few hours reviewing some tutorials. Most tutorials say that you don't have to know programming to use it. But of course, you are programming it, just using a high level lang (close to english), but the structures are the same  
    For example: Bedroom is a room. (same as string bedroom), the instructions are sequential, and can obviously follow the basic structured programming concept of 1 input, 1 output per routine,etc.  
    . . .Anyway for me, it does two important things, lets me get right into the story, and keeps me thinking logically. (not easy for a 75 yr old  )


{'source': 'discourse', 'url': 'https://intfiction.org/t/most-appealing-game-navigation/54526', 'title': 'Most appealing game navigation', 'views': 602, 'has_accepted_answer': False, 'word_count': 5981, 'like_count': 63, 'reply_count': 28, 'participant_count': 16, 'posts': 44, 'tags': '', 'author': '@gandalf (Michael)', 'participants': '@gandalf (Michael), @fos1, @tundish, @dfabulich (Dan Fabulich), @tobiasvl (Tobias), @AmandaB, @ramstrong (Harry Hardjono), @DeusIrae (Mike Russo), @jkj_yuio (jkj yuio), @HanonO (Hanon Ondricek), @kamineko (Drew Cook), @FriendOfFred, @StJohnLimbo, @smwhr (Ju/), @Alianora_La_Canta (Alianora La Canta), @billmaya (Bill Maya)', 'image_url': [None], 'created_at': '2022-02-10T20:33:02.523Z', 'last_posted_at': '2022-02-14T22:49:51.474Z'}