post mortem

name

the trip

year

2014

platform

iOS / Android

engine

Unity

team

Antonio Vicentini - Art; Ben Hantoot - Composer; Henry Gosuen - Developer

initial goal

Learn collision detection and frame-by-frame animation workflows in Unity.

final product

Mobile infinite runner game on Android and iOS.

executive summary

• What we set out to do: After Antonio Vicentini completed the original The Trip animation, he had a number of unused animation frames available and allowed me to experiment with them in Unity. The initial integration worked well, which led to additional assets being incorporated into the project.
• Limitations: The project had no budget, was developed in parallel with full-time work, and used assets provided for non-commercial use.
• What we shipped: A hand-drawn mobile infinite runner built around simple tap-based gameplay.
• Result vs. goal: What started as a collision and frame-animation test evolved into a complete mobile release with animation states, gameplay systems, achievements, platform integration, and post-launch updates.

metrics snapshot

overall mechanics

• Core loop: Avoid obstacles, react to modifiers, survive for as long as possible, and improve your distance record.
• Art as direction: The game's progression was not only mechanical. Visual elements, obstacles, and power-ups progressively distorted the world, reinforcing the psychedelic themes inherited from the original The Trip animation.
• Perception-based challenge: Certain power-ups altered the player's relationship with obstacles. A vehicle that normally required a jump could become something the player should pass underneath, forcing quick adaptation without introducing additional controls.
• Difficulty curve: Speed-up items appear over milestones, increasing speed, reducing reaction windows, and requiring more precise timing.
• Controls and feel: The vehicle moves automatically. Player interaction is driven by tap actions, creating an accessible control scheme while maintaining challenge through timing and obstacle recognition.
• Content variety: Obstacles include oncoming vehicles with different sizes and movement patterns, as well as surreal elements such as flying vehicles, stretching objects, and orbiting eyes.
• Environmental progression: Background elements were grouped by distance milestones, creating the perception of traveling through different locations despite the endless structure.

what went well

• Resource reuse: Gameplay variety, environmental progression, and obstacle differentiation were achieved primarily through reuse, recombination, and contextual presentation of existing assets.
• Animation pipeline: Texture atlases, animation state transitions, and particle effects enabled the visual identity of the game despite hardware limitations.
• Tools, libraries, and APIs integration: Integrating platform services, SDKs, deployment pipelines, and external production tools successfully enabled simultaneous releases on iOS and Android.
• Community feedback loop: More than 3,000 text reviews were individually answered. In some cases, players returned simply to continue the conversation.

what didn’t go well

• Device fragmentation: The project lacked access to a broad device testing pool, so player reviews became the main source for identifying compatibility issues.
• Analytics: The game shipped without analytics or attribution tools, which limited our ability to understand retention, churn, traffic sources, geographic performance, and player behavior.
• Content depth: After a few minutes, players had seen most enemies and variations. The game had a strong initial loop, but limited long-term progression.
• Discoverability: Reaching press and media outlets proved harder than expected. Visibility depended mostly on organic discovery and player reviews.

key decisions

1. HD compatibility strategy

• Problem: Large texture atlases exceeded hardware limitations on some devices.
• Solution: A screen-detection mode was implemented to deliver alternative asset sets based on device capabilities.
• Outcome: Improved compatibility, but increased maintenance complexity.
• Lesson: A scalable asset strategy would have been preferable to maintaining separate rendering paths.

2. adjust background color

• Problem: Obstacles and background elements could be confused during gameplay.
• Solution: Colors were adjusted to increase contrast and readability.
• Outcome: The modified background improved readability.
• Lesson: Preserving artistic intent is important, but readability should take priority when gameplay clarity is affected.

3. easy achievements

• Why: Provide early goals and encourage engagement among achievement-oriented players.
• Outcome: Achievement-related feedback appeared repeatedly in review comments and became one of the most frequently mentioned positive features.
• Lesson: Small, attainable achievements provided immediate player satisfaction and encouraged engagement during the first sessions.

4. direct review responses

• Problem: Limited QA and support capabilities made it difficult to identify issues across a large variety of devices.
• Solution: Player reviews were treated as an active feedback channel, with every text review receiving a direct response.
• Outcome: Critical bugs were identified more quickly, response times improved, and player engagement increased.
• Lesson: A visible feedback loop can become a valuable QA resource.

surprises

• Unexpected traction in Russia: A large volume of installs and reviews came from Russia, helping identify serious bugs, including the black square issue.
• Comparison with Google Dino Run: The game launched around the same period as Google's Dino Run, which led some players to assume it was inspired by it.
• Players created progression where none existed: Even though the game was an infinite runner, players interpreted grouped background variations as a journey through different places.

technical post-mortem

• Early mobile constraints (2014): Many features now taken for granted were either immature or unavailable. Building the game often meant building the process required to make the game.
• Black square bug: Some devices could not handle large texture atlases correctly, causing animated assets to render as black squares. This became one of the main drivers behind the introduction of a dual asset strategy.
• Runtime optimization: Object creation and destruction patterns were replaced by object pooling, reducing garbage collection activity and improving runtime stability.

end of active development

The iOS version was removed from the App Store in 2018, as maintaining an Apple Developer account became difficult to justify for a free project.

Development effectively stopped after a version control issue damaged part of the project's working structure. As the project remained inactive, recovering and updating it became increasingly difficult due to changes in Unity's ecosystem, tooling, and platform requirements.

For several years, The Trip existed only as a released product and a historical project. Active development had effectively come to an end.

final update

In 2026, the project was revisited and partially restored. Modern AI-assisted development tools helped recover core gameplay functionality and accelerate the reconstruction of missing systems.

With the game playable again, player feedback collected over the years was reviewed and prioritized. Several commonly requested features were implemented:

• Interactive tutorial sequence
• Pause functionality
• Music and sound toggles
• Night mode

The tutorial was implemented using Rive, and the workflow became a valuable reference for future Unity projects.

This final update transformed the project from a historical release into a practical exercise in software preservation, legacy maintenance, and modernization.

timeline

2014 - Development and launch
2016 - Runtime optimization update
2018 - Removed from App Store
2023 - Removed from Google Play
2026 - Restoration and final update

lessons learned

• A small project can grow beyond its original learning goal. The Trip started as an animation and collision test, but became a complete mobile release across iOS and Android.
• Shipping the game was easier to understand than understanding the product after launch. Technical problems could be investigated, reproduced, and fixed, but product questions remained unclear without proper analytics.
• Player feedback can reveal both bugs and hidden opportunities.
• Building a game felt like stitching one piece to the next. Each solved problem revealed the next one, and the full product only became clear through that process.
• Documentation is essential for understanding what a project actually became, not only what was released.