Turns out, I have not really declared my huge 💛 for #eventsourcing since I‘m on Mastodon. 😺
We‘re building a company-internal social card game @MaibornWolff with #golang - and it’s #eventsourced
If you want to learn about the #domainlogic of the game, I described it here:
After many busy months I was finally able to work on the game again, mostly while spending ~10 hours in the 🚆
1/x
We‘re finally working on „achievements“ - badges which also give extra points.
E.g.: When players have finished 3 tasks they reach level 1 of the „number of cards“ achievement and get one extra point.
Gamification. In a game. Crazy, huh!? 😁
2/x
No surprise that implementing such a feature is really straight forward in an #eventsourced system. Everything feels natural.
Iterate through the event stream, count the number of finishes cards (tasks), memorize which achievements were already granted, check the specs and produce a new event if a new achievement (or level) was reached.
Should we want to introduce temporal achievements like „finished tasks per week“ - easy peasy, the time is in the events.
3/x
There is literally no achievement logic we could not implement.
Without ES we could do some of those features trivially, some others with some heavy lifting, and some not at all, because the information would just not be there with classical storage.
4/x
To close this, we‘re using subscriptions from #eventstoredb with stored checkpoints (thx @oskardudycz for showing me), each achievement has their own subscription. The consumed events (finished cards) trigger the checks (if achievements have been reached). This enables to introduce new achievements that are granted to players in retrospective.
5/5
Anton Stöckl ✅