Thank you!
Your request has been sent.
We'll review your request and get back to you within 1–2 business days.
Thanks for the feedback!
We appreciate you helping us improve.
Art built for
browser game pipelines
UI/UX, concept art, characters and props produced to your specifications – 2D and 3D art drawn from two stylized mobile games.
2 stylized mobile games with our UI/UX, concept art, characters and props – no browser project published
Request a Quote
01 · The Platform
HTML5 games run inside a web browser and are built with HTML, CSS and JavaScript, often with WebGL for 2D and 3D graphics. Players can open them through a link on supported devices, without necessarily installing a separate client. Compatibility depends on the browsers and hardware the team targets, so load size and rendering limits matter for each asset.
There is no single hardware target. WebGL needs support from both the browser and the device's GPU, so a project defines which browsers and devices it supports, and the art specifications follow that list.
Art for web games: UI/UX · concept art · characters
CONTEXT 01
Browser games are often accessible without installing a separate client, which makes the initial loading experience important. Texture dimensions, exported file sizes and sprite atlas organization can influence loading requirements. Your development team defines when and how assets are loaded.
Art priority: compact texture sets, organized sprite atlases, assets grouped for staged loading
Agreed at the brief: file-size limits, which assets your team loads first
CONTEXT 02
The same game may be opened on a desktop monitor, a laptop or a phone browser. Interfaces and key art have to hold up across aspect ratios and screen sizes.
Art priority: flexible UI layouts, scalable icons, readable text and contrast
Agreed at the brief: supported browsers and devices, screen sizes, who builds the layouts
CONTEXT 03
Web games draw through technologies such as WebGL, which remains important for browser compatibility, while WebGPU offers a newer graphics API. WebAssembly is used alongside JavaScript. Your engine and team decide which of them a game relies on, and that shapes shader, material and texture limits.
Art priority: assets prepared to the renderer and format limits your team sets
Agreed at the brief: engine, renderer, texture and file formats
CONTEXT 04
Some browser games are built around 2D or stylized art, where interface, characters and props carry most of the look. A stable style reference keeps a library of such assets consistent.
Art priority: consistent style, reusable assets, clear naming
Our related work: UI/UX, concept art, characters and props on two stylized mobile games (see Cases)
Looking at the platform from the genre side?
See our casual and puzzle game art.
02 · Platforms
Public documentation shows what the target looks like. Exact requirements for a project come from your team.
Web games are played in desktop and mobile browsers, and support for graphics features differs between them. WebGL renders 2D and 3D graphics in the browser without plug-ins. WebGPU is a newer API with limited availability, so some engines keep WebGL 2 compatibility. WebAssembly is a low-level bytecode format designed to work alongside JavaScript.
Engines such as PlayCanvas, which runs on WebGL and WebGPU, and frameworks such as Phaser target the web directly. Godot can export to the browser and requires WebAssembly and WebGL 2.0 support from the player's browser. The choice is made by your team.
03 · Engine
The engine and framework are chosen by your team; we deliver to the pipeline you use. For a web project we agree a specification sheet with your team: supported browsers and devices, resolution and aspect ratios, texture and sprite limits, file formats, naming and file structure. We produce assets to that sheet and organize the source files for handoff.
Possible scope, confirmed at the brief:
| Deliverable | Detail |
|---|---|
| UI asset exports | Icons, buttons and panels exported at the resolutions and formats your team specifies |
| Sprite sheets and atlases | Character and prop frames organized to your size limits |
| 2D character and animation files | Layered source files and exported frames or animation assets for your engine |
| Responsive layout variants | Interface variations for the aspect ratios you support |
| Vector or raster sources | Scalable sources for interface art where your pipeline allows |
| Texture and material sets | For 3D assets, textures and materials prepared to your renderer's limits |
| Source files and handoff | Organized, named, editable files |
| Task | Who does it |
|---|---|
| Asset production: UI/UX, concept art, characters, props | Nasty Rodent |
| Specification sheet: browsers, limits, formats, naming | Agreed with your team at the brief |
| Organized source files and handoff | Nasty Rodent |
| Game development, engine integration, build size, performance testing | Your team; not part of our services |
| Browser compatibility testing and publishing | Your team and the platform or portal |
| Adapting existing mobile or PC assets for web | Possible scope; not demonstrated by our cases, confirmed and scoped separately |
04 · Studios
The right setup depends on where the game is in production.
| Studio | What you need | Typical scope | How we plug in |
|---|---|---|---|
| Teams building a browser-first game | A style and an asset library planned around loading limits | Possible scope: interface kit, characters, props, key art to your specifications | A dedicated team under our art director |
| Teams bringing a mobile or PC game to the browser | Additional assets in the existing style | Possible scope: new UI layouts and asset batches built to your style reference and art bible | Confirmed at the brief |
| Teams with a live web game | Steady content against an agreed specification sheet | New content batches | A long-term partner or Team Extension |
Scoping the art for your first playable slice
05 · How We Work
Web production runs from supported browsers to art specifications, production and handoff. Choose the model for where you are – it can change as the project does.
You provide an agreed asset list – interfaces, characters, props or concept art – and our art director and project manager coordinate the production and delivery of those assets through the approved review stages.
Our artists work within your pipeline and under your art direction – you run the process, we add the capacity and the skill.
Before production we agree the specification sheet described above, and production and handoff follow it. Integration and performance testing stay with your engineers.
06 · Cases
We have not published a project delivered for a browser or HTML5 game. The closest evidence is our work on two stylized mobile games, where we produced interfaces, concept art, characters and 2D assets.
UX/UI, 2D props, 2D environment and concept art. A web version is not documented.
View the Wave Master case
Concept art, 2D and 3D characters, rig, 2D props and environment, 2D and 3D animation, and UI/UX. A web version is not documented.
View the Bubble Quest of Vikings case07 · The Evidence
| Topic | Confirmed on our cases | Agreed with you at the brief |
|---|---|---|
| Interface design | Wave Master, Bubble Quest of Vikings | Screen sizes, layouts, who builds them |
| Concept art and characters | Wave Master (concept art), Bubble Quest of Vikings | Style, number of characters |
| 2D props and environments | Wave Master, Bubble Quest of Vikings | Kit size, scale, sprite limits |
| Assets for browser or HTML5 games | Not shown on these cases | Browsers, engine, loading limits from your team |
| Game development, build optimization, porting | Not part of our services | Handled by your team |
Building a
Browser Game?
Tell us about your game, your supported browsers and your content plan. We come back with questions and a draft scope in 1–2 business days.