Let’s see how far i’ve gotten right now:

Falling platform

Felt like it could be an easy addition just because i could use AnimationPlayer to direct everything (Shaking animation, collision, visibility, the “falling” and “respawn” effects etc).

Only the Player can make it fall, meaning that the Companion isn’t that heavy.

Conveyor platform

Also a basic idea in my head that somehow i struggled at first until i discovered that StaticBody2D has an exclusive function for this.

I’m glad because it affects both main characters.

Pushable object

Finally i got it working and thanks to mjbolt after i rewatched a video.

You’ll notice that the Player and Companion have subtle physics differences but still a very small thing and otherwise, it’s almost exactly how i wanted it to be.

Ice

So far, the Player has ice physics and i even made it that if you jump from an IceFloor, you’ll still remain the slippery jump and only return to normal by touching a regular floor.

(It seems the Cubio demo is gone, so the frankensteined code i took from it is all that remains).

As for Companion, it might be hard considering that their AI follower role is done in a way that their movement doesn’t seem to use a normal velocity/speed variable.

Maybe the solution is to learn the other ways to make an “AI follower” thing in GDScript and use that.

(Might be wrong but even if i had to “reinvent” their logic, i hope that at least leads to some other things being fixed/discovered).

Soccer Ball and Goal

I decided that the Soccer Ball might as well be a projectile, not only for combat but to also interact with goal nets.

Because these nets could be related to events in the level design (Even if as something like doors or unlocking pickups like a Mario question mark block).

How it works: First you press to “shoot” to be locked in the KICKBALL state, then press either left or right to kick the ball to a certain direction.

When you kick a ball, you go back to MAINSTATE but you can also press down to return to MAINSTATE without wasting a ball.

I might implement an “ammo” system for the ball or something.

The KICKBALL state also prevents the Player from having ice physics but again, that exploit won’t be common if you have no Soccer ball.

The amount could be one ball at a time and you could “pick” it up from, i guess a bag implied to have multiple of them.

What else

• I once thought of making it so the Companion automatically jumps near an edge/cliff so they don’t have to rely on Player’s Y position, but i wonder if such a method would even acknowledge platforms and objects not part of the TileMap.
• Something to consider is Companion CLIMB states because i hope that unlike their SWIM states, they don’t awkwardly shake since i could make their climbing based only on vertical directions (I might need an “interact” command related to them so i can decide when they start climbing).
• Giving them CRAWL states could also be a good way to give them places that the Player can’t go and even use the Green Switches for situations where both characters are seperate (Maybe the real challenge would be rearranging collision shapes under these states).
• Godot 4 looks amazing but as for now i’ll stick with 3.5.1 because there’s still more to learn on this version of the engine.

Project as usual is here: https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish

https://tapas.io/episode/2781617

Felt like sharing.

So far there's the first chapter and i thought it was cool.

Thanks to Nkzar on r/Godot, i managed to fix the melee breaking the Player hitbox by making the melee attack's "animation" based on code (Turns out a scene can't use more than 2 animations from AnimationPlayer at once).

There's technically combat, even if it's a basic melee attack.

But more importantly:

Moving platforms.

Watched some tutorial videos and they seem to be working, specially without some weird physics affecting both characters (Maybe it's because the tutorial videos i watched were from older Godot builds).

And i wanted to use moving platforms on a switch system i wanted to include, which also took tutorials and experimentation.

Switches and Signals

I settled for an AutoLoad "Signals" script that connects the signals between switches and their desired objects.

So far, a switch is interacted with the Player simply touching it (May or may not change).

Besides signals, i still used AnimationPlayer to affect movement of platforms and the collisions of the buttons.

Blue switch

The first one i tried: Simply touch it and its permanent.

Yellow switch

This one has a "timed" effect but can be pressed again.

Green switches

Eventually i settled for two (One deactivates the other and vice versa) to work around the "binary" role but it also works.

What else

• I might want to use Signals in other things in the future and maybe reinvent some things like the health bars to make a proper HUD system.
• Speaking of HUD/UI, an idea i had was an on-screen notifier for the Companion's position when they're off-screen. Basically, like an arrow that only shows up if the Companion is off-screen and it points at their direction.
• Because of a change on the Player's movement, i thought about if i could try slippery ice floors in the future (Could be a unique platform on its own and not something related to TileMap, i don't mind), even if i can't find any tutorial on how to make this stuff.
• Something i'm thinking on trying is a falling platform based on if a character stands on top; May be a bit more complicated than i assume.
• Pushable object situation: Still on hold but 2 specific things i also want to keep in mind; One being that both characters should be able to push it BUT don't have to do it at the same time (And i might come up with PUSHRUN/PUSHFOLLOW states for the Companion) and another being the Pushable not clipping with walls etc).
• Companion shaking underwater: Also on hold.
• The ugly art currently in-use is "placeholder" and i haven't released/uploaded a "proper" drawing for a while.

Anyway, game is available at https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish

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.

https://eyeballtank.itch.io/my-first-doom-map

This is a milestone for me that i wanted to do in a while.

I expect it to be in a weird quality, which is why feedback is appreciated and hopefully my later maps in the future are much better.

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.

https://imgur.com/a/twyyJTI

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

At some point, the player couldn't be hurt when idle, but i fixed it.

I ended up using the Enemy Hitbox method from Heartbeast's Pixel Platformer tutorial, where enemies share an Area2D that has a collision shape attached.

There is an issue: The player can either "enter" the Enemy Hitbox and survive damage as long as they're inside it or touching it after being hurt once.

I know i cannot turn off the Player's collision because they'd obviously fall through the level.

An idea i had was to temporarily turn off the Enemy Hitbox (Which could even affect multiple enemies sharing it but it'd give the illusion of an "invincibility frame", i guess?).

But this could lead to two things:

• If the Player gets hurt, they're technically turning off Enemy Hitbox in a way that the Companion can survive being hit.
• Because it'd be the Player deactivating it, the Companion can be hurt without the illusionary "iframe" caused by the Enemy Hitbox's temporary disable state.

And this is also because of the weird way how things are coded/structured.

This is also why i wanted a "knockback" effect from the Player/Companion, but even the mere ideas of "where the Player is going", "where the Enemy is going" etc could lead to a lot of work.

So just having them simply jump seems to be reasonable enough.

In other news:

• I decided to take a break from the Pushable object situation and maybe focus on that in a better time (I still made a post on the godotengine dot org QA site, just in case).
• I added a sound effect for an object ingame and it even works with the volume slider (It's from Freesound user strangehorizon).
• I also added "placeholder" scenes for keys, in case i develop a key/locked door system.

But some things are going forward.

Got a message from r/Godot about get_overlapping_bodies() while is yet another thing i haven't really heard/tried, so i still have things to learn.

Also, turns out i still got OC related ideas https://eyeballtank.tumblr.com/post/708642344678965248

And i've also returned to Doom mapping, recreating a Moai statue and creating a structure i want to be relevant to Nortubel in some way https://eyeballtank.tumblr.com/post/708518804061306881

Prev: https://eyeballtank.newgrounds.com/news/post/1331598

I wanted to add a pushable object that the Player and Companion could interact, by pushing it.

At first i used a RigidBody2D but had 2 issues:

• Every video i watched about pushing RigidBody2D's almost used the same "velocity = move_and_slide(parameters)" method and using that in a Player character script always messed with their values/physics (They jump higher and move faster than they should be); Because ideally, i'd want to access only one parameter which is the inertia part.
• The "pushable" object still felt floaty, even if it's just a matter of getting settings right.

So instead, i opted for a KinematicBody2D for the pushable object and even made copies of the Player, Companion and said Pushable object so i could use them as bases for new code.

And the stuff i did:

• Made a state machine on the player, including a PUSH state.
• Also put a state machine on the Pushable object, with "FROZEN" and "PUSHED" states.
• Once made it so that if the player touches the Pushable, they switch to a "state" with slow speed (Making the Pushable almost like a sludge hazard, since it works even when the player was on top).
• Gave the Pushable extra CollisionShape2D nodes based on up/down/both left and right sides, with a "left and side" collision being under a "pushableside" group (Then went back to one Collision).
• Used a RayCast2D on the player but it had like 3 problems:

1. First was that it'd crash with things like the Tilemap or Area2D scenes because of specific code expecting another KinematicBody2D.
2. Second being how it didn't flip properly (And even with code to flip, the angels were random as if it wasn't properly counting 360 degrees).
3. Third being how the Raycast, no matter the size, would stop pushing the Pushable if the player was high enough in terms of placement.

So i deleted the Raycast node.

If you look at my code for the 3 scenes (Player, Companion, Pushable: Each with "Copy" after their names), you see a lot of commented code because i tried different methods.

I'm obviously committing the mistake of copying code from different tutorials and all, but it's because my coding skills are still weak.

The idea of using a RayCast2D came from a video by clecioespindolagamedev (Video titled "Como EMPURRAR e RESPAWNAR OBJETOS na Godot 3.4 (+Bug Fix Plataforma)") and the video even showed the pushable object as a KinematicBody2D.

Because i believe it's possible to make a pushable object (And pushing state for the player) work while using a KinematicBody2D instead of RigidBody2D.

A method i'm not even sure if i tried properly was make the PushableCopy detect collission from Player/Companion but only from its left/right sides and using inputs (Pressing "left/right") IF it's behind touched by those characters and from respective sides but the exact code reference is not in my head.

Again, my project can be seen here https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish/commits/main

Even if you don't download it, you can see the updates and where the specific scenes are stored and their code.

As for other updates with my game:

• After the main menu, i got a somewhat working pause menu (Didn't made it a proper autoload scene, so it's part of the level technically).
• Got a jump pad scene that works.
• Added "placeholder" scenes like a soccer ball and ladder, that should be updated in the future (Even if i feel stuck in this Pushable situation because i made copies of the main characters, so i feel like i have to choose which versions of some scenes will stay so i can update them afterwards).

Guess the least i should do is focus more on learning Godot stuff.

Any help is appreciated.

I implemented a scene transition method, where i can refer to a certain scene (The scene manager) from other scenes.

It uses a transition effect because in a way it had to, so i got a bit creative with what the effect should look like (When i properly expand the game's setting, you'll get what the effect references in-universe).

Though Doors are another issue, therefore i need to properly make them "flexible" sometime.

I organized layers/masks for scenes (Apparently i forgot to do this before) and now the door scene can detect even the companion to change scenes.

ALSO, i should consider making it that both Player and Companion are needed to finish a level.

I also created a "main level script" that levels inherit from, like how Player and Companion already inherit from a "actor" script.

At least i got a custom font (Mikodacs by gluk on FontSpace) that works with Portuguese.

I also managed to make a working options menu thanks to a video tutorial by 16BitDev.

But i also think i should consider a pause button soon, specially if you're playing the game on fullscreen mode.

Again, my project is available on Github.

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

And because i'm still somewhat clueless and still learning, any help is great.

So lately, i've been thinking of adding a "scene manager" autoload scene to manage how scenes are switched in my game.

Because i had 2 things in mind:

• There could be cutscenes and other types of menus/UI stuff in my game besides just the levels.
• The levels (And other scenes) may/will not be in a "linear" order (Specially if i want to include HUB areas, backtracking and/or secret/optional levels and so on).

My plan here is to add a method of changing scenes that is more universal/flexible and future proof, to make sure scenes are changed nicely.

Because hardcoding specific stuff isn't ideal and i want to make sure stuff is loaded properly, even if i need transition effects or some method of keeping track with info (Like if characters carry the same health values or items and so on).

I still added a door object that could be an end level feature, but i still want to make said door to use the "scene manager", even if it needs signals.

While at it, i made folders for specific sprites and added some extra commented/unusable code for when i add extra states to characters.

Again, project can be found here https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish