Networked Gunplay: Part 3 - Monkanics Devlog #29 (11-9-2025)

------------------------------------------------------------------------------------------------

If this is your first time visiting my devlogs, check out the welcome post:

https://monkanics.blogspot.com/2025/10/welcome-to-monkanics-devblog.html

------------------------------------------------------------------------------------------------


The name’s Demetrius Dixon, and I’VE FINALLY MADE A BREAKTHROUGH!!!


I’ve been ruminating nonstop about how to send projectile info from the player to the server, since the player and projectile were separate.


OR SO I THOUGHT!


In actuality, the projectiles are CHILDREN of the player. So the client IS able to reference the projectile, then send that projectile info to the server!


(The projectiles are both the area3D’s in the scene tree and the red pills in-game)


Now, this eliminates the roadblock, but not the technical implementation.


Side Note:


Direct knowledge roadblocks like these make me want to avoid Monkanics development when they happen. That’s why the last 3 days have been nothingburgers.


Let me clarify here, DIRECT KNOWLEDGE ROADBLOCKS are the problem, not general problem-solving/designing I do every day. 


Knowledge roadblocks make it physically impossible to make progress. Making dev sessions turn into me banging my head against a brick wall over and over, instead of an engaging experience.


I haven’t run into one like this since I started these devlogs. Mainly because I already went through the pain of learning netcode months ago.


However, as I continue with new features I have no experience with, I WILL run into more of them. When that happens, I might be out of it for a few days as I try to learn what’s not working/how something works.


Man, it’s great to finally write a side note again. It’s been too long.


--------------------------------------------------------------------------------


With this new knowledge, I can map out how networked projectiles will work and exactly what I need to do next.


So here’s how networked gunplay should theoretically work: 


  1. When the client presses the primary action input (left click), the client input function will now call the player shoot function and pass its own arguments.

  2. The player script will then create the projectile.

  3. After that, the client will grab that projectile’s information (aim direction, spawn location, etc) and send it to the server via RPC.

  4. The server will parse this info and create its own version of that projectile. This server-side projectile will be the true version that determines collisions between enemies and such.

  5. The server sends back a new gamestate with updated info to all clients.


--------------------------------------------------------------------------------


The first thing I actually need to do isn’t related to projectiles, but instead the player and their camera’s rotation.


When the client shoots, the projectile’s movement direction and spawn point depend on 2 things:


  1. The side-to-side rotation of the torso.
    (Called the `CameraHorizontalRotation`)

  2. And the up-and-down rotation of the head.
    (Called the `CameraVerticalRotation`)



What I have to do is sync these to all other clients, currently, it doesn’t.


It actually used to work, but it broke sometime ago for a reason I can’t remember. I didn’t bother to fix it because it wasn’t important at the time.


I actually made myself a nice to-do list of player changes (I use Google Tasks):



All these are related to the camera and its rotation in some way. Which will be essential for projectile networking.


For a more in-depth explanation on the latter 3:


  • The `GlobalRotationPivot` is a node I made a LONG time ago to handle the player’s rotation.

    It has become outdated with new nodes, but for some reason, it still breaks the game when I remove it.

    The hardest part is gonna be remembering why.



  • Rotating the player based on their movement is an important aspect of Monkanics’ gamefeel I want to implement.

    Currently, the player model rotates with camera movement. This is the default for most third-person shooters.

    However, Monkanics is a little different. It has a great emphasis on platforming and movement. Having the model rotate in the player’s movement direction would put more emphasis on the player’s movement.

    The best comparison I have is the Splatoon games. The player rotates in their movement direction unless their shooting.

    There’s a bit more nuance to this system, like rotating with the camera when shooting, model changes based on where you look and move, but that’s going to come a lot later in development.


  • Fixing the camera’s spring arm has been the most “I’ll get to it later” task in Monkanics’ development.

    The spring arm works, until it doesn’t. The collision is all wonky, it’ll clip through walls all the time.

    I’m not sure how to go about fixing it, honestly. I’m going to have to ask the Godot Forum to help.


--------------------------------------------------------------------------------


This has been THE comeback dev session. I’m confident again! Confident that I’ll be able to work on what actually needs to be worked on.


I also worked for that hour I wanted to because I didn’t start at 11:00 fucking PM.


Hopefully, this continues into tomorrow. Which is also day 30, signaling a whole month of daily devblogging. You could also argue that 1 month is 31 days, but if you do, screw you!


Wish me luck tomorrow!


--------------------------------------------------------------------------------

Thanks for Reading!


Personal Development Stats:


  • Time Worked Today: (1 hour(s) and 16 minutes)

  • Total Time Worked: (62 Hours and 16 Minutes)


--------------------------------------------------------------------------------

Comments

Post a Comment