Build a Chirp Pong Game

Build a two-player Pong game that sends positions between devices as chirps.

Introduction

30 Second Summary

Multiplayer games usually rely on an internet connection to keep both players in sync. Two nearby phones can also pass messages with sound.

In this project, you will build a two-player Pong game in a single static HTML page. You will use the Web Audio API to encode ball positions as tones that another device decodes through its microphone.

What You'll Build

Your finished game will move the ball between two screens with audible chirps while both devices run the same public page.

By the end of this project, you'll have:

A chirp encoder that turns ball positions into distinct tones you can hear.
A live frequency graph that shows incoming chirps as visible spikes.
A two-screen Pong game that you can publish at one public URL and play with a friend.
Secret Mission: An optional challenge to push your audio game skills further.

Are there any prerequisites?

You will need either a laptop plus a phone or two phones. Each device needs a working speaker and microphone.

You also need access to a coding agent plus a free static host.

Before We Start

The final game hands a moving ball from one screen to another. That handoff only works when both devices can produce sound and capture it cleanly.

This step checks your physical setup before any project files exist. You also confirm that your build tools are ready.

In this step, get ready to:

Verify the audio loop on both devices.
Check that each device has a modern browser.
Prepare a coding agent plus a local text editor.

Test both devices

Each device needs a working microphone to receive moves. Its speaker sends moves back as sound.

Place both devices on a stable surface within easy reach.
Set both devices' media volume to 50 percent.
Use the first device's system search to find its built-in voice recorder.
Open the recorder.
Record five seconds of your voice.
Play the recording through the first device's speaker.

You should hear your recording clearly from the first device. This confirms that its microphone can capture sound.

Use the second device's system search to find its built-in voice recorder.
Open the recorder.
Record five seconds of your voice.
Play the recording through the second device's speaker.

You should hear clear playback from the second device. That audio loop is ready on both sides.

Use each device's app search to find the browser you normally keep updated.
Open the browser on each device.

You should see a browser start page on both screens.

Is a recording silent?

Raise the device's media volume before playing the recording again.
Confirm that the voice recorder can use the microphone in the device's privacy settings.
Move away from headphones so the recording plays through the device speaker.
Help me diagnose a silent recording on my device.

Prepare your coding workspace

The coding agent drafts the static page from your requirements. The local editor gives you a place to inspect its work.

Use app search or a browser tab on your primary computer to find your coding agent.
Open the coding agent.
Wait for its blank prompt to load.
Use system search on your primary computer to find your local editor.
Open the editor.
Create an untitled document without saving it.

You should see a blank prompt in the coding agent. Your editor should show an empty untitled document.

Does a build tool fail to open?

Check the coding agent's connection or sign-in state if its prompt does not load.
Restart the local editor if it cannot create an untitled document.
Help me get my coding workspace ready.

Confirm the gameplay boundary

The game uses audio encoding to turn a ball position into a chirp. The nearby browser converts that chirp back into a position.

What stays local?

Wi-Fi does not carry game moves. Bluetooth does not carry game moves.

A server does not relay game moves. Nearby sound carries gameplay after each browser has the page.

Before the final check, consider which missing item would block the first audio handoff.

Confirm that the first device played back a clear recording.
Confirm that the second device played back a clear recording.
Confirm that each browser shows its start page.
Confirm that the coding agent shows a blank prompt.
Confirm that the editor shows an untitled document.

You should hear clear playback from both devices. You should see a browser start page on each screen.

Your primary computer should show the agent prompt. Your editor should show an untitled document.

You're ready to build. Every part of the sound-to-screen loop now has a device or tool waiting for it.

Readiness Checkpoint

Two audio-capable devices, modern browsers, a coding agent, and a local editor are ready. No game files or hosted site exist yet.

Your devices and build tools are ready. Next, you'll experience the finished interaction on two devices so you know what your own game needs to achieve.

Try the Reference Game

Your two audio-capable devices are ready. A working reference gives you a concrete target before you build your own audio handoff.

In this step, you will watch a ball move between two screens through audible chirps. You will find the physical arrangement that keeps those chirps reliable.

In this step, get ready to:

Start two-player mode in the reference Chirp Pong game.
Observe a ball handoff between the two screens.
Find a reliable gap for the top-to-top device arrangement.

Start two-player mode

Each device displays one half of the same court. The top edge of each screen acts as the handoff point for the ball.

On your first device, open the reference Chirp Pong game.
On your second device, open the same reference game page.
On your first device, tap Play on two phones.
On your second device, tap Play on two phones.

You should see Pair the phones on both screens. Each device is now waiting for the audio connection.

Pair the devices with sound

The receiving microphone needs a clear path to the sending speaker. A top-to-top layout keeps the audio hardware close enough for reliable chirp detection.

The page needs microphone access for incoming chirps. A browser permission request can appear during the first audio check.

Set the media volume on both devices to maximum.
Switch off silent mode on both devices.
On your first device, tap Test this phone's speaker + mic.
Grant microphone access if your browser requests it.

You should hear the first device play its audio test. This confirms that the page can use its speaker.

Repeat the audio test on your second device.

You should hear the second device play its audio test. Both devices are ready for the two-way connection.

Lay both devices flat on a table.
Point the top edge of one device toward the top edge of the other device.
Leave a gap of a few centimetres between the top edges.
On your first device, tap Call the other phone.

The second device should answer by itself. You should then see one half of the court on each screen.

Can't pair the devices?

Return the devices to a gap of a few centimetres.
Confirm that microphone access is enabled for the page in each browser.
Reduce nearby music or conversation that could hide the chirps.
Run Test this phone's speaker + mic on each device again.
Help me troubleshoot two devices that cannot connect in Chirp Pong.

Find the reliable playing position

A successful handoff gives you a visible test for the audio link. Changing the gap shows where that link becomes unreliable in your room.

Drag anywhere on the first screen to move its paddle.
Drag anywhere on the second screen to move its paddle.
Continue the rally until the ball crosses from the first screen to the second screen.

You should hear a chirp as the ball leaves the first screen. You should then see the ball enter the second screen from its top edge.

Move the devices slightly farther apart.
Play another ball transfer at the new gap.

A successful transfer means the new gap still carries the ball reliably.

Repeat the spacing test until a transfer becomes unreliable.

The first missed transfer marks the edge of the reliable audio range for your current room.

Return the devices to the last gap that worked.
Play one transfer at the restored gap.

You should see the ball cross successfully again. This confirms the practical spacing you can reuse while building your own game.

Record the reliable gap here: your reliable spacing in centimetres.
Record the working position here: top-to-top.

Before the final check, do you expect the ball to cross to the second screen and return without a missed chirp?

Set the device gap to your reliable spacing in centimetres.
Place the devices in the top-to-top position.
Play one final rally with a handoff in each direction.

You should hear a chirp during each handoff. You should see the ball cross to the other screen before it returns.

You've captured the key benchmark. Your two-device rally now works with a known physical setup.

Your reference benchmark is clear. Next up, you'll ask your coding agent to generate the first two chirps for your own page.

Create the Chirp Sender

Your reference test showed what a complete two-device rally feels like. The first piece of your own version is the sound sender.

A sender turns each ball-position value into a short tone. The Web Audio API creates those tones directly in the browser.

In this step, get ready to:

Guide your coding agent to create the local index.html sender page.
Check that two ball-position values use distinct short chirps.
Play both chirps through your device speaker.

Ask your coding agent to build the sender

The sender needs only one local file. Keeping the page self-contained also prepares it for static hosting later.

Switch back to the coding agent from earlier.
Start a new request that describes a browser-based chirp sender.
State that the result must be a single static index.html file saved on your Desktop.
Require two labeled controls that each represent a different ball-position value.
Require each value to play a distinct short audio frequency through the Web Audio API.
Require visible status text that shows the last value sent.
Tell the agent to leave microphone input out of this version.
Submit the request to create the file.

Your coding agent may request permission to write the new file. Limit that permission to the index.html file on your Desktop.

Approve the file-write request if it appears.
Switch back to the local editor from earlier.
Use the editor's file navigator to confirm that index.html exists on your Desktop.
In Finder on macOS or File Explorer on Windows, select Desktop.
Double-click index.html to open it in your browser.

You should see two labeled chirp controls. You should also see an area that reports the most recently sent value.

Sender page missing or incomplete?

Confirm that the coding agent saved the file as index.html instead of returning the code only in the conversation.
Ask the agent to add the missing test controls if the page has fewer than two.
Check that your browser opened the new file from your Desktop.
Help me check why my local chirp sender page is missing its two controls.

✔️ The sender page is open

Good progress. Your local sender page now has the visible controls needed for the audio test.

ⓧ I'd like to double check the full code

Coding agents can organize the file in different ways. Confirm that your complete index.html includes every required part.

Confirm that the file contains the page structure for two labeled test controls.
Confirm that the file contains styling that keeps both controls usable on a phone screen.
Confirm that the script creates short tones through the Web Audio API.
Confirm that the script maps two ball-position values to two different frequencies.
Confirm that each control plays its mapped chirp.
Confirm that the page displays the last value sent.

Inspect the chirp mapping

Audio encoding gives each game value its own sound. The two mappings must stay visible so the receiver can decode the same frequencies later.

Why use two frequencies?

Each frequency acts as an audio label for one ball-position value. Distinct pitches give the later decoder two signals it can separate.

Return to the coding agent conversation.
Ask the agent to list the two position-to-frequency mappings used in index.html.
Record the first mapping's ball-position value as first ball-position value.
Record the first mapping's frequency as first chirp frequency.
Record the second mapping's ball-position value as second ball-position value.
Record the second mapping's frequency as second chirp frequency.
Switch back to the browser page.
Confirm that the control labels agree with the two mappings you recorded.

Test both chirps

A working sender produces a repeatable tone for each control. The pitches need to sound different enough that you can tell them apart.

Before you test, do you expect the two controls to produce the same pitch or noticeably different pitches?

Set your device's media volume to a moderate level.
Press the control for first ball-position value.

You should hear a short tone. The status area should show first ball-position value as the last sent value.

Press the control for second ball-position value.

You should hear another short tone at a different pitch. The status area should now show second ball-position value.

Alternate between the two controls several times.

You should hear two repeatable pitches. Each control should always produce its own chirp.

Can't hear one of the chirps?

Raise your device's media volume above mute.
Tap a chirp control directly after the page loads on iOS.
Ask your coding agent to choose frequencies closer to the middle of the speaker's range if one chirp remains faint.
Help me debug an inaudible chirp in my Web Audio API sender.

You have the sender working. Your page now turns two game values into distinct audible signals.

Next, you will listen for those chirps through the microphone. A live frequency graph will make each tone visible.

Visualize Microphone Frequencies

Your page can already turn two ball positions into distinct chirps. The receiving side still cannot see what its microphone hears.

In this step, you'll add microphone input through the Web Audio API. A live frequency graph will make each chirp visible as a spike.

In this step, get ready to:

Extend the local page with a microphone permission request.
Route the microphone stream through a frequency analyser.
Play a chirp to confirm it appears as a spike on the live graph.

Add microphone analysis

A microphone provides a continuous stream of audio samples. Your page needs an analyser between that stream and the graph so it can measure the strength of each frequency.

Return to the coding agent from the previous step.
Ask it to inspect the existing index.html before making changes.
Tell it to preserve the two existing chirp frequencies plus their test controls.
Tell it to request microphone access with getUserMedia after a deliberate user tap.
Tell it to connect the microphone MediaStream to an AnalyserNode through an AudioContext.
Tell it to render the analyser data as a continuously updating frequency graph.
Tell it to keep the chirp sender available while the graph runs.
Ask it to update index.html directly.

How does the audio pipeline work?

The getUserMedia request asks the browser for microphone input.
The returned MediaStream carries live audio from the selected microphone.
The AudioContext creates the browser audio pipeline.
The AnalyserNode exposes frequency strengths that the graph can draw.

Apply the coding agent's proposed update to index.html.
Switch back to the browser tab from earlier.
Refresh the local page.

You should still see the two chirp test controls. You should also see a microphone control plus a frequency graph.

Play each existing chirp from the refreshed page.

Both chirps should remain audible. This confirms the microphone update preserved the sender.

Missing the graph or chirp controls?

Ask the coding agent to restore the original chirp controls if either one disappeared.
Ask the coding agent to check that the graph element is present in index.html.
Ask the coding agent to inspect the browser console for a script failure.
Help me debug my microphone frequency graph.

✔️ Awesome, I've got everything!

Great. Your saved index.html now contains the chirp sender plus the microphone visualization.

ⓧ I'd like to double check the full code

Ask your coding agent to review the complete index.html against this checklist:

The original test controls still play two distinct chirps.
The getUserMedia request starts after a user action.
A microphone MediaStream connects to an AnalyserNode through an AudioContext.
The frequency graph redraws with current microphone data.

Watch a chirp become a spike

Microphone access can feel sensitive because the page starts listening to nearby sound. Your static page processes the frequency data inside the browser.

Use the microphone start control added by your coding agent.
Approve the browser's microphone request when it appears.

The graph should begin moving with the sound in the room. That movement confirms the microphone stream is reaching the analyser.

Why does the graph keep moving?

A microphone hears background noise even in a quiet room. A chirp stands out because it creates a concentrated rise at one frequency.

Before you test the chirp, predict whether the tone will create a narrow peak or a broad lift across the graph.

Play one of the existing chirps.
Watch the frequency graph during the tone.

You should see a clear spike rise above the surrounding frequencies while the chirp plays. The spike may disappear as soon as the short tone ends.

Play the second existing chirp.
Compare its spike position with the first chirp.

You should see the second spike appear in a different part of the graph. That separation proves the microphone can distinguish the two transmitted values.

No permission request or spike?

Serve the page from localhost with your editor's local preview if the browser blocks microphone access.
Check the browser's site permissions if microphone access was previously denied.
Move the device speaker closer to its microphone if the graph moves but the chirp does not stand out.
Reduce nearby sound if background noise hides the chirp spike.
Help me find why my chirp does not appear on the graph.

You have turned an audible chirp into visible frequency data. Next, you'll convert those spikes back into ball-position values.

Decode Received Chirps

Your Web Audio API graph already proves that microphone audio reaches the browser. The missing link is meaning because a frequency spike does not identify a ball position by itself.

Your coding agent will add a decoder that finds the strongest configured chirp. The page then turns that tone into a ball-position number for the receiving player.

In this step, get ready to:

Detect the strongest configured chirp in the microphone data.
Map the detected tone to its existing ball-position value.
Prove that a nearby device receives the position through sound.

Build the chirp decoder

The live graph gives you a picture of the incoming audio spectrum. A decoder uses the same data to decide which configured chirp is strongest.

How does the decoder decide?

The microphone analysis reports the strength of each measured frequency.
The decoder compares the signal near each configured chirp frequency.
The stronger clear match becomes the corresponding existing ball-position value.
Weak readings are ignored to reduce false matches from background noise.
The received-position display updates when the decoder finds a clear match.

In the coding agent from earlier, ask it to inspect your current index.html before implementing the decoder requirements above.
Save index.html in your local editor after the coding agent completes the edit.

Refresh the local page in your browser.

You should see a received-position display beside the existing frequency graph. The two chirp controls from earlier should still be available.

Do not see the received-position display?

Confirm that the coding agent edited the same index.html file that your browser preview loads.
Save the file again before refreshing the browser.
Ask the coding agent to preserve the existing sender controls when it adds the received-position display.
Help me find why the received-position display is missing from my page.

✔️ Awesome, I've got everything!

Great. Your page now shows where a decoded ball position will appear while keeping the sender controls and live graph.

ⓧ I'd like to double check the full code

Use this full-file contract while checking your current index.html:

The existing two-value chirp sender remains in the file.
The existing microphone input still feeds the live frequency graph.
The decoder reads the existing microphone frequency data.
The decoder checks which configured chirp frequency is strongest.
The strongest clear match maps to its existing ball-position value.
The mapped value appears in a received-position display.

Return to the coding agent from earlier.
Ask it to audit the complete index.html file against this contract.

Send a position between devices

The receiving browser needs active microphone access before it can decode a chirp. It may request permission again when you load the updated page.

Use the same microphone-capable preview method that worked in the previous step. This keeps the test focused on decoding instead of changing your preview setup.

Load the updated page on your sending device through the preview method from the microphone graph test.
Load the updated page on your receiving device through the same preview method.

You should see the chirp controls, live graph, and received-position display on both devices.

Approve the microphone request on the receiving device if the browser asks.
Use the existing page control on the receiving device to start microphone input.

The receiving device's graph should react to nearby sound. This confirms that its microphone analysis is active.

Place the devices top to top at the spacing you recorded during the reference game test.

Before you send the first chirp, which of the two positions do you expect the receiving readout to show?

Use the existing control for the first ball-position value on the sending device.
Check the received-position display on the receiving device.

You should see the receiving graph spike. The received-position display should show the first value selected on the sending device.

Use the existing control for the second ball-position value on the sending device.
Check the received-position display on the receiving device again.

You have crossed the key gap. One device can now turn a chirp from the other device into the matching ball-position number.

Chirp heard but no position received?

Confirm that the receiving graph reacts when the sending device plays a chirp.
Move the devices closer using the spacing that worked during the reference test.
Raise the sending device's speaker volume if the graph shows only a small spike.
Reduce nearby speech or music that could overpower the chirp.
Ask the coding agent to confirm that the decoder checks the same two frequencies used by the sender.
Help me debug why my receiving device shows chirp spikes but no decoded position.

Checkpoint

A second nearby device received a chirp through its microphone and displayed the decoded ball-position number.

Your sound link now carries ball positions between two devices. Next up, you will turn those positions into a Pong court with paddles, scoring, and a full rally.

Build the Two-Screen Pong Game

Your Web Audio API decoder can already turn a chirp into a ball-position number on another device. That proves the audio link works.

A number on the screen cannot create a rally by itself. The page needs a complete game layer.

In this step, you connect that game layer to the existing audio link. The ball then crosses between top-to-top devices through chirps.

In this step, get ready to:

Build a playable Pong court with player paddles.
Add ball movement with score tracking.
Transfer the ball between two nearby devices through chirps.

Build the game layer

The page already knows how to send a position through sound. The game layer gives that position a visible job when the ball crosses between screens.

What does the game layer need?

Each device renders a Pong court with one player paddle.
Player controls move the paddle on the current device.
Ball physics handle paddle bounces plus court boundaries.
Score tracking records the winner of each rally.
The page provides a way to choose which device starts with the ball.
The existing chirp sender transmits the ball position at the transfer edge.
The existing decoder turns a received position into an incoming ball.
A visible game control supplies the user gesture that starts play.

Switch back to index.html in your local editor.
Ask your coding agent to update the current index.html so it satisfies every requirement above.
Save index.html after the agent finishes its edit.
Refresh the local page from earlier.
Use the game-start control on the page.

You should see a Pong court with a player paddle. The ball should move inside the boundary.

You should also see the score on the page. The existing chirp controls should remain available.

That is a major shift. Your audio experiment now has a playable game layer.

Court missing or ball frozen?

Confirm that the agent edited the existing index.html file from the earlier steps.
Confirm that index.html is saved before refreshing the page.
Use the game-start control again if the ball remains still.
Ask the agent to restore the earlier chirp pipeline if any sender or microphone feature disappeared.
Help me debug my Pong court and ball movement.

Test one screen first

Local ball movement needs to work before you test the acoustic handoff. This smaller loop isolates paddle collisions from microphone detection.

Before you return the ball, where do you expect it to go after it touches your paddle?

Move the paddle under the approaching ball with the page's player control.

You should see the ball reverse direction after touching the paddle. The rally should continue inside the court.

Before you miss the next shot, which score do you expect to change?

Move the paddle away from the next shot.

The ball should pass the paddle. The score should update for the completed rally.

Start another round with the page's game control.
Keep the ball in play until it leaves through the transfer edge.

You should hear the outgoing chirp. The ball should leave the local court for transfer.

Ball bounce or score incorrect?

Ask the agent to compare the paddle collision area with the paddle drawn on the court.
Ask the agent to update the score only after the ball passes the player paddle.
Confirm that the outgoing chirp uses the ball position from the transfer edge.
Help me fix the local Pong game loop.

Play a rally across both devices

The final test reconnects the game layer to the acoustic link you already proved. Device placement now determines whether each outgoing chirp reaches the other microphone clearly.

Use the effective spacing you recorded from the reference game. Keep the devices in the same top-to-top orientation.

Return to the local game page from earlier on both devices.
Place the devices top to top at the effective spacing you recorded earlier.
Use the page's role control to choose one device as the starting side.
Use the other page's role control to make that device wait for the incoming ball.

Before you begin, where do you expect the ball to appear after it leaves the starting screen?

Use the game-start control on the waiting device.
Use the game-start control on the starting device.
Play one full rally until one player scores.

You should see the ball leave the starting court. You should hear the outgoing chirp.

The waiting device should draw the ball at the corresponding position. A later crossing should send it back.

Once a player misses, the score should change on the game page. That completed rally proves the full game loop works.

Ball not crossing between screens?

Restore the device spacing that worked during your reference-game test.
Raise the speaker volume on the device sending the chirp.
Move the devices to a quieter location if the decoder reacts to background noise.
Confirm that microphone permission remains enabled on the device waiting for the ball.
Help me debug the two-device Chirp Pong handoff.

That is the hardest integration complete. Two nearby devices have now played a full Chirp Pong rally with the ball crossing between screens through speaker-to-microphone audio.

Your local two-screen game works. Next up, you'll publish the page so both devices can load it from one public URL.

Publish the Game

Your local Chirp Pong game already completes full rallies through the Web Audio API. The ball can cross between two nearby screens as a chirp.

The game still lives in your local index.html file. That file does not provide a public link. Microphone access also needs HTTPS or localhost.

In this step, you'll store the complete page in a GitHub repository. You'll publish that repository with GitHub Pages so both devices can load the game from the same public address.

In this step, get ready to:

Create a public repository that contains the complete index.html game page.
Publish the repository as a static website with a public HTTPS URL.
Open the hosted game on both devices to complete another audio-powered rally.

Store the game in a repository

A repository preserves the finished game outside your local editor. It also gives GitHub Pages a source to publish.

Choose the path below that matches your current GitHub account state.

✔️ I have a GitHub account

Open the GitHub sign-in page in your browser.
Sign in with your GitHub account.

ⓧ I need a GitHub account

A free GitHub account can hold the public repository used for this deployment.

Open the GitHub sign-up page in your browser.
Complete the registration prompts shown by GitHub.
Sign in to your new GitHub account.

Why Use a Public Repository?

GitHub Pages is available through GitHub Free when the repository is public. Public visibility makes every uploaded file visible to anyone.

This static game does not require a password or API key inside index.html.

Remove any personal data or credentials from index.html before publishing it.

Open the new repository page in GitHub.
Enter your Chirp Pong repository name in the Repository name field.
Select Public under repository visibility.
Select Add a README file.
Click Create repository.

Your repository now has a default branch with its first tracked file. The storage piece is ready for your game.

Click the Add file dropdown above the repository file list.
Click Upload files.
Choose the existing index.html file from the project you built earlier.
Enter Add Chirp Pong game in the Commit message field.
Select Commit directly to the main branch.
Click Commit changes.

Good progress. You should now see index.html in the repository file list beside README.md.

Cannot See the Game File?

Return to the repository's main page to confirm the upload commit finished.
Repeat the upload if index.html is missing from the file list.
Check that the filename is exactly index.html so the host can use it as the site's entry page.
Help me diagnose why my uploaded index.html file is missing from my GitHub repository.

Publish the repository with GitHub Pages

GitHub Pages can serve a static file directly from a repository branch. Your one-file game needs no build process.

The hosted address uses HTTPS. That secure context allows the browser to request microphone access for chirp decoding.

Click Settings under the repository name.
Select Pages in the sidebar.
Choose Deploy from a branch under Source in the Build and deployment section.
Select main in the branch dropdown.
Choose the repository root in the folder dropdown.
Click Save.

The first publish can take up to 10 minutes, so a quiet Pages screen during that window is normal.

Wait for the deployment to finish on the Pages screen.
Click Visit site when it appears.
Confirm the browser address uses HTTPS.
Save the published address here: your public Chirp Pong URL.

Your game is live. You should see the complete court with the paddles, ball, scores, and existing game controls.

Hosted Page Missing?

Allow up to 10 minutes for the first deployment to finish.
Confirm main remains selected as the publishing branch.
Confirm index.html sits at the top level of the repository.
Help me diagnose why my GitHub Pages deployment does not show my Chirp Pong index.html page.

Test the hosted game on both devices

Each browser handles microphone permission for the hosted address separately. Each device also needs a user interaction before the game can start its audio features.

Before you test the public copy, do you think microphone access granted to the local page carries over to the hosted HTTPS address?

Open your public Chirp Pong URL in a modern browser on the first device.
Use the game's existing start control on the first device to activate its audio features.
Grant microphone permission when the first browser requests it.
Open your public Chirp Pong URL in a modern browser on the second device.
Use the game's existing start control on the second device to activate its audio features.
Grant microphone permission when the second browser requests it.
Position the devices top to top at the effective spacing you recorded earlier.
Play a rally until the ball crosses between the two hosted screens.

You should hear the transfer chirp from the sending device. You should see the ball continue from the matching position on the receiving device.

That is the full loop working from a public site. The hosted game can render the court, update the score, and exchange ball positions through sound.

Ball Not Crossing Between Devices?

Confirm both browsers show the hosted HTTPS address before checking microphone permission.
Use the game's start control again if a device has not activated audio playback.
Restore the top-to-top orientation from your successful local rally if the receiving device misses the chirp.
Help me debug why my hosted Chirp Pong game loads on both devices but does not transfer the ball through audio.

What You Have Now

A public GitHub repository named your Chirp Pong repository name contains the complete static game in index.html.

GitHub Pages serves that repository at your public Chirp Pong URL.

Both devices can load the HTTPS page, grant microphone permission, and play a rally through audio chirps.

Your Chirp Pong game has moved from a local experiment to a shareable two-device experience. The repository preserves the finished project while the public URL keeps it ready for another rally.

Secret mission

Stress-Test Chirp Reliability

A successful rally proves that your audio link works once. Can you measure how reliably the game transfers the ball across different distances and background sound levels?

Clean Up Your Resources

The hosted page has no ongoing cost. Decide whether to leave browser microphone permission active, pause by closing the game, or remove that permission.

Resources you used:

Microphone permission granted to the public HTTPS URL in each device's browser.

Keep everything running

No action needed. Choose this if you still play Chirp Pong across both devices.

Keep the repository unchanged.
Keep the hosted deployment unchanged.
Leave microphone permission enabled in each browser.

Pause - I'll come back to this later

Close the game for now while keeping every project artifact ready for another rally.

Close the Chirp Pong browser tab on each device.
Keep the repository unchanged.
Keep the hosted deployment unchanged.
Return to the public HTTPS URL on each device when you want to play again.

The game stops using the microphone once its browser tabs are closed.

Delete - I don't want to use this again

Revoking permission affects only the game's microphone access in each browser. The hosted page with its repository remains intact.

Browser permission controls can be easy to miss because they sit beside the address bar.

Open the public HTTPS URL on the first device.
Open the current site's permission controls from the browser address bar.
Remove microphone access for the current site.
Repeat the permission change on the second device.
Reload the public HTTPS URL on the first device.
Start microphone listening on the first device.

You should see your browser ask for microphone permission again before the game can listen for chirps.

Nice Work!

You did it! Your static Chirp Pong game now transfers the ball between two devices through audible sound.

From a public HTTPS page, you can place two devices top to top to play a full rally without Wi-Fi or Bluetooth. No server carries the moves.

You've learned how to:

Encode a ball position as short audio chirps that another device can hear.
Use the Web Audio API to turn a microphone frequency spike into a decoded ball-position number.
Publish a two-device Pong game at a public HTTPS URL where the ball crosses between screens through speaker-to-microphone audio.
Complete the optional Secret Mission to push the game beyond its core rally.

Ready to quiz yourself?