Most appealing game navigation

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.


I am good with 3. type in the directions.

Me too. I have discovered that an excess of one does not compensate for the lack of the other :smile:

1 Like

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.

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.


That’s excellent advice.

1 Like

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.

1 Like

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.


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.

1 Like

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.

Oh, this again? Is that how you did CoG? Because it was much easier than that when I did it. :grin:

1 Like

Sorry that’s been a bother for you. But this is how progress happens.

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 good at both.


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.

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.)

1 Like

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 incremental at best.

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.


Making your own paper out of wood isn’t even all that hard.

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!)

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.

1 Like

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)


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. :slight_smile:

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.

My “for fun” games are basically niche. I think you mean “commercial” games, but that’s not fun for me. Everyone is different.

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.