Yet another game engine — why?
The Problem
Prior to Covid, Euchre was a regular part of family get-togethers on one side of the family, and board games on the other. During Covid, we started using a popular mobile app to keep up the tradition. We’ve continued using that app to play when some of us are traveling, or when we’re just too busy to play in person. However, over time the app has stepped up its monetization with full-screen ads that have a close button that doesn’t look like a button and appears in different places after the ad has been visible for a while. Many times the button never appears at all. Instead, you’re forced to visit the app store and come back just to make the close button show up. If you’re not quick enough, you’ll get booted from the game.
That adds stress to a game that’s supposed to be fun. Add to that a little confusion and some memory decline for one of our regular players, and it became very stressful listening to her struggle to get past all that in time to stay in the game.
The Goal
Earlier this year when we were traveling I couldn’t take it anymore. I decided to write my own card game engine so that I could control the UX. I wanted to make it flexible enough to support the various house rules we use. I could also add a tips mode to help with the confusion and keep the game fun for all of us. I wanted to make sure that if, for some reason, someone gets booted from the game they could rejoin it in the same seat they previously had. I also wanted the game engine to be generic enough that I could easily add other card games.
Why Build Instead of Buy
I’m not trying to do side scroller games, 3d immersion games, and I don’t need a sprite system. I just wanted a card game engine.
How many times have you used a framework because it offers so much only to end up spending a lot of time customizing it when you try to do something just outside its specialty? This seemed like the perfect opportunity to exercise all of my skills, many of which I don’t get to use in my day job, and build it from scratch. I wanted the challenge of making it perform and scale as much as possible with hosting costs as small as possible.
It seems like very few game engines are built on Java. After reading about the billion row challenge, that high-frequency trading firms use Java, and learning about virtual threads combined with web sockets it seemed that Java would be just fine for the server.
Games were my original motivation for learning to program. But when the opportunity to move to Silicon Valley finally came, I knew enough about the industry to pass — the work-life balance was brutal. I went into automotive advertising instead (lol) and have had a great journey through a variety of industries and technologies: Chrysler’s first marketing website, auto-generated dealer websites, kiosks, interactive CDs, a white-labeled e-commerce system for selling music and games, an application performance management system, mainframe modernization, and currently a source code security and zero-trust multi-tenant platform.
The main goal behind building yet another game engine was to have complete control over the UX, and to make it easy for my family member to keep being the card shark that she is, even as her memory continues to decline.
The Stack
- Game engine: Java + Spring Boot, with WebSockets for real-time play.
- Data: PostgreSQL, plus Redis Streams for event sourcing.
- Frontend: a Vite + React SPA (JavaScript/TypeScript) for the game itself, and static HTML / plain CSS for the pages that teach the game.
- Auth: AT Protocol, Facebook, and Google for user authentication.
- Hosting: Cloudflare for the UI, DigitalOcean for the backend, Nginx out front.
- Load testing: k6.
- Ads: AdSense for, hopefully, well-placed ads — if I ever get approved, lol.
- Analytics & monitoring: Google Analytics for, well, analytics :-). Sentry.io for error tracking, Prometheus/Grafana for observability.
- Deploys: Kubernetes felt like overkill for now, so Wrangler plus a bash script handle deployment — which I’m planning to turn into CI/CD.
- Source control: dual SCM with gitlab.com as cloud backup and Forgejo for self-hosting. Semgrep and Trivy run on Forgejo’s version of GitHub Actions.
What’s Next
It’s a journey that’s not finished. Terraform for IaC is planned as well as better UI testing. I have several popular Euchre house rules: Ace no Face, Farmers Hand, Stick the Dealer, and Cutthroat 3-person Euchre.
I’m also in the middle of a rewrite of the core logic of the game engine, to simplify it, and to squeeze more performance out of it. Try it out at https://detroit.games/euchre. I’d love to hear your feedback about it. :-)