Návod pro začínající vývojáře a týmy

[Paranoik]

Návod pro začínající vývojáře

V uplynulých letech jsem spolupracoval s několika více či méně úspěšnými týmy, které však ve většině případů svou práci nedokončily. Existuje spousta důvodů a rád bych pár všeobecných rad naházel zde na jedno místo, aby i začínající vývojáři neopakovali chyby, které i pro ně mohou být fatální. Tolik k důvodu proč vlastně tento text vzniká.

Předně, na začátku jakékoliv hry je nápad. U amatérsky tvořených projektů málokdy budete mít k dispozici tým, který nemá co dělat a roubovat nápad na to, co zvládne. V drtivé většině je to více či méně zajímavý nápad, kvůli kterému dáváte dohromady tým. Není to dobře ani špatně, bohužel je třeba si uvědomit, že jádro takového týmu tvoří třeba pouze dva lidé, kteří se znají nějak dlouhodoběji a dokáží spolupracovat, zbytek jsou "guesti", ze kterých se mohou vyklubat skuteční profesionálové, většinou ale bohužel skončí na opačném konci pomyslné stupnice. Nikdy se za žádných okolností nepouštějte do realizace své vize s nesehraným týmem. Dejte dohromady všechny zdroje, zapojte všechny části týmu a udělejte něco jednoduchého - třeba tetris nebo arkanoid s nějakým inovativním prvkem. Chovejte se i k tomuto projektu tak, jako by to byl váš hlavní - vytvořte návrh, odhadujte čas, jaký na jednotlivých částech strávíte, všechno archivujte a výsledek s těmito odhady srovnejte, využívejte forum a veškeré vývojářské nástroje, které byste použili u jiného projektu. Taková jednoduchá hra by vám neměla sebrat více než pár desítek hodin čistého času, na druhou stranu ale odhalí spoustu nedostatků ve vzájemné interakci a do následujícího vývoje se tento čas několikanásobně vrátí.

V drtivé většině případů je na začátku amatérských vývojových týmů jeden člověk s jedním nápadem, případně vizí. Nechci tvrdit, že špatným, ale opět - v drtivé většině týmů se tento jedinec jakožto "nositel základní myšlenky" dosazuje do pozice lídra týmu, designera a manažera, a jelikož nemá zkušenosti, pravděpodobnost dokončení projektu je skutečně mizivá. Abychom se z tohoto zamotaného kruhu vymanili, vytvořme seznam požadavků, které jsou na takového manažera naloženy.



1) Zrání
Ve většině případů dochází k tomu, že designér chce všechno hned, teď a okamžitě. Začíná to tak, že teď má nápad, teď chce sehnat lidi a teď chce začít pracovat na vývoji (a ideálně za týden už mít realizovaný nápad na stole). Opět, neříkám, že je to špatně, ale existuje jedna, i pro nábor lidí rozumnější cesta - zpracovat herní koncept písemně. Na začátku musí být komplexní vize a nikoliv pouze jeden nápad - nelze vytvářet hru jako "nějaké RPG s inovativním bojovým systémem ..." Takže cílem je vytvoření dvou dokumentů. V první fázi patří do dokumentu cokoliv, co patří ke hře a co dokáže takovou vizi přiblížit ostatním lidem, všechny záznamy je vhodné pořizovat digitálně, tedy i artworky a poznámky co nejdříve přepisujte nebo foťte a především opatřujte datovými razítky. Sepsanou studii nechte řádově dny uležet.

Čtěte si výsledek každý den, opravujte chyby, doplňujte detaily a zpřesňujte nedodělky. Jakmile je tento koncept hotov, zpracujte z něj výtah o objemu zhruba 2-5 tisíc znaků. Tento výtah musí obsahovat velmi stručné seznámení s projektem a především být doplněn o informace o aktuálním vývoji jako použité technologie, odpracovaný čas, odhadované dokončení, odkazy na bližší informace (web projektu) a kontaktní údaje. Tento text je pak vhodné používat při náborových akcích a vlastně svým způsobem patří na hlavní stránku webu o projektu. Do tohoto stručného textu nepatří například citace příběhu, jména postav nebo popis systému bitev. Z tohoto výtahu musí být jednoznačně jasné, jestli půjde o mix člověče nezlob se a šachů nebo skákací plošinovku. Nikoho v tuto chvíli nezajímá, jestli má princezna tři hlavy a žere draky, ale čím má být hra zajímavá a proč zkusit ji a ne některou z tisíců jiných.

Již během vytváření konceptu je třeba brát v úvahu několik následujících bodů:

- Je nápad životaschopný?
Autor je málokdy schopen nápad zkritizovat, je tedy vhodné vytvořit seznam s body proč se do projektu pouštět a proč nikoliv. Nápad je vhodné konzultovat s několika lidmi a tyto seznamy průběžně doplňovat.

- Je nápad zajímavý?
Stejně jako u předchozího bodu, autorovi bude připadat nápad zajímavý vždy, jinak by jej nepublikoval. Nezávislé posouzení je tak velmi vhodné. Samozřejmě je třeba brát v úvahu nejen samotný nápad, ale koncept jako celek. Ani zajímavý nápad však není všechno, hru nedělá jeden nápad napasovaný na jinou hru, ale především provedení a sladění všech částí. Zajímavé nápady mám dva denně a u některých je mi vážně líto, že se žádné realizace nedožijí.

- Je nápad originální?
Většina amatérských her vzniká jako reakce na nějakou hru komerční, čerpají z nich to dobré a špatné něčím nahrazují. Někdy to funguje, jindy nikoliv. Místo přepisování celé hry se v tomto případě zamyslete nad možnostmi modování původního projektu. Základna hráčů bude pravděpodobně větší a celkově máte k dispozici již kompletní produkt, na jehož základech pouze realizujete vlastní nápady.

- Jaká je cílová skupina?
Kdo by měl hru vlastně hrát? Jsou to krvavá jatka, logika nebo adventura? Každý herní a i grafický styl má svoji cílovou skupinu a ty jsou různě početné. Cílové skupině je třeba koncept přizpůsobit - například frekvencí autosave, objemem textů a složitostí textů, hádanek, herním časem a případně též nutným časem, který je do hraní nutné investovat denně (například plněním denních questů). Stejně tak je třeba přizpůsobit distribuci a PR.

- Jak bude vývoj financován?
Přestože většina amatérských her vzniká pouze jako fanouškovská dílka s původním záměrem věnovat se jim pár týdnů a pak je vypustit zdarma na webu, čas ukáže, že původní představy se s realitou rozcházejí, a z původních pár týdnů se může občas stát i pár let. Každý z týmu vývoj bral nejdříve jako oddychovou aktivitu, ale čím je akce delší, tím více sil stojí a určitá finanční kompenzace je motivující. Jako kompenzaci můžete uvažovat i společnou dovolenou nebo workshopy v hospodě. Berte v úvahu též možný nutný nákup softwarové výbavy - vývojové nástroje, grafické a zvukové editory, grafický engine. Pokud má tým dostupné zdroje, vhodným PR lze na web projektu přilákat klidně i tisíce lidí a od části získat dotace na vývoj. Stejně motivačně může pro vývojáře znít vidina alespoň nějakého mála - z prodaných her nebo dotací si sice nejspíš nepostaví dům a ani nekoupí auto, ale každá korunka dobrá. V okamžiku, kdy jde o prachy však padají i nejvěrnější přátelství a původně sehraný tým si může jít po krku i kvůli drobným, je tedy nanejvýš vhodné dohodnout a všemi nechat akceptovat rozdělení případných zisků. Jako nanejvýš efektivní jsem zažil transparentní systém "akcií". Každá akce, část vývoje, otestování, nebo i hodnocení podnětných příspěvků na fóru (tedy přivydělat si mohli i lidé mimo původní tým) je ohodnocena "akciemi", jejichž počet je předem neznámý. V dohodných intervalech si pak vývojáři rozdělili finance podle počtu "akcíí" na daném projektu.

- Jak bude projekt distribuován?
Na webu projektu, krabicově nebo půjde o onlinovku? Zjistěte si již předem možnosti a přizpůsobte PR aktivity. Těžko budete motivovat lidi k práci na dalším free projektu, když si ten poslední stáhnou dva lidi do měsíce. Asi nejjednodušší pozici mají mobilní aplikace prodávané přes obchod, zajímavou cestou mohou být flashovky - weby platí autorům za každé zobrazení, takže vhodná motivace hráče k častým návratům může znamenat zajímavý zdroj příjmů. Volně stahované hry, pokud se neumístí v nějaké soutěži, mají poměrně trpký život.

- Jaké technologie budou použity?
2D/3D, platforma, vývojové, grafické a zvukové nástroje, engine. Máte nějaké, umíte je používat, existují tutorialy? Setkal jsem se s mnoha enginy a přestože dokáží generovat skutečně skvělé výsledky, ve většině případů (u těch zdarma) jde o neskutečně zprasky. Nedořešené vývojové nástroje, chybějící kontextová nápověda, placená podpora. Vybírejte z enginů, které mají solidní základnu uživatelů, rozsáhlou nápovědu s příklady a především komplexní a dokončené projekty.

- Jak velký bude tým?
Game designér, 2D grafik, 3D grafik, programátor, level designér, zvukař, webař, tester, PR manažer, scénárista, projekt manažer? Aktualizujte seznam a uvědomte si, že zatímco grafik bude potřeba především v úvodu a středu vývoje, level designer a tester v jeho závěru, takže se nebojte hledat lidi, kteří budou mít průběžně více úkolů. Pamatujte, že čím menší tým je, tím lépe se hlídá, udržuje vývoj v chodu a kontroluje kvalita prací jednotlivců. Dva lidé na stejné pozici neudělají dvojnásobek práce, ale mnohdy stěží to, co udělají sami v jednom. Pokud nejsou optimalizované komunikační kanály...

- Jak bude tým komunikovat?
Před lety se týmy sdružovaly v městech, případně soustředily ve školách nebo práci, v době internetu se nebojte hledat globálněji. Pokud zvládáte jazyk, hledejte klidně i v zahraničí. Kdysi se organizovaly workshopy v hospodách (a je asi zřejmé, že si málokdy málokdo něco pamatoval), dnes máme spoustu online nástrojů zdarma, které můžeme využít. Používejte hlasové služby - teamspeak nebo klidně i skype, ale dohodněte se, že budete pořizovat záznamy ze svých jednání. Všechnu komunikaci zaznamenávejte písemně - pokud jste se ústně dohodli, že bude něco tak a tak, napište a potvrďte si písemně, že to skutečně platí. K tomu je vhodné pořídit fórum - nejběžnějším je klasické phpBB, nicméně jako developerské mně osobně nepřijde příliš efektivní. Jeho výhoda však je, že můžete zřídit soukromou sekci pro každou část nebo období vývoje a následně fórum rozšířit i pro veřejné publikum. Zamyslete se, jak budete řešit TODO listy, testování, tedy popis chyb a jejich následné ladění, priority implementace jednotlivých součástí a oprav chyb, jak (a kdo) budete komunikovat s veřejností (tedy odpovídat na fóru), jestli budete uvolňovat hru pro veřejné testování a jak budete reagovat na návrhy hráčů - tedy spíše jak odhalovat kvalitní nápady, případně ty, které se setkají se širším zájmem.

- Jaký je plánovaný termín?
Vytvořte harmonogram vývoje, odhadněte vypuštění alfa a beta verzí a aktualizujte data v jeho průběhu. S postupem prací se budou data více zpřesňovat a ve svých odhadech budete stále lepší. Pokud je váš první odhad vyšší než jeden rok a jde o první větší projekt týmu, vývoj vzdejte - šance, že jej skutečně dokončíte je prakticky nulová. Myslete na 80/20 pravidlo - 80% práce zvládnete za 20% času, zbylých 20% práce za 80% času.

- Proč?
Odpovězte si na otázky proč vlastně chcete hru vyvíjet? Nevyhovují vám jiné? Chcete se vzdělávat? Chcete se zaměřit na vývoj her? Chcete zabít nudu? Chcete vytvořit hru, která vám bude šitá na míru? Odpovězte na každé podobné "proč", které vás napadne. Každou pochybnost nad započnutím nebo pokračováním vývoje si poznačte a v průběhu vývoje komentujte. Uvědomte si, že vytvoření hry "pro sebe" je prakticky nereálné. Pokud nevyužijete vysokých poměrů náhody nebo pokročilých umělých inteligencí, jako autoři budete vždy znát vnitřní herní mechanismy a tím pro vás bude hraní vždy a za každých okolností snažší než pro ostatní. I z tohoto důvodu je vhodné k testování přibírat v pokročilé fázi i externí spolupracovníky (případně přistoupit k veřejnému betatestu), jelikož nemají z vývoje žádné uplatnitelné znalosti, které by jim hraní zjednodušilo.



2) Lidé

Nejdůležitější částí projektu je bezpochyby výběr lidí týmu. Přestože může jít o frustrující zkušenost (, především pokud to děláte poprvé), berte tento vztah podobně jako zaměstnavatel / zaměstnanec v libovolné profesi. Pokud hledáte lidi, předně je seznamte s projektem (použijte zkrácený koncept z předchozího bodu) a vypište koho hledáte, jaké zkušenosti potřebujete, kolik času od něj potřebujete, jaké povinnosti bude člověk mít a co jste mu schopni nabídnout. Doplňte kontaktní údaje a především čas, kdy je možno vás zastihnout.

Naopak, pokud nabízíte spolupráci nebo reagujete na nabídku místa v týmu, uveďte svůj věk, odborné znalosti (tedy co jste již ve svém oboru dokázali - připravte si reference, zda jste obor studovali, v jakých aplikacích pracujete, jak často, jak dlouho), co děláte (práce / škola, obor), kde bydlíte (kvůli případným osobním schůzkám) a především jaké jsou vaše časové možnosti (především skrze školu - zkouškové) a v jakém horizontu.

V týmech se mnohdy setkávají lidé hned několika generací, je vhodné hned v zárodku nabídnout tykání, pokud jste staršího data výroby - když máte v týmu spolupracovat, musí jít o určité přátelské prostředí a vykání toto svým způsobem znesnadňuje. Vykání manažerovi týmu pak lze přerovnat pouze k situaci, že jste se buď zapsali do dobrovolného otroctví nebo prostě pracujete bez nároku na mzdu. (Opět, výjimky možné, ale výjimečné.)

Připravte si náborové texty a případně reakce na ně, pokud hledáte větší tým, budete se setkávat s dotazy a pokud se některé budou opakovat, zahrňte je do základních informací o projektu. Opevněte se trpělivostí, především pokud hledáte hned několik lidí, pravděpodobně absolvujete desítky zbytečných rozhovorů. Přesto byste neměli přejít do flegmatického nebo cholerického režimu - těžko do týmu seženete lidi, když se hned v úvodu vývoje psychicky zhroutíte.

Všichni členové týmu musí být připraveni přečíst neuvěřitelná množství textu - fóra, cizí nápady a názory, weby konkurence. Pokud neradi čtete a vůbec, neradi (nebo opravdu pomalu) píšete, ani se do vývoje nezapojujte. I z tohoto důvodu by se všichni členové měli naučit komunikovat efektivně - nepoužívat zbytečné (např. "jsi tu?") nebo příliš rozsáhlé otázky, vyhnout se nekonkrétním dotazům a všeobecně holým větám, případně odnaučit se zdravit, vyzvídat o přítelkyni, jak jezdí auto a vůbec řešit témata nesouvisící s projektem (stanovte si pracovní / komunikační dobu a tato témata můžete řešit jindy).

Designeři / manažeři
Na ramenou designéra / managera visí všechny problémy týmu. Většina týmů se rozpadá kvůli tomu, že designér si vlastně hraje na boha a přitom na projektu sám skoro nic neudělal. Existují samozřejmě výjimky, nicméně většina takových se podílí právě správou komunikačních kanálů a udržováním projektu v chodu. Problém však je, že tito lidé jsou samozvaní a ne vždy mají dostatečné zkušenosti - měli by mít logicky přehled (alespoň základní) ve všech oborech vývoje, především však mít sociální inteligenci a přestože by měli komentovat postup prací, nezasahovat do nich. Setkal jsem se s mnoha případy, kdy tým vedl programátor a věnoval projektu skutečně neuvěřitelný čas. Čas, který měl věnovat vedení a směrování týmu. Takže přestože svoji práci měl prakticky hotovou, zbytek týmu se plácal na začátku, komunikace vázla, projekt neměl žádný web, žádnou propagaci a vlastně zemřel. V rukou manažera týmu je budoucnost projektu a, bohužel, o dobrého manažera dnes jen tak nezakopnete, dobrým manažerem se nestanete od narození, ale pouze zkušenostmi. Dobrý manažer bude pořádat brainstormingy, ale i soukromá sezení, bude řešit sociální jiskření a taky zvládne poradit (resp. sehnat někoho kdo poradí) s problémy okolo vývoje, se kterými si tým neví rady.

Programátoři
Programátor by měl vybírat prostředí, ve kterém bude hra vznikat. To může samozřejmě probíhat v návaznosti na 3D engine, nicméně programátor by měl být ve své práci jistý. Nemůžete pracovat na projektu s enginem a prostředím, resp. lidmi, kteří s enginem a prostředím nikdy nedělali. Problém výběru programátora je především v jejich plošném nedostatku. Je jich málo v komerční sféře a o to méně v té "neplacené". Málokterý profesionál po x hodinách v práci přijde domů a s nadšením se pustí do zdlouhavé, amatérské a mnohdy špatně vedené práce na hře. Většina profesionálů se do takových projektů pouští v době, kdy mají v práci menší zátěž - aby nepočítali pavouky na stropě, věnují se projektu alespoň takto. Bohužel se však může stát, že takový programátor zase z ničeho nic z týmu vystoupí, protože se práce nakupilo. Jednou z cest jsou tak studenti a různě zájmoví programátoři, jejichž práce není většinou efektivní a ani kvalitní.

Grafici
Pravděpodobně všichni grafici, se kterými jsem se setkal byli věčně nespokojení, především se svou prací. Projevuje se to tak, že nedělají nedodělky, s každým detailem se piplou hodiny a v návaznosti na ně navázaná práce stojí. Na druhou stranu výsledek byl vždycky perfektní a většinou na něj nebylo třeba už sahat. Ve všech případech si při vývoji zpracujte náčrtky nebo drátěné modely a pracujte s nimi. Sprity, textury nebo modely lze následně nahradit finálními (ovšem myslete předem na to, aby takovou jednoduchou změnu podporoval engine). Většina grafiků, se kterými jsem se setkal byli profesionálové, kteří si prací na hře odpočinou od práce, plní dětské sny nebo prostě umělecky tvoří, na což v práci nemají prostor.

Zvukaři
V tomto ohledu nemůžu sloužit, v drtivé většině projektů jsme si vystačili se zvuky volně stažitelnými z netu a úpravami běžnými softwarovými nástroji, tedy s profesionály jsem se nesetkal.

Level designéři
Level designérem je obvykle game designér, protože sám ví, co od hry čekat, co všechno by měla umět a co všechno by se v levelech mělo objevit. U většiny her však platí, že na levelech (resp. na jejich návrhu nebo nápadech) by se mělo podílet více lidí, jelikož málokdy fantazie jednoho designéra dokáže uspokojit masu hráčů. Práce level designéra obvykle začíná až v pozdějších fázích vývoje (záleží na typu hry), nicméně již v počátcích vývoje by měly být specifikovány vlastnosti, které budou levely mít a tomu přizpůsobeno herní prostředí, engine a případně editor levelů.

Scénáristé
Podobně jako u level designu, i na scénáři může pracovat více lidí, případně někteří vytvářet charaktery různých postav. Bolestí většiny amatérských her je právě sterilní prostředí. Nudný příběh, případně příběh nacpaný akcí, neustálými zvraty a wow efekty. Příběh by měl být vyprávěn dynamicky, zajímavě a především být zcela oddělený od herních mechanismů - tedy postup ve hře by neměl být závislý na detailním sledování a pochopení vyprávění (tedy pokud nejde o detektivní adventuru). Především ale slohově zajímavý a bez stylistických a gramatických chyb.

Testeři
Kvalitní profesionální testeři mají práce až nad hlavu, nicméně testerem se může stát vlastně kdokoliv se smyslem pro detail a není flegmatik. Smyslem testerů je dokumentovat chyby a případně popisovat způsob, jak jich docílit. Vzhledem k tomu, že většina chyb je, a to především v amatérských podmínkách, špatně trasovatelná, nicméně velmi dobře replikovatelná, doporučuji při testování používat nějaký nahrávací nástroj. V okamžiku, kdy dojde k problémům, můžete jednoduše sáhnout po záznamu a krok za krokem zjistit, co tester před vznikem události dělal.



3) Tvorba

Na samotné započnutí výroby byste měli mít kompletní tým a rozdělené role. Měly by být připraveny všechny nástroje, především pro vzájemnou komunikaci a výměnu dat - v tomto ohledu rozhodně neprohloupíte použitím SVN, a to pro kompletně všechna data okolo hry (včetně artworků a všech dokumentů).

Organizujte týdenní skupinové diskuse - řešte jak je na tom projekt, jak si jednotlivci stojí proti harmonogramu, s čím potřebují pomoci a co je naopak v pořádku. Pořizujte záznam, nebo alespoň zápisy z těchto schůzek a ukládejte je na společné fórum nebo i mezi soubory na SVN.

Samotnou výrobu hry lze rozdělit do tří časových úseků, nicméně toto dělení se používá především u profesionálních her, kde efektivně funguje řízení projektů.

- Preprodukce
Během této fáze by měly by být zajištěny všechny potřebné zdroje, tedy především vývojové nástroje, herní engine a podobně. Většina her však využívá herní engine vlastní, případně upravuje veřejně dostupný, tedy ten by měl v této fázi vzniknout. Vyvrcholením tohoto období je vydání prealpha verze, která umožňuje spuštění enginu a testování základních možností hry. Tato verze nebude obsahovat hratelné levely, stoprocentně kompletní grafiku a prakticky ani ozvučení.

- Produkce
Během druhé fáze by mělo dojít k ohýbání enginu na potřeby tvorby levelů, odstraňování jeho chyb a doplňování grafických a zvukových součástí. Engine by již měl v téměř nezměněné podobně zvládnout nadesignovat většinu vymyšlených levelů a alpha verze, jejíž vydání by měla toto období korunovat, by měla obsahovat již zcela nadesignovanou scénu, level nebo případně jejich části tak, aby byla bez problémů hratelná. Tato verze může mnohdy sloužit jako hratelné demo. I to by však mělo projít patřičným laděním.

- Postprodukce
Během závěrečné fáze vývoje se dodávají kvalitní a upravené modely a textury, doplňují všechny složky příběhu a kompletují levely. Zhruba v polovině tohoto období je publikována betaverze, která by měla být vlastně finální neodladěnou hrou - tedy takovou verzí, která je od všech členů týmů označena z jejich strany jako kompletní. V drtivé většině případů však dojde k tomu, že, přestože všechno fungovalo samostatně a izolovaně od ostatního, jako celek se vše hroutí. Smyslem betaverze není zkouška nervů testerů, ale především odhalování problémů a jejich ladění. Hra by měla být především během této doby opakovaně hrána a dohrána. Finální verze i tak s nejvyšší pravděpodobností bude obsahovat klidně i desítky bugů, které je třeba opravit. Přestože je vývoj ukončen, je třeba myslet na možný vznik problémů (například při použití zatím neexistujícího OS) a určit, jak bude vývoj po vydání plné verze pokračovat.




Závěr

Většina týmů dělá tu chybu, že začne nějak pracovat, s nějak rozdělenými rolemi a čekají, že to nějak dopadne. Ano, vznikly hry, které vzešly z takových základů, ale neskutečné násobky jich díky tomu zanikly, takže doporučuji, přestože chcete tvořit amatérskou hru, postavit se k tomu profesionálně. Jeden můj přednášející kdysi řekl, že žádná dobrá komplexní aplikace nevznikla výhradně tak, že by si programátoři sedli a měsíce pracovali nad UML modelem, stejně tak dobrá hra nemusí vzniknout jedině tak, že se budete držet nějakých návodů nebo doporučení, berte tedy i tento návod jako inspirující.

Přestože jsem se setkal s doslova desítkami projektů, rád bych uvedl tři starší příklady, z nichž můžete čerpat zkušenosti:

- logická plošinová hra, remake na PC z jiné platformy
Hra vznikla v tříčlenném týmu během několika měsíců, z původní hry byl přebrán koncept a základní set levelů (rozšířený o desítky vlastních), přidány vlastní artworky, kvalitnější (vlastní) grafika, vlastní hudba a ozvučení z volně dostupných zdrojů. Hra ve výsledku graficky kvalitnější, obsáhlejší a uživatelsky přívětivější než originál. Po dokončení byl však ze strany autorů původní hry vysloven nesouhlas s vydáním hry i jako freeware, jelikož z jejich pohledu kazí dobré jméno originálu. Poučení z příkladu je doufám evidentní - VŽDY si zjistěte licenční omezení, pokud využíváte jakékoliv cizí zdroje.

- logická adventure plošinová hra, realizace uměleckého nápadu
Umělecky zaměřený autor cítil nutkání se realizovat v herním průmyslu a chtěl vytvořit hru, ve které by zvládl prezentovat veškeré své schopnosti. Během několika měsíců vznikl hudební doprovod, zvukové efekty, desítky obrázků, intro, outro a několik cutscén, animace postav, papírové skicy více než dvou set úrovní a vtipný příběh. Bohužel autor neměl žádné programátorské zkušenosti a i ty manažerské se ukázaly jako zcela nedostačující. Přestože na hře odvedl skvělou práci a mohlo jít o velmi zajímavý umělecký kousek, nikdy nebyl ke hře napsán ani řádek kódu. Tedy zcela zjevně - VŽDY si zajistěte nejnutnější části týmu.

- top down střílečka, tuctová kopie
Poznal jsem člověka, který zvládl přes 200 hodin modelovat helikoptéru. Výsledek byl neuvěřitelný a až bych doufal, že teď se podobnými pracemi zabývá někde v hollywoodu. Nicméně, když skončil, přišlo mu líto ten model odložit do šuplíku, takže dal dohromady tým a během několika tvrdých týdnů vytvořili klasickou střílečku s pár bonusy, bossy a upgrady. Hlavní roli hrál jeho vrtulník - který byl na obrazovce asi 30 pixelů široků. Původní model se objevil v úvodní obrazovce jako artwork, ale nemyslím, že mu někdy někdo věnoval pozornost. Hra jako celek propadla, jednoduše nenabídla nic nového, originálního, šlo prostě o jeden z titulů dohraj a smaž. Jak už jsem psal v úvodu - jeden nápad hru nedělá.

Závěrem závěru

Tento text vznikl 15.4.2011 a přestože mě napadá dalších spousta věcí, které bych rád řekl nebo zmínil, šlo by většinou pouze o popis ojedinělých situací nebo mlácení prázdné slámy. Nemyslím tedy, že bych tento text dále rozšiřoval, nicméně pokud máte nějaké nápady k zakomponování, diskuze je otevřená. Nebráním se kopírování částí tohoto textu, nicméně, přestože nejsem zastáncem centralizovaných řešení, uvedení odkazu na toto forum může prospět pouze nám všem.

[frca]

[Paranoik]

[VladR]

Bohuzial, historia dennodenne dokazuje (asi vo vsetkych sferach zivota), ze skusenosti su medzi jedincami spolocnosti neprenosne


Vsetci sme si museli nabit pysky, ked sme sa ucili chodit jak lezuni a takisto kazdy developer sa musi parkrat oplieskat o stenu.


Pokial by si chcel, aby to poucenie si zobrali ostatni, musis to spisat do putavej a zabavnej formy - teda z vyssieho odstavcu vznikne kratsia kniha, lebo clovek si na zaklade jednoduchych prikladov skor vytvori asociacie (na dane situacie), ako na zaklade sucheho (aj ked pravdiveho) textu.

Nemal som teraz cas precitat tvoj prvy prispevok, len som ho zbezne preletel, takze sa k tomu zatial nevyjadrujem.

[aimia]

Paranoik: Výborný článek, spousta nápadů na zamyšlení. Takže díky

PS: Spolupracuješ ještě stále na vývoji free titulů, nebo jsi článek pojal jako zakončení "kariéry" a shrnutí zkušeností?

[Paranoik]

[nonder]

Musím poďakovať za super článok. Bohužiaľ pre mňa som ho prečítal až v tomto období a väčšinu vecí čo popisuješ som zažil aj ja. Utvoril som si zo skúseností 2 pravidlá ktoré sú možno pre niektorých aj provokačné:

"Nikdy nechoď do tímu ktorý zakladá level designer."

"Čo môžeš spraviť sám, nenechávaj na druhých."

K tomu prvému poviem len toľko, že väčšinou som sa stretol s ľudmi ktorý šli zakladať tím po tom ako si prečítali pár návodov, pohrali sa s editormi (pracujem v engine-och) a následne sa pomenovali ako "level designer" bez toho aby vedeli prečítať čo i len jeden riadok kódu (myslím, že aspoň drobné základy kódu je treba vedieť) alebo chápali nejaké jednoduché princípy, no proste nemali ani z ďaleka potrebné skúsenosti na to aby sa mohol vôbec nejaký vývoj začať. Nechýba u nich ani neustále prehováranie a na otázky k vývoju sú väčšinou odpovede: "to už nejako urobíme". Bohužiaľ hra sa nedá robiť cez copy&paste desiatich návodov z internetu ako si to niektorí začiatočníci myslia.

Druhým pravidlom sa riadim v poslednej dobe pretože stávalo sa, že keď som nechal niečo na iného tak sa práca len predĺžila alebo na tom nepracoval. Občas z neho po čase aj vyšlo, že vôbec nevie ako na to. Samozrejme sa jednalo o vec ktorú by som si sám hravo spravil.

Zostal som už k tímom trochu skeptický a najmä si dávam veľký pozor na to s kým do toho idem. Ale je možné, že niekomu sa to podarí aj s prvým tímom. Toto sú len moje skúsenosti.
_________________
S pozdravom NoNder.

[Paranoik]

Naprosto sedí s tím, proč tento článek vznikl. Většina začátečníků to vidí tak, že programuje každej druhej, tak to nemůže být tak těžký a nějak se to udělá. A taky se téměř vždy zapomíná na 80:20 pravidlo. Těch 80% práce jde hezky od ruky, odsýpá, ale jakmile se jde do finále, je potřeba debugovat a opakovaně testovat, vytvářet gui, validátory, už to prostě není ono.

Doufám, že jmenovaným nebude vadit: setkal jsem se tu s managerem menšího týmu (hádám tří lidí) 3D RPG, sám 3D grafik, já se přimotal jako scénárista (nejspíš mu došly nápady). Programátorovi zadal úkol typu: potřebujeme vytvořit 3D engine jako má fallout 3. Co jsem z projektu viděl byl nadesignovaný kostel ve 3D a náčrtek mapy na papíře asi s pěti lokacemi. Na tomto projektu bylo špatně snad úplně všechno, co špatně být mohlo.

Vážně, manager nemusí být čistokrevný programátor (ba naopak mám zkušenost, že programátoři jsou pro managerskou činnost příliš "asociální"), ale MUSÍ do programování vidět.

Troufám si odhadnout, že 90% týmů se rozpadne dřív, než vytvoří vůbec cokoliv, co by od nich mohl přebrat někdo další. A kolikrát je to škoda.

Celkem by mě zajímalo jak je to s těmito pravděpodobnostmi na základě věku členů týmu. Nikdy jsem si tyto statistiky nevytvářel, ale nejspíš začnu. Po paměti se mi zdá, že čím mladší, tím větší problémy s odhadem svých schopností členové mají, a tím rychleji se tým zase rozpadá.

Nicméně takové problémy lze čekat od kohokoliv a i pro free projekt je vhodné si lidi vybírat. Před nějakou dobou jsem hledal databázového vývojáře a ozval se absolvent oboru "se zaměřením na databáze", který ovšem nezvládl dát dohromady jednoduchý vnořený dotaz. Zarážející nebylo ani tak, že to nezvládl, ale že celou dobu prohlašoval, že něco takovýho vůbec není možný, že on na to má školu a všichni jsme neschopní, když po něm něco takovýho vůbec chceme.

[P1trs]

Díky za článek.
A ještě bych měl dotaz. Když dělám na hře, vemu do týmu např. grafika, ten mi udělá pár modelů aj. Potom se rozhodne skončit nebo se nepohodnome. Musím poté všechny jeho modely nahradit, aby mi třeba v budoucnu nedělal nějaké problémy? Nebo se dělá nějaká smlouva předem?

[Paranoik]

[japaja]

a preto sa ucim c++ neskor pjdem na c# a modely a animacie,fyzika s nimi pracujem uz 2 roky a nikoho mi netreba k tomu
_________________
skype: dead.lol1

[Paranoik]