Broke a promise but i'm making a game, so you get to know some stuff without having to surf through a large wall of text someday.

https://www.diffchecker.com/j1yc8niO/

And

https://docs.google.com/document/d/1QWjE2D9l4qEJQ3rzirwRv3P5pTL15K1Hf8es6vMVG4k

After a while, i might as well make another news post about Project Nortubel just to see what's happened:

Remade Companion

First things first, i had to remake Companion with a new variation called Comp4. This is because of 3 major reasons:

• CCopy used a complicated code that i couldn't easily modify in my favor.
• CCopy specifically used methods that i assumed could be troublesome for future players and hardware.
• The fact that CCopy moves left and right when close to the Player might be odd to some and i couldn't even take advantage of sees_player() from Gonkee's project, but at least Comp4 stops when close enough during FOLLOWME.

It took a while but i eventually managed to fix issues they had.

Companion on ice

The Companion finally has ice physics. Besides the fact that ICERUN/FOLLOW have some build up when direction changes, the fact that ICEIDLE can be slippery (And even so the "idle" part of when they're close enough to the Player during ICEFOLLOW) is also good.

Companion crawl states

First i added a "CrawlCheck", then the "enter/exit Crawlzone" areas, then some code based on touching those areas, then some code related to resizing/positioning the collision shapes and then code related to the commands and movement.

So it's there. The main idea here is having a reason to seperate the characters in some scenarios and trying to make the little bro/sis character a bit more useful in some scenarios.

Slow floors

These floors are kinda like opposites to the ice floors and mainly exist because when i was working on the Pushable object, i tried a method of "it automatically slows down the Player when they touch it" which made me realize i could make this a thing.

Visually, think of it like some really thick and slimey mud (And this feature might as well be rare depending on how annoying it'd be for players).

The first power up (A lifeguard floater)

To make this work, i simply had to learn about set_monitoring because unlike with the Melee attack, i couldn't call the collision of the Area2D with dot disabled = false. But at least it's there.

What it needs is some sort of visual feedback for both during activation and when it's picked up/gone.

Originally it was going to be a green jacket but a lifeguard ring/floater makes more sense with the setting (Plus, depending on potential character sprites, i don't want to make the characters wearing a green jacket when i already thought of 3 Player characters).

So far, it only works on the Player by turning their hurtbox temporarily.

Checkpoint system

A checkpoint is something i always had in mind and when i first implemented i faced a lot of issues in regards to scene instancing and node names.

So i used a tutorial video by matinator9185/MateuSai to make a checkpoint method that "drags" the Player to a specific spot as the respawn spot.

However, this had another issue which was the game crashing if you haven't set a checkpoint prior due to needing a place for the player to respawn to.

So i created a "playerspawn" scene to fix that (And did the same for the Companion).

Even had to tweak the visuals to make sure each character is made invisible, so they seem like they actually disappear and reappear.

Export var behind Door

Now the Door scene that ends levels has an export var, so i can change the next level in the inspector instead of creating specific scripts

Sprites

Still not finished but i implemented various character sprites and even got an export var to select specific characters by levels.

The sprites themselves look weird but at least some mechanical stuff is there.

I also found a way to fix the Player's pushing animation.

Though the placeholder sprite scenes still exist (Are set behind the characters' AnimatedSprite scenes), partially because of comparison stuff and other test related things.

I also had to redo how the Player's melee works because somehow i broke it (Ended up creating a seperate PlayerMelee scene that the Player spawns in the spot of their original hitbox).

Current issues

• The Player's new "Hurt" animation using AnimatedSprite and/or HURT state are messy; One issue i noticed is how the Enemy can still hurt the Player because it takes a while for the "playerhurt" animation to actually play. I want "playerhurt" to start RIGHT when the Player's hurtbox collides with the EnemyHitbox.

I felt like redoing how the Player receieves damage, even if i broke it.

• The current Pause Menu scene isn't AutoLoad/"universal" because it's set as a node under a CanvasLayer node in each level, so i need to make this as an actual recurring game scene.
• The Pause Menu shows up ABOVE the SceneManager's animation but it doesn't pause the animation: Therefore the scene changing animation still plays and changes the scene (And i only didn't make the Pause Menu AutoLoad because i don't know how to make it unavailable in certain scenes like the Main Menu).
• The Companion's AI could improve as it only jumps when it's "under" the player's position (And there's more to consider depending on what will eventually be added to the game).
• Current health bars are attached to the main characters and not part of an ingame HUD attached to the screen.
• Companion shakes during climbing when close enough to the Player, as seen in the AnimatedSprite still retaining the "Climbidle" frame when supposedly moving.
• There may be a subtle bug on Comp4 during "Pushing" animation where it returns to "Running" while on PUSHRUN state i guess.
• Comp4 doesn't have the "updated but still broken" take on getting hurt that the Player has (Part of this is because i want to learn how you make an scene change to a previous state, because i don't know how a script can keep a "previous state" in mind, so the Player's HURT state just changes to MAINSTATE which can be weird if the Player was on CLIMB state).

Other stuff

• Just learned that Gonkee's video on the Jared AI project is gone. Because not only do i borrow code from that project, it's a specific version where unlike the Jared thing, i don't have that "sees player" code used on may game.
• With the checkpoint, i'd like to work on a life system: Ideally, both characters share "lives" despite the health being seperate meaning that if one dies, both characters respawn.
• Another idea i consider is an oxygen system. Maybe make it that the number is 100 by default/outside water but when is_on_water(), it slowly goes down and whether or not it's insta death or health drain depends.
• I need to do something about collision shapes for stuff since i added new sprites for the characters.

I got too ambitious with this game but if i tweak/add enough stuff, i like to think i'm close enough to make a playable demo.

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

I felt like redoing a follower based AI for reasons related to how Gonkee's code was settled: Not just the code structure being difficult to wrap around my head but also if OS.get_ticks_msec() could lead to performance related issues (And even if Time.get_ticks_msec() is the better version of this, i still wanted to try something different).

(Also my fault for copying code without understanding most of it, but i also did it when his video was still up but now it's gone while the Github page is still up).

So i made different versions of the Companion: First one that uses another version of Gonkee's Jared AI (Just to make an edit of the sees_player() function) and then a version reinventing the automatic movement, before i made a fourth/purple clone that can jump: CompanionFourth is now the base that i want to use to replace CompanionCopy who's technically the second version (CCopy was the one i used the most and replaces the original Companion whose code was rearranged entirely).

Therefore, i'll have to see if Comp4 (Let's refer to CompanionFourth like that) works with the same objects as CCopy (Who i've been using most of the time and is the most developed iteration).

PROBLEMS:

• Comp4 's hurtbox doesn't work. I had a similar issue with CompanionCopy and i fixed it by making their hurtbox both monitorable/monitoring but that solution doesn't work here somehow. It's weird because i'm pretty sure i tried to repeat what works with CCopy. And yes, i still made the "iframe/pain" animation based on AnimationPlayer but that's because a certain idea of it being turned off permanently only affected the Player due to a melee attack being an animation and all.
• Comp4 can't detect the Jumppad when it originally worked with CompanionCopy. I even renamed "velocity" to "vel" just to make it work but still nothing.
• Comp4 "can" swim and follow the Player underwater but they shake really hard, which is also another old problem coming back (And it's probably worse here because the movement is inconsistent and i can't tell if their vertical swimming is inverted). Need to find a way to make their movement feel "diagonal" and smooth.
• Climbing is also there but with shaky physics, because there will be parts in the game where both Player and Comp4 will climb close to each other (And THIS is WHEN i made the change automatic: Trying to get Comp4 into any CLIMB state with "if Input.is_action_just_pressed("interactcomp"):" when touching the Ladder somehow didn't work). With CCopy, you could make them attached to the Ladder but only if they were on STANDSTILL state and their climbing was rather smooth.

Meanwhile, the SLOW states work at least and so does pushing objects, entering portals and interacting with switches.

Still, i hope Comp4 becomes better than CCopy because i even want to see if it'd work with something like ice floors.

And once i've added enough states/mechanics to the 2 characters, i could finally try the character sprites and maybe redo levels to feel like actual levels or at least nice tutorial levels (Well, maybe also make the Gong checkpoint actually work and some other stuff).

As usual, project is on Github and this is Comp4's code https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish/blob/main/src/play_actors/CompanionFourth.gd in case someone wants to see how this character works (And what does not work).

Even if i end up abandoning CCopy, i may still keep them and the other Companion versions in the game's files just so people see them (And also because my game technically contains renmants of that now-gone Cubio demo).

Meanwhile, i still haven't found a way to fix what's going on with the PauseMenu and SceneChanger scenes (And i'm pretty sure i wanted the Score Counter to be under the SceneChanger's scene changing animation).

I finally fixed the Companion's SWIM "movement" so they don't shake anymore. They also got a "SWIMRUN" state.

Companion climbing

They can also use ladders, though first they have to be on their "STANDSTILL" state and then you use a command for them to attach to the ladder. The system is technically there, even if it's a bit weird right now.

Said command is one that could be used for "special interactions" even if it should be developed more and done better.

Score counter

Now the screen has a counter for the coins you pick up.

"Ammo" for the soccer ball

Once you kick a ball, you lose it but a sports bag object will restore it, so you can kick it again.

The backpack is technically "infinite", so the placement of this object could be considered for the sake of it.

Both characters can use switches

And i also set up a basic "timer" for green switches, so when the 2 characters press them you don't have the stuff changing its state too quickly.

Rope/hook

Originally was going to be a grapple hook, but i dropped that idea because it'd probably be too complex for my current status as a novice dev.

So the result is a basic swingable rope that the player automatically attaches to and can jump from.

Portals

They can be a good way to extend "traversal" on levels and even useful for some behind-the-scenes stuff (Like in case i implement that Companion "pointer" UI idea i once mentioned and use portals to see if it works in the future).

Their "grid" design is because of some idea of them being magical portals and it's supposed to look like energy or something, but the placeholder art is very basic.

Fall-through platforms

An "inverse" to jump-through platforms, which could make levels challenging but also in case some "restrictiveness" can be helpful in some cases to avoid issues.

What else

• Redid a section in the main Github page just because. Even with my case of getting overly ambitious, i like that i wrote the stuff that's done, because a "to do" list isn't enough, so a "done" list also helps (Though the section itself is not organized which could be fixed later i guess).
• In the files, i added a "sheet" of character sprites that i may use since i'm getting a lot of "planned" mechanics/features for characters. The "grid" is of 16 rows and 13 columns but depending on how/when/if better art is added, i'll obviously redo these sprites.
• A feature in the works is "CRAWL" states for the Companion. In theory i think i can make it work, but one thing to consider is the collision shapes being adjusted for their states and all.
• Current issue: The Pause Menu shows up ABOVE the SceneManager's animation but it doesn't pause the animation: Therefore the scene changing animation still plays and changes the scene (And i only didn't make the Pause Menu AutoLoad because i don't know how to make it unavailable in certain scenes like the Main Menu).

As usual, project is here: https://github.com/EyeBallTank/PROJECT-NORTUBEL-main-ish

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.