After adding SWIM and CLIMB states, i tried adding SWIM states to the Companion but there’s a catch.

I technically succeeded at adding swim states to the Companion (2 states equivalents to FOLLOWME and STANDSTILL so it can chase the Player underwater) but the one issue is that the character vibrates when on SWIMMING state.

My theory is that the movement is coded in a way that there’s no proper diagonal movement, so it’s actually switching between horizontal and vertical movement really fast.

It’s what i get for simply copying Gonkee’s Jared AI project without studying a bit further.

Because otherwise, it’s technically “there” but it just looks off.

Key/Doors:

There’s solid doors that block paths and keys that can be picked up to open them (With a basic red/blue/yellow color system).

Best part is that the Player’s “has key” variables are false by default as a scene is loaded, so i don’t have to check if the Player can or can’t open a door without picking up a key first.

An issue (Besides maybe some notifier on the HUD/screen) is that i wanted to make Companion able to use keys but so far, it didn’t work.

Which can be weird because stuff like the Health pickup and Jump pad work for both characters.

“RUNAWAY”:

I simply thought “what if the Player will want the Companion to go forward without having to use FOLLOWME?” and created a “RUNAWAY” state/command.

It’s essentially the opposite to FOLLOWME and could be useful in some scenarios.

Perhaps an issue here is the future controls of the game, since this will be a keyboard focused PC game unless i figure a way to set console controller inputs somehow.

It’s also clear that the Companion AI will always be limited and impact level design in some way.

What else:

• Pushable situation: Still on a break.
• Maybe the “hurtbox/iframe” situation may also be on break.
• Even in the main Github page, i’ve already written stuff that may need fixing in the future like if the health bars of both characters should be placed on the screen like a proper HUD.

https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish

But i’ve also been thinking on working on a level switch/button feature.

Something inspired by Pacman World where yellow/blue/green switches have specific functions based on their color.

Blue is “permanent”, green is “toggleable” and yellow is timed (Not entirely like Pacman World but still).

The idea is that these switches are “modular” in the sense that in different levels, they can fill different effects and uses, even if this area is complicated.

I was thinking that at least, they could be related to moving platforms or something else besides doors because technically, the door stuff is already fulfilled by the keys (Maybe).

Unless i create different scenes for specific blocks/platforms with code based on receiving some signals and select some of those scenes for a level.

This also makes me wonder about the actual interaction:

• If it’s “automatic”, the Player has to be carefull with when they touch the switch and if the Companion can bring a bit of trouble with pressing a switch in the wrong time.
• If it’s manual, i’d be setting up even more RayCast2D nodes and creating a new Input to make the control scheme more complex.

But this is just speculation.

I’ve seen a tutorial video where both a switch and door were under the same “scene” and the video used “editable children” to place each object uniquely in a level. But i’m pretty sure that “editable children” can impact a scene in general if i wanted to reuse it differently in multiple levels.