How We Built Skybound in Unity for WebGL

Skybound is an original fantasy flying game created by Lalo Games using Unity. The goal is simple: guide a magical winged creature safely through openings between enchanted rune pillars and survive for as long as possible.

Although the core controls are easy to understand, building a complete and polished browser game required much more than adding gravity and obstacles. We had to develop the gameplay systems, create a responsive interface, solve visual problems, generate sound effects, optimize the project and prepare it for WebGL.

We also used ChatGPT as a development assistant during the process. It supported parts of the programming, troubleshooting and visual-asset creation, while we directed the game’s concept, evaluated each version, tested the gameplay and decided what needed to be improved.

This article explains how we developed Skybound, the problems we encountered and what the project taught us.

You can play Skybound online on Lalo Games directly in your browser.

The idea behind Skybound

We wanted to create a small browser game built around a one-action flying mechanic. The player only needs to click, tap or press a supported key to move the character upward while gravity constantly pulls it downward.

The basic mechanic is familiar, but we did not want the game to look like another copy of an existing flying game. Instead, we developed a distinct fantasy identity using:

• A magical winged creature
• Ancient rune-covered pillars
• Floating islands and ruins
• Mountains, clouds and waterfalls
• Turquoise and golden particles
• An original fantasy music loop

The result was Skybound: a simple endless game presented inside a colorful fantasy world.

How the gameplay works

The player controls a flying creature affected by Unity’s 2D physics system. Every click, tap or keyboard input gives the character a fixed upward impulse.

The objective is to pass through the space between two rune pillars without touching either one. Passing a complete gate awards one point.

The run ends if the character:

• Collides with a rune pillar
• Flies above the permitted area
• Falls below the permitted area

After a crash, the game displays the current score and the best score saved on the device. The player can immediately start another run or return to the main menu.

The game becomes progressively harder because the world’s horizontal speed increases as the score rises. It starts at a manageable pace and gradually becomes more demanding, without changing the basic controls.

[Insert a gameplay screenshot showing the creature flying between two pillars.]

Developing the game in Unity

Skybound was developed using Unity 6000.3.15f1, also known as Unity 6.3.15f1. The project uses C# and Unity’s Universal Render Pipeline with the 2D Renderer.

Some of the main Unity systems used include:

• Rigidbody2D for the flying physics
• CircleCollider2D for the player
• BoxCollider2D for the pillars
• SpriteRenderer for the visual assets
• ParticleSystem for magical effects
• TrailRenderer for the character trail
• Unity UI for menus and score displays
• AudioSource for music and sound effects
• PlayerPrefs for storing the best score

Most of the game is controlled by one main script named SkyboundGame.cs. This script creates the player, environment, obstacles, interface, effects and audio systems when the game starts.

This runtime-generated structure helped us build and transfer the prototype quickly. However, it also taught us that a larger future version should divide these responsibilities into separate scripts for easier maintenance.

Building the flying controls

The creature is created with a Rigidbody2D. Gravity is disabled while the player is in the menu and activated when a run begins.

Whenever the player flaps, the script replaces the current vertical velocity with a consistent upward velocity. This means each flap feels predictable, even if the character was falling quickly immediately before the input.

Skybound supports:

• Left mouse click
• Screen tap
• Spacebar
• Up Arrow

Supporting several inputs through one simple action made the game suitable for desktop and touchscreen play.

We also added an important UI check. If the pointer is positioned over a menu button, the game ignores the flap input. Without this check, pressing a menu button could unintentionally move the character at the same time.

Creating procedural obstacles

The rune gates are generated while the game is running.

Each gate contains an upper and lower pillar with a randomized opening between them. The upper pillar uses the same artwork as the lower pillar but is flipped vertically.

A new gate is generated approximately every 1.75 seconds. All active gates move toward the left side of the screen. After a gate leaves the visible area, it is destroyed and removed from the active list.

The scoring system checks whether a gate has passed behind the player. Once that happens, the player receives one point and the gate is marked as scored so that it cannot award another point.

As the score increases, the gates move faster. This creates difficulty progression without introducing complicated controls or rules.

[Insert a Unity Play Mode screenshot showing the generated gates in the hierarchy.]

Designing a responsive game screen

A browser game can be opened inside many different window sizes. We therefore needed the camera, background and interface to respond to changing aspect ratios.

The interface uses Unity’s CanvasScaler with a reference resolution of 1920 × 1080. Its width-and-height matching value is balanced so the menus remain readable when the screen dimensions change.

Skybound uses an orthographic camera. The camera displays a wider or taller area depending on the current screen shape.

The background is also automatically scaled to cover the visible camera area. This prevents empty edges from appearing when the game is displayed at an unusual resolution.

This system was especially important for preparing Skybound for browser publication, where the game may appear inside an embedded player rather than a fixed mobile screen.

The background problem

One of the first visual problems appeared in the sky background.

Our original implementation used two copies of the same background image to create a scrolling environment. However, the illustration was not created as a seamless texture. When the two copies were placed next to each other, a visible division appeared in the middle of the screen.

The code itself was working, but the visual result looked unfinished.

We solved the problem by removing the duplicated scrolling backgrounds and using one complete centered illustration. A background-fitting method now calculates the camera’s visible dimensions and scales the image until it covers the full viewport.

This produced a cleaner environment without a noticeable seam.

The lesson was straightforward: a beautiful illustration is not automatically suitable for seamless scrolling. A scrolling background needs specially designed edges, multiple overlapping layers or a different presentation technique.

[Insert before-and-after screenshots of the divided and corrected background.]

Fixing the pink particle effects

We added magical particle bursts whenever the player flapped. During the first test, however, the particles appeared as bright pink squares.

In Unity, pink visuals commonly indicate that a material or shader is missing or incompatible. The problem was not simply the selected particle color—the particle renderer did not have a suitable visible texture and material.

To fix it, we generated a small radial glow texture directly through C#. The center of the texture is visible, while the alpha gradually fades toward its edges. We then assigned this cached glow material to the atmospheric effects and flap bursts.

The result was a softer combination of turquoise and golden glowing particles that better matched the fantasy environment.

This change improved both the visual quality and the clarity of the feedback produced by every flap.

Solving the repeated particle warning

Another issue appeared repeatedly in the Unity Console:

Setting the duration while system is still playing is not supported.

The warning occurred because a newly created particle system could already be active when the script attempted to change its duration.

We fixed it by stopping and clearing the system before configuring its duration and other particle properties. Once the configuration was complete, the system could safely play and emit its particles.

This was a small correction, but it removed repeated warnings and made the effect initialization more reliable.

Generating music and sound effects through code

Skybound does not rely on imported music or sound-effect files in its current version. Instead, the audio is synthesized at runtime using C#.

The game generates sounds for:

• Flapping
• Scoring
• Collisions
• Button interactions
• Background music

The first music implementation was a short ambient chord, but it was not clear or memorable enough during testing. We replaced it with a longer 12-second loop containing a simple melody, bell-like tones, harmonic layers, a low pad and a slow volume pulse.

Creating the audio programmatically kept the project self-contained and taught us more about waveform-based sound generation. However, a future version could still benefit from professionally produced audio and more detailed sound mixing.

Saving the player’s best score

Skybound stores its best score locally using Unity’s PlayerPrefs system.

When a run ends, the current score is compared with the saved result. If the new score is higher, it becomes the player’s new personal best.

This small feature gives players an immediate reason to replay the game. Even without accounts, online leaderboards or a complex progression system, the player has a clear target to beat.

Preparing Skybound for WebGL

Skybound was created with browser publication as its primary target rather than being converted from an existing mobile release.

The WebGL preparation included:

• Gzip build compression
• WebGL data caching
• Compressed textures with size limits
• Disabled debug symbols
• Disabled WebGL threads
• Engine-code stripping
• A lightweight URP configuration
• Responsive camera and background fitting
• Mouse, keyboard and touchscreen-compatible input
• No dependency on native mobile APIs
• Local score storage using PlayerPrefs

We also disabled features that were unnecessary for this small 2D game, including HDR, the depth texture and the opaque texture. These decisions help keep the rendering setup relatively lightweight.

The game still requires complete testing of the exported build across desktop and mobile browsers before we consider browser validation finished. Unity Play Mode testing and WebGL preparation are complete, but we do not want to claim browser results that have not yet been verified.

What playtesting improved

The first playable version already contained the main flying and scoring loop, but playtesting revealed details that were difficult to judge from the code alone.

Testing led us to:

• Replace the divided background
• Improve the fantasy music
• Repair the particle material
• Remove the particle-duration warning
• Improve the feedback produced by every flap
• Add visible Lalo Games ownership to the opening menu

These changes did not completely transform the rules of the game. Instead, they made the same mechanic clearer, cleaner and more enjoyable.

That is one of the most valuable lessons from this project: a mechanic can function correctly and still need considerable presentation work.

What we learned from developing Skybound

Skybound gave us several practical lessons.

First, artwork must be created for its intended technical purpose. A non-seamless background should not be treated as a seamless texture.

Second, runtime-created particle systems need to be configured in the correct order. Small initialization mistakes can create persistent warnings or unexpected visuals.

Third, a shared input system can support desktop and touchscreen players, but UI interactions must be separated from gameplay input.

Fourth, testing visual feedback is just as important as testing game rules. Particles, sound, movement and screen fitting all affect how responsive the game feels.

Finally, AI can accelerate development, but it does not replace human direction and testing. ChatGPT helped us generate and refine parts of the project, but every version still needed to be opened, evaluated and corrected according to the result we wanted.

Future plans for Skybound

There are several ways we could expand the game in the future:

• Reuse obstacles through object pooling
• Divide the main script into smaller systems
• Add collectible crystals
• Create unlockable creature appearances
• Add achievements and missions
• Introduce new fantasy environments
• Add changing weather and day/night conditions
• Improve the music and sound design
• Test and optimize the game across more browsers
• Introduce online scoreboards

For now, Skybound remains a focused experiment in creating a complete fantasy browser game around a very simple control system.

Final thoughts

Developing Skybound showed us that even a small game contains many connected challenges. Player physics, obstacle generation and scoring formed the foundation, but responsive design, particles, audio, interface behavior, saving and WebGL preparation were equally important to the finished experience.

The project also demonstrated a practical way to use AI during game development. Instead of expecting AI to produce a perfect game in one attempt, we used it as an assistant inside an iterative workflow: build, test, identify a problem, improve the implementation and test again.

Skybound may use a one-action mechanic, but creating its fantasy identity and solving its technical problems gave us valuable experience that we can carry into future Lalo Games projects.

Frequently asked questions

What engine was used to develop Skybound?

Skybound was developed with Unity 6000.3.15f1 using C# and the Universal Render Pipeline’s 2D Renderer.

Is Skybound an original Lalo Games title?

Yes. Skybound was created as an original Lalo Games project with its own fantasy environment, character, rune obstacles, visual effects and audio implementation.

Was AI used to create Skybound?

ChatGPT was used as a development assistant for parts of the programming, troubleshooting and visual creation. The concept direction, testing, feedback and final development decisions were handled through the Lalo Games development process.

What controls does Skybound support?

The game supports mouse clicks, touchscreen taps, the Spacebar and the Up Arrow key.

Was Skybound designed for WebGL?

Yes. It was created with browser publication as its primary target and includes WebGL-specific project preparation. Full browser compatibility should only be documented after the exported build has been tested on the relevant browsers and devices.

Ready to explore the floating fantasy world? Play Skybound online and try to beat your highest score.