Browser game development: from an idea to a link people can play

People usually think of commissioning a game because of an occasion: an anniversary, a campaign, a subject that is hard to teach in class. Then the questions arrive. Who builds this sort of thing, will it open on a phone, how do you even describe a game to someone? This guide explains browser game development from the client’s side, in the order you will meet each decision.

What a browser game is

A browser game runs inside a web browser. It opens like a web page. Nothing is installed, because the game is written with web technologies the browser already understands.

Years ago these games needed a separate plug-in. Browsers now draw graphics, play sound and read touch input by themselves. That is why one game can open on a computer and on a phone.

There is a limit. A game in the browser cannot use the device as freely as an installed one. Card games, puzzles, platform games and quizzes suit it very well. Very large three-dimensional worlds do not.

Browser or app store: the mobile question

When people ask for a mobile game they can mean two different things, and the two are often confused.

The first is a store app. It is downloaded to the phone and its icon sits on the home screen. That requires a developer account with the app store, a review by the store and a fresh submission for every update. It takes longer and involves more work.

The second is a game that opens in the browser on the phone. There is no download. Tapping a link is enough. For gifts, campaigns and teaching games this is usually what is needed. Asking someone to install an app puts a hurdle between them and the game.

To tell which one you need, think about how long the game will be played. If it is played once or for a few days, the browser is enough. If it has to stay on the phone for months and send notifications, a store app is the conversation to have.

Write the idea on one page

Telling a developer “I want a fun game” is like telling a tailor “I want a nice dress”. Each of you pictures something else. Answer these questions in writing before the first meeting.

• Who will play? A seven-year-old and a forty-year-old do not play the same game.
• What does the player do? Jump, match, answer questions, collect things.
• How do they win, and how do they lose?
• How many minutes does one session last?
• Where will it open: on a phone, on a computer, on a large screen at an event?
• What makes it yours? Names, photographs, a story, a logo, the facts to be taught.

Personalized games: what makes them work

Personalized games are built around one person or one brand. The mechanics can be simple. What carries the game is recognition: the player sees their own street, their own dog, a joke only two people understand.

That puts the weight on the material you supply. Gather the photographs, the names and the small stories before the build starts. Check that the people in the photographs would be happy to appear. A late change to the story costs more than a late change to a colour.

Keep it short. A gift game that takes ten minutes and ends on a message is played to the end. One that takes two hours is abandoned at level three.

What decides the cost

This guide gives no figures, because a figure quoted without the scope misleads. Knowing what the price is made of lets you read a quote.

Artwork is usually the largest item. Every character, background and movement is drawn separately. Ready-made art packs shorten the work but make the game look like others.

The second item is the number of levels and how involved the rules are. A one-screen quiz and a ten-level adventure are far apart in effort. Sound and music, a scoreboard, saved progress and extra languages each add work of their own.

The last item is testing. The more devices and browsers the game has to run on, the more places it has to be tried.

Common mistakes

• Starting too big. Three good levels beat twenty unfinished ones.
• Leaving the phone until last. A game designed for a keyboard can become unplayable on a touch screen. The device should be settled on day one.
• Forgetting sound. Browsers generally do not play audio until the user has touched the page. The opening of the game has to allow for that.
• Using protected material. A famous character or a well-known song cannot be used without permission. Use artwork and music that are yours.
• Not testing with the real audience. If the game is for children, let a child play it before delivery.

A small game that is well described gets played more than a large one left vague. Once the idea is on one page, half the work is done. At Webitro we begin by listening to that idea, put the design in front of you for approval and deliver the game playable in the browser or on desktop.