Dead Ducklings: Fowl Play — Multiplayer CTF with Cartoon Knockback

Godot Version

4.7

Hello everyone! This is my first post on the Godot forums.

I’m currently developing a multiplayer game called Dead Ducklings: Fowl Play. It is a fast-paced, third-person capture-the-flag game where tiny ducklings battle across oversized, hazardous environments using improvised toy weapons, exaggerated movement, and cartoon-style knockback.

The ducklings are only about twelve inches tall, so ordinary objects become major pieces of the battlefield. Rooftop vents, air-conditioning units, pipes, water towers, soda cans, garden hoses, rulers, rubber bands, and other everyday objects are being turned into weapons, obstacles, and traversal tools.

The Main Idea

The goal is to combine:

  • The readable team combat and classless chaos of games like Team Fortress 2
  • The strong knockback and recovery mechanics of platform fighters
  • Over-the-shoulder movement and aiming
  • Tex Avery-inspired reactions and physical comedy
  • Small characters navigating environments built at a much larger scale

It is a traditional capture-the-flag game, but combat is focused heavily on launching opponents out of the arena rather than simply draining a health bar.

Players can be knocked into the air, bounced off walls, flattened, stunned, thrown from rooftops, and forced to recover before falling out of bounds.

Current Development

The game is being developed in Godot 4.

So far, I have been working on:

  • Server-authoritative multiplayer movement
  • Player spawning, despawning, and respawning
  • Snapshot interpolation
  • An over-the-shoulder camera
  • Jumping, high jumps, wall jumps, and aerial movement
  • Knockback and environmental hazards
  • Capture-the-flag objectives
  • A modular rooftop arena
  • Early weapon and reaction concepts

The first playable map is called Rooftop Ruckus. It is an industrial rooftop arena built around a central water tower, with vents, air-conditioning equipment, catwalks, pipes, jump routes, and several ways for players to get launched off the building.

Sticky-Hand Grappling Mechanic

One of the mechanics I’m currently designing is a grappling tool based on the stretchy sticky-hand toys that kids get from vending machines.

The player will be able to:

  • Attach it to walls and environmental objects
  • Pull toward the attachment point
  • Release during the pull to launch through the air
  • Swing around corners
  • Grab lighter or weakened players and pull them closer
  • Get pulled toward heavier or stronger players

I want it to feel playful and unpredictable while still being reliable enough for competitive movement.

Visual Direction

The game has a colorful post-apocalyptic setting, but the tone is more playful than grim. The ducklings have permanently crossed-out X eyes as part of their character design, even while they are alive.

The reactions and combat are meant to be exaggerated, energetic, and funny rather than realistic or graphic.

What I’m Hoping to Learn

This is my first serious multiplayer project in Godot, so I’m looking forward to learning from the community and documenting the development process as the game grows.

I would especially appreciate feedback on:

  • Server-authoritative character movement
  • Knockback systems in multiplayer
  • Grappling and swinging mechanics
  • Responsive third-person movement without client-side physics becoming unstable
  • Efficient workflows between Blender and Godot
  • Organizing a growing multiplayer project

I’ll continue sharing progress, gameplay tests, technical problems, and art as development moves forward.

Thanks for taking a look at Dead Ducklings: Fowl Play.

1 Like

For the “tiny ducks in a giant world” bit, drop in one oversized prop early (soda can / AC unit) even as a scaled primitive; the joke lands harder once scale is in the blockout, not only in the pitch.

On the tech side you’re asking about: do knockback as a server impulse (set velocity / add force once on authority, then let clients interpolate), not each peer simulating the hit. Same for the sticky-hand; authority owns attach point + pull; clients just show the stretch. Saves a lot of desync pain later.

2 Likes

Thanks, this is super helpful.

I hadn’t thought about introducing the scale joke that early, but that makes a lot of sense. Right now I have oversized rooftop elements like AC units and vents, but adding something instantly recognizable like a soda can near the spawn would probably sell the size difference much faster.
I was thinking of doing a soda can launcher like a rocket launcher, so I’ll have to figure scale out.

I’m still figuring out the multiplayer side, so your explanation about the server owning the knockback is especially useful. My current setup is server-authoritative, but I’m still learning where the line should be between the server simulation and what the client handles visually.

For knockback, would you normally have the server directly change the player’s velocity once when the hit is confirmed, or apply a force over a few physics frames? I like the idea of Smash Brothers fighting physics where the player is booted out of the screen. I thought this would be fun in this setup.

The sticky hand is the part I’m most unsure about. Having the server own the attachment point and pull while the client only displays the stretch sounds much cleaner than what I was imagining. Would you also have the server control the swing movement itself, or let the client predict some of that and then correct it?

Appreciate the response!!!

2 Likes

For Smash Brother-style boots: one server write when the hit confirms; set (or add to) velocity hard, maybe stash a short “in knockback” timer so ground/friction doesn’t kill it instantly. Multi-frame forces work too, but keep them server-only; clients just show the result. Continuous force per peer is what desyncs.

About sticky hand: server owns attach + the pull/swing motion (or at least the CharacterBody integration). Client can cosmetic-predict the stretch/arc for snappiness, then snap/correct when the next snapshot disagrees. Don’t let the client be the authority on “am I attached / where’s the anchor.”

Rule of thumb: server decides outcomes (hit, attach, launch); client dresses them up.

2 Likes

Quick update,… I’ve got the basic multiplayer working now!

This is a local 3-player test with a host and two clients. Players are spawning, moving, and replicating correctly between all three instances.

It’s still very much a blockout, but it’s pretty cool finally seeing multiple ducklings running around together. :grinning_face_with_smiling_eyes:

Next I’m starting to get into the combat/knockback side of things, so the advice above about keeping those outcomes server-authoritative came at a really good time.

2 Likes