What is a web game port?
Most engines can export a browser build. Unity has its Web platform, Godot has a web export and Construct games are HTML5 from the start. A web game port goes further. The team also changes how the game behaves in a browser: download size, controls, audio, saves, ads and the first session.
If you want to see how other teams did it, read our list of mobile games ported to the browser. The steps below are the practical side of the same work.
1. Audit the source project
Start with the code and the build you have now. Before anyone writes new code, list everything the game depends on. From this list you can tell how big the port is.
- Engine and version. Write down the exact engine version and the render pipeline or renderer the game uses.
- Plugins and native code. Mark every plugin, native library and SDK. Code written for iOS or Android has no web version and needs a replacement.
- Assets. Measure the total size of textures, audio, video and fonts. Large atlases and long music tracks are the usual problems.
- Backend. Note logins, purchases, leaderboards, remote config and analytics, and check how each one talks to the server.
- Design. Check orientation, session length and how much of the game a new player sees in the first minute.
At the end of the audit you should know what you can keep, what you must replace and what you can drop for the web version.
2. Choose the engine for the web version
The next decision is whether to keep the original engine or move the game to another one. It depends on the engine and on how strict your target platform is.
- Unity. Unity's Web platform needs a browser with WebGL 2 and WebAssembly. Unity lists iOS Safari 15 and newer and Chrome 58 and newer on Android as supported mobile browsers. The usual risks are the size of the first download, memory use on phones and native plugins.
- Godot. The Godot 4 web export needs WebGL 2 and the Compatibility renderer. Godot documents that C# projects made in Godot 4 cannot be exported to the web yet. Since Godot 4.3, web exports are single threaded by default, and the Godot docs call this more compatible with web publishers such as Poki and CrazyGames.
- Construct. Construct games already run on HTML5. The work is mostly controls, performance on weak phones and the portal SDK.
- Other engines and native code. Games built in Swift, Kotlin, Java, Objective-C or an in-house engine have no web export. The team keeps the design, art and content and rebuilds the runtime in an engine with a good web target, such as Defold.
When the target portal is strict about download size, a move to Defold is worth checking. We describe the details in our guides to web porting with Defold and porting a Unity game to Defold.
3. Rendering and WebGL
In the browser, games are drawn with WebGL. Most mobile 2D and light 3D games fit well, but some effects need changes.
- Replace shaders that use features WebGL does not have. Test them in Safari as well as in Chrome.
- Cut draw calls with atlases and batching. Phones in a browser have less headroom than the same phones running a native app.
- Pick texture formats the target browsers support, and keep an uncompressed fallback for older devices.
- Handle a lost WebGL context, for example when the player switches apps on a phone and comes back.
4. Input: from touch to mouse and keyboard
Mobile games are designed for a finger on glass. In the browser, people may play the same game with a mouse, a keyboard, a touchpad or a gamepad.
- Map every gesture to a desktop action. A swipe can become arrow keys, a long press can become a right click or a held key.
- Show the right prompts for the device in use. A keyboard player should not see a tap tutorial.
- Stop the page from scrolling or zooming when the player touches the game area.
- Request fullscreen and pointer lock only from a click or a key press, because they are allowed only after user input.
- Release held keys and buttons when the tab loses focus, so no input stays stuck.
5. Asset size and loading
On a portal the player can leave before the game starts. Keep the first download small and load the rest while they play.
- Set a size budget for the first load early. Poki recommends an initial download of up to 5 MB and 8 MB in total. CrazyGames requires 20 MB or less for games shown on its mobile homepage.
- Compress textures and audio, remove unused assets and split levels or skins into packs you download later.
- Serve files with gzip or Brotli and cache them with versioned file names.
- Show real progress on the loading screen and go straight to play when loading ends.
Our article on HTML5 game optimization covers these techniques in more detail.
6. Audio and autoplay rules
In browsers, sound is blocked until the player interacts with the page. MDN describes the rule: audio may play once the user has clicked, tapped or pressed a key. Music that starts on its own in the editor stays silent in the browser.
- Start the audio system on the first click or tap, for example on a Play button.
- Pause the music when the tab is hidden and resume it when the player comes back.
- Mute the game during ads and restore the volume after them.
- Use compressed formats that every target browser can play, and test on iPhone with the silent switch on and off.
7. Saves and storage
On a phone, saves stay on the device. In the browser, saves go to storage that belongs to the site or the portal, and players can clear it.
- Move local saves to browser storage such as localStorage or IndexedDB, and keep them small.
- Test saves inside an iframe, which is how most portals show games. Unity notes in its documentation that Safari does not support IndexedDB for content running in an iframe.
- Use the portal's save system when there is one. The CrazyGames data module keeps progress in sync across devices for logged in players, with a limit of 1 MB of saved data.
- Plan a migration if players already have progress from an older web build.
8. SDKs, ads and web portals
Mobile ad and analytics SDKs do not work in the browser. Each portal has its own SDK for ads, rewarded videos, saves and gameplay events.
- Put all platform calls behind one small layer in the game code. Then for a new portal you write a new adapter and keep the gameplay code as it is.
- Call gameplay start and stop events when the portal asks for them. Portals use them to place ads at the right moments.
- Replace in-app purchases with the portal's options, rewarded ads or a simpler economy, depending on the platform rules.
- Remove everything the portal does not allow, such as links to app stores or external logins.
9. Performance testing on low-end devices
You may see a smooth frame rate on a laptop and dropped frames on a cheap Android phone. Test on the devices your players use, and start early.
- Keep a few older Android phones and an older iPhone in the test set, and test in Chrome and Safari.
- Measure the time to first interaction, the frame rate in busy scenes and memory use over a long session.
- Check what happens after a tab switch, a phone call or a screen lock.
- Test on a slow connection too, away from office Wi-Fi.
On iOS a browser tab has less memory than a native app. When a game uses too much, the page is reloaded in Safari, so watch memory as closely as frame rate.
10. Release on web portals
Each portal has a review with technical and content rules. Read them before you finish the port, because some of them affect the design.
- Prepare the portal assets: thumbnails, a short description, screenshots or a video, and the controls list.
- Check the build against the portal's technical requirements, such as size, SDK events and ad placement.
- Keep one codebase and produce a separate build for each portal through the platform layer.
- After launch, watch the portal's statistics for load drop off, session length and ad events, and update the game in small steps.
Who should do the port?
An in-house port works well when your team knows web builds and has time next to the mobile roadmap. If not, an outside team that has done web ports before will find the risks sooner. Our guide on how to outsource game development explains how to brief a studio and compare offers.
Codeward is a game studio from Kraków with many client projects behind it. We have ported mobile titles from Unity to Defold for the web, and our team includes experienced Unity developers with advanced C#. If you want Defold developers to join your own team, see hire Defold developers.