Role w projekcie growym

Gry bywają naprawdę duże i ilość ról w projekcie może przyprawić o zawrót głowy.

Paradoksalnie w małym projekcie każda z tych ról dalej może być obecna.

Po prostu z mniejszą liczbą osób atakuje się prostsze wyzwania, a każda z osób pełni więcej funkcji na raz.

Nawet w przypadku jednej osoby po prostu raz zakłada się kapelusz biznesmena, innym razem grafika, a innym programisty.

Część pracy można oddelegować albo kupić gotowe wyniki, ale nawet wtedy trzeba ocenić jakość tych elementów i je połączyć.

## Biznes

Ok chcesz tworzyć grę... to naprawdę sporo roboty.

Wiele osób spędzi wiele godzin projektując założenia gry, projektując planszę, pracując nad kodem, rysując grafiki, dodając audio.

**Zarządzanie zespołem** nie jest proste, trzeba zebrać odpowiednią grupę ludzi z odpowiednimi umiejętnościami.

Dać im motywację tak żeby byli w stanie projekt ukończyć.

Co zrobić jeśli członkowie teamu mają różne opinie na jakiś temat?

Zbudowanie sprawnie działającego zespołu to nie takie proste zadanie, zwłaszcza ze każdy człowiek i każdy zespół jest inny.

Jeśli projekt jest większy i chciałbyś go wydać komercyjnie trzeba też pomyśleć jak **zdobyć środki** żeby osobom pracującym przy grze zapłacić.

Niezależnie od tego czy projekt ma być komercyjny czy nie, trzeba pomyśleć o graczach.

Czy robisz grę tylko dla kilku znajomych czy dla szerokiego grona odbiorcy?

Jak gracze dowiedzą się o twojej grze? Jeśli chcesz ją sprzedawać to po ile? Czy masz budżet na **marketing**?

Co przyciągnie graczy do gry? Kto będzie stale dbał o **komunikację z graczami, prasą** itp?

Nawet najmniejszy team musi odpowiedzieć sobie na takie pytania.

[TODO: dodać linki do biznesowych artykułów; organizacja teamu, rekrutacja, budżety, marketing, sprzedaż, itp. itd.]

## Projektowanie

(Game designer, creative director)

Jak wspomniano wyżej zrobienie nawet prostej gry to sporo roboty.

Warto zacząć od dobrego pomysł co będzie się dziać w grze. Ale trzeba się nastawić na to że pomysły ewoluują w trakcie rozwoju gry. Często w nieprzewidywalny sposób. Dobry projektant gry nie tylko wpada na ciekawe pomysły, ale też musi umieć przedstawić je zespołowi, nieustannie wprowadzać poprawki i dostosowywać swoją wizję do realnych możliwości zespołu.

Mam świetny pomysł na MMORPG... ale nie mam zespołu... Ok, to co jest kluczowe w tym pomyśle? Może da się to wyrazić w jakiejś prostszej formie? Może wystarczy seria grafik, kilka prostych wyborów, dobrze napisany text i przyjemna muzyka w tle. Może nie jest to gra moich marzeń ale i tak wyszło coś fajnego z czego team jest zadowolony. Grafik narysował ładną lokację która nie pasuje do początkowej wizji... czy możemy jej użyć, czy musimy ją trochę przerobić, czy może to nie jest dobry kierunek i ta lokacja do tej gry nie trafi.

I przeniesione na ekran pomysły często działają zupełnie inaczej niż w głowie projektanta. Zaczęliśmy realizować ten świetny pomysł pomysł... ale to w ogóle nie działa. Gra jest nudna i nic się nie dzieje... Brniemy dalej czy zmieniamy kierunek?

Takie dylematy staną przed **projektantem gry**.

Żeby sprostać takim wyzwaniom projektant musi znać wile różnych istniejących gier żeby szybko ocenić które rozwiązania mają potencjał, a których kierunków trzeba unikać. Umieć zaprezentować wizję tak żeby pokierować zespołem w sensownym kierunku. Znać się na aspektach technicznych żeby nie próbować zrobić czegoś co jest zbyt trudne i spowoduje że projekt nigdy się nie skończy.

* Mtg - Mark Rosewater - doświadczenia z 20 lat projektowania karcianki

Oprócz projektanta całej wizji gry często potrzebne są też osoby do bardziej szczegółowych zadań.

**Projektant poziomów** (level designer) - to osoba która zadba o ustawienie elementów na poszczególnych poziomach tak żeby rozgrywka była ciekawa. Poustawia dostarczone przez zespół kocki tak żeby tworzyły ciekawe wyzwania zręcznościowe albo intelektualne. Dobry projektant poziomów nawet z prostych elementów zrobi fajną rozgrywkę (porównaj z: artysta poziomów)

**Projektant systemów** (system designer) - to osoba która zajmie się numerkami w grze. Poustawia prędkości przeciwników, ilość obrażeń, częstotliwość spadania klocków, itp. itd. Każda gra z rozbudowanym liczbowym systemem potrzebuje kogoś kto będzie grzebał w wielkim arkuszu liczb i dobierał je tak żeby rozgrywka była jak najprzyjemniejsza. Tu przydaje się połączenie znajomości różnych gier i zdolności analizy dużych zbiorów liczb.

## Grafika

Czym byłyby wirtualne krainy bez wspaniałych cieszących oczu grafik.

Nawet najprostsza gra tekstowa używa czcionki, ma tło i tekst jakiegoś koloru i dba o czytelne przedstawienie informacji na ekranie odpowiednio łamiąc wiersze i nie wrzucając za dużo tekstu na ekran na raz.

A duże tytuły potrafią tworzyć ogromne żyjące własnym życiem światy z masą detali, malowniczymi krajobrazami, strasznymi potworami i w pełnym 3d.

Pierwszy etap to **grafiki koncepcyjne** (concept art) podobnie jak projektanci szukają najlepszych rozwiązań mechanicznych, główny grafik musi znaleźć wiodącą koncepcję graficzną pasującą do założeń gry. Większość eksperymentów najlepiej i najszybciej zrobić na grafice 2d. Tu umiejętności ilustratorskie i znajomość narzędzi do szybkich fotomontaży, łączenie różnych elementów tak żeby znaleźć kierunek dla gry. To jeszcze nie będą grafiki których da się użyć w samej grze, ale bez nich gra będzie niespójna i często duże teamy grafików nie będą wiedziały w którą stronę podążać.

Jak znana jest wizja artystyczna gry można przejść do tworzenia zasobów (assetów) które wykorzysta silnik gry.

Największa decyzja to czy gra będzie 2 czy 3 wymiarowa.

**Graficy 2d** dostarczają obrazki zgodnie z wymaganiami technicznymi silnika. Grafiki muszą być nie tylko ładne, pasować do gry ale też spełniać szereg wymagań technicznych. Wraz z usprawnieniem technologii wymagania są mniej restrykcyjne. Kiedyś trzeba było przedstawić swoją wizje na bardzo małej siatce pikseli, ilość kolorów których mogła użyć grafika też była mocno ograniczona. Współcześnie grafika 2d może trafić z programu graficznego praktycznie wprost do silnika. Ale dalej trzeba mieć na uwadze wiele elementów specyficznych dla gry. Jaka będzie kamera w grze, jaki schemat kolorów pozwoli zachować czytelność rozgrywki, które elementy rozgrywki wymuszają na grafice pewne ograniczenia, a czasami jakiś fajny pomysł techniczny typu specyficzne oświetlenie wymaga dostosowania wszystkich zasobów graficznych.

Jeśli chodzi o **grafikę 3d** to temat jest bardziej złożony. Każdy model składa się z siatki trójkątów z których trzeba zbudować model 3d w specjalnych programach. Potem te trójkąty rysują się na ekranie za pomocą różnych materiałów / tekstur. Często wyglądających inaczej w zależności od oświetlenia. Poziom skomplikowania całego procesu sprawia ze narzędzia będą się znacząco różnić między sobą, a niby ten sam model w programie graficznym i w silniku może wyglądać zupełnie inaczej. Więc oprócz zmysłu artystycznego, obsługi dość nieintuicyjnych programów do rzeźbienia i malowania po wirtualnych trójkątach, trzeb też wykazać się znajomością specyfiki różnych silników bo model w programie graficznym i w grze może wyglądać inaczej. Jest też więcej ograniczeń technicznych bo łatwo zabić nawet mocne maszyny wrzucając zbyt wiele modeli na scenę, rysując zbyt wiele trójkątów, lub wykonując zbyt drogie obliczenie w materiale. Często graficy 3d specjalizują się w modelach, materiałach, aspektach bardziej technicznych itp

Na koniec ta grafika musi ożyć, czyli się **animować**. To kolejne pole które często wymaga mocnej specjalizacji.

W przypadku grafiki 2d animacja polega na narysowaniu wielu klatek pokazujących "film" danego ruchu. Jeśli grafika była dobrze przygotowana można przesuwać różne elementy (np nogi) niezależnie i sobie ten proces trochę przyspieszyć. Ale nie obędzie się bez ręcznego sprawdzenia każdej klatki i poprawienia kawałków które nie wyglądają dobrze. A często jednak każdą klatkę trzeba będzie ręcznie przerysować wprowadzając wiele zmian. Czasami animacja 2d jest na tyle kosztowna, że bardziej opłaca się zrobić model 3d, zaanimować, a potem tylko poprawić wynik animacji 3d albo w ogóle wstawić model 3d stylizowany na 2d.

W przypadku 3d przemieszczanie wszystkich trójkątów w każdej klatce nie jest rozsądne ani technicznie ani jeśli chodzi o ilość pracy. Dlatego w model który będzie się poruszać trzeba wstawić szkielet (**rig**, rigowanie). Taki szkielet to zestaw wirtualnych kości do których przypina się trójkąty tworzące rzeźbę. Następnie animator może przesuwać duże grupy trójkątów na raz zmieniając położenie kości. Wiele umiejętności wymaga poruszanie taką kukiełką tak żeby stworzyć iluzję danej akrobacji, nadać jej odpowiedni klimat, spełnić założenia rozgrywki, i zadbać o to żeby trójkąty na łączeniach kości zachowywały się rozsądnie, a wirtualne ścianki, które nie mają kolizji, nie przenikały się (za bardzo).

Aby osiągnąć realistyczne efekty animacji 3d często stosuje się technikę **motion capture**. Polega ona na przeniesieniu ruchu prawdziwych aktorów na wirtualne kości modelu. Podstawą techniki są kamery wideo, aktorzy z markerami przyklejonymi do ciała i oprogramowanie które przerobi "płaskie" nagrania z kilku kamer na pozycje kości w 3 wymiarach. Taka technika wymaga sporo sprzętu i powierzchni, więc mocapy robi się w specjalnych studiach mocapowych, którym zleca się wykonanie animacji do gry. Proces też jest czasochłonny ale daje lepsze wyniki niż ręczne ustawianie kości w przypadku realistycznych animacji.

Specjalnego wysiłku wymaga też animowanie twarzy. Z racji dużej ilości mięśni mimicznych i dużej roli twarzy w wyrażaniu emocji. Tylko duże projekty decydują się na takie zabiegi, mniejsze gry zwykle muszą unikać szczegółowego pokazywania twarzy.

Jako że animacji potrzeba dużo a są kosztowne gry muszą sprytnie wybierać które animacje są warte wytworzenia, a które akcje lepiej wykonać poza kadrem albo bardzo symbolicznie.

Jest też dużo elementów czysto **filmowych** jak trailery, intra, outra, filmiki pomiędzy planszami czy filmowe sekwencje w trakcie rozgrywki już w silniku i pośród elementów gry. Takie elementy wymagają umiejętności typowo filmowych. Storyboardów, reżyserii, montażu itp.itd. Nawet do prostych animacji w czasie gry warto poczytać o kadrowaniu, zarządzaniu uwagą widza i wizualnej kompozycji sceny.

A jak już mówimy o planszach to samo przygotowanie wizualne plansz do gry to kolejne zajęcie które przy większej produkcji może wymagać kolejnego etatu albo kilku. Bo jeden zespół narobi modeli ścian, drzwi świeczników, zasłon i całej reszty. A kolejny musi z tych elementów ułożyć dobrze wyglądające pokoje zamku. (**level artist**) Jest to praca wymagająca kreatywności w recyklingu modeli. Jako że będzie ich ograniczona ilość, a każda scena powinna mieć swój charakter. Nie bez znaczenia jest też oświetlenie sceny, w niektórych projektach do oświetlenia może być oddelegowana kolejna osoba z racji tego że światło w silnikach gry potrafi się zachowywać w bardzo skomplikowany sposób i trzeba sporo doświadczenia żeby osiągnąć niektóre efekty wizualne. Światło kieruje uwagą gracza więc miewa duży wpływ na rozgrywkę. A w dużym świecie będzie sporo lokacji którym trzeba nadać blasku.

Wcześniej wspominałem o projektantach poziomów, nie trudno się domyślić że artyści poziomów będą mieli dużo odczynienia z projektantami. Bo pracują często na tej samej planszy, często nawet na tym samym pliku. W różnych zespołach jest to różnie rozwiązane, jednak zwykle projektant bardziej odpowiada za rozgrywkę, a artysta za stronę wizualną i muszą się jakoś dogadać żeby oba elementy były na wysokim poziomie. Czasami artyści przejmują mają więcej funkcji projektantów, czasami projektanci muszą mieć mocniejsze umiejętności artystyczne bo odpowiadają też za stronę wizualną.

Wspomnę jeszcze o 2 specyficznych kategoriach grafiki które często wymagają specjalisty o innych umiejętnościach. Będzie to konfiguracja **silników cząstek** odpowiedzialnych za "efekty specjalne" (VFX) gry, takie jak ogień, dym, wybuchy, lasery. Ale nie tylko, efekty cząstkowe są kluczowe do np sprawienia że woda rozbryzguje się na kamieniach, albo symulacji światlików unoszących się nad polaną. Wile scen wymaga tego specyficznego talentu który znacznie różni się od pracy "zwykłego" grafika.

Jest też **interfejs użytkownika** (UI) który rządzi się swoimi prawami i nie każdy ma talent do projektowania przycisków, ramek, ikonek itp. elementów, które są niezbędne do funkcjonowania gry.

Rozmiar tej części odpowiada też typowym zapotrzebowaniu dużego zespołu. Żeby wypełnić życiem duży świat gry AAA potrzebne będzie naprawdę masa pracy grafików. Mimo wielu wysiłków w celu automatyzacji najczęstszych działań i wielu sklepów z gotowymi zasobami graficznymi i tak nie obędzie się bez można specjalistów. Bo nawet kupioną "gotową" grafikę trzeba dostosować do potrzeb projektu, a generator proceduralny odpowiednio skonfigurować i doczyścić to co wygeneruje.

## Audio

Często lekceważona część produkcji gry, która może naprawdę mocno wpłynąć na wrażenia gracza.

W części audio należy wyróżnić muzykę, efekty dźwiękowe (SFX) i nagrania głosu postaci (VO).

Dobra muzyka mocno wpływa na emocje gracza i znacząco zmienia odbiór sceny.

Efekty dźwiękowe dodają dużo życia różnym sytuacjom w grze. Zupełnie inaczej czuje się gracz, który strzelając usłyszy potężny huk, a inaczej jeśli do jego uszu dojdą jakieś dziwne uderzenia pokrywek od garnków. Dźwięki mają też znaczenie w rozgrywce będąc dodatkowym elementem informującym gracza np o zagrożeniu ze strony czyhającego wroga, albo informującym, że zszedł cooldown i umiejętność właśnie jest dostępna.

Jeśli chodzi o głos postaci kilka tytułów bardzo dużo zyskało na wprowadzeniu narratora. A gracze zwłaszcza przy większych tytułach wolą usłyszeć głos aktora niż samemu czytać paragrafy tekstu. Dla dużej części gier będzie to naprawdę sporo godzin nagrań. Czasami w kilku językach.

## Story

Poza oczywistością czyli główną osią fabuły w grze jest też naprawdę dużo tekstu, który trzeba napisać, żeby świat gry mógł żyć własnym życiem.

Wszystkie dialogi w grze, wszystkie "one linery" postaci, nazwy przedmiotów, opisy przedmiotów, ktoś musiał spisać zanim trafiły do gry.

A sama **główna historia** też wymaga specyficznych umiejętności do poprowadzenia bo gra jest interaktywna i opiera się na rozgrywce. Więc trzeba pogodzić wymogi dobrej historii z wymogami grywalnej rozgrywki. Dla różnych tytułów równowaga będzie przebiegać w innym miejscu. Ale nawet najbardziej skupione na historii tytuły nie mogą zapomnieć o tym że gracz chce jednak grać, a nie oglądać film. A nawet najbardziej skupione na rozgrywce tytuły dodadzą bardziej subtelne wyjaśnienia tego czemu postać gracz jest tam gdzie jest i robi to co robi.

Nie zapominajmy też że w trakcie produkcji część lokacji może zupełnie wylecieć z planów, a dużo postaci jest dopiero w trakcie tworzenia i nie wiadomo co z nich wyjdzie finalnie... co sprawia że stworzenie dobrej historii do gry ma trochę unikatowych wyzwań których nie doświadczy np autor książki. Specyfika gry wymaga też innej długości tekstów i scenek co stawia też ciekawe wyzwania osobom piszącym **dialogi**. Generalnie dostępnego tekstu na głównej ścieżce będzie zwykle sporo mniej więc trzeba się zastanowić jak go dobrze wykorzystać. Jednocześnie gra umożliwia tworzenie bardzo długich materiałów dodatkowych na ścieżkach pobocznych.

Tworzenie **historii świata** to element który też pojawi się w dużej części produkcji. Rozwijanie Tolkienowskich wizji z rozpisaniem historii wszystkich królów i wiosek krainy zwykle nie będzie miało specjalnego sensu. Ale jakaś spójna narracja i dodanie charakteru postaciom i lokacjom znacznie podnosi zaangażowanie gracza w świat gry.

## Testy

Wszyscy którzy trochę grali na pewno natknęli się na dużo różnych błędów w grze. Czasami coś wygląda dziwnie, czasami postać gracza gdzieś się klinuje, czasami jakaś kombinacja umiejętności albo przedmiotów zachowuje się absurdalnie, czasami gra po prostu się wyłącza pokazując błąd, a czasami popsuciu ulegnie zapis gry zmuszając gracza do rozpoczęcia rozgrywki od początku (co często oznacza zakończenie przygody z grą).

Jest też dużo elementów których sami twórcy nie są w stanie ocenić. Muszą zebrać opinie od graczy. Na ich podstawie decydują czy dany element zachowuje się zgodnie z założeniami czy wymaga mocnych poprawek. Które elementy gry są uznawane za najlepsze i trzeba je rozwijać, a które budzą irytację graczy i trzeba je poprawić albo usunąć.

Elementów z obu kategorii jest naprawdę dużo i na praktycznie każdym etapie tworzenia gry trzeba sprawnie zorganizować zbieranie wrażeń (feedback) i informacji o ewidentnych błędach w grze (bug report).

Tych informacji jest na tyle dużo że trzeba im umieć nadać priorytet, wiedzieć które problemy są akceptowalne na danym etapie tworzenia gry, a które wymagają natychmiastowego zaadresowania. Dodatkowo nawet samo poprawne spisanie błędu czy sugestii wymaga zadziwiająco dużo umiejętności, tak żeby taki zapis mógł trafić do osoby pracującej nad danym elementem w formie która umożliwi jej zrozumienie gdzie jest problem i zrobienie poprawek.
"Ta nowa broń jest do kitu" vs "Atakowanie przeciwnika ogr na 5 poziomie, z łuku reflekcyjnego na 7 na planszy las\_15 wymaga 50 trafień. Taka konfrontacja budzi duzą frustrację gracza." Nie trudno się domyślić która wersja feedbacku pomoże projektantowi poprawić balans rozgrywki.

Studio musi zadbać zarówno o **playtesty** na różnych etapach - testowanie gry na graczach i zbieranie feedbacku. Jak i sprawnie działający **dział kontroli jakości** (QA) który będzie ogrywał grę praktycznie przez cały okres tworzenia, znajdywał najdziwniejsze błędy, organizował listy błędów, przekazywał informacje do osób które mogą błąd poprawić, a na koniec potwierdzał że błąd faktycznie został poprawiony.

Ciekawym zagadnieniem jest **automatyzacja testów**. Powtarzalne nudne testy warto zlecić maszynom. Nie jest to łatwy proces i wymaga przygotowania narzędzi, ale dzięki niemu pewien zestaw testów może być wykonywany bez udziału testera np po każdej zmianie wersji gry.

Ale nawet automaty nie zastąpią kreatywności dobrego testera. A te automaty też ktoś musi konfigurować i utrzymywać. A inne rzeczy są subiektywne i maszyny ich nie wykryją, ale są bardzo istotne dla wrażeń z gry. Tak czy siak nie obędzie się bez kilku etatów w dziale kontroli jakości.

Testy ręczne generalni nie wymagają wieloletnich przygotowań, więc jest to jedna z bardziej dostępnych furtek żeby popracować w firmie gd. Praca nie jest łatwa i często nie jest wysoko wynagradzana... ale jest to jakaś opcja.

## Programowanie

Na sam koniec zespół który sprawia, że w te całe może pomysłów, arcydzieł i treści faktycznie można zagrać, a nie tylko o nim poczytać i pooglądać.

Czarni magowie zaklinający maszyny, by skonstruowane do liczenia równań zimne kawałki krzemu zaczęły symulować fantazyjne światy i budzić emocje graczy.

Jeśli chodzi o koderów można wyróżnić 2 główne grupy - programiści silnika i programiści rozgrywki. Podział nie jest bardzo sztywny, programiści silnika często też lubią zobaczyć jak ich praca wpływa na efekt końcowa. A programiści rozgrywki projektują czasem algorytmy albo dorabiaja różne niskopoziomowe kawałki kodu. Ale co do zasady mają inne zadania.

Głównym zadaniem **programistów silnika** jest stworzenie narzędzi, podstawy na której budują wszystkie inne teamy. Ponieważ jest tam naprawdę dużo roboty zwykle nei mają czasu zajmować się konkretnymi przedmiotami, przeciwnikami czy lokacjami. Ich głównym zadaniem jest budowa, mudyfikacja, utrzymanie i naprawianie błędów w fundamentach na których opierają sie wszytskie części gry.

**Programiści rozgrywki** skupiają się na rzeczach wykonanych w poszczególnych systemach. Pracują mocniej z projektantami, żeby zaproponować rozwiązania techniczne, które pomogą przenieść pomysły do działającej gry. Komponują z klocków dostarczonych przez twórców silnika różne kombinacje i zajmują się dopracowaniem szczegółowych elementów różnych zachowań.

W zależności od projektu role programistów mogą się znacząco różnić. W niektórych programista będzie też projektantem i będzie miał duży wpływ na końcową wizję rozwiązania. W innych bardziej dostarczycielem narządzi na których inni członkowie teamu będą dostarczać konkretnych przeciwników, itd. Czasami projektanci sami są w stanie oskryptować sobie różne niestandardowe zachowania, czasami będzie potrzebna pomoc programisty do obsługi każdej niestandardowej sytuacji na planszy.

To co zawsze jest prawdą to to że silnik ogranicza możliwości gry do tego co wspiera. Kluczowa jest **dobra komunikacja programistów i reszty zespołu**. Tak żeby programiści rozumieli potrzeby zespołu i gry. I ciągle szukali nowych rozwiązań idących w tym kierunku. A reszta zespołu rozumiała jakie są ograniczenia technologii i jakich elementów muszą unikać inaczej gra w ogóle nie powstanie.

O ile część zwłaszcza małych projektów można próbować robić bez programisty na gotowym silniku. Ale nawet taki projekt szybko zaczyna generować problemy techniczne. Z którymi ciężko będzie sobie poradzić bez pomocy kogoś kompetentnego.

O tyle i tak **musi być ktoś techniczny kto będzie w stanie poradzić sobie z** najdziwniejszymi **błędami** na różnych konfiguracjach i platformach. Bo jeśli te problemy nie zostaną rozwiązane gra nie będzie słabsza... nie będzie jej w cale bo nie będzie się nawet odpalać.

Dobry team techniczny jest podstawą sprawnie działającego zespołu. Przez cały okres produkcji gry rozwija narzędzia i pomaga innym członkom zespołu w rozwiązywaniu problemów technicznych. A gry mają tendencje do budowy naprawdę złożonych systemów, z olbrzymią ilością różnych kombinacji ustawień i interakcji między elementami, w krótkim czasie i z niskim priorytetem na utrzymanie. To zwykle oznacza masę różnych błędów przez cały czas produkcji gry, a często nawet po zakończeniu projektu wymagane są poprawki techniczne. Czasem nawet niemożliwe do przewidzenia w trakcie produkcji jak np nowe wersje sprzętu czy technologii które zachowują się w inny sposób niż poprzednia generacja.

Warto także zaznaczyć ze rola programistów nie zawsze jest czysto techniczna. Wiele gier i mechanik powstało w wyniku rozwinięcia koncepcji z dema technicznego, a zmiany w sprzęcie i nowe algorytmy umożliwiają budowę nowych typów gier.

Wiele dziwnych ograniczeń technicznych musi być respektowanych. Inaczej gra nie będzie działać wcale. Zwłaszcza na bardziej egzotycznych urządzeniach z mniejszą mocą obliczeniową.

Więc pomimo dużych trudności w zrozumieniu technicznego aspektu projektu (nawet sami programiści czesto nie są w stanie zrozumieć złożoności systemów które tworzą i którymi się opiekują), respekt i poważne traktowanie aspektu technicznego jest kluczowe do powodzenia projektu.

**Bez działającego kodu** **gra** będzie zbiorem pomysłów i assetów, **nie będzie grą**.