00:00
00:00
EyeBallTank
Working on Project Nortubel.
https://rentry.co/axmy9

READ MY RENTRY POST

Joined on 8/24/21

Level:
19
Exp Points:
3,802 / 4,010
Exp Rank:
13,733
Vote Power:
6.09 votes
Rank:
Civilian
Global Rank:
> 100,000
Blams:
0
Saves:
17
B/P Bonus:
0%
Whistle:
Normal
Medals:
29

Added CLIMB state and then SWIM state

Posted by EyeBallTank - February 10th, 2023


Yet again thanks to Heartbeast's Pixel Platformer tutorial, i added a functional ladder and CLIMB state that i'm proud of.

This time, a RayCast2D node wasn't leading to weird bugs of "colliding with the wrong thing" (Might be the code i added to clarify something collision related).

But as i was working on climbing, there was a point where gravity was still present and dragging the character down, making me realize i could make a swimmable state of the character.

And eventually i added:

  • Another Raycast2D After LadderCheck, i added a swimCheck and hopefully it doesn't create issues, if there's nothing wrong with a character having multiple Raycast nodes (And both functions calling the Raycasts having "var collider" in the code because of variable definition inside functions and such).

(I was told on Godot's Discord that two different functions having "var collision" isn't bad because the definition is within the "scope" of the function or something in that line).

  • SWIM State: Giving the player those controls and physics is easy. Then there's adding WHEN the player SHOULD and SHOULDN'T use that state. It was a bit like is_on_ladder() but instead called is_on_water() and with a similar condition checking by adding specific code within states.
  • Water based Area2D: It's a similar case as the Ladder Area2D where the scene has its own "pre-defined" CollisionShape2D (Unlike Enemy Hitbox and "jump through platform" scenes, that are left "unfinished" so they get specific collisions when used in the levels/under enemies and so on). I found this a bit disappointing because water as a level design element will always be shaped differently.


Perhaps the solution would be two scenes like this: One that "activates" the Player's SWIM state and another that "deactivates" it; Then both without CollisionShapes, so said collisions are defined when used as nodes under the level. Maybe for the future.


  • Companion? I guess the little one should get a SWIM state too, even if i need to include SWIMIDLE and SWIMMING states as equivalents to IDLE/FOLLOWME. Might be more complicated with getting an AI to climb a ladder for a bunch of reasons.

But i can call states within states, so maybe there's hope.


In other news:


  • Pushable situation still on hold for now.
  • After a repy on r/Godot, i might readd a Player Hurtbox Area2D node and find a way to make the engine's output not put out red text AND make the Hurtbox use an animation (AnimationPlayer) where the Collision is temporarly disabled, to create a "iframe".


(For the output red text part, i was told about "deferred" signals which is yet another alien thing to me).


  • Speaking of STATES, "state changing" level areas and Companion: When i do use the spriteset i shared once, i might try and give the Companion a CRAWL state where they can go to tight spaces that the Player can't.


But as usual, any help is appreciated and my stuff is available here https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish

I'm also kinda busy with Doom mapping and plan to release my map some time.

The map itself might be weak BUT the main point was to learn some features of Doom mapping that could be used/done better in the future.

Maybe the next Doom map or so might also be another practive one and it will also be Boom/DSDA Focused.


Tags:

Comments

Comments ain't a thing here.