Björn Godeck (Posts about geobingo)

SnapHunt Bingo at the MediaNight

Björn Godeck — Mon, 16 Feb 2026 14:52:30 GMT

This is the third and final blog post about the game project "SnapHunt Bingo" which im developing with three other university students as part of our obligatory software project. I'm planning to publish and maintain this game so stay tuned for more posts to come!

The MediaNight came closer and closer so we picked up the development pace to get a fully functioning version of our game that we are proud of presenting at the media night.

But first… there is the Präsentationstag. We created some beautiful slides so everyone wants to play our game:

We also created a poster that we can hang up at the MediaNight to show the visitors what our project is about:

Our desk was in the Modulbau (M003). We were project 3 in this room plan:

Unfortunately we had two VR projects right next to us (project 8 and 9) so there was often a queue waiting to play these games right in front of our desk. Nevertheless we had many people visiting us and trying out our game.

We decided to create a list of 9 words that can be found at the HdM - most of them directly at our table - so visitors can test the app with a low barrier:

Our impressions of the MediaNight

Björn

I’m not a big fan of presenting - especially in front of big crowds. But the only way to keep improving and build confidence is doing these things again and again. And while my part of the presentation at the Präsentationstag might not have been the best project presentation I’m still happy with my performance.

The MediaNight itself was surprisingly pleasant. From past visits I remembered a loud and crowded environment and while it was loud and somewhat crowded I still liked it. I think our idea of having two lent smartphones and some objects on our table to test the game was great. Most used those to test the game. There was only a handful of people who downloaded the app on their own phone and probably none of them decided to make the walk to the excavator. Most people don’t have the patience to test one app over the whole evening which is totally fine. I didn’t do more than one QR-Code on the RewardRun project myself either.

Another positive aspect was that two students from a journalism/public relations course of study approached us at the beginning of the semester to write an article about our project which was released the weekend before the MediaNight:

Auf der Jagd nach dem Bingo-Sieg

Erzan

Like Björn, I am not naturally someone who enjoys presenting in front of large audiences. However, over the past few years, especially through presentations at work and in previous courses, I have had many opportunities to practice speaking in front of groups. Because of that experience, presenting our project on the Präsentationstag felt significantly easier than it would have a few years ago. It felt good to see how much more confident I have become compared to earlier semesters.

The MediaNight itself was my very first one, and I was honestly impressed. I did not expect the event to be this large, well-organized, and full of different projects. Walking through the building and seeing so many creative ideas being presented was inspiring.

We were very happy to see that people stopped by, asked questions, and tried out our game.

Reflection on the Final Project Phase

Looking back at the last weeks before the MediaNight, time management was one of the biggest challenges. As the event approached, it became increasingly important that we had a stable and presentable version of the app.

About one week before the Media Night, parts of the backend were not functioning as they should. We decided to reprioritize responsibilities to ensure that the project would run reliably during the event. Leon shifted more strongly into backend stabilization and took over parts of my previous implementation to make sure everything worked smoothly for the presentation.

At the same time, I focused on other deliverables for the Media Night and the Präsentationstag:

Designing and preparing the presentation slides
Creating the project poster
Producing the trailer

After the event, I shifted my focus back to the backend and worked on additional backend tests.

Leon

This was my first MediaNight, and before the event I could not imagine how many people would actually come to see the projects developed throughout the semester. I was surprised by how many people were interested in our project in the end. At first, no one came to look at our project, and we jokingly made bets about how many times we would be asked about it. In the end, we explained our project to many visitors.

Even though most of them liked the concept and the version of the game there were a few critics. One of them being that the words were fixed and not interchangeable. The biggest flaw was the missing result view.
We had major problems regarding the development of the backend. Even shortly before the MediaNight, the basic game functions had not yet been implemented. I was assured multiple times that they would be finished the following week. As the MediaNight approached fast, I took over the development of the WebSocket-based game logic in the backend while also continuing to work on my frontend tasks.
I was quite happy that we could work out a working version for the MediaNight. Even though we missed the mark with what was planned due to these issues.

Abel

This actually was my second MediaNight, my first one was the one last year for the “Game-Praktikum” lecture where we developed a video game with around 20 people. I was more detached from the whole planing and presentation aspect of the MediaNight. But due to this being a more intimate project with 4 people, I had to stay for around 7 hours instead of the 1 hour last year. Even though I had to stay longer at the MediaNight, it did not feel annoying in any way. Having people come to us and presenting something you spent so much time and effort to build up from the ground was something special. It felt really rewarding, having people coming up to us and being genuinely interested in our project.

My favorite interaction was when someone came up to us and said that they voted for us for the students choice award, which we sadly did not win.

One thing that left a sour taste was the amount of people who after reaching the vote stage kept pressing the “next word” button being confused why it stopped working. I think as a developer you focus a lot on just getting something to work that you start missing the most important part. A game where you can not see whether you reached the predefined goal probably is not a good game. And in our case the missing scoreboard and the amount of people who criticized it was a bit of a downer.

But in the end it was a great experience and I am a bit sad to probably not being able to part take in another MediaNight.

What’s left to do and what’s still to come

Our app is still far from perfect. We still found some bugs and have some features we want to implement. New features would be:

Join lobby with QR-Code: Instead of typing in the 5 digit lobby code the user should be able to just scan a QR-Code from the host’s screen to join the lobby. That makes playing together easier.
Summary Screen with download function: We planned to include a summary screen at the end of the game where you can see every player’s bingo board. This way you can see who took which picture and who managed to get a bingo/full line, so extra points (the player already gets extra points on a bingo but they can’t verify it visibly). This view should also have a download button to download one player’s or all players’ pictures on your phone. In the backend development we looked ahead and made decisions so this feature would be easy to include later.
Custom server address: To make the game self-hostable we want to include a setting on the first screen of the app where you have to type in the server address where the backend is running on.
Small UX improvements: At the MediaNight we saw some user experience flaws where users tried to do things that are not possible. For example in the evaluation they tried to swipe to the next word instead of using the button on the bottom right. Or they thought that the green box effect after the image was uploaded meant that the AI recognized it as “right”.
Make it self-hostable: The plan for the project is to not let it die after we got our grades but to keep it alive on a public GitHub page so other people who want to play this game have the ability to do so. For this the backend should be easily deployable, preferably using only one docker-compose file.

So stay tuned for more to come!

- The SnapHunt Bingo team

First prototype: SnapHunt Bingo is making progress

Björn Godeck — Sun, 21 Dec 2025 14:46:29 GMT

This is the second part of a three part blog post about the game project "SnapHunt Bingo" which im developing with three other university students as part of our obligatory software project.

The development of our game “SnapHunt Bingo” is making progress. All the important screens of the app - login screen, main menu, lobby, game board and the evaluation screen - are now present and some of them are already fully functional. You are now able to go through the different stages of the game. The backend has also made a lot of progress but the connection between the frontend and the backend hasn't been fully carried out yet.

How the game looks and what works

To test the game you first have to install the .apk. When you open the app you are greeted with a login screen. On this screen you can choose to login with your Google Account or choose to play as a guest. The login functionality is the first that has a connection to the backend and thus is fully functional.

After you login you get redirected to the main screen. There you can either create or join a game. The logic for joining a game is not implemented yet, so for now our proof of concept is only a single player experience. When you create a game, you'll get to the lobby screen. On that screen you can make some settings like enabling the AI integration or removing words/players. These are still static data only saved in the frontend so changing them won’t actually change anything.

Once you start the game you'll see the game board with your bingo field and a timer running down. You can click on the words and get to a camera view where you can snap a picture. For now the picture is only stored on your device and not sent to the server. You can see the picture on your bingo card where once the text was.
In the end you can go the evaluation screen. For now it is filled with random stock footage but it shows how it’ll look like in the finished game.

Even though there is no multiplayer yet playing the game at the HdM made some fun:

Frontend Update

We have already made significant progress on the frontend of our project since the last blog post. One of the first things we did was deciding on an architectural pattern. The Flutter documentation recommends the use of the MVVM pattern. As beginners in Flutter we did a lot of mistakes while trying to implement this pattern - just as we expected. For example, we intended to have the view for the guest login and the google login with the same data behind it, so we can use the created user object in the whole application. However, a View Model should have a one-to-one relationship with its corresponding view.

At first we ignored this issue, but as similar problems occurred repeatedly, we decided to introduce a dedicated repository layer for data handling. With this change we also completely reworked our folder structure. This is the next big topic in our queue. The next picture shows an example of the architecture of our frontend:

As for the thought process behind the different views: We split the different views evenly between the two frontend developers. At first, we tried implementing the views completely with their respective view models and services. However, since we needed a first demo before Christmas, we decided to build a complete gameplay loop as a client-side application. The login views were the first to be fully completed and are currently the only ones connected to the backend. The other views only contain the basic logic and layout of them.

To make the demo a bit more realistic we tried to contain some information from the other views for example the selected playtime. We also thought about using the pictures that were taken in the evaluation, but decided not to because this would work completely different to our final version where we will push the pictures to the backend while playing and later fetch everything again. Implementing a purely client-side solution for this did not make sense to us, as it would be discarded once the backend integration is complete.

Backend Update

Since the last developer blog we have focused on building the foundation of our backend. The Django project is now running and we have integrated the Django REST Framework for API development and prepared Django Channels for real-time communication. Redis is set up as the message broker and the ASGI server Daphne is ready for WebSocket support.

We implemented the lobby features, allowing players to create a lobby, join, view details, and start a game. In addition we developed the Game model, which stores all essential settings such as duration, word list, grid size and game mode. The main endpoint POST /api/lobby/game/create/ is complete – it validates the input (e.g., exactly 9 words), takes the players from the lobby, and creates a new game.

A good application needs secure authentication so we implemented a safe way for users to create a account. User now can login via Google and as a guest. The guest login was important for us as we want to set the game entry barrier as low as possible. The login itself is quite boring as we use the basic Google API. For the guest login we basically create a user with the name the users puts in and we create a random email address. Both authentication versions create a refresh and access token.

Testing the app was a bit tricky because Google requires a "key" from the .apk file to verify the address where tokens are sent. Since the backend team isn’t familiar with Flutter, we struggled to figure out how to retrieve the token. To make matters worse, only one person on the frontend team had access to the Google Cloud SDK, so we decided not to spend too much time troubleshooting the Google-related issues.

Another major challenge for the backend team was deploying the app to a server. For the first prototype, we wanted a functional server to handle frontend requests. One team member secured server access, and the backend team developed a Dockerfile to build a production-ready version of the app. The process went smoothly, with only minor issues like routing errors and file-copying mistakes in the code.

The AI Problem Part II

One thing that we kind of set aside was the AI picture classification. We haven’t had a server to test the AI performance problems we might encounter. We decided to first focus to make a functioning prototype and then to think about the AI feature and how to implement it. One big problem with the testing of different AI Models and Image classifier is the limited hardware availability for the testing. So one thing we need to consider is that local testing can only be made by one person in the backend team.

What’s next

There are still many things we plan to do to get a production ready game. These things include:

Fully connect frontend with backend to achieve full multiplayer functionality
Create working websockets, using daphne, for a smooth multiplayer experience
Add a screen that shows the bingo fields of each player so you know who took which pictures and who got a bingo (full line)
Create the game and scoring logic
Add a score screen that shows the winner and how many points each player got
Some bug fixes and improvements (for example the timer stops after the app has been idle for some time)
Create a logo for the app’s main screen and the smartphone’s home screen
Implement some sort of AI image classification
Testing, testing and some more testing

SnapHunt Bingo - A real life version of GeoBingo.io

Björn Godeck — Fri, 14 Nov 2025 19:18:00 GMT

SnapHunt Bingo - The idea and our plans

This is the first part of a three part blog post about the game project "SnapHunt Bingo" which im developing with three other university students as part of our obligatory software project.

Bingo, the old peoples game? Who wants to play that?

Well, let me introduce you to our new innovative game that isn’t played in a retirement home but outside in the real world. Yes, you have to leave your gaming chair but it will be an adventure you won’t forget for a long time.

This is a social game, so you need some friends to enjoy it. Theoretically you can play with just two players, but it’s more fun to set off in groups of two - so four or more players is recommended.

This is also a mobile game: You need a smartphone running the app or the web version.

But what’s all this about?

To summarize it: You have to find things from your bingo card in the real life and take a picture of it. These things can be anything you can see or grasp in the real world for example a pink car, a burning candle, a rabbit, a helicopter, yellow road markings, an olive, a disused fridge or flying frisbee. You as a group can either come up with your own words or use a list of predefined words (or a mix of both). All players have the same set of words, but they are arranged differently on the bingo boards. Once you took a picture the word is checked off and if you get a whole row you get bonus points. At the end of each game all players get together to discuss the pics they hunted. You might argue if the car is really pink or rather purple or if the racoon is in fact a cat. To help with filtering all the pictures we might add an AI integration that analyzes the easily recognizable images.

Inspiration

To be clear upfront: We didn’t invent this game. The first version of this type of game was “GeoBingo” which became popular through twitch streamers. It is not played in real life but in Google Street View. You agree on a list of words and search for them in the whole world by skimming through Google Street View imagery. You can play this game on https://geobingo.io/ but it costs money since Google Street View API costs are rather high. Since this game is open source you can self host it and use your own API key (which is free if you don’t spend every second of your free time playing this game).

Next up some streamers came up with the idea to bring this game into real life. It looked like a fun activity for a group of friends so me and some friends tried it out. But it was a hassle to keep track of the words and all the pictures. So we decided we need a proper mobile application for this task. This is how SnapHunt Bingo was born.

Design

I already had some ideas how the game flow should be like and how the app’s pages should look like so I scribbled some concepts:

After some discussion with the team I created prettier versions of the screens with Figma:

Those designs are not final but they are a good foundation for discussion about the design and an inspiration for the development process.
They are also great to give an impression on how the game will look like and how it works to our readers.

Team structure

To make our development process more efficient, we split our team into two parts. Björn and Leon are responsible for the frontend section of SnapHunt Bingo while Abel and Erzan focus on the backend and AI integration of our project.
This separation of responsibilities allows each of us to concentrate on our strengths and ensures a clean and better structured development process.

If timing issues happen and the backend backlog begins to grow, Leon will also assist with backend tasks. This flexibility helps us keep the workflow steady, even when unexpected issues occur.

We manage our tasks in GitLab using separate issue tags for the frontend and backend. The team members can select the issues that they want to work on. To ensure that out project makes the desired progress we meet every Monday evening to discuss progress, upcoming tasks, and other open questions.

Frontend

We considered multiple framework options for our frontend development. After evaluation of our options we chose Flutter. We also thought about using React Native and after our mentoring professor suggested the Godot Engine, we also looked at that option.

In the end we decided on Flutter due to several reasons:

Cross-platform support: With a single codebase, we can deploy our application on multiple platforms. Our primary platform will be Android, but if there is enough time we want to deploy our application in the web too.
UI flexibility: Flutter has a very extensive widget library which enables us to easily build consistent and modern app designs without huge effort.
Strong community: Flutter is still actively developed by Google and therefore has a big and active developer community, which help us to find solutions to issues we might come by.

While our other options also partially had those pros a key factor was that Björn already has some basic knowledge in Flutter, while the other two options would have been completely new to us.

We use JetBrains Android Studio as our main development environment for the frontend, as it integrates easily with Flutter and provides us with an Android Emulator, which we will use for the first weeks to try our application.

Backend

The reason we decided to use Python in the backend was because we wanted to learn something new, as no one has any experience using Python as a backend language. The second and bigger reason on why we decided to use python, is because of the AI compatibility of Python. Python is the industry standard for AI development so choosing it was a no-brainer.

Django is the biggest Python backend framework and has a lot of built in features and libraries that would spare us a lot of development time. We discussed other options such as FastAPI and Flask due to some performance issues that might occur due to the way Django handles async functions.
In the end we decided for Django as our backend as a potential performance bottleneck should not occur for our use-case. And we will safe some time using the vast libraries.

The AI Problem

The last decision to be made is how to tackle the image identification.

We have to balance word-complexity, user-input-flexibility, accuracy, and computing power and that is something that needs more time to test and plan. If we let the users pick their own words and let the uploads be checked by the AI, we can not assure for the reliability of the results if the word is too obscure.

Talking about complexity, the words we provide can not be too complex but also shouldn’t be too boring. For example: A simple image classifier can identify a car. But there are a lot of cars on the street. So simply using “car” as a word would be a boring experience for the player but easy to reliably implement for us. Most simple image classifiers start to struggle if the complexity increases. If we provide “green car” as a bingo field, the image classifier might detect a non-green car next to a green bush as a false-positive which should be avoided.

There are two ways to ensure that the image classier returns a correct result:

A. We use a more powerful image classifier.
B. We train our own image classifier.

A has the problem that we will reach a computing bottleneck pretty fast as we have only limited hardware available for the MediaNight. A fully fledged LLM has a high reliability, but an answer can take up to 5 minutes depending on the hardware.

We currently tend to option B which has the problem that we have to carefully pick the words we use because the players should have unique experiences, playing multiple rounds without repeating words. So if we have a 5x5 grid resulting in 25 words, we should have around 250 words that are not prone to false positives. Which means we will spend a lot of time for training and fine tuning the model which might take a lot of time of the project.

Our primary goal in terms of AI integration is to provide a 3x3 grid with 9 selected words for the MediaNight that work reliable with an image classifier in the backend.