Development notes
How game development works: from first launch to playing again
From our work at Onknee Games, an independent game studio based in Portugal.
Game development covers the whole player journey, from opening a game for the first time to wanting to come back. First, players need to get through loading and understand the controls. Then they need to enjoy an action, see its result and find a reason to continue.
Technical and design decisions work together along this journey. Fast loading helps people reach the game, a clear interface helps them get comfortable, and reliable saving lets them finish a session and pick it up later.
The first second starts with the choice of technology
We use Unity for Success Saga, Pet Rock Workshop and a new mobile project. Parking Chain, Brainrot Merge Squad, Needle Quest and Skyloop Minigolf are built in JavaScript.
Unity provides tools for scenes, graphics, animation, physics, interfaces and builds for different platforms. These are useful as a project grows, adds content and brings together several interacting systems. Unity’s capabilities.
For a small browser game, the priority may be a minimal initial download. In that situation, Unity’s general-purpose runtime is often more than the project needs.
Native JavaScript lets us choose the components we need, control loading order and work directly with browser APIs. JavaScript can also support 3D games: Needle Quest and Skyloop Minigolf both use it for that purpose.
The technology also shapes how the team works. Some projects benefit from the engine’s existing tools; others benefit from an architecture built around a specific task. Modern tools, including AI, help us explore alternatives, draft solutions and investigate errors. The solutions we choose are then checked in a working game and on target devices.
What can a player’s connection actually download?
For a short browser game, we aim to make the first playable action available in roughly a second. Someone arrives through a link, and a long wait can end that first encounter before play begins.
Real-world connections show the scale of this challenge. SpeedOf.Me’s report for the first half of 2026 publishes median browser-test download speeds by country. Countries need at least 500 tests to appear in the ranking, which combines different types of connections. Report and methodology.
For concrete examples, take two of our games. Needle Quest’s published web package, version 0.52.0, is about 9.7 MB. For the Android version of Success Saga 0.261, Google Play Console reports a download size of 134 MB for new installs.
These downloads occur at different points in the player journey: browser resources load when someone opens a link, while a mobile app is installed beforehand. The table estimates how long it takes to transfer these amounts at the median test speeds:
| Country | Median test speed | Needle Quest · 9.7 MB | Success Saga · 134 MB |
|---|---|---|---|
| United States | 143.5 Mbps | 0.5 s | 7.5 s |
| Portugal | 110.1 Mbps | 0.7 s | 9.7 s |
| Germany | 60.3 Mbps | 1.3 s | 17.8 s |
| Brazil | 51.3 Mbps | 1.5 s | 20.9 s |
| India | 33.9 Mbps | 2.3 s | 31.6 s |
| Russia | 20.8 Mbps | 3.7 s | 51.5 s |
| Indonesia | 15.5 Mbps | 5.0 s | 69.2 s |
| Egypt | 11.5 Mbps | 6.7 s | 93.2 s |
These figures use the formula MB × 8 ÷ Mbps; they are calculations rather than measured startup times. For Needle Quest, the reference is the publishing ZIP: the platform extracts it and serves individual files to the browser. For Success Saga, the reference is Google Play’s download estimate, which can vary by device. The examples illustrate the scale of data transfer rather than compare engine efficiency.
Startup also includes preparing code, graphics and resources. Some of this work can happen while files are downloading. That is why the full time until controls become available needs to be measured on target devices.
Initial downloads can be reduced through suitable image and audio formats, removing unused resources, compression and loading later content on demand. The first level does not need to wait for everything a player might use half an hour later. Browser-game loading techniques.
Caching helps repeat visits. The first visit still needs its own checks, with no files already cached and a connection that reflects the audience.
After loading, players need to feel in control
Once the game is ready, attention shifts to the action: is it clear where to tap, is the response visible, and do the controls feel comfortable?
On a phone, we need to account for finger placement, a small screen and familiar gestures. On PC, the considerations include mouse and keyboard input, different resolutions and other input devices. The same game rule may need a different presentation.
In Needle Quest, we specifically coordinated touch input with the click generated by the browser: one tap should produce exactly one action. That precision makes an interface predictable.
Moving to mobile also affects the application’s structure. On iOS, Needle Quest’s JavaScript and Three.js game code runs inside a Swift host with WKWebView. The game resources are included in the app, while the native layer connects the game to device capabilities.
Preparing the iOS version includes building in Xcode, checking real devices, signing, uploading to App Store Connect, testing through TestFlight and preparing for App Review. Apple’s workflow.
The finished version should deliver a simple result: people can reach the game quickly, understand the first action and get the response they expect. This is where technical readiness becomes the first player experience.
Bounce rate: how much attention is lost at the first encounter?
People arriving at a game follow the same path: loading, understanding the screen and learning the controls. Some may stop at any of those steps.
Bounce rate helps assess early losses. In GA4, for example, it is the share of sessions that did not meet its engagement criteria. For development, its practical value is in understanding how often that first encounter ends before the game has had a chance to draw someone in. GA4’s definition.
Similar exits can reflect different experiences. One person gets tired of waiting. Another taps the screen and cannot tell whether anything happened. A third finds a game that does not match the expectations set by its cover or advertisement.
Bounce rate therefore needs to be considered alongside startup speed, the first meaningful action and the traffic source. When people leave during loading, we investigate the technical startup path. If the game is ready but people do not begin interacting, we examine the first screen and controls. If early exits are especially common for one traffic source, we compare what the advertisement promises with the actual opening experience.
Improving that first experience makes audience acquisition more effective: more of the people who have already arrived get to discover the game itself. The next question is whether their interest lasts beyond those first actions.
The first few minutes: from learning to playing independently
Players have learned the controls and seen a result. Now they need an opportunity to use what they have learned: solve the next task, try another approach or put a reward to use.
Conversion rates to 30 seconds, one minute, two minutes and five minutes show what proportion of first sessions reaches each milestone. Looking between adjacent milestones helps investigate a particular part of the experience. For example, conversion from two to five minutes shows how many of the sessions that reached two minutes continued to five.
At these points, we examine pacing, difficulty and the clarity of the available actions. A new decision or a noticeable improvement in the player’s capabilities can sustain interest. Extra confirmations, unexplained waiting and repetition of what has already been learned can interrupt that flow.
This analysis needs an agreed definition of playing time, with loading, background time and ad pauses accounted for separately. Comparisons also need to consider game versions, devices, traffic sources and the team’s own test sessions.
The first session should offer a comfortable stopping point
The length of a first session does not explain how it ended. Someone may have lost interest, encountered a difficulty or simply completed what they intended to do and returned to other activities.
Finishing a level, receiving a reward or buying an upgrade can provide a natural pause. At that point, it helps to show what the player has achieved and leave a clear opportunity to continue.
The technical side supports this moment. In Brainrot Merge Squad, the battle result, reward and progress are recorded before the victory animation: the reward is already part of the saved state.
The first encounter can then leave two reasons to return: enjoyment of what the player has done and an idea of what they could do next.
The second session: quickly bring back the experience players came for
When people return, they expect to find at least some of the enjoyment they discovered the first time. They need to reach that familiar, satisfying action quickly.
Save data needs to load reliably and restore the game’s state accurately. The first playable screen of a returning session should already show the correct level, earned rewards and available options.
In Needle Quest, this includes changes to the haystack itself: collected straws, dug passages and discovered objects. Returning preserves the feeling of a world the player has already interacted with.
The design task is to bring that enjoyment back before asking players to work through more setup. Repeated onboarding and a long sequence of preliminary screens can delay the moment they opened the game for.
Second-session conversion measures the share of new players who begin another session within a stated period. It is considered alongside the time until they return: the same day, the next day or later. With a comparable cohort and an observation window of several days, this rate is usually higher than D1, because it also includes people returning on the day they first played.
For a short casual game, players choosing to play again soon is especially valuable. If they usually open it again only several days later, it is worth examining the strength of that first impression: what did they enjoy, and what did they want to repeat? A long wait before returning may indicate that this desire was weak; it needs to be interpreted in the context of the genre and the game’s usual rhythm.
D1: does the desire to play survive until the next day?
D1 measures the share of new players who return on the next calendar day after their first experience. Retention definitions.
While the second session captures the repeat choice and its timing, D1 looks at returning after the day has changed. The initial impression has had time to fade, and the game is competing with other activities again.
Here, it helps to investigate whether players remember the game loop, whether they felt a sense of achievement and whether they still want to continue. Work on D1 is connected to the impression left by that first experience and how clearly players can see what lies ahead.
When a player comes back for the first time, a longer story begins. What can the game offer them a week later, once the initial novelty has worn off? We’ll cover long-term player interest, how a game evolves and D7 retention in a separate article.