How the scores were made
Methodology
Every number here is a calibrated judgment backed by source-code evidence. Here is the rubric, the weighting, the process, the external checks — and the limits.
The 1–10 anchors
| Score | Meaning |
|---|---|
| 1–3 | Amateur / serious problems |
| 4–5 | Works, but rough |
| 6–7 | Solid, well-executed |
| 8–9 | Professional grade |
| 10 | Industry-leading |
The weighting
Technical depth and design carry the most weight (20% each) because they define what a game *is*; backend/security and code quality (15% each) determine whether it survives contact with real users; testing, completeness and originality (10% each) round out the health check. The weighted total is computed live from the per-dimension scores — change one score and the total follows.
| Dimension | Weight | What it measures |
|---|---|---|
| Technical Depth | 20% | Engine & rendering technique, performance engineering (instancing, pooling, spatial structures), algorithmic substance, architectural difficulty. |
| Game Design | 20% | Core loop, balance, progression, game feel, UI/UX. For the non-game project (ssd) this dimension is scored as Content & Pedagogy. |
| Backend & Security | 15% | API design, database, anti-cheat, rate limiting, secret hygiene, input validation — or deployment security posture for static sites. |
| Code Quality | 15% | Architecture, modularity, naming, type discipline, duplication, magic numbers. |
| Testing | 10% | Automated test existence and coverage, assertions, CI. No tests at all scores 1–2. |
| Completeness | 10% | Playability/usability, polish, documentation, deployment status, audio & art coverage. |
| Originality | 10% | How much is genuinely new versus a copy of existing games or content — judged on mechanics and substance, not theme alone. |
The process
- Full clone, full history. All eight repositories were cloned with complete git history; commit timelines, authorship and cadence were analyzed alongside the code.
- Source-level review, not README-level. Every project's core game logic, backend functions, database schemas, security mechanisms, tests and build configs were read directly. Every claim in this report cites a file (and usually a line range) as evidence.
- One rubric, cross-calibrated. All eight projects were scored on the same 1–10 anchors by parallel reviewers using an identical brief, then cross-checked so a '7' means the same thing everywhere. For the one non-game (ssd), the Game Design dimension was re-scoped to Content & Pedagogy.
- Live verification. On 2026-07-20 all eleven public URLs of the first six projects (deployments, intro pages and the embedded game) were checked, and on 2026-08-25 the two life-sims' deployments were checked the same way — every one returned HTTP 200. All eight projects are live.
External verification
- Genre context: 'Vampire Survivors–like' is a recognized subgenre with its own Wikipedia entry; 3D takes on the formula (e.g. Megabonk, 2025, one million copies in two weeks) are an established trend — context for zombie-survivors' originality score. source ↗
- Ad-fakery context: the gap between Whiteout Survival's ads and its real gameplay is widely documented (the 'ads vs gameplay' genre of coverage) — the exact phenomenon fake-whiteout-survival satirizes by building the fake game for real. source ↗
- Shared authorship, checked in the data: CheerLife's README credits its original concept to 最先生 (@mr.themost), the same name on YaKyoLife's title screen — and `mr.themost <ja42022@gmail.com>` appears as a committer in YaKyoLife's git history, sharing an email address with that repository's owner account. The two games are treated in this report as one design lineage on that basis.
Limits & disclaimer
- This is a static, code-level audit: nobody profiled frame rates or fuzzed the APIs. Runtime claims (e.g. 'dead code never triggers') come from reading control flow, not instrumentation.
- Scores are calibrated judgments, not measurements. The rubric and evidence are public precisely so you can disagree with a number and check the reasoning behind it.
- Security findings are reported for defensive awareness. The leaked keys described here protect message boards on free hobby games; they are cited as hygiene lessons, not as an invitation.
- Commit counts are not comparable across projects. CheerLife was published entirely through the GitHub web UI, so its 17 commits are upload events, not development history; its real iteration happened off-platform and cannot be read from git at all.
- Two audit dates, not one. The first six projects describe commits as of 2026-07-20; yakyulife and CheerLife were audited on 2026-08-25 and describe their state on that date.
- One snapshot in time (2026-07-20). Repositories move; scores describe the audited commits, not the future.
This is an independent, unaffiliated analysis. Project names, repositories and trademarks belong to their respective owners. Findings describe the state of each repository as audited on 2026-07-20.