Author Topic: The concept of the backroute applied to other purposes  (Read 2681 times)

0 Members and 1 Guest are viewing this topic.

Offline Strato Incendus

  • The King of Shimmiers (crowned by Flopsy ;D )
  • Posts: 1747
  • #RIP Spearer/Grenader (2020 - 2021)
    • View Profile
The concept of the backroute applied to other purposes
« on: November 28, 2018, 11:27:26 PM »
Well, what this seemingly useless hobby of creating fictional problems for fictional little green-haired people can be useful for sometimes :thumbsup: : I'm currently trying to backroute my own stuff.
Not so much my Lemmings levels, though (Arty is taking care of that! ;) ), but my writing.

And indeed I think the concept of the backroute might be a good idea for any hobby writer or similar in order to clear up inconsistencies in their stories:

As someone who is guilty of somewhat enjoying criticising other people's works for plotholes and similar, of course I try to be equally strict with myself - even though it's just a hobby of mine :D . And one thing I've noticed is that a lot of logical missteps in stories arise from overpowered skills or items - kinda like in Lemmings :) .

One famous example would be the time reversal tool in Harry Potter (don't know what exactly it's called in the English original); as soon as an author adds something as powerful as time travel / teleportation / telepathy / telekinesis (funny how these all start with t :D ), that always begs the question: "Well, why didn't the characters use this in situation A / B / C?"

Likewise, in Lemmings, once a skill is on the panel, you must always consider the option of the player employing that skill in a totally different place than you expected them to - and that is just as valid, until you come up with a way to prevent it without simultaneously preventing it from being used in the intended location as well. ;)

Harry Potter example (click to show/hide)

Human beings, both while playing Lemmings as well as in real life, like to take the path of least resistance. Which means, if there is an easier solution to something and it's apparent to them, they will usually use it. In essence, you could consider backroute searching an application of Ockham's razor, always asking the question: "Is there an easier way to do this?"

So it's nothing new, far from it; however, thinking of plotholes as backroutes to intended solutions gave me somewhat of a new incentive to actively try looking for such inconsistencies in my stories myself :D . It feels like a more "scientific" approach, where you actively try to falsify your own claims.



So, why did it take playing a lot of Lemmings in order for me to discover this for myself? :D

Maybe it is due to the more or less established mindset of a backroute in a level being usually regarded as the level designer's fault - combined with the awareness that it is in a level designer's power, and thereby their responsibility, to fix it. With plotholes in stories, in contrast, you often find both the authors as well as devoted fans rationalising the events after the fact, making additional assumptions in order to make excuses. This is because both the loyal fans and, obviously, the authors themselves, have already "locked in" on the intended solution, and now try their best to enforce it.

Hence, in both cases, it is usually easier for level testers / beta readers to discover "backroutes". And I think this is down to the same phenomenon that prevents a level designer or story author from finding it ;) : I've already mentioned functional fixedness and mental set before on this forum - aspects of problem solving which mean that once we found a working solution to a given problem, we have a hard time coming up with possible alternatives.

This affects both level designers / authors and players / readers:
1) The author knows the intended solution, which obviously works, so they have trouble contemplating other solutions that might also work - because it would require them to actively stray from an already successful approach.
2) The reader is presumed to have a natural scepticism that needs to be overcome in order to achieve immersion in the story (suspension of disbelief); if common sense would suggest a less complex and more obvious approach to a problem, and a character still decides to do it in a more complicated way, it's going to ruin the immersion, because usually people don't act this way in real life.
The Lemmings player, likewise, is naturally "lazy" in the sense that he doesn't want to waste more time on a level than necessary. So once he finds a solution that works, there's no need to keep fiddling around to try something else: You find a backroute, you go for it. And then, later, once that backroute has been removed, re-solving these levels is often harder than solving new ones, because now you have to actively bypass the formerly successful approach which you still have somewhere in the back of your head.

Thus, the author can't stop not finding backroutes, and the player can't stop using them if they find them. The reader can't ignore a plothole once it's discovered, and trying to ignore them in order to  re-immerse onself in the story requires active endeavour on one's own part.



The irony is that this mechanism is probably usually beneficial: The Rubicon model makes a clear distinction between considering different options at first, and then, once you have decided on the one you're going to use, initiating action. Meaning: You don't go back to the planning phase anymore ;) . No way "back to the drawing board". I also like to think of this as "putting blinders on a horse before having it move forward" :D .

But backroutes and plotholes fall into the category "what must not be cannot be", and in those cases, you have to force yourself to go back to the drawing board. So for such purposes, this mechanism seems to be disadvantageous.


Don't really know how useful or interesting this might be to anyone of you, but I like discovering such "patterns" by drawing analogies between seemingly totally unrelated fields. Sometimes, these analogies may end up a little too forced. (That's why my brother and I refer to these shitty analogies as analogies :evil:.)

But if I didn't enjoy looking for abstract patterns and ways to connect the dots between them, I probably wouldn't enjoy playing Lemmings either in the first place. So I guess we've come full circle here :D .


Any other "life lessons" you guys learned from playing Lemmings, no matter how arbitrary they may seem? 8-)
My packs so far:
Lemmings World Tour (New & Old Formats), my music-themed flagship pack, 320 levels - Let's Played by Colorful Arty
Lemmings Open Air, my newest release and follow-up to World Tour, 120 levels
Paralems (Old Formats), a more flavour-driven one, 150 levels
Pit Lems (Old Formats), a more puzzly one, 100 levels - Let's Played by nin10doadict
Lemmicks, a pack for (very old) NeoLemmix 1.43 full of gimmicks, 170 levels

Offline Crane

  • Posts: 1079
    • View Profile
Re: The concept of the backroute applied to other purposes
« Reply #1 on: November 29, 2018, 12:53:03 AM »
It's an interesting parallel.  I am a budding writer too, so I have my own thoughts about how my world functions and I do my best to think about a character would react to a situation or how a skill etc. could be abused.

I don't quite equate backroute to a plot-hole, since the concept of a backroute is more about solving a puzzle in an unintended way, such as tunnelling under the walls of a fortified castle, or going through the unguarded back door of a house (my original analogy).

For the Harry Potter example, I think J. K. Rowling tried to explain that the remaining Time Turners were destroyed during the battle in the Ministry during Harry Potter and the Order of the Phoenix, and that witches and wizards seem to be getting weaker with time, with no-one being able to make new Time Turners - the problem here though is that it's supplementary material and J. K. Rowling explaining the fact after the stories were written in an attempt to patch up plot-holes that people have noticed.  Of course, almost no stories are watertight, but it's good to think about "what if" scenarios if you introduce magic or some kind of powerful device.

Sometimes it's also fun to play with tropes, especially if you want a truly powerful villain.  Two of my favourite exchanges, one was from "The Good, The Bad and The Ugly" and the other from the awful "Wild Wild West".

*A one-off villain barges into the bathroom where "The Ugly" is washing and apparently defenceless, and points his gun at him*
"I've been looking for you for eight months, now I have you right where I want you. I've had a long time learning to shoot with my left."
*"The Ugly" instantly guns him down with his gun hidden in the bath*
"When you have to shoot, shoot; don't talk!" (thus subverting the whole 'villain speech' and talking being a free action)

Wild Wild West:

Hero: "I have but one request, that you aim for my heart, the heart that has loved this country."
Villain (to his lackey): "Shoot him in the head."
Hero: "Damn!" (being extremely 'genre savvy' and assuming the hero has a hidden metal plate under his shirt)

And one should never dismiss going back to the drawing board.  Sometimes you have to.  You might have to restrict a power, or redesign a level.  You never know what you might discover or write.  For example, in my story, most characters who can use magic have to take some time to power it up, so soldiers who are used to fighting them just charge straight in before they have a chance to get it off.  I had one enemy soldier do that to my deuteragonist, and I really had to think how the battle would play out to keep it 'realistic' while still having the deuteragonist win, and as a result, it became incredibly exciting (at least I felt it did), involving her pressing her hands against the soldier's breastplate (while pinned to the ground) and summoning fire over time to make it red hot, for example.
« Last Edit: November 29, 2018, 01:10:32 AM by Crane »

Offline Simon

  • Administrator
  • Posts: 3860
    • View Profile
    • Lix
Re: The concept of the backroute applied to other purposes
« Reply #2 on: November 29, 2018, 01:46:41 AM »
Very nice. Also bugs in programs behave like backroutes.

The word "Backroute" is so useful that I already consider the word too long. Chess problem composers call their backroutes "cooks".

The designer has a hard time finding their own backroutes. In the extreme form, Kory Heath (creator of Zendo) considers design itself purely an escape from inadvertent mental lock-ins. Full article: Monkey traps

-- Simon

Offline Crane

  • Posts: 1079
    • View Profile
Re: The concept of the backroute applied to other purposes
« Reply #3 on: November 29, 2018, 02:11:05 AM »
Blame me for the creation of the word "backroute" (or if it existed before, I wasn't aware of it!).  People like words with fewer syllables... "cooks", "hacks"... it seems that "backroute" stuck for this community!

Authors are always at a disadvantage of locating bugs, backroutes or plot-holes and the like because they have intrinsic knowledge of the solution or the inner workings.  With writing, they may forget to put everything to paper; with bugs, they won't use the program in the same way an end user might or think to test a particular function to the fullest (I've consistently triggered internal errors on a compiler before); with a level, it's hard to break away from the intended solution and do something completely left field unless you're forced.

One of my past competition levels had the name "(Part Two)" in the title even though a part one didn't exist - the reason being was because the toolset was 02 02 02 02 01 01 01 01 of the original eight tools, and before the submission phase ended, I decided to set it all to 01 to humour myself... and I ended up solving it!!  So I kept the backrouted version with some minor modifications as part 1, and the patched version as part 2.

When it comes to bugs, it is why SQA is so important (and to give a sad example, I think Activision Blizzard are cutting back here... the latest Co-op commander on StarCraft II had so many bugs upon release, some of which would have been found simply from playing him a few times).  As a developer you're never going to catch everything no matter how good you are, so it's always good to let another developer evaluate your code or otherwise test your program.
« Last Edit: November 29, 2018, 02:23:42 AM by Crane »

Offline Proxima

  • Posts: 4562
    • View Profile
Re: The concept of the backroute applied to other purposes
« Reply #4 on: November 29, 2018, 03:33:40 AM »
Blame me for the creation of the word "backroute" (or if it existed before, I wasn't aware of it!).

It was already in use in 2004, and that topic is now on the very last page of Lemmings Main. No idea if it originally came from other civilisations... I mean communities :P before this one existed.

Time Turners in the Harry Potter universe have a limit of five hours. I accept that this is a "handwave" -- there's no real explanation for why things are this way except that the author needs it to be so for the plot to work -- but it's not a plot hole. J K Rowling has every right to say that's just how things are in her fictional universe.

Actually, I wouldn't use "plot hole" for this kind of situation in general. Humans don't always act rationally. A better (simpler, safer, more reliable) way to achieve our goals might exist, and we might not take advantage of it, through mistaken appraisal of the situation, or simply failing to notice that the other way exists.

(I looked up "plot hole" on Wikipedia, and found this link to a discussion that has a pretty good definition of "plot hole": ...an aspect of the story that goes against the logic set forth by the rest of the plot or the movie’s universe. An inconsistency, like someone’s glass of water changing places throughout a scene, won’t count as a plot hole. Neither will character choices -- a character not making the obvious choice isn’t a plot hole, it’s characterization.)

"Backroute" may be a better term :) It's less judgemental -- we look for backroutes in our own works (whether it's levels or fiction) and we get testers to look for them, but if some escape our notice, it's not necessarily a bad thing.

I'm trying to come up with examples from my own work, but right now I can't think of anything. Maybe I'll come back to this topic some time when I'm less tired :)
« Last Edit: November 29, 2018, 04:27:07 AM by Proxima »