Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Maze directions in sugarcane

Hello, all. Somewhat new to the more complex aspects of Twine, and I need some help with a problem I've encountered involving perspective and directional changes. I'm making a maze exploration game, and as it's set up now, each passage is a branching part of the maze, with the player being given multiple options on where to go depending on the layout of the maze (left, right, forward, back). The issue arises when taking into account the perspective of the person. Since directions like right and left are dependent on the person, i.e. if I turn left what was my left is now my forward, it's possible to walk to the same places in the maze but have everything a completely different direction relative to the player. Crude example below:

undefined

And this is the problem: how do I make it so each passage knows from which direction the player entered it so the directional options can be changed accordingly?

Thank you in advance for your help.

Comments

  • Use the degrees in a circle broken into quarters (eg. 0, 90, 180, 270) to track which way the player is facing, if they go right then add 90dec, if they go left minus 90dec, and if they go back (or reverse direction) then add (or minus) 180dec. If the player direction goes below zero then add 360 and if above 259 the minus 360, to adjust it.

    So in your first example the player starts facing up/north so <<set $pdirection to 0>>.
    To get to the position in the second example they would of gone left,right,and about face, so that would be:

    <<set $pdirection += -90>>
    <<set $pdirection += 90>>
    <<set $pdirection += 180>>
    Which results in $pdirection equal to 180, which indicates that the are facing down/south on your maze.
  • On the other hand, you could just use the cardinal directions (north, south, east, west) or stipulate that the player is always facing one direction (north) when s/he enters a new passage.
  • greyelf wrote:

    Use the degrees in a circle broken into quarters (eg. 0, 90, 180, 270) to track which way the player is facing, if they go right then add 90dec, if they go left minus 90dec, and if they go back (or reverse direction) then add (or minus) 180dec. If the player direction goes below zero then add 360 and if above 259 the minus 360, to adjust it.

    So in your first example the player starts facing up/north so <<set $pdirection to 0>>.
    To get to the position in the second example they would of gone left,right,and about face, so that would be:

    <<set $pdirection += -90>>
    <<set $pdirection += 90>>
    <<set $pdirection += 180>>
    Which results in $pdirection equal to 180, which indicates that the are facing down/south on your maze.


    This is very helpful, but how would it all look in an actual passage? I'm trying to put what you posted into a setter link, but I keep getting error messages. I know this is probably horribly wrong. M srry.

    [[Left|debug_left][set $pdirection += -90>>]]
    dacharya64 wrote:

    On the other hand, you could just use the cardinal directions (north, south, east, west) or stipulate that the player is always facing one direction (north) when s/he enters a new passage.


    That's a possibility. If I could help it I'd rather use the other way, but if the maze ends up being too large or too complex I might end up with the cardinal directions.
  • I think the cardinal directions would be much easier cause the broken down in quarters thing does not work
  • TooMuchDog wrote:

    This is very helpful, but how would it all look in an actual passage? I'm trying to put what you posted into a setter link, but I keep getting error messages. I know this is probably horribly wrong. M srry.

    [[Left|debug_left][set $pdirection += -90>>]]


    Well, for one thing, the keyword "set" is not needed in a setter link, or the close-macro-brackets. It should look more like:

    [[Left|debug_left][$pdirection += -90]]
    You also want to use the modulo operator to make sure the values don't get outside the valid range. Although personally I'd just as soon use 0-3 (with a % 4), since you don't need all those between-angles anyway.

    [[Left|debug_left][$pdirection = ($pdirection - 90) % 360]]
    Then, in each maze passage, you could just change the direction in your descriptions. It might be useful to have custom javascript functions for each cardinal direction, like a north() function that uses if statements to print either left, right, front, or rear, depending on the value of $pdirection. If you did that, you would also have to use a function for the direction change, like northChange(), so it could figure out the right direction to change in. Then your links would look more like:

    There is a passage to your [[north()|passage02][northChange()]]
    ...you might also be able to use other passages with the <<passagename>> macro instead of functions, but I haven't tried using that inside of a link.

    If you don't have many unique features in any spaces in the map, you could also just use a single passage, and use an array to keep track of which spaces are connected, and check the array to see which directions are valid. You could probably find some examples in game programming tutorials. That would involve less passages and more javascript code, but you would also not be able to use the visual story view of Twine to view the maze.

    edit:
    Actually, if you do it the above way and every link is explicitly north/south/etc, and you're only changing the words, you don't have to do the add-modulo-thing. Just have $pdirection be a string, then your north() function would look like:

    function north() {
    if(state.history[0].variables['pdirection'] == "north") return "front";
    if(state.history[0].variables['pdirection'] == "east") return "left";
    ..etc..
    }
    And your link:

    There is a passage to your [[north()|passage02][$pdirection = "north"]]
  • Okay, I think I'm beginning to understand. I've written out a simple 3 passage test and it seems to work. Please tell me if I'm completely off base with this or not:
    Passage 1:

    <<set $pdirection = 0>>
    The gates of the maze close behind you. There's only the way forward now.
    [[forward|dm3_1-1]]
    Passage 2:

    <<if $pdirection is 0>> You see a wall in front of you, with a large red X painted on it. The wall stretches out to your left and right as far as you can see. Which direction do you choose?
    [[Left|dm3_0-1][$pdirection = ($pdirection - 90) % 360]]
    [[Right|dm3_1-2][$pdirection = ($pdirection + 90) % 360]]
    <<endif>>

    <<if $pdirection is 270>> The path in front of you seems to go on forever. To your left you can see the maze's gate, to your right you can see the red X.
    [[Forwards|dm3_0-1][$pdirection = ($pdirection + 0) % 360]]
    [[Sternforemost|dm3_1-2][$pdirection = ($pdirection + 180) % 360]]
    <<endif>>
    Passage 3:

    <<if $pdirection is 90>>
    Strange, it's a dead end. You have no choice but to go back.

    [[Sternforemost|dm3_1-1][$pdirection = ($pdirection + 180) % 360]]
    <<endif>>
  • One of the reasons I suggested using degrees over cardinal points is that if you later want to support mazes that allow the player to travel in other directions (like northwest or southeast) then all you have to do is add/minus a smaller number of degrees from the player direction, whereas if you a number range like 0-3 you would have to change your existing code to support a large number range like 0-7.
  • I've encountered an issue with the numbers solution, specifically, going left and subtracting 90 from $pdirection doesn't work. At least how I thought it would. I'll show you what I have. Placeholder text removed to save space.

    <<if $pdirection lt 0>><<set $pdirection to ($pdirection + 360)>><<endif>>
    <<if $pdirection gt 259>><<set $pdirection to ($pdirection - 360)>><<endif>>

    <<if $pdirection is 0>>*snip*
    [[Left|dm3_0-1][$pdirection = ($pdirection - 90) % 360]]
    [[Right|dm3_1-2][$pdirection = ($pdirection + 90) % 360]]
    <<endif>>

    <<if $pdirection is 270>> *snip*
    [[Forwards|dm3_0-1][$pdirection = ($pdirection + 0) % 360]]
    [[Sternforemost|dm3_1-2][$pdirection = ($pdirection + 180) % 360]]
    <<endif>>

    <<if $pdirection is 90>> *snip*
    [[Forwards|dm3_1-2][$pdirection = ($pdirection + 0) % 360]]
    [[Sternforemost|dm3_0-1][$pdirection = ($pdirection + 180) % 360]]
    As far as I can tell all the other numbers work and the directions are fine, but going left never resolves to 270, always -90. Is this how it should be? Did I misunderstand the posts here? is my code flawed?
  • TooMuchDog wrote:

    As far as I can tell all the other numbers work and the directions are fine, but going left never resolves to 270, always -90. Is this how it should be? Did I misunderstand the posts here? is my code flawed?


    Your problem stems from the fact that JavaScript does not, currently, have a true modulus operator.  Instead it has the remainder operator (%), which is subtly different.  So, it would be correct to say that the example you were given was flawed.  I'd suggest the following instead.

    Add this to a script tagged passage:

    window.changeFacing = function (facing, adjustment) {
    facing += adjustment;
    return (facing < 0 ? facing + 360 : facing) % 360;
    };
    Then try the following instead of the sample you posted:

    /% The two <<if>>'s here are intentionally missing, as they shouldn't be necessary if you use changeFacing(). The second one was broken anyway. %/

    <<if $pdirection is 0>> *snip*
    [[Left|dm3_0-1][$pdirection = changeFacing($pdirection, -90)]]
    [[Right|dm3_1-2][$pdirection = changeFacing($pdirection, +90)]]
    <<elseif $pdirection is 270>> *snip*
    [[Forwards|dm3_0-1][$pdirection = changeFacing($pdirection, +0)]]
    [[Sternforemost|dm3_1-2][$pdirection = changeFacing($pdirection, +180)]]
    <<elseif $pdirection is 90>> *snip*
    [[Forwards|dm3_1-2][$pdirection = changeFacing($pdirection, +0)]]
    [[Sternforemost|dm3_0-1][$pdirection = changeFacing($pdirection, +180)]]
    <<endif>>
  • Thank you, TheMadExile  :D This method seems to be working well. I made a small debug maze and it hasn't given me any problems so far.
  • Ah, I wasn't aware of the problem with javascript's % operator. I'm glad TheMadExile was able to point you in the right direction.
Sign In or Register to comment.