Behind the Scenes: Building Geo Challenge with Open Source Geospatial Tech

When you play the Geo Challenge, you see a smooth, beautiful 3D experience that effortlessly perches you above a small Swiss village, a dramatic French coastline, or a German city. What looks effortless on screen, however, required careful technical decisions and a commitment to Open Source geospatial tools. This post is about lifting the curtain on how Geo Challenge was designed and built—and the technical choices that went into it.

Play Geo Challenge here. 

From a technical perspective, what looked simple but proved complex to build? Surprisingly, it wasn't the data rendering. That’s our bread and butter. The game mechanics were the most challenging part for me. Because this was my first game development project, creating the core game loop, designing the score calculation logic, and building the user feedback systems were completely new challenges. It was a steep but rewarding learning curve.

Our architecture was shaped by balancing key constraints. The primary constraint was the trade-off between terrain quality and perceived loading speed. We needed to use the exceptionally high-quality Swisstopo data for the Swiss map and Google Maps for France and Germany, but we also had to optimize the delivery to ensure a smooth experience. This optimization also extended to device compatibility: the game needed to run seamlessly across all devices, ensuring that no one was excluded due to a slow loading time or a less powerful machine. Accuracy and scale were non-negotiable foundations for the entire design.

To meet these goals, we made two key technology choices. First, we chose Cesium as our 3D globe engine. We chose it because I wanted to experiment with alternative ways for a non-technical audience to interact with a 3D globe. Cesium provided the performance and capability we needed to render the complex Swiss topography. Second, we leveraged Google Firebase for the scoring and leaderboard system. This decision was part of an experiment to see if a small application could be developed without the burden of having to manage the server side myself. This cloud-native approach allowed us to focus squarely on the front-end game experience.

The use of Open Source tools was a massive influence on the project’s delivery. Open Source platforms like CesiumJS allowed for direct collaboration with the developer community. If we hit a bug or had an idea for a new feature, we could actively engage with the creators. The community forum is a fantastic resource, accelerating problem-solving and allowing us to build on a foundation that is transparent and constantly improving. It provides concrete benefits that bypass the bureaucracy of proprietary systems.

As a developer, I always anchor my side projects in real-world professional credibility. If the Geo Challenge had been a client project instead of a game, what would I have done the same way, and what would I change?

I would have absolutely kept the commitment to high-quality, Open Source geospatial technology like Cesium. The core data pipeline would also remain the same. However, for a client project, I would have involved more developers and allocated significantly more time for rigorous testing. Crucially, I would have developed the score system myself. While Firebase was great for the rapid prototyping of a side project, a client-facing solution would require me to guarantee full control and data backup of the core game data, which means owning the backend.

Ultimately, the Geo Challenge proves that a playful experience can be built on the back of thoughtful, cutting-edge technical decisions, all while using the power of the Open Source community.