Dolt is a version controlled SQL database. How would you use such a thing?

A popular Dolt use case is version controlling configuration. Modern games have a ton of configuration. Managing megabytes or gigabytes of configuration across many files becomes a mess when using Git or Perforce. If you have this configuration in a standard SQL database like Postgres for better structure and easier querying, you lose the ability to version control.

With your game configuration in Dolt, you get a powerful SQL interface combined with the Git-style version control you are used to, the best of both worlds. Game developers all over the world, like Scorewarrior, are adopting Dolt to clean up their configuration mess and build games faster and cheaper.

Scorewarrior

Scorewarrior is a Game developer based in Limassol, Cyprus. They publish a single, popular title called Total Battle. It's a free-to-play 4X strategy game in a fantasy world. You have a town which you develop, gaining resources either through production timers or fighting various mobs on a shared player-vs-player map. You join a team and defend against or attack other player teams.

I played Total Battle on mobile but you can also play in a browser, which I only learned writing this blog. One vacation a couple years back, I had fun playing the game and even spent some money but when my vacation was over, I put it down. I don't really have time in my normal life for a video game hobby. I spend most of my time trying to build Dolt for you all. That said, it's a fun game. Please give it a try!

How Scorewarrior Uses Dolt

Scorewarrior adopted Dolt in late 2021. They have been an Enterprise Support customer since early 2022.

Scorewarrior uses Git to version game code. Before Dolt, they used Postgres to manage game configuration. Their developers and designers would query and modify configuration via Postgres. At build time, the configuration was extracted from Postgres and bundled into binary artifacts. They would regularly dump their Postgres tables to CSVs and store these files in Git so they would have historical information about past configurations. This structure allowed for historical data but did not allow for merges and cherry picks, features they wanted as they added more developers to the game.

Scorewarrior decided to move their combination of Postgres and CSVs in Git to Dolt, a natural fit. They wrote a little bit of Postgres to MySQL conversion code for the migration but quickly moved the entire process to Dolt.

They use Dolt branches, merges, and cherry picks to develop their game configuration across multiple teams. When they are ready to ship, they cut a tag and build the binary artifacts, much like a build workflow one would find with Git and source code.

Game Configuration

Scorewarrior structured their game configuration as simple tables using JSON columns for deeply nested data. A table with a dozen or so columns with a two to four column primary key is a common pattern. An example table from their schema matching this pattern is seen below.

+-------+------------------------------------------------------------------+
| Table | Create Table                                                     |
+-------+------------------------------------------------------------------+
| stars | CREATE TABLE `stars` (                                           |
|       |   `star_system_id` int NOT NULL,                                 |
|       |   `segment_id` int NOT NULL,                                     |
|       |   `star_id` int NOT NULL,                                        |
|       |   `effect_id` int NOT NULL,                                      |
|       |   `price_unlock` json NOT NULL,                                  |
|       |   `client_config` json DEFAULT (json_object()),                  |
|       |   `rating_contribution` bigint NOT NULL DEFAULT '0',             |
|       |   `unlock_condition` text NOT NULL,                              |
|       |   PRIMARY KEY (`star_system_id`,`segment_id`)                    |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_bin |
+-------+------------------------------------------------------------------+

And here is a GIF of the feature that table powers. You can get a pretty good idea of the values stored in that table from watching the GIF.

In Dolt, game configuration is often structured this way. We used a similar pattern in the Endless Sky demo we built for the 2024 Game Developer's Conference. Yury Dynnikov from Scorewarrior says, "A version controlled SQL database fit our existing development environment even though Dolt was MySQL and we used Postgres."

Branch and Merge

Scorewarrior has always taken advantage of data merges. Dolt uses primary keys to identify rows across versions. If two versions modify different rows or cells, data merges cleanly. If two versions modify the same (primary key, column) pair, a conflict is generated. Scorewarrior leveraged this functionality from the start and it fits the game configuration use case well. If one designer is modifying a monster and the other is modifying a hero, both changes merge cleanly.

More interestingly, Scorewarrior's schema changes a lot. As the team adds new features to the game, new tables get added and new columns are added to existing tables. These features are generally developed on a feature branch. The feature branch constantly merges main to keep configuration up-to-date with the current game. When the feature is ready to ship, the feature branch is merged into main.

This feature development process results in "schema merges". The feature branch has added new columns and tables and now needs to merge with main. Dolt's support of schema merges has gotten better over time and Scorewarrior's use case has helped a lot ferreting out complicated edge cases. Just recently, Scorewarrior uncovered this bug with schema merge.

Yury Dynnikov from Scorewarrior says, "Schema merging causes very few problems for us these days."

Branch Permissions

Scorewarrior was an early adopter of branch permissions. Branch permission control which users can write to which branches. Read permissions are global to a server.

Scorewarrior's main branch is locked down. Each developer or designer has their own branch namespace. Teams have development branches. The added security of branch permissions prevents mistakes.

DoltHub

Scorewarrior uses DoltHub as a remote. DoltHub allows non-technical users the ability to inspect and change game configuration through a web user interface. It also allows Scorewarrior to leverage a Pull Request workflow for game configuration changes. Integrated human review of changes through a web user interface prevents mistakes.

Enterprise Support

Scorewarrior has been an Enterprise Support customer since early 2022. We've fixed many issues for them and they have influenced our development roadmap. They particularly leverage a private Discord channel to talk directly to Dolt developers. Yury Dynnikov from Scorewarrior says, "Even though there's a time difference, getting support directly from a Dolt developer is easy. Most issues are fixed in less than 24 hours."

Conclusion

Scorewarrior was an early adopter of Dolt. Scorewarrior uses Dolt and DoltHub to manage game configuration. Can Dolt help you manage your game configuration? We'd love to chat about it. Come by our Discord and we'll help you figure out how Dolt can help you.