Reskinning Unity Games: A Step-by-Step Guide

Reskinning has a bad reputation, largely earned by people who changed the colours and hit publish. Done properly it is a legitimate production method: you take a validated mechanic and build a genuinely different game on top of it, in a fraction of the time building from scratch would take.

The order matters more than most guides admit. Doing these steps out of sequence is how people end up with broken prefab references and a project they cannot build.

Step 1: Get a clean build before changing anything

Open the project in the exact Unity version the seller specified. Not a newer one — upgrades can be done later, deliberately, once you have a known-good baseline.

Build for your target platform and run it on a real device before you touch a single asset. If you skip this, you will not know later whether a problem came from the template or from your changes. This is the single most valuable habit in the whole process.

Step 2: Read before you edit

Spend an hour understanding the structure. Specifically, find: where the game state machine lives, how levels are defined and loaded, where scores and progression are saved, and where ads and analytics are called from. You do not need to understand every line — you need to know which four or five files matter.

Step 3: Replace art in place

The safest approach is to overwrite the existing texture files rather than importing new ones and repointing references. Keep the same filenames and, where possible, the same dimensions and import settings. Prefab and material references then survive untouched.

• Match the original resolution and aspect. Different dimensions change how sprites sit in layouts, especially with 9-slice UI.
• Watch sprite atlases — if the project packs atlases, replacing a source sprite is fine but changing its size can shift packing.
• Preserve alpha and pivot settings. A changed pivot moves every instance of that sprite.
• Replace particle textures too. They are easy to miss and instantly recognisable to anyone who has seen the original.

Step 4: Audio, fonts and colour

Audio is the most under-used differentiator. Players identify games by sound faster than most developers expect, and swapping the music and core SFX changes the feel disproportionately to the effort.

Fonts change perceived identity more than almost anything else — and check the licence permits embedding in an app. If the project uses a central theme or palette asset, change it there rather than editing individual objects.

Step 5: Make it a different game

This is the step that separates a legitimate release from one that gets rejected. New art alone is not a new product, to app stores or to players.

• Redesign the levels. If levels are data-driven, this is often just a config file and it is the highest-value change you can make.
• Retune the difficulty curve — speeds, spawn rates, timers. This alters how the game actually feels to play.
• Add or remove a mechanic. Even one new obstacle type or power-up meaningfully differentiates the experience.
• Rework the progression and reward pacing, which drives retention more than the core loop does.

Step 6: Identity and store configuration

1. Set a new bundle identifier and product name in Player Settings.
2. Replace app icons at every required resolution, and the splash screen.
3. Replace ad unit IDs and analytics keys with your own. Shipping the template author's IDs sends your revenue to them — this happens more often than you would think.
4. Update the privacy policy URL and confirm the consent flow works in the regions you target.
5. Regenerate signing keys. Never ship with a key that came inside a template.

Step 7: Test properly

Test on real devices, including at least one low-end Android handset. Check multiple aspect ratios — notches and tall screens break UI that looked fine in the editor. Verify that ads load and, critically, that the game behaves correctly when they fail to load, which is the more common case in practice.

Mistakes that cause rejections

• Changing too little. The most common cause of a rejection or removal.
• Leaving the original game's name or branding in strings, achievement IDs or the store listing.
• Shipping placeholder assets the template used for demonstration.
• Forgetting to replace ad IDs, which is both a revenue loss and a policy problem.
• Publishing several near-identical reskins from one developer account, which stores treat as spam.

A useful benchmark: could someone who played the original recognise yours as the same game? If yes, you have not finished. If they would recognise it as the same genre — that is fine, and normal.