Building Foundations with Ktor and SurrealDB: Crafting a Doppelkopf Point Tracker – Part 1

I've always been fascinated by Doppelkopf, the classic German card game. Over time, one challenge became evident: tracking scores and player stats. To better understand and explore the tech stack, and to showcase my programming abilities, I embarked on a journey to create a point tracker for Doppelkopf.

Features of the App:

1. Point Tracking: At its core, the app allows for easy tracking of both points and fines for each player.

2. Accommodating Multiple Players: While Doppelkopf traditionally involves four players, this solution can accommodate games that involve player rotations, making it versatile.

3. Automatic Score Calculation: One of the key features is that the application does the heavy lifting by automatically calculating positive and negative points. You just identify the winning team and the app handles the rest, including solo play tracking.

4. Backend and Frontend Integration: This was a chance for me to experiment with Ktor and Kotlin for the backend, combined with React and React Router for the frontend.

5. UI Experience: I used semantic-ui-react to give the app a user-friendly and intuitive interface.

6. Database Choice: The surrealdb serves as the data backbone for the app, ensuring data integrity and smooth retrieval.

7. Build System: Gradle streamlines the build and deployment process.

Understanding the Code Structure:

One of the areas I paid keen attention to was ensuring the code remained organized and modular. This would not only make debugging easier but also allow for potential future expansions.

Within the src directory, I laid out the core functionalities: model definitions, routing logistics, database interactions, among others.

Deep Dive into the Data Model:

The essence of this project lies in its data models, designed specifically for the complexities of Doppelkopf.

• Game Class: This class is instrumental in tracking parameters like players, sessions, points, fines, winners, and other game-specific metrics.

• GameSession Class: It helps keep track of all the games within a particular session, essential for understanding the progression of games.

• PlayerGroup Class: This model defines distinct groups of players, which can be especially handy when playing in rotations.

The relations between these classes are designed to mimic the flow of the actual game:

• A PlayerGroup relates to multiple users (n:m relation) and is also connected to various game sessions (1:n relation).
• Each GameSession then ties back to multiple individual games (1:n relation).

Database Caveats:

While building this project, I came across several interesting challenges and lessons pertaining to the database. This section is dedicated to highlighting some of those intricacies and how I approached them.

In Conclusion:

This project was a wonderful learning experience, allowing me to delve deeper into the tech stack while also enjoying the strategic nuances of Doppelkopf. If you're curious about the inner workings or considering similar projects, feel free to explore the code in more detail. Feedback and insights are always welcome!

Remember to replace placeholders with the actual content before sharing or publishing.