Waterbird and Bananas

Project summary

Minecraft players get a naturally spawning waterbird they can tempt, tame, follow, and command to sit, plus a banana that grants a brief speed effect. The mod separates shared simulation from client rendering, reuses native tameable-mob systems, and ships custom models, textures, and four animation states.

Architecture

Trace loading, interaction, simulation, and rendering through the mod.

Deployed: Mod JAR → Fabric mods folder · Minecraft client or server

Outcomes

• 1 in 10 · banana tame chance
• 10 s · banana speed effect
• 1 to 3 · natural spawn group
• 4 · modeled animation states

Skills demonstrated: Fabric lifecycle separation · server-authoritative entity interaction · goal-based tameable mob behavior · state-driven client animation · resource and registry wiring

Problems and solutions

Keep gameplay authoritative while fitting a small mod into Minecraft's existing systems.

▓ Extend ParrotEntity for tameable behavior

Problem: The waterbird needs taming, ownership, flight, following, and sitting without rebuilding Minecraft's passive-mob machinery.

Subclass ParrotEntity, retain its lifecycle, then add banana interaction and waterbird-specific goals and attributes.

• Rejected a custom MobEntity implementation because it would duplicate ownership, tame state, and movement behavior
• Accepted trade-off: inherited parrot behavior constrains future specialization
• Outcome: a compact entity supports taming, following, sitting, and flight

█ Keep taming and sitting server-authoritative

Problem: Ownership and sitting state must remain consistent for every player in the world.

Consume the banana and change tame or sit state on the server, while returning sided interaction success to Minecraft.

• Rejected client-side state mutation because it could create visual success without durable world state
• Accepted trade-off: interaction code must branch on world side
• Outcome: the server owns state while clients receive standard entity updates and particles

▒ Split common and client initialization

Problem: Entity registration and world spawning must run on servers, but model and renderer classes are client-only.

Use separate Fabric main and client entrypoints, with rendering registration isolated in WaterbirdClient.

• Rejected registering rendering from common initialization because dedicated servers cannot load client classes
• Accepted trade-off: related setup is distributed across two entrypoints
• Outcome: the same mod JAR can load in client and server environments

▤ Drive animation from entity state

Problem: Walking, flying, idling, and sitting require distinct poses that track live entity behavior.

Update client-side animation states each tick and let the model combine movement with idle, fly, and sit clips.

• Rejected one generic loop because flight and sitting need visibly different poses
• Accepted trade-off: state priority and transitions live in hand-written tick logic
• Outcome: four modeled states respond directly to movement, air, and sitting conditions

▚ Reuse banana as food and creature affordance

Problem: Players need a discoverable item that matters both to them and to the new creature.

Register one banana that restores hunger, grants a 10-second speed effect, tempts waterbirds, and attempts taming.

• Rejected a separate taming token because it adds another item with only one purpose
• Accepted trade-off: food balance and taming balance now share one resource
• Outcome: one item connects inventory, player effects, AI temptation, and ownership