A space education build listed in the published portfolio as receiving 1st Prize, using a custom canvas game loop, an ISS tracker, Dialogflow support, and monitoring tooling to make the experience interactive without reducing it to a gimmick.
Problem
The challenge was to make a space-learning product engaging enough to hold attention while still keeping the educational layer credible. The most demanding part was shipping interactivity that felt game-like without dragging the rest of the experience into a heavy framework.
Timeline
Product framing
I framed the build around interactive learning rather than pure gamification so every major feature still pointed back to the educational goal.
The existing project brief and module structure both center educational usage rather than standalone gameplay.
Gameplay module
The most demanding interaction was implemented as a purpose-built canvas system using requestAnimationFrame, keeping the module fast and local to the product instead of introducing a larger framework dependency.
The repository includes a dedicated SpaceShooter component with a custom animation loop.
Learning features
I combined real-time feeling product features with the main educational experience so the platform had more than one form of interaction.
The repo contains an ISSMap component with polling logic and a Dialogflow API route.
Reliability and recognition
I backed the interactive surface with monitoring and delivered it as a complete project; the published portfolio lists it as receiving 1st Prize.
The repository includes Checkly configuration; the prize reference is a published portfolio claim.
Key Decisions
The game experience needed direct control over rendering and update cadence, but the rest of the product still lived inside a standard web application.
I built the Space Shooter around a custom canvas game loop so the most interactive feature stayed tightly scoped and performance-aware.
Tradeoff: A custom loop gives more control, but it also means owning more of the gameplay architecture directly.
Impact: The game became a differentiating module without forcing the entire product into a game-engine-first architecture.
A static space site is less compelling when users can reasonably expect real-world context such as ISS tracking.
I added an ISS tracker flow that polls an internal API and computes user distance in the interface layer.
Tradeoff: Polling adds moving parts and requires discipline around update cadence.
Impact: The site feels closer to a living learning product than a static educational brochure.
Interactive APIs and chatbot flows degrade trust quickly if they fail silently.
I included Checkly-based monitoring so the product had a reliability posture beyond basic deployment success.
Tradeoff: This added operational setup to what could have remained a purely feature-focused project.
Impact: The project demonstrates product stewardship, not just feature implementation.
Architecture
The product is built as a Next.js application with multiple learning modules rather than as a single-purpose game shell.
For the most performance-sensitive experience, the Space Shooter module uses a custom canvas loop inside the React application instead of depending on a heavyweight game engine.
The broader product combines API-backed features such as the ISS tracker and Dialogflow support, with monitoring infrastructure to keep those integrations observable after launch.
The project became a stronger credibility piece because it shows range: real-time canvas work, API-backed educational interaction, chatbot integration, and a reliability mindset. The published portfolio lists a 1st Prize recognition claim for the project.
This project shows I can cross the boundary between application engineering and interactive systems work while still keeping the product grounded in a clear user outcome.