Goldmaster
Production dashboard indie játékstúdióknak.
Projekt áttekintés
Röviden.
A Goldmaster egy projekt management dashboard, amit kifejezetten kis indie játékstúdióknak terveztem — 2-5 fős csapatoknak, akik valódi játékokat készítenek szűk büdzsével, szűk határidőkkel, és nulla tolerenciával az útban lévő eszközök iránt.
Öt fő területet fed le: projekt áttekintés, task board, milestone követés, bug naplózás és csapat koordináció. Figmában terveztem, HTML/CSS/JS-ben építettem, és élőben deployoltam GitHub Pagesen.
Ez a projekt a 4. csomag ajánlatomat demonstrálja — end-to-end terméktervezés és frontend implementáció — üres briefből kész termékig.
A probléma
Az eszközök nem illenek az emberekhez.
A kis indie stúdiók rossz felhasználókra épített eszközök közé szorultak. A Goldmaster arra az egy kérdésre épül, amit minden projekt lead minden reggel feltesz magának: Tartjuk az ütemet?
Jira
Enterprise mérnöki csapatoknak tervezve. Erős, drága, és napokig tart konfigurálni. Egy négyfős indie stúdiónak nincs Scrum Mastere. Van egy fejlesztője, aki egyben a design briefet is megírja.
Trello
Túl egyszerű. Nincs milestone követés. Nincs build verziókövetés. Nincs játék-specifikus szóhasználat. Mindent egyedi címkékkel és workaroundokkal kell összetákolni.
Notion
Rugalmas, de igényes. Minden csapat a nulláról építi fel a saját rendszerét, és az állandó karbantartást igényel. Az eszköz szervezésével töltött idő nem a játék készítésére fordítódik.
Táblázatok
Amit a legtöbb kis stúdió valójában használ. Működnek, de nem skálázódnak, nem hozzák felszínre az akadályokat, és nem válaszolnak arra az egy kérdésre, amit minden projekt lead minden reggel feltesz magának.
A felhasználó
Kaito, projekt lead a PixelForge Studionál.
Kaito
Lead Developer & Project Manager · PixelForge Studio, Tokió
A PixelForge egy fiktív négyfős indie stúdió, akik az első kereskedelmi címükön dolgoznak. Kaito a vezető fejlesztő — és alapból a project manager is. Túl sok kalapot hord. Kódol, review-zik, követi a haladást, mozgásban tartja a csapatot. Nincs ideje olyan eszközre, ami karbantartást igényel.
Meg kell nyitnia a dashboardot, öt másodperc alatt megérteni a helyzetet, és vissza a munkához.
Céljai
- Bármikor pontosan tudni, hol áll a projekt
- Elkapni a scope creepet, mielőtt válsággá nőne
- Tartani a csapatot egy irányban napi standupok nélkül
- Időben kiszállítani — vagy legalább tudatosan későn, ne véletlenül
Félelmei
- Crunch, amit meg lehetett volna előzni
- Akadály, amit senki nem jelzett, amíg már túl késő nem lett
- Elveszteni a követést, hogy melyik build hozott melyik buggal
Az eszközei a Goldmaster előtt: Egy Notion doksi, amit a harmadik héten már nem frissített senki, és egy táblázat, amit ő maga épített és gyűlöl.
Kutatás
Valódi problémák, valódi források.
Ez egy koncepció projekt fiktív ügyféllel — de a probléma valós. Az indie játékfejlesztés jól dokumentált terület, és a production tooling körüli fájdalompontok következetesen felmerülnek a közösségben.
Hivatkozott források
- GDC postmortemek — nyilvános előadások, ahol a fejlesztők őszintén reflektálnak arra, mi ment félre
- r/gamedev — szálak production workflow-król, crunchról és tooling frusztrációkról
- itch.io fejlesztői blogok — indie stúdiók írásai a folyamataikról
- Blood, Sweat, and Pixels — Jason Schreier
Kulcs minták
A scope creep az első számú gyilkos
A stúdiók következetesen alábecsülik a feladatokat, és nem veszik észre az elcsúszást, amíg már mélyen a crunchban vannak. Egy eszköz, ami felszínre hozza a milestone-onkénti teljesítettségi százalékokat, korábban láthatóvá teszi az elcsúszást.
A játékfejlesztésnek saját nyelve van
Alpha, Beta, Gold Master, build number, QA pass — ezek a kifejezések konkrét dolgokat jelentenek. Egy általános PM nyelvet használó eszköz súrlódást okoz. Egy eszköz, ami ugyanazt a nyelvet beszéli, ezt eltünteti.
A kis csapatoknak láthatóság kell, nem hierarchia
Senkinek sem kell ticketeket menedzserekhez rendelnie. Azt kell látniuk, ki min dolgozik, mi van blokkolva, és mi következik.
Felhasználói folyamat
Design rendszer
Még mielőtt egyetlen képernyő is megszületett volna.
Színek
Közel-fekete háttér (#0D0D0D, #141414, #1C1C1C) egyetlen arany accenttel (#E8C547). Az arany közvetlenül kapcsolódik a termék nevéhez — gold master, az a pillanat, amikor a játék kész és szállításra kész. A státusz színek a standard piros/sárga/zöld tompított verziói — az UI nyugodt marad, még akkor is, ha az adatok nem.
Tipográfia
DM Mono minden adathoz, számhoz, build verzióhoz és kód-szomszédos címkéhez. Syne a címsorokhoz, navigációhoz és UI címkékhez. A kombináció technikai és editorial érzetet kelt — egy eszköz, amit valaki olyan készített, akit érdekelt.
Megépített komponensek
Navigáció · Card shell · Task kártyák (összes állapot) · Típus tagek · Státusz badgek · Súlyossági badgek · Progress bar · Avatar státusz ponttal · Gombok · Filter pillek · Táblázat sorok. Minden komponens Auto Layouttal épült Figmában. A fájl handoff-ready.
A képernyők
Öt képernyő. Egy kérdés megválaszolva képernyőnként.
01. képernyő
Projekt áttekintés
"Tartjuk az ütemet?"
A dashboard kezdőlapja. Minden elem arra van kiválasztva, hogy egy kérdést a lehető leggyorsabban megválaszoljon. Játék címe, build száma, összesített teljesítettség, a következő milestone-ig hátralévő napok, aktív sprint cél, top akadályok, csapat státusz. Semmi más. A három top akadály a legfontosabb design döntés ezen a képernyőn — ahelyett, hogy a blokkolt taskok a task boardban temetve lennének, automatikusan itt jelennek meg.
02. képernyő
Task Board
"Min dolgozik mindenki?"
Egy kanban board, ami játékfejlesztésre van strukturálva — nem általános PM munkára. Az oszlopok: Backlog, In Progress, In Review/QA és Done. A taskok típus szerint vannak címkézve: Art, Code, Audio, Design, QA, Writing. A típus tagek valódi problémát oldanak meg — játékfejlesztésben egy "blokkolt" task mást jelent attól függően, hogy kód-függőség vagy egy art asset, ami briefre vár. A drag-and-drop JavaScriptben van implementálva.
03. képernyő
Milestone Tracker
"Milyen messze vagyunk a kiszállítástól?"
Egy vízszintes idővonal, ami a Pre-Productiontől a Post-Launchig fut. A teljesített milestone-ok az arany accenttel vannak kitöltve. Az idővonal alatt minden milestone-nak van egy kártyája, ami mutatja a célzott dátumot, teljesítettségi százalékot, státuszt (On Track / At Risk / Delayed), és a nyitott blokkoló taskok számát. A design szándéka az volt, hogy az idővonal térképnek érződjön — ne haladási jelentésnek. Egy navigációs eszköz.
04. képernyő
Bug & Issue napló
"Mi nem működik és kihez tartozik?"
Egy tiszta adattáblázat. Bug címe, súlyosság, kihez van rendelve, melyik build számban találták meg, és a jelenlegi státusz. A sorok 52px magasak — olvashatóak, de sűrűek. Súlyosság szerinti rendezés. Státusz szerinti szűrés. Gyors megoldás kapcsoló minden soron. A build szám oszlop apró, de fontos részlet — játékfejlesztésben tudni, mikor jelent meg egy bug, ugyanolyan fontos, mint tudni, hogy mi az.
05. képernyő
Csapat nézet
"Mindenki jól van?"
Négy csapattag kártya. Mindegyik mutatja a nevet, szerepet, jelenlegi feladatot, kapacitás indikátort, egy személyes fókusz jegyzetet és az utolsó aktív időbélyeget. Ez a képernyő kifejezetten nem időkövető eszköz. A design szándéka a koordináció, nem a felügyelet. A személyes fókusz jegyzet — egy rövid szabadszöveges mező, ahol minden csapattag leírja, mire fókuszál ezen a héten — közvetlenül a kutatásból származott.
Az építés
Figmában tervezve. HTML/CSS/JS-ben építve.
Mind az öt képernyő reszponzív frontendként épült vanilla HTML, CSS és JavaScript használatával. Nincsenek frameworkök. Nincsenek könyvtárak, kivéve a SortableJS-t a task board drag-and-drop funkciójához.
- CSS custom property-k minden színhez, betűmérethez és térközhöz — az egész vizuális rendszer a :rootban él
- A sidebar fix komponens, az összes képernyőn megosztva
- A progress barok oldalbetöltéskor animálódnak CSS @keyframesszel
- A milestone idővonal tiszta CSS-szel épült — nincs canvas, nincs SVG könyvtár
- A task board drag-and-drop SortableJS-szel implementálva
- Teljesen reszponzív — működik tableten és mobilon
- GitHub Pagesen deployolva
Reflexió
Mit csinálnék másképp valódi ügyféllel.
Ez a projekt önirányított volt, ami szabadságot adott, de elvett valami fontosat — a súrlódást. Egy valódi ügyfél visszanyomott volna. Lettek volna olyan megkötései, amiket nem láttam előre, preferenciái, amik köré kellett volna terveznem, és üzleti céljai, amik teljesen átírhatták volna a prioritásokat.
Mit tanultam
- A brief megírása a Figma megnyitása előtt volt az egyetlen legjobb döntés. Tervezési döntéseket kényszerített ki, mielőtt csábításba estem volna, hogy csak szépre csináljam.
- A design rendszer építése a képernyők előtt az egész folyamatot gyorsabbá és konzisztensebbé tette. Komponensek először, képernyők utána — ez a sorrend, ami működik.
- A kódolt frontend olyan dolgokra tanított, amire a Figma fájl nem tudott volna. A design és implementáció közti szakadékban él a valódi mesterség.
Mit építenék következőnek
- Felhasználói autentikáció és perzisztens adatok
- Egy "crunch riasztás", ami jelez, ha egy milestone veszélyben van a jelenlegi task tempó alapján
- Értesítések blokkolt taskokról és lejárt milestone-okról
Ez az a funkció, ami a Goldmastert valóban hasznossá tenné, nem csak vizuálisan vonzóvá.