• 

• 

• 

Project Story

About the Project

Duck Extraction is a top-down extraction shooter in which players enter dangerous zones, search for supplies, fight enemies and bosses, and attempt to reach an extraction point while managing limited resources.

I wanted the project to be more than a game about simply defeating enemies. My goal was to capture the most exciting part of the extraction genre: every exploration involves risk, every reward can be lost, and what truly matters is not how much you collect, but whether you can bring it back alive.

The project’s tagline is:

Scavenge the danger. Extract alive.

What Inspired Me

The project began with my interest in extraction shooters, tactical survival games, and lightweight indie games.

Many extraction games have complex systems and a high barrier to entry. I wanted to create something more accessible and lightweight while still preserving resource management, risk assessment, exploration, and the pressure of escaping safely.

To give the game a more recognizable identity, I chose a cute duck-like character instead of a traditional military protagonist. This creates a deliberate contrast between the lighthearted character design and the dangerous industrial battlefield.

That contrast became one of the main ideas behind the project:

• The character can be cute, but the combat should still feel tense.
• The visual style can be playful, but the gameplay should still require strategy.
• The controls should be easy to understand, but the player should still make meaningful decisions.

Throughout development, I kept asking myself:

• How can players understand the controls quickly without removing tactical choices?
• How can exploration feel purposeful rather than becoming aimless movement?
• How can many enemies, projectiles, items, and effects appear on screen without causing poor mobile performance?
• How can the desktop and mobile versions share the same core gameplay?
• How can I build a playable game prototype without a large team or a complete collection of professional art assets?

These questions encouraged me to keep redesigning and improving the game instead of stopping at a simple technical demo.

How I Built the Project

The project started as a single-file HTML prototype. I used JavaScript for the game logic and Three.js with WebGL to render the top-down battlefield.

I first built the basic gameplay loop:

Enter a raid
→ Explore the map
→ Search for supplies
→ Fight enemies
→ Manage health, armor, stamina, and ammunition
→ Reach the extraction point
→ Bring the collected items back to the base

I then gradually added:

• Player movement, aiming, shooting, reloading, and rolling
• Pistols, assault rifles, and different ammunition mechanics
• Medical kits, energy drinks, grenades, and flashbangs
• Enemy tracking, shooting, projectiles, and damage systems
• Bosses and supporting enemies
• Buildings, roads, indoor areas, and high-risk zones
• Loot containers, item pickup, backpacks, and secure storage
• A warehouse, market, workbench, medical station, duck nest, and radio station
• Raid results, an economy system, and local save data
• Keyboard and mouse controls for desktop
• Touch controls for mobile devices
• A minimap, full map, status panels, and combat controls
• Adaptation for different mobile resolutions and WeChat’s landscape browser behavior

To make the project easier to distribute, I embedded many images and resources directly into the HTML file. This allowed the game to run as a single standalone file.

Later, I packaged the project as an Android APK so it could be installed and launched without relying on a normal browser.

The game was not built in a single pass. It developed through repeated testing and version updates. I would first create a playable version, test how it felt, and then adjust character size, combat speed, button placement, enemy strength, map structure, and performance.

Challenges I Faced

1. Mobile UI Layout

The mobile interface was one of the most frequently revised parts of the project.

Different phones have different screen ratios, safe areas, browser behaviors, and logical resolutions. A minimap or control layout that looks reasonable on desktop may block a large part of the battlefield on a phone. WeChat’s internal browser also handles landscape mode differently from many standard mobile browsers.

Earlier versions used many fixed pixel values and several separate parent containers. As a result, the same UI component could appear in different positions on different devices.

To improve this, I began rebuilding the HUD around a unified coordinate and layout system. The minimap, health panel, joystick, weapon information, quick items, and combat buttons could then follow the same positioning rules.

I also created a visual UI adjustment tool that allowed components to be moved, resized, and given different opacity values.

This taught me that mobile interface adaptation cannot be solved by repeatedly moving individual buttons. A consistent system of anchors, proportions, and layout rules must be designed from the beginning.

2. Performance and Enemy Count

To create the feeling of a dense battle, the game needs enemies, projectiles, items, buildings, and effects to exist at the same time.

However, if every object performs complex calculations every frame, mobile devices quickly begin to lose performance.

I reduced unnecessary update frequency, lowered the calculation detail of enemies far away from the player, and simplified pathfinding, collision detection, projectiles, and visual effects.

I also learned that a scene does not always need to contain an enormous number of fully simulated objects. Sometimes it only needs to create the visual impression of a large crowd.

This led to an important lesson:

What the player perceives and what the program actually needs to calculate do not always have to be identical.

3. The Limitations of a Single-File Architecture

A single HTML file made the game easy to share and launch, but as the project grew, the code, styles, images, resources, and game data all became concentrated in one place.

New CSS rules could conflict with older rules, and the same button could be affected by several different layout systems. This made maintenance increasingly difficult.

The problem encouraged me to rethink the project structure and gradually separate it into clearer systems:

• Core game logic
• Maps and environments
• Combat systems
• UI systems
• Input handling
• Resource management
• Local save data
• Platform-specific runtime layers

I learned that rapid prototypes are useful for testing ideas, but growing projects eventually require clear module boundaries and consistent interfaces.

4. Supporting Multiple Platforms

Browsers, Android WebView, and WeChat Mini Games use different runtime environments.

The current HTML version can run in browsers and Android applications, but a true WeChat Mini Game cannot directly use the complete HTML DOM and CSS layout system.

Because of this, I began planning a migration that would preserve the Three.js scenes, combat data, maps, weapons, enemies, and gameplay rules while replacing the interface, input, audio, and storage systems with platform-compatible versions.

This helped me understand that cross-platform development is not simply placing the same file on several platforms. The game logic must be separated from the platform-specific runtime.

What I Learned

The most important lesson I learned from this project is:

Finishing a project is not only about implementing features. It is about repeatedly discovering problems, testing solutions, and redesigning systems that no longer work well.

During development, I learned and practiced:

• Three.js and WebGL scene construction
• JavaScript game-state management
• Collision detection, projectiles, and enemy behavior
• Mobile touch input
• Responsive UI and safe-area adaptation
• Local save systems and data persistence
• Game performance optimization
• Android WebView packaging
• Modular and cross-platform architecture
• Continuous interaction testing from the player’s perspective

I also learned that adding more code is not always the right solution. Sometimes the best improvement comes from removing duplicated rules, reducing unnecessary calculations, unifying systems, or redesigning an interaction completely.

What the Project Means to Me

Duck Extraction is still being developed, but it has already grown from a basic shooting prototype into a larger game project containing combat, exploration, loot, an economy, a base, maps, bosses, save data, and multi-platform support.

For me, it is more than just a game. It is a long-term learning and experimentation project that combines creative design, programming, visual presentation, and practical testing.

It has shown me that even with limited resources, one person can gradually transform an uncertain idea into something that can actually be played and experienced.

In the future, I hope to continue improving the maps, enemy variety, equipment progression, and multiplayer possibilities. I also plan to migrate the project to a more stable and maintainable architecture so that it can continue growing over time.

Built With

• android
• boss-battle
• cross-platform
• extraction-shooter
• game-ai
• game-development
• html5
• indie-game
• inventory-system
• javascript
• local-storage
• loot-system
• mobile-game
• pathfinding
• performance-optimization
• resource-management
• responsive-ui
• survival-game
• tactical-shooter
• three.js
• top-down-game
• touch-controls
• user-interface
• webgl