Bubble Horn: playable musical instrument proposal

Status: concept and gameplay design proposal. Not native implementation, not a claim about released AoA mechanics. The original weapon remains available, and the previous concept is preserved as an alternate.

Original-versus-upgrade gallery · Complete weapon standard

Released baseline to preserve

Read-only inspection of the released AoA3 3.7.1 / Minecraft 1.20.1 classes confirms that the BaseBlaster firing wrapper calls Bubble Horn’s projectile hook, which creates BubbleShotEntity. The inherited energy consumption uses Spirit, and the class identifies its existing firing sound as ITEM_BUBBLE_GUN_FIRE. Its tooltip and impact hook also carry target-slowing intent. These are released-code findings, not native test footage. Released-class evidence and artifact hashes.

The new idea is the actual trumpet-playing presentation, musical-note styling, horn articulation and optional animated sight, not the invention of bubbles themselves. The earned mouthpiece is now explicitly a functional power upgrade: much higher damage, more projectiles per accepted shot and faster projectiles. Keep the released behavior as the separate original mode. Retain Spirit as the resource family rather than replacing it with generic bullets or inventing a required physical ammunition magazine.

Current visual direction

Keep the large brass bell, lower looping tube, three cyan instrument valves and dark rear structure. Refine the original identity rather than replacing it with an unrelated gun. The generated character and hand poses below are concept staging, not proof of Steve/Alex or TaCZ rig compatibility.

Preserved earlier alternate

Optional playable-trumpet attachment

The player actually raises the mouthpiece to their lips and blows the horn, rather than merely triggering a trumpet sound over a normal firing animation. Fingers work the cyan valves, the horn note sounds with the shot, and iridescent bubbles containing musical-note motifs leave the bell.

• A removable rear mouthpiece module enables the playing presentation. Keep it distinct from the optional sight attachment.
• Ready: held below the face, with clear mouthpiece and hand space.
• Play: mouthpiece visibly contacts lips; the bell points away from the face; support and valve hands retain clear ownership.
• Release: lower the instrument naturally; already-created valid bubbles continue only according to their defined gameplay lifetime.
• Each accepted shot synchronizes breath/playing motion, valve movement, horn audio and bubble emission. Dry or blocked attempts cannot create free projectiles.
• Earned power upgrade: blowing through the equipped mouthpiece substantially increases damage, musical-bubble count per shot and projectile speed. This is explicitly functional, not merely cosmetic. Preserve the unmodified original mode separately. Exact multipliers, resource cost and unlock route remain tuning/design work; do not silently cancel the requested power increase with compensating nerfs.
• The original mode must remain available. Removing the mouthpiece does not delete the instrument's original cyan valves or other core geometry.

Earned power-up requirements

The mouthpiece must be earned through progression, with its exact recipe or reward route designed against the relevant release. It should feel like a major payoff: stronger hits, a visibly fuller musical volley and clearly faster bubbles.

• Resolve damage, projectile count and projectile motion from the equipped, legitimately unlocked attachment. Tooltips and previews must show the same resolved values used by the server.
• All volley projectiles need correct owner and shot identity. Verify actual damage against Minecraft/AoA invulnerability and hit-processing rules so extra bubbles are not merely decorative copies that fail to deliver the intended upgrade. Do not globally disable damage safeguards.
• The original bubble entity has its own per-tick motion behavior. Validate actual travel speed, not just an initial-speed number that another update immediately cancels. Original mode retains its released behavior.
• Keep Spirit as the resource family. Cost, cooldown and lifetime are explicit tuning decisions, not assumed penalties. No damage multipliers, free resources or final recipe are claimed as implemented by the concept art.
• Removing the mouthpiece returns to original mode; the independent bubble sight can remain equipped. Test earned-state persistence, save/reload, transfer rules and multiplayer authority.

Independent musical-bubble sight

A small musical bubble forms above the optional sight emitter, opens into a readable aiming aperture while focused, and pops into brief droplets and musical motes when focus is lost. Keep the center clear and the aim marker stable. The rim can feel lively without moving the actual aim point.

The mouthpiece and sight are separate choices. The combined playing-and-sighting pose still needs a dedicated first-person clearance study: avoid face clipping, an obstructed view or a mouthpiece that forces the sight off the aiming line. Removing either attachment must preserve the other and the original instrument details.

Musical bubble VFX study

Thin-film iridescence and small musical-note motifs connect the projectile to the instrument. Keep trails short and readable; the illustrated impact pop is non-destructive visual direction, not a definition of damage or collision behavior.

Animation, audio and accessibility requirements

• Explicit cancellation for weapon switch, sprint, interrupted actions, attachment removal, death and disconnect. Do not leave a stuck mouthpiece, playing loop or orphan bubble sight.
• Record a coherent musical palette and varied short articulations. Audio range, volume and overlap limits need multiplayer tests; avoid uncontrolled note spam.
• Offer reduced particle density, reduced motion and controllable effect audio. Preserve readable gameplay cues when decorative effects are reduced.
• Verify first- and third-person poses, both supported player-arm types, focus transitions and all attachment combinations in AoA plus TaCZ.
• No native gameplay, animation, sound or performance acceptance is claimed by these sheets. All other dedicated customization categories remain required.