I’m making a game that takes heavy inspiration from Zelda games like Ocarina of Time, Wind Waker, and Twlight princess, i.e. OoT-lineage Zelda as opposed to BotW & TotK and games that stem from Link to the Past. It’s not a fan game, of course, but if you like OoT/MM/WW/TP/SS, then you’ll (hopefully) like my game.

One central aspect to nail is the camera system these games use. There’s some variation, so I’ve picked one to “clone.” I’m basing this camera off of Wind Waker’s. It has a default mode where Link runs around the camera with left and right and pushes/pulls the camera with up and down. If you wait long enough, the camera will move to be behind him, and of course there’s a Z-targeting mode that will force the camera to move behind him and let him strafe. Finally, there’s a free camera mode that works like the camera in a lot of modern third person games.

In terms of movement, there’s walking and running, but jumping is relegated to hopping across short gaps in these games, and I’ve implemented that system as well.

  • @KindaABigDylOP
    link
    English
    2
    edit-2
    1 year ago

    Is this what you’re doing here as well

    Not at all. I don’t have wall clipping support set up yet at all! It’s a lot more simplistic. I’ve handled wall clipping in a similar camera system before using a SpringArm, but I don’t think that will work here.

    What I do here is I have one object that follows just the camera’s y rotation, and I use that to get a forward vector using -object.basis.z.normalized() and I set a target position at player_pos + -forward * FOLLOW_DISTANCE + Vector3.UP * FOLLOW_HEIGHT and lerp to there. That handles moving with the player forward and backwards.

    Then in the player code, I read the stick input into Vector3(x, 0, y) and then rotate it based on the camera’s y rotation to put it into screen coordinates. Then I multiply by MOVE_SPD and set velocity.x & .z to the x and z of the product. This makes the player move forward and back with relation to the camera’s forward and back.

    However, you move left and right based on the tangent of a circle around the camera because back in the camera code, I have a look_at which causes the camera to turn as the player moves right/left relative to it, causing circular motion.

    Beyond that, there are some simple tweaks like a timer that runs before setting a boolean to cause it to rotate back behind the player or only moving if the player is outside of the follow distance. Things like that.

    It’s pretty tightly coupled, which isn’t great from a code perspective, but it’s also unlikely to fundamentally change. If that were to happen, I’d probably want to totally rewrite the system anyway.

    PS: I like that the test pattern texture of your level has so much detail. Not just the same plane checker square over and over again. :)

    I just found it online somewhere years ago lol. Probably opengameart? I no longer have the original source, but it’s pretty good for testing:

    • FeyterM
      link
      English
      11 year ago

      That sounds a bit fiddly just from reading it but I’m sure it makes totally sense in code. Now that you mentioned it, yes adapting the players forward based on camera view is something I totally forgot here.