Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/player-one/llms.txt

Use this file to discover all available pages before exploring further.

The Case Studies page takes the portfolio’s most significant and complex projects and presents them as boss battles — the climactic, high-stakes encounters that define a player’s campaign. Where the Projects page (/projects) gives each work a quick arcade-cabinet summary, this route goes deep: each case study walks through the problem that had to be defeated, the strategy and tools deployed to fight it, and the outcome that marked victory. The Briefcase icon in the navigation panel positions these as serious professional engagements. The boss-fight metaphor transforms what might otherwise feel like dry project documentation into a narrative the visitor wants to follow to its conclusion.

Route Info

PropertyValue
Path/case-studies
Arcade LabelBOSS BATTLES
Navigation IconBriefcase (briefcase)
Page TransitionPageTransition blur/scale wrapper, pt-24 pb-32 padding

Visual Layout

Each case study is presented as a full-width section or a large card with a dramatic internal structure:
  1. Boss intro header — project name displayed as a “BOSS NAME” title card, optionally with a difficulty rating or context badge.
  2. The Problem (encounter setup) — a clearly delineated section describing the challenge, constraint, or client need that initiated the project.
  3. The Solution (battle strategy) — the approach taken: architecture decisions, technologies chosen, design patterns applied, and key implementation details.
  4. The Outcome (victory screen) — measurable results, lessons learned, and what the delivered work achieved.
  5. Supporting media — screenshots, diagrams, or links to the live result or repository.
Multiple case studies stack vertically, separated by thematic dividers that evoke boss-stage transition screens.

Key Components

PageTransition

Shared entrance animation wrapper. Blurs and scales the case study content in on route navigation.

Case study card / section

The primary content container for each boss battle. Holds the problem, solution, and outcome sub-sections with pixel-styled internal headings.

Navigation

Used in the Navigation inventory panel to identify this route. Signals professional depth and seriousness relative to the lighter Projects page.

GhostSprite

Background floating sprites consistent across all routes, maintaining the arcade atmosphere behind the detailed writeups.

Content Structure Per Case Study

Each boss battle entry follows the same three-act narrative structure:
SectionArcade MetaphorWhat to Write
ProblemBoss encounter beginsThe challenge, constraint, client need, or technical problem that had to be solved
SolutionBattle in progressTechnologies, architecture, design decisions, and implementation approach
OutcomeVictory screenMeasurable results, shipped deliverable, lessons learned, or impact achieved

Interactivity & Special Features

  • Boss intro animation — the boss name/title card may animate in with a dramatic entrance (shake, flash, or glitch effect) to heighten the encounter feeling.
  • Section reveals — problem/solution/outcome sub-sections can animate in sequentially on scroll to simulate the escalating tension of a boss fight phase.
  • Media embeds — screenshots or short video clips of the delivered work can be embedded within the solution or outcome sections to ground the narrative in tangible evidence.
  • Difficulty or impact badges — optional pixel badges (e.g., “HIGH COMPLEXITY”, “SHIPPED TO PRODUCTION”, “TEAM OF 4”) provide at-a-glance metadata about each engagement.

Customization Notes

Case study content lives in a data array or set of structured objects inside the Case Studies page component. Each entry should have at minimum a title, problem, solution, and outcome field. Add new case studies by extending that array.
Not every project belongs here. Reserve the Case Studies route for two to four of the most complex, impactful, or technically interesting projects. Use the Projects (/projects) page for the broader catalogue. Depth over breadth is what distinguishes a boss battle from a regular level.
Write the Problem section first and make it specific — a vague problem statement (“the client needed a website”) undermines the drama. Concrete constraints (“the platform had to handle 10,000 concurrent users with a two-week deadline”) make the subsequent solution feel genuinely hard-won.
The Outcome section is the victory screen — make it feel like one. Lead with the most impressive quantifiable result (load time reduced by 60%, feature shipped on time, zero downtime migration) before discussing softer takeaways. Visitors remember the scoreboard.
Avoid copying and pasting the same project that already appears in the Projects page without adding meaningful new depth. If a case study doesn’t contain substantially more detail than the arcade cabinet summary, it doesn’t justify the Boss Battles treatment and may feel like filler to an attentive visitor.

Build docs developers (and LLMs) love