|
Hey 👋 I'm happy to share a tool I've been quietly working on for some time now. Sorry I'm 25 years late for contributing.
screpdb is a BWChart-style tool (replay-based reporting on your local computer), but with a heavy focus on semantic reporting.
It's complementary to existing tools like RepMastered and vespene.gg; each does different things. In fact Dakota_Fanning has been very helpful with knowledge transfer, and the tool is based on screp which is his project as well.
Some screenshots (not an exhaustive list of features):
Filtering replays by high-level semantic features
Game summary, with one-click staging of a replay for watching on the game client
Rich game events browser with map overlays
Skill proxies measurements: Viewport Multitasking, Unit Production Cadence, First Unit Efficiency
Here's the project page: https://github.com/marianogappa/screpdb
Installation instructions: https://github.com/marianogappa/screpdb/tree/main#installation
And here's the story behind it in my blog (it touches on replay engineering, community tools, AI, you might find it an enjoyable read): https://marianogappa.github.io/thoughts/building-an-advanced-starcraft-reporting-tool/
Since it hasn't seen extensive testing by enough people, you should currently treat it as an unfinished product with rough edges, but I'm here to make corrective/perfective maintenance. I'd love your help to improve it.
We've been using it every weekend with my best mate for months and we really enjoy it for pre-game intel and post-game review; I also use it for finding and staging specific replays quickly for watching.
It’s fully free 🍺 and open source. No donations needed, don’t buy me a coffee. You can contribute by filing issues & improvements.
Also thanks to 2Pacalypse- & Peeano (and others) for their help betatesting and for pointing me to the right people.
|
Croatia9545 Posts
It's an interesting looking tool! Has a lot of features and options so it might take some time to figure out all the benefits you get out of using it.
|
The semantic search is something a lot of people have been asking for elsewhere. Really cool! Could you go into a bit of detail as to how you made it work?
|
On July 14 2026 22:07 Jealous wrote:
The semantic search is something a lot of people have been asking for elsewhere. Really cool! Could you go into a bit of detail as to how you made it work?
Hey, thanks!
The best answer to this question is the So, how do you get semantics anyway? chapter of the blogpost. The section before that explains why it's hard to get semantics from replays.
As a quick TL;DR:
- Created a separate library that extracts map data (starting locations, walls, ramps, walkability) and calculates base polygons and other semantics (e.g. mineral-only, "natural", "9 o'clock"). Once you have this, you can infer "cannon rush" and all things like that, since that requires knowing where things happen semantically.
- Minimised replay spam with a battery of best-effort algorithms like per-player economy simulation (not all algos are best effort, e.g. most researches cannot be done twice so I only keep the latest ones). This surfaces the building blocks for Build orders.
- Manually and patiently watched ~200 replays and tagged them manually in order to have "integration tests" to validate that a set of rules correctly matches certain build orders.
- There's an annoying way to enrich "incomplete" commands with coordinates and unit types based on keeping track of something called "unit tags". It's a little technical, but the bottom line is that it's possible to get a better understanding of commands by implementing some reasonably straightforward algorithm.
I'd be happy to go into detail on specific cases, but I suspect no one cares 😂 Just let me know if you're curious. I'd be more than happy to nerd out on this; I absolutely love it.
|
I am not able to dive in to the project deeply at the moment, but from what I've seen, there are obviously cool features and the "semantics search" or wtv is an incredibly valuable way to work with our large replay archives.
If I'm not mistaken this may lead to the first win % by build order down the road. Which I think would great way to understand maps/matchups in the pro scene.
Thank you for your time and energy and your contribution. May the future treat you as well as you have treated us. Cheers!
|
It looks awesome! Thank you for sharing and your contribution! Downloading it now!
|
Looks awesome, thank you so much for investing your time into this!
Also kudos for not charging 50$ for it!
|
There has been so many tools presented lately that im really out of the loop. I wish someone did a recap about all of them lol.
|
On July 15 2026 23:48 [sc1f]eonzerg wrote:
There has been so many tools presented lately that im really out of the loop. I wish someone did a recap about all of them lol.
Look no further! 😂 The tools that already existed. Someone let me know if I missed something big.
|
On July 15 2026 12:15 AttackZerg wrote:
I am not able to dive in to the project deeply at the moment, but from what I've seen, there are obviously cool features and the "semantics search" or wtv is an incredibly valuable way to work with our large replay archives.
If I'm not mistaken this may lead to the first win % by build order down the road. Which I think would great way to understand maps/matchups in the pro scene.
Thank you for your time and energy and your contribution. May the future treat you as well as you have treated us. Cheers!
That's an interesting use case; I'll open an issue this week to look into it. Player aggregations is something I struggled a lot with.
There are some big challenges with it though. Off the top of my head:
- I think no two people can agree on a standard categorisation of build orders.
- Build order matching is reasonably good but it's still best-effort, I think a perfect automated system is unattainable based on replays alone.
- screpdb wasn't really optimised for ingesting large numbers of replays. After the 1000 replay mark, re-ingesting becomes kinda slow, and certain queries become slow, making the UI slightly sluggish. This is mostly a design decision to use SQLite as a storage backend, which is not optimised for fast ingestion or OLAP queries, but it's zero-dependency, embedded relational database, and folks that might contribute or build on top understand well.
These are solvable problems though, given sufficient interest. Certainly, if a progamer would find it useful, I think it's worth putting some work onto it.
|
Very nice work!
This is slightly off-topic, but It would be incredibly cool to be able to get the BO information from replays as well. But due to how replays work, there's no other way other than re-running the game engine.
The headless openBW setup can process a 10 minute game in below 1 second (i.e. fully re-run the game). However this only works with replays 1.16.1 and below.
If we somehow could get the dude from the other thread to share how he got headless remastered to run, we'd be set... well almost. We'd also need to convince @dakota_faning to run it on about 25 million replays :D
|
awesome app - 8000 is an extremely common port to use for web apps locally, i do wonder if you want to consider using an entirely different/random port for other people
|
On July 20 2026 22:28 SethN wrote:
awesome app - 8000 is an extremely common port to use for web apps locally, i do wonder if you want to consider using an entirely different/random port for other people
Don't worry! On startup, screpdb will check if the port is being used, and if so it'll use a different one. This is also to prevent multiple instances open: if the port is being used by a different screpdb instance it will just route you to the existing one and shutdown.
EDIT: I forgot to mention that you can also select the port with `--port 1234` if you run it via terminal (e.g. PowerShell)
|
On July 16 2026 05:17 Kraekkling wrote:
Very nice work!
This is slightly off-topic, but It would be incredibly cool to be able to get the BO information from replays as well. But due to how replays work, there's no other way other than re-running the game engine.
The headless openBW setup can process a 10 minute game in below 1 second (i.e. fully re-run the game). However this only works with replays 1.16.1 and below.
If we somehow could get the dude from the other thread to share how he got headless remastered to run, we'd be set... well almost. We'd also need to convince @dakota_faning to run it on about 25 million replays :D
Hey, it's not off topic 👍
I assume you mean dethsc and vespene.gg. Always happy to collaborate!
At the moment that project is closed source so you're right that I cannot use that. But according to dethsc, it's a reverse-engineer, so although it's conceptually "headless remastered", technically it's a reimplementation (same as openBW), so I can't be 100% sure that the output is exactly what you'd see in the replay without sufficient manual tests.
But currently screpdb does get BO information from replays, and I'd say it's pretty decent at it. Perhaps the categorisation isn't quite what everyone expects; I'm happy to revise it. The main limitation from replays info alone is tracking worker counts (command spam is hard to eliminate), especially with Terran & Protoss. Other than that, the difficulty in inferring build orders is intrinsic to defining them formally (that is, even with 100% knowledge you'd struggle anyway).
|
Very nice!
Also iCCup in nickname means old school cool if any newer people are wondering. ^_._^
|
|
|
|
|
|
EPT![[image loading]](https://cdn.jsdelivr.net/gh/marianogappa/screpdb@e83a995e2e4a65adbf9a00e1c246d68695b35736/docs/images/game-list.png)
![[image loading]](https://cdn.jsdelivr.net/gh/marianogappa/screpdb@e83a995e2e4a65adbf9a00e1c246d68695b35736/docs/images/game-summary.png)
![[image loading]](https://cdn.jsdelivr.net/gh/marianogappa/screpdb@e83a995e2e4a65adbf9a00e1c246d68695b35736/docs/images/game-events.png)
![[image loading]](https://cdn.jsdelivr.net/gh/marianogappa/screpdb@e83a995e2e4a65adbf9a00e1c246d68695b35736/docs/images/skill-proxies.png)
