The desktop UI manages profiles, draft state, candidate lists, and score explanations through commands and observable view models.
Case File 02
Competitive Drafting AssistantExplainable recommendations for time-limited team decisions.
A desktop decision-support tool that combines player comfort, role fit, patch value, team composition, counter pressure, and draft risk.
01 / Product
What the application does
The application gives a coach or player a structured draft board rather than a single opaque recommendation. Users create team profiles, rate champions by player and role, import a patch dataset, and compare candidate picks while the draft changes.
Every recommendation exposes its component scores and weightings. The tool is designed to support discussion, not replace human judgement.
Primary workflow
Load team profile → enter bans and picks → compare candidates → inspect score breakdown → save scenario.
Illustrative stack
C#, .NET 10, Avalonia, MVVM, SQLite, configurable scoring engine, JSON patch imports.
Core features
Player profiles, champion-role ratings, draft board, composition tags, candidate comparison, scenario history.
Target users
Competitive teams, coaches, analysts, organised amateur groups, and players reviewing draft choices.
Top lane candidateChampion A
Jungle candidateChampion B
Mid candidateChampion C
Bot candidateChampion D
Support candidateChampion E
Player comfort88
Role fit82
Patch value74
Composition fit91
Draft risk68
02 / Problem
The problem behind the interface
A strong statistical pick can still be wrong for the player, team identity, or current composition. Drafting compresses many uncertain inputs into a short decision window.
The application needed to organise that complexity without presenting a score as objective truth. The user should always be able to see why the recommendation changed and which assumptions caused the change.
Primary design requirements
- Keep player-specific ratings separate from general patch data.
- Expose every scoring component and weighting.
- Allow fast comparison without forcing the user through several screens.
- Represent missing data and uncertainty rather than silently substituting zero.
- Save draft scenarios so decisions can be reviewed after a match.
03 / Ownership
My role and responsibilities
As Project Lead and the studio’s only developer, I treated the project as both a software system and a product exercise. I owned scope, technical direction, interface behaviour, implementation, testing, prioritisation, and the final portfolio narrative.
- Defined the scoring categories and the first usable draft workflow.
- Designed SQLite entities for players, champions, role ratings, patch values, composition tags, and saved drafts.
- Implemented the Avalonia draft board, filters, profile editor, comparison panel, and score explanation views.
- Built a deterministic scoring engine with configurable weights and human-readable reasons.
- Created sample team data and review scenarios to test score changes and edge cases.
04 / Architecture
How the proof of concept is structured
The scoring model is isolated from the Avalonia interface so it can be unit-tested and adjusted without rewriting presentation code.
SQLite stores players, role comfort, champion metadata, patch versions, composition tags, and saved scenarios.
Pure C# domain services calculate component scores, apply configurable weights, and return both the total and the reasons behind it.
A versioned import layer reads external patch data from JSON and records the source version so historical drafts remain reproducible.
05 / Decisions
Technical decisions worth discussing
The proof of concept is intentionally small, but the decisions below show how the application would remain understandable and maintainable as it grows.
The interface displays comfort, role fit, patch value, composition fit, counter pressure, and risk as separate values.
Player comfort 30%, role fit 20%, patch value 20%, composition fit 15%, counter pressure 10%, draft flexibility 5%.
An unknown value produces an incomplete-data warning and reduces recommendation confidence instead of being treated as zero.
Every saved draft stores the patch version, team profile version, weights, picks, bans, and resulting breakdown.
06 / Validation
Sample proof-of-concept evaluation
The sample proof of concept was reviewed against twelve draft scenarios designed to expose weight changes, incomplete profiles, and composition conflicts.
Each scenario produced a repeatable breakdown and could be reloaded with the same patch and profile versions.
Users could identify which factor changed the recommendation without opening a separate diagnostic screen.
Increasing player comfort from 30% to 45% changed several recommendations, making the trade-off visible rather than hidden.
Candidates with missing role or comfort data were flagged as lower-confidence instead of receiving a misleading precise score.
07 / Outcome
Result, limitations, and next steps
The proof of concept demonstrates a complete local workflow for profile management, draft entry, candidate comparison, and explainable scoring. Its largest limitation is that the sample model is only as useful as the quality of the player ratings and patch dataset provided.
The recommendation can be challenged because the interface exposes both its inputs and its assumptions.
The scoring model does not prove competitive advantage and should not be presented as predicting match outcomes.
Add historical draft review, opponent tendencies, pick/ban simulation, collaborative team notes, and versioned model experiments.
Show one complete draft, one sensitivity comparison, the scoring-service tests, and the stored scenario schema.
What this project demonstrates
C# application architecture, Avalonia data-heavy interfaces, SQLite modelling, explainable scoring, configuration management, and responsible presentation of uncertain recommendations.
Project links