WIP: Session Statistics Prototype

Quaternions commented

2025-07-26 03:05:19 +00:00

Owner

Sessions are created once and immutable (no Update)
List is used to display session history so players can discover which maps they previously played
Aggregate is used to sum play time and attempts.
- Filter by MapID-GameID to see total play time and attempts for map
- Filter by MapID-GameID-UserID to see play time and attempts for player on map
- Other filters are possible but I do not currently plan to use any others. Could be fun for landing page statistics: "Bhoppers have played a collective 8912487 hours with 14091015082 attempts!"
Attempt number is added to Times table to record the exact attempt number of the time entry

- Sessions are created once and immutable (no Update) - List is used to display session history so players can discover which maps they previously played - Aggregate is used to sum play time and attempts. - Filter by `MapID-GameID` to see total play time and attempts for map - Filter by `MapID-GameID-UserID` to see play time and attempts for player on map - Other filters are possible but I do not currently plan to use any others. Could be fun for landing page statistics: "Bhoppers have played a collective 8912487 hours with 14091015082 attempts!" - Attempt number is added to Times table to record the exact attempt number of the time entry

Quaternions added 4 commits 2025-07-26 03:05:19 +00:00

sessions 55c8dfd379

sessions: extend with attempts 1969f9e2fe

sessions: aggregate request 62ffc6a365

times: record attempt number to time entry 8a5f33b1b4

Quaternions commented

2025-07-26 03:07:01 +00:00

Author

Owner

Problem: Sessions as proposed do not include GameID. If maps are on multiple games, such as Fly Trials (and I'd like to add surf_mail_yourself_in_a_box to bhop), they are not seperable.

Quaternions added 1 commit 2025-07-26 03:09:15 +00:00

sessions: track GameID 149ee727ca

Quaternions commented

2025-07-26 03:09:58 +00:00

Author

Owner

Sessions could be further subdivided per-style, but that seems excessive. It's appealing in the sense that we could track how much time players spend in each style...

Quaternions added 1 commit 2025-07-26 03:18:30 +00:00

sessions: record StyleID e687c190ba

Quaternions commented

2025-07-26 03:19:14 +00:00

Author

Owner

I've given in and added StyleID. I'm imagining a player profile page that shows your hours in each style. May as well track it from the start.

Quaternions force-pushed sessions from e687c190ba to a3a63a8475

2025-07-26 03:19:52 +00:00

Compare

Quaternions added 1 commit 2025-07-26 03:22:17 +00:00

sessions: remove SessionsService.Get a18a5c423b

I can't think of any scenario where getting a session by ID is required.

itzaname commented

2025-07-26 03:41:14 +00:00

Owner

Why is AttemptNumber part of the Times table? That introduces coupling that should be avoided. If the statistics service is the primary consumer of this field, it should likely live there instead. Keeping it in the Times table ties unrelated concerns together and reduces modularity.

It also looks like the statistics service is being set up to issue broad, generic queries, with the expectation that downstream consumers will perform further processing and aggregation. That approach scatters logic across services and weakens the role of the statistics service. Ideally, it should act as the source of truth and return data in a form as close to final as possible. Aggregating closer to the database is generally more efficient and easier to maintain.

Right now, this is still very bare bones and doesn’t show how you plan to implement each user story. I’d recommend fleshing out the actual use cases, expected query patterns, and specific data access needs before moving forward. We need to be clear on what we’re trying to solve to avoid issues later.

Why is AttemptNumber part of the Times table? That introduces coupling that should be avoided. If the statistics service is the primary consumer of this field, it should likely live there instead. Keeping it in the Times table ties unrelated concerns together and reduces modularity. It also looks like the statistics service is being set up to issue broad, generic queries, with the expectation that downstream consumers will perform further processing and aggregation. That approach scatters logic across services and weakens the role of the statistics service. Ideally, it should act as the source of truth and return data in a form as close to final as possible. Aggregating closer to the database is generally more efficient and easier to maintain. Right now, this is still very bare bones and doesn’t show how you plan to implement each user story. I’d recommend fleshing out the actual use cases, expected query patterns, and specific data access needs before moving forward. We need to be clear on what we’re trying to solve to avoid issues later.

👍 1

Quaternions commented

2025-07-26 05:37:57 +00:00

Author

Owner

I'll need to ruminate on your points and flesh out my ideas for ability estimation using session data.

Writing down another consideration: if MapID and StyleID switches, it creates a new "session", but it's not actually a new session. I mentioned an idea to address this in my original post StrafesNET/data-service#32 (comment)

we can use the same SessionID for playing multiple maps within the same session

and extend that to when the StyleID changes too. However, session count seems like low-value data, and I already track JoinCount in the PlayerData. I'm also not fond of this idea since it's an aggregate-timeline hybrid. The only way to really get a handle on session count at different hierarchical levels (server session count, map session count, style session count) would be to switch to a pure timeline of events like "Player Joined" "Map Changed" "Player Changed Style" "Player Left" and that seems like a pain in the ass to aggregate.

I'll need to ruminate on your points and flesh out my ideas for ability estimation using session data. Writing down another consideration: if MapID and StyleID switches, it creates a new "session", but it's not actually a new session. I mentioned an idea to address this in my original post https://git.itzana.me/StrafesNET/data-service/issues/32#issue-589 > we can use the same SessionID for playing multiple maps within the same session and extend that to when the StyleID changes too. However, session count seems like low-value data, and I already track JoinCount in the PlayerData. I'm also not fond of this idea since it's an aggregate-timeline hybrid. The only way to really get a handle on session count at different hierarchical levels (server session count, map session count, style session count) would be to switch to a pure timeline of events like "Player Joined" "Map Changed" "Player Changed Style" "Player Left" and that seems like a pain in the ass to aggregate.

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin sessions:sessions

git checkout sessions

WIP: Session Statistics Prototype #10

Checkout