Reskin an Open-Source Browser Game

Reskin an open-source strategy game and publish it on GitHub Pages.

Introduction

30 Second Summary

A familiar game can feel completely different when its characters and colours belong to a new world. A strong theme can give the same rules a fresh identity.

In this project, you will reskin an open-source browser game with your own theme. You will publish the playable result with GitHub Pages at your own URL.

What You'll Build

You will open your own URL on your phone to play a full round inside a browser game transformed by your theme.

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

A playable themed fork running at your own public URL.
A before-and-after models page showing your redesigned unit next to the original designs.
A complete mobile play-through proving that your new colours and on-screen text work throughout a live game.
An optional Secret Mission to extend your themed game and push your skills further.

Are there any prerequisites?

You need a GitHub account and a browser.

A coding agent can help you edit the unit model.

Before We Start

Reskinning a browser game happens across two screens. Your desktop gives you room to work with GitHub.

Your phone later proves the finished game works for mobile players. This step gets both devices online.

You also need a signed-in GitHub account. It becomes the home for your public version of the game.

In this step, get ready to:

Confirm a desktop browser can access GitHub.
Confirm your phone can reach the web.
Prepare a signed-in GitHub account.

Check both browsers

Your desktop browser handles the GitHub work in this project. Your phone provides the final mobile test.

Press Cmd+Space (macOS) or the Windows key (Windows) to open system search.
Type the name of your installed browser into the search field.
Press Enter to launch it.

You'll see a browser window on your desktop. This confirms you have a place to manage the game project.

Tap the browser icon on your phone's home screen.

You'll see the phone browser open. This gives you the second screen needed for mobile testing.

Enter https://github.com in your desktop browser's address bar.
Confirm the GitHub homepage finishes loading.
Enter https://github.com in your phone browser's address bar.
Confirm the page finishes loading.

You should see the GitHub homepage on both devices. Both screens now have working internet access.

Prepare your GitHub account

A personal GitHub account lets you create your own public copy of the game. A verified email address gives the account access to basic repository tasks.

Account setup involves private credentials. GitHub's own forms are the only place those credentials belong in this project.

✔️ I already have a GitHub account

Your existing account only needs an authenticated desktop browser session.

Return to the GitHub homepage in your desktop browser.
Click Sign in.
Enter your GitHub credentials into the sign-in form.
Complete the verification prompt if GitHub shows one.

ⓧ I need a GitHub account

A personal account gives you the identity required to publish your version later.

Return to the GitHub homepage in your desktop browser.
Click Sign up.
Follow the prompts to create your personal account.
Verify your email address when GitHub asks.
Click Sign in if GitHub asks you to authenticate.

The GitHub homepage now shows your profile controls. This confirms your desktop browser is signed in.

Can't finish signing in?

Confirm the email address belongs to the GitHub account you want to use.
Complete any verification request sent by GitHub.
Help me troubleshoot my GitHub account access.

Verify your starting setup

The final check ties your devices and account into one ready state. Each screen proves a different part of the setup.

Before the final check, what do you expect each device to prove?

Refresh GitHub in your desktop browser.
Confirm your profile controls remain visible.
Refresh GitHub in your phone browser.
Confirm the homepage loads without a connection issue.

You'll see GitHub load on both devices. Your desktop session also shows that your account is signed in.

You've cleared the setup hurdle. The creative work can start from a connected account.

Next up, you'll compare Battle Drones with Panache. You'll see how a new theme can transform the same game.

Compare the Original and Panache

A convincing reskin starts with a clear baseline. Without one, it is hard to judge which changes preserve the game or create a new identity.

Battle Drones gives you the original gameplay baseline. Panache shows how Belle Epoque 3D unit models can transform that baseline.

In this step, get ready to:

Play a short round of the original Battle Drones game.
Play a short round of the Panache fork.
Compare the original units with Panache's redesigned Belle Epoque units.

Play the original Battle Drones

The original game is your reference point for every later change. Focus on how its units look during normal gameplay.

Open the Battle Drones game in a new desktop browser tab.
Start a short round from the game's opening screen.
Play until you have seen several units moving during gameplay.
Notice the shapes of the original units.
Notice the game's colour palette.

Good start: the original units are now your gameplay reference.

Game not loading?

Refresh the browser tab once.
Disable any content blocker for the Battle Drones page.
Try the page in a current desktop browser if it remains blank.

Help me troubleshoot the blank game page.

Play the Panache fork

Panache keeps the game recognizable while moving its setting into Belle Epoque France. Its introduction gives you the first sign of that new identity.

Open the Panache game in a neighboring browser tab.
Watch the animated introduction.
Start a short round from the game's opening screen.
Play until you have seen several redesigned units moving during gameplay.
Switch back to the original Battle Drones tab.
Compare the games' unit shapes.
Compare the games' colour palettes.

The contrast is already visible: Panache turns the familiar game into a different world through its presentation.

Compare the models pages side by side

The models pages let you inspect each design without a battle moving around it. This makes small changes in shape or decoration easier to spot.

Getting two browser windows aligned can be a little fiddly, but a rough half-screen layout gives you a clear comparison.

Open the original Battle Drones models page in a new browser tab.
Open the Panache models page in another browser tab.
Drag the original models tab away from the browser's tab bar to create a separate window.
Place the original models window on the left half of your desktop.
Place the Panache models window on the right half of your desktop.

Before you compare the galleries, which visual change do you expect to carry Panache's theme most strongly?

Scan the original models page from top to bottom.
Scan the Panache models page from top to bottom.
Drag one original model to inspect its shape from different angles.
Drag a corresponding Panache model to inspect its redesign.
Compare the silhouettes of the two units.
Compare their colours.
Compare their decorative details.

What should I see?

You should see the original Battle Drones units in the left window. You should see Panache's Belle Epoque redesigns in the right window.

Differences in silhouette, colour, and decoration make the two themes easy to distinguish. The side-by-side view shows how new models can change the identity of the same game.

Your visual baseline is locked in. Next, you'll fork Battle Drones on GitHub before publishing your untouched copy.

Fork and Publish the Game

Your comparison showed how the same game can carry a completely different visual identity. The next move is to place an untouched copy under your own GitHub account.

A public fork gives you space to change the game without affecting the original. Publishing that baseline with GitHub Pages proves your copy works before you start the reskin.

In this step, get ready to:

Create a public fork of the Battle Drones repository.
Enable the existing publishing workflow in your fork.
Load the untouched game from your own GitHub Pages URL.

Fork the Battle Drones repository

A fork keeps the original commit history inside your copy. It also retains the Apache 2.0 license that allows you to adapt the project.

Open the original Battle Drones repository in your desktop browser.
Click Fork in the top-right area of the repository page.
Select your personal account in the Owner dropdown.
Keep battledrones in the Repository name field.
Click Create fork.

You should see the repository under your username. The page also shows a link back to the original Battle Drones repository.

Your public fork is ready. You now control a complete copy while the original source remains intact.

Enable the publishing workflow

The repository includes a GitHub Actions workflow that builds the game for GitHub Pages. GitHub disables inherited workflows when a public repository is first forked.

The enable screen can look serious. The button activates every inherited workflow in your fork.

Click Actions in your fork's top navigation.
Click I understand my workflows, go ahead and enable them.
Click Settings in the top navigation.
Select Pages in the left sidebar.
Open the Source dropdown under Build and deployment.
Select GitHub Actions.

Why GitHub Actions?

Battle Drones needs a build process before GitHub Pages can serve it. The repository already contains the workflow that performs that build.

The workflow publishes from the main branch. Future changes on that branch can flow to the same public game URL.

The first publication can take up to 10 minutes. A short wait here means GitHub is building the game files.

Click Actions in the top navigation.
Select Publish Pages in the left sidebar.
Click Run workflow above the workflow runs.
Select main in the Branch dropdown.
Click Run workflow in the open menu.
Wait for the Publish Pages run to display a green check.

Publishing workflow not running?

Check the Actions page for the workflow enable notice.
Check the Source setting on the Pages page for GitHub Actions.
Check the Branch selection for main.

Ask for help with the workflow result: troubleshoot my Battle Drones Pages workflow

Open your published game

A successful workflow creates the public site attached to your fork. The final check confirms that the deployment serves the real game.

Click Settings in your fork's top navigation.
Select Pages in the left sidebar.

Before you open the site, do you expect its visuals to match Battle Drones or Panache?

Click Visit site on the GitHub Pages screen.

You'll see the familiar Battle Drones title screen from the original game. The browser address now belongs to your GitHub account.

That is a real milestone: the untouched game is running from your own public fork.

Record the published address here: your GitHub Pages game URL.

Site still unavailable?

Check the Publish Pages run in Actions for a green check.
Check the Source setting in Pages for GitHub Actions.
Wait up to 10 minutes before opening the site again.

Get help tracing the deployment: diagnose my unavailable GitHub Pages game

Your public baseline is live. Next up, you will choose a theme and redesign your first unit model.

Redesign a Unit Model

Your untouched fork is live on GitHub Pages. That proves your publishing pipeline works. Visitors still see the original Battle Drones identity.

This step gives your fork its first unmistakable themed unit. You will redesign the Scout. You will also publish a models-page comparison that makes the transformation visible.

In this step, get ready to:

Define your theme through a palette plus one signature model detail.
Redesign the Scout model to match your theme.
Publish the original Scout beside your themed version.

Define your visual theme

A clear theme gives every design choice the same direction. The palette controls the mood. A signature detail makes the Scout recognisable as your version.

Switch back to the original Battle Drones models page from earlier.
Focus on the Scout model's silhouette.
Switch back to the Panache models page from earlier.
Compare how Panache changes the unit's silhouette while preserving its role.
Record your theme here: your game theme.
Record your palette here: your colour palette.
Record one defining feature here: your signature model detail.

What makes the redesign readable?

The Scout must remain recognisable from above during a match. Keep its compact flying-drone footprint. Change visible forms such as the canopy, rotor guards, antenna, armour panels, or sensor housing.

Use your palette on large surfaces that remain visible at phone size. Use your signature model detail to connect the silhouette to your game theme.

Redesign Scout in the browser

Battle Drones builds its low-poly models through Three.js code. The Scout geometry lives in src/game/three/models.ts. Its visual portraits come from the same model.

GitHub Codespaces gives your browser enough compute to preview the model. Creating one uses account quota. GitHub shows who pays before the environment starts.

Return to your public Battle Drones fork.
Select the publishing branch that already serves your site.
Click Code above the repository files.
Select the Codespaces tab.
Review the message that identifies who pays for the codespace.
Click Create codespace.

The environment can take a few minutes to prepare. That delay comes from assigning the remote machine plus loading the repository.

Your browser-based development environment is ready when the repository files appear in the editor. That gives your coding agent the complete model source to work from.

Scout Model Requirements

Inspect the existing Scout definition in src/game/three/models.ts before changing it.
Preserve the Scout's compact drone footprint.
Add at least two visible geometric changes inspired by your signature model detail.
Apply your colour palette to prominent model surfaces.
Keep the Scout's gameplay identifiers plus statistics unchanged.
Keep the existing Apache 2.0 license plus source history intact.

Ask your coding agent to inspect the current Scout implementation.
Give your coding agent the Scout model requirements above.
Ask your coding agent to start the project preview after completing the first model pass.

Before you check the preview, which part of the Scout do you expect to make the theme obvious first?

Open the forwarded browser preview created by your coding agent.
Visit /tools/models.html?only=units inside that preview.
Find the Scout model in the unit gallery.

You should see the familiar Scout footprint with your new silhouette details. The prominent surfaces should use your colour palette.

That is the first visible transformation complete. Your fork now has a unit model that belongs to your game theme.

Gallery and Portrait Requirements

The public gallery needs to prove what changed. The themed model remains the version used by the game.

Preserve the original Scout geometry in comparison-only code.
Update models.html so the original Scout plus the themed Scout render side by side.
Label each version clearly on the models page.
Regenerate public/assets/icons/scout.webp from the themed model.
Regenerate public/assets/icons/red/scout.webp from the themed model.
Keep every other model card working as before.

Ask your coding agent to complete the gallery plus portrait requirements above.
Ask your coding agent to run the project build after finishing the changes.

Before you refresh the public gallery preview, what differences should be visible between the two Scout models?

Open /models.html in the forwarded preview.
Find the Scout comparison.
Rotate the themed Scout to inspect its silhouette.
Compare the themed Scout with the original version beside it.

You should see the original Scout plus your themed redesign in the same comparison area. The new palette plus signature detail should remain visible as you rotate the themed model.

Model Preview Not Working?

Ask your coding agent to check the browser console plus the latest Scout edits. A missing geometry argument or an invalid colour value can stop the viewer from rendering.

If the comparison works but the portraits remain unchanged, ask the agent to inspect the portrait-generation instructions in ICONS.md.

Help me troubleshoot a Battle Drones Scout redesign that is not rendering in the model gallery.

Publish the model comparison

Your fork's existing GitHub Actions workflow builds the current game after a push to the publishing branch. A successful run publishes the themed model plus its comparison page.

Select the Source Control view in your Codespace.
Stage the changed model files.
Stage the updated models-page files.
Stage both regenerated Scout portrait files.
Enter Redesign Scout for my theme as the commit message.
Open the dropdown beside Commit.
Select Commit & Push.

What happens after the push?

The repository's Publish Pages workflow builds the current game plus the models page. Its deployment job sends the completed site to your existing GitHub Pages URL.

Return to your Battle Drones fork on GitHub.
Select the Actions tab.
Select the newest Publish Pages run.
Wait for the workflow run to finish successfully.

A successful workflow run confirms that the model code builds. It also confirms that GitHub Pages accepted the new site artifact.

Pages Workflow Failed?

Open the failed job to identify whether the build or deployment stopped. Give the failed step to your coding agent so it can trace the problem back to the changed files.

Help me diagnose the failed Publish Pages workflow for my Battle Drones fork.

Before you open the published models page, do you expect the live site to show the original Scout or both versions?

Return to the GitHub Pages URL from earlier.
Append models.html to the existing URL path.
Refresh the page after the workflow succeeds.
Find the published Scout comparison.
Rotate the themed Scout in the live viewer.

You should see the redesigned themed Scout beside its original Battle Drones counterpart. The themed model should respond to rotation controls at your public GitHub Pages URL.

Strong work. Your fork now has a committed model redesign plus the visual evidence to prove it.

Your first themed unit is published. Next up, you will carry the same identity into the game's colours plus on-screen text.

Apply Your Theme to the Game

Your redesigned unit already appears beside its original counterpart on the published models page. That gives your theme a visible anchor.

The original palette still surrounds your redesigned unit during play. One familiar label also keeps the old identity visible.

In this step, get ready to:

Replace the game's visible colour palette with your theme colours.
Rename one label visible during a live match.
Verify the published reskin in your browser.

Apply your colour scheme

Recurring interface colours make the game feel like one visual world. Menus repeat those colours. Match controls repeat them too.

Switch back to your public GitHub fork from the previous step.
Use the repository's file search to locate the colour values that style the game menu.

You should see source matches connected to the menu or interface styles. These matches reveal where the original visual identity is defined.

Check the matching files for the same palette in the in-match interface.
Use the browser editing workflow from your model redesign to replace the recurring identity colours.
Choose replacement colours with strong text contrast.
Review the diff for unintended changes to health colours or warning colours.

The diff should show focused colour changes in the interface source. Gameplay rules should remain untouched.

Commit the colour changes to the branch used by GitHub Pages.

The fresh deployment can take a few minutes. A short wait here is normal.

Switch back to your published game after the deployment finishes.
Reload the page.

You should see your theme colours on the menu. You should also see them inside the match interface.

The reskin now reaches beyond one model. Your redesigned unit belongs in its surroundings.

Still Seeing the Original Colours?

GitHub Pages may still be publishing your commit. Wait for the deployment to finish before reloading the game.

Your browser cache may keep the previous build. Reload the page without using the stored version.

If the old colours remain, confirm that your commit reached the publishing branch. Help me find why my Battle Drones colour changes are missing from GitHub Pages.

Rename an in-game label

A short label can connect the interface to your redesigned unit. Choosing text that appears during play gives you a clear test after publishing.

Switch back to your published game.
Start a temporary browser match.

You should now see labels inside the active match. Pick one that you can reveal again without playing a full round.

Choose a short label connected to your redesigned unit.
Record the exact label here: current in-game label.
Choose its themed replacement here: your themed in-game label.

Why Change Display Text Only?

A visible label carries your theme into the match. The internal identifier may connect that unit to gameplay logic.

Keeping internal identifiers unchanged protects the unit's existing behaviour.

Return to your GitHub fork.
Search the repository for current in-game label.

You should see one or more exact source matches. The correct result supplies text to the live game interface.

Open the source result that supplies the visible label.
Replace the current display text with your themed in-game label.
Review the diff for changes beyond the visible string.

The diff should show one focused text replacement. The surrounding unit logic should match the previous version.

Leave the repository license unchanged.
Leave the original project credits unchanged.
Commit the text change to the publishing branch.

Verify the live reskin

The second publish has the same short delay. Give the updated site a few minutes to become available.

Before you reload the game, which colour change do you expect to notice first? Where should your renamed label appear?

Wait for the latest deployment to finish.
Reload your published game.
Start a browser match.
Navigate to the control or unit that carries your themed in-game label.
Confirm the themed text is visible.
Confirm your theme colours are visible in the live interface.
Switch to the models page from your published site.
Confirm the redesigned unit remains beside its original counterpart.

You should see the new palette throughout the live interface. The renamed label should appear in its expected match location.

That completes the visual handoff. Your published game now carries the same theme as your models page.

Seeing Only Part of the Reskin?

If the colours changed without the label, check that the text commit reached the publishing branch. Search the deployed source match again if you edited a duplicate string.

If the label changed without the colours, confirm that the colour edits affect files used by the live game. Help me troubleshoot my partially deployed Battle Drones reskin.

Your fork now carries your theme through the model and live interface. Next up, you will play a full round on your phone to prove the reskin works end to end.

Publish and Play a Full Round

Your themed Battle Drones fork already works in a desktop browser. The public site now needs its final release check.

A full round on your phone tests the game from start to finish on a real mobile screen. A source check confirms the Apache 2.0 license plus its attribution materials remain with your fork.

In this step, get ready to:

Confirm the public game matches your finished desktop version.
Verify the release includes its complete public record.
Play one full round on your phone.

Confirm the public release

Your GitHub Pages site is the player-facing release. Your public fork is the source record that preserves credit for the original work.

Switch back to the live game tab from earlier.
Refresh the page with your browser's refresh control.
Check that your redesigned unit appears in the game.
Check that your chosen colour scheme remains visible.
Check that your theme-specific on-screen text appears.

You should see the same themed release that you approved during the desktop test.

Switch back to the published models page from earlier.
Refresh the models page with your browser's refresh control.
Confirm that the redesigned unit appears beside its original counterpart.
Return to your public repository fork from earlier.
Confirm that the original license plus its attribution materials remain present.
Confirm that the repository still retains its original source history.

The live game, models comparison, and repository credit now form a complete public release.

Play a full round on your phone

The desktop check proves that your visual changes are deployed. A full mobile round tests the controls plus the complete game loop.

Before you load the game on your phone, do you expect the mobile release to match the desktop version throughout the entire round?

Open the web browser on your phone.
Enter the fork's GitHub Pages URL from earlier in the address bar.
Load the address with your browser's navigation control.
Start a new round with the game's start control.
Confirm that your chosen colour scheme appears during the round.
Confirm that your changed on-screen text appears during play.
Confirm that your redesigned unit appears during play.
Play through the round until it reaches its normal conclusion.

You should reach the game's end state with all three theme changes intact.

That is the finish line: your themed fork now works through a complete mobile round at its public URL.

Seeing an older release on your phone?

Reload the page with the browser's refresh control if your old colours or text still appear.
Close the game tab if the stale release remains after a refresh.
Use a fresh tab to load the same GitHub Pages URL again.

Ask for help if the mobile browser still shows the earlier version: Help me troubleshoot why my GitHub Pages game looks updated on desktop but stale on my phone.

Secret mission

Audit Your Theme Across Devices

Audit your published game in a desktop browser. Repeat the audit on your phone. Compare both versions with the models page to prove that your theme stays recognizable.

Clean Up Your Resources

Your published fork can stay online through GitHub Pages with no ongoing project charges. Choose whether to keep it available, pause its hosted site, or delete the fork entirely.

Resources you used:

The public Battle Drones repository fork on GitHub that contains your complete themed game and required attribution materials.
The GitHub Pages deployment that serves the reskinned game and models comparison page.

Keep everything running

No action is needed. Choose this option while you want people to play your themed game.

Leave the public Battle Drones fork available on GitHub.
Keep the Apache 2.0 license and attribution materials in the repository.
Leave GitHub Pages publishing enabled for the selected branch.

Pause - I'll come back to this later

Pausing takes the game offline while preserving every committed theme change in your fork. You can re-enable the same publishing branch when you are ready to return.

Return to your public Battle Drones fork on GitHub.
Open the repository settings page.
Go to the GitHub Pages publishing controls.
Disable the current publishing source.
Visit your fork's GitHub Pages URL.

You should no longer see your themed game at the URL. Your committed game and models page remain safe in the fork.

Delete - I don't want to use this again

Deleting the fork is permanent, so take a breath before choosing this option. It removes your themed source and takes the GitHub Pages site offline.

Return to your public Battle Drones fork on GitHub.
Open the repository settings page.
Scroll to the repository deletion controls at the bottom of the general settings.
Choose the permanent repository deletion option.
Type the repository's full name shown in the confirmation prompt.
Confirm the permanent deletion.
Visit the former GitHub Pages URL.

You should no longer see the game or its models page at that URL. This confirms that both listed resources have been removed.

Nice Work!

You did it! Your themed Battle Drones fork is live on GitHub Pages at its own URL. It has survived a full round on your phone.

You've learned how to:

Publish a public fork at your own playable URL. Preserve the original license materials. Keep the original attribution visible in the repository.
Redesign a unit model around your chosen theme. Apply a matching colour scheme. Replace one on-screen text string. Present the result on a models page beside the original.
Run a mobile play test on the deployed game. Prove the reskin works end to end by finishing a full round on your phone.
Secret Mission: Complete the optional challenge to push your published game beyond the core reskin.

Ready to quiz yourself?