Skip navigation

Monthly Archives: Wrzesień 2010

Ktoś chciał bym opisał skróty jakie używane są przy produkcji gier, generalnie nie jest powiedziane, że skróty, które ja tutaj podam są wykorzystywane wszędzie – tyle ile jest firm, tyle różnych skrótów się robi, no, ale może komuś się to jednak przyda. Nie będę pisał regułek, tylko postaram się wytłumaczyć co dany skrót znaczy, pewnie będzie to brzmiało jak tłumaczenie dziecka, ale tak każdy przynajmniej zrozumie.

IP
Regułkę możecie sobie znaleźć na google. Generalnie IP oznacza prawa do pewnego szeregu rzeczy. Przykład: stworzyłeś grę, która traktuje o Bobrze, którego przygoda rozgrywa się w świecie Coś. Posiadasz do wytworzonych pomysłów prawa autorskie, jeśli je zabezpieczysz (zarejestrujesz) posiadasz IP (czyli zebrane prawa majątkowe/autorskie) do danego produktu. IP możesz komuś udostępnić. Przykłady IP: Fallout (postacie, świat, fabuła i wszystko to co zostało stworzone w tej grze), Baldur’s Gate, Dungeone Keeper, Snickers, Mars, Zupka Chińska Wifon. Nawet jak nie zarejestrujesz swoich praw a zauważysz, że ktoś skoipował sobie Twojego Bobra w świecie Coś możesz go podać do sądu o plagiat i złamanie ogólno dostępnych zasad praw majątkowych.

Licensor / Licensor Holder / LH
Może być to firma/osoba, która posiada IP do jakiegoś produktu. Przykład: TVN mający prawa do serialu Niania. Mogą udostępnić Ci Licencję na stworzenie gry Niania, taka osoba w gamedev najczęściej nazywana jest Licensorem/Licensorholderem/LH

AP
Ap = Action Points. Generalnie możesz się spotkać z sytuacją gdzie developer mówi Ci: „This will be AP for you”, oznacza to po prostu zadanie dla Ciebie, które wykonane ma być ASAP.

ASAP
Wykonaj coś jak najszybciej – najczęściej chyba używany skrót w tej branży i nie tylko 😉

GD
Game Dev, czyli branża twórców gier.

RFP
Dokument z propozycją projektu, na którego bazie tworzy się plan i budżet.

RC
Reference Candidate albo Release Candidate – jest to nazwa jednego z ostatnich milestone’ów w produkcji gier.

Milestone
Zawsze nie umiem powiedzieć co to jest po polsku 🙂 klucz milowy? milowy klucz? pare dni zapierdol? Chyba po prostu oznacza to Kamień Milowy w produkcji gier. Przykładowo developer zakłada sobie, że za 3 miesiące chce mieć pierwszą grywalną wersje z takimi i takimi feature’ami – to jest klucz milowy dla nich.

Feature
Czyli jedna z możliwości gry. Przykład: zajebiste cząsteczki, kamera FPP, rzut izometryczny, zaawansowane AI

FPP
Widok kamery z pierwszej osoby.

AI
Sztuczna inteligecja

Lockit
Dokument w którym są spisane wszystkie teksty gotowe do lokalizacji.

Lotcheck
Robiąc gry na różne platformy, niektóre firmy muszą sprawdzić grę zanim będzie można ją wydać. Apple, Microsoft, Nintendo, Sony – moment sprawdzania naszej gry przez providerów konsoli nazywany jest lotcheckiem.

PO
Po prostu umowa, bądź dokument stwierdzający prawidłowe wykonanie zlecenia.

CR

Code review, czyli analiza kodu gry i spisanie wszystkich uwag/rzeczy do poprawy.

QA
Etap w którym zaczyna się gruntowne testowanie naszej gry.

PM
Postmortem – czyli spotkanie/dokument/powiedzenie co w projekcie zostało zrobione dobrze, a co źle, co można by poprawić, krytykuje cały projekt.

SP
Sprint Plan – czyli plan projektu

Mockup
Koncept, nie koniecznie stworzony w kolorach przez grafika. Może być wykonany przez designera bądź jaką kolwiek inną osobę – ważne by odzwierciedlał pomysł.

Placeholder
Jest to po prostu asset, dzięki któremu programiści i inni developerzy mogą pracować dalej. Placeholderem może być tekstura, dźwięk, obiekt, tekst – przykładowo masz rozmowe z jakąś postacią, a ta postać ma czarną teksturkę i mówi do Ciebie „bla bla bla” – postać taka używa tekstu placeholderowego, tak samo jak i tekstury. Placeholery podmieniane są w finalne assety wtedy kiedy przyjdzie na to czas. Generalnie prototypowanie tworzy się z placeholderów tak by nie inwestować 5 miesięcy na tworzenie assetów. W moich projektach placeholdery tworzone są od razu, zanim jeszcze GDD zostanie skończone.

GDD
Game Design Document.

TDD
Technical design document.

Prefab
Jest to zbiór funkcji, assetów. Przykładowo załóżmy, że grafik złożył cały domek z paru elementów, a game designer oskryptował go, tak by animowały się niektóre jego części. Niektóre technologie potrafią taki szereg danych zapisać jako jeden prefab, dzięki czemu znacznie łatwiej jest zorganizować sobie scenę/level design

POF
Proof of concept. Może to być prezentacja stworzona w programie graficznym, może to być grywalne demo gry, może to być prototyp. Generalnie chodzi o to by sprawdzić czy idea jaką się wymyśliło będzie taka jak każdy się spodziewał.

EFIGS
Tłumaczenie na język Angielski, Francuski, Włoski, Niemiecki i Hiszpański – są to najbardziej popularne tłumaczenia do gier.

GMG
Get more games, w wielu grach na urządzenia mobilne można znaleźć funkcjonalność w stylu „Pobierz więcej gier”, ten skrót oznacza taką funkcjonalność.

TBYB
Try before you buy. Skrót oznacza wersje gry która jest za darmo, ale z pewnymi ograniczeniami. Try Before You Buy mówi raczej wszystko.

Dropfeatures
Może oznaczać planowanie etapu w którym okraja się grę i tworzy szereg flag by gre można było uruchomić na różnych konfiguracjach sprzętowych/urządzeniach.

LNG
Może oznaczać plik w którym są spisane wszystkie/bądź szereg tekstów.

Crunch-Time
Oznacza zapierdol dla niektórych/wszystkich członków zespołu przez to, że osoby zarządzające projektem źle zaplanowały projekt/część projektu.

Polishing
Oznacza dopracowywanie funkcjonalności/assetów gry

Tweaking
Podobnie jak Polishing, ale generalnie tutaj chodzi o mniej skomplikowane rzeczy.

Jak by ktoś gdzieś znalazł jakiś skrót – niech napiszę, będę aktualizował ten wpis. Ciężko mi jest tak z głowy wszystkie je wymienić.

Reklamy

Jaki jest idealny programista wg Producenta?

Ktoś zadał mi takie pytanie, więc postaram się z mojej perspektywy to naświetlić. Pamiętać trzeba, że moja perspektywa nie oznacza ‚tej dobrej perspektywy’, która jest mile-widziana we wszystkich firmach.

Generalnie pierw trzeba sobie odpowiedzieć na parę pytań:

– Czym zajmować się może programista w branży gier?
– Jakie obowiązki w codziennej pracy ma programista?
– Z Kim współpracuje?

Na dzień dzisiejszy specjalizacji w których programista może się wyszkolić jest masa: programista fizyki, programista AI, programista Menu, programista 2d, programista 3d, programista efektów specjalnych, programista gameplayu, programista audio, programista portowania, techniczny programista, główny programista, programista PHP…oj nie będę nawet tego wymieniał – generalnie każdy programista jest inny. Producent będzie uwielbiał tych, którzy pasują do projektu, który prowadzi.

Przykład: Gra Point&Click 2d na różne platformy na nie znanym developerowi silniku.

Na pewno będzie potrzeba głównego programisty w takim projekcie, który zaznajomi się z silnikiem. Musi znakomicie znać angielski. Będzie musiał zorganizować pracę innych programistów, więc musi mieć ogromne doświadczenie tak by jego Code Review i organizacja pracy pomagała a nie przeszkadzała. Na pewno ktoś będzie musiał stworzyć podwaliny wyświetlania grafik – więc programistę 2d potrzeba, nie musi znać angielskiego, nie musi mieć dużego doświadczenia. W takim projekcie trzeba pewnie będzie zaprojektować konkretny system skryptowy, poprzez który gameplay będzie obsługiwany na wszystkich platformach więc wszyscy programiści powinni mieć doświadczenie z portowaniem i wiedzieli z czym to się je. Do takiego projektu na pewno potrzebny będzie gemeplay programmer, z dobrym angielskim i doświadczeniu w takich projektach na różne platformy. Dodatkowo można wrzucić osobę zajmującą się tylko skryptami, od której dużo wymagać się nie będzie.

Jak widać nie potrzebny jest ‚dream team’.
Idealny programista dla mnie to taki, który sprawdza się na swojej pozycji, ważne by miał pewne cechy:

– Musi być rozmowny. Nie może się bać podejść i powiedzieć: „To chyba będzie głupi pomysł”, „Nie dam rady tego zrobić”, „Nie zrobię tego w takim czasie”. Dla mnie ważny jest feedback od programisty, tak bym mógł dokładnie i bez crunch-time’u zaplanować jego pracę.
– Powinien znać angielski na poziomie w którym jest w stanie rozmawiać z Kimś po angielsku. Musi umieć wytłumaczyć dlaczego coś jest trudne do zaimplementowania i dlaczego tyle czasu na to potrzeba
– Nie powinien być zamknięty w sobie, często powinien latać, pytać. Uwielbiam gdy programiści współpracują między sobą/producentem/designerem/klientem. Nie może być sytuacji gdzie stawiam 5 programistów w jednym pokoju, a oni po prostu ze sobą nie rozmawiają.
– Idealny programista na pewno potrafić będzie dokładnie zaplanować swoje zadania. W każdym projekcie prędzej czy później mogą pojawić się pytania: „Ile czasu Ci to zajmie”, „Rozpisz mi zadania jakie widzisz dla programisty w tym projekcie”. Raczej nie planuje wszystkiego sam, tylko zbieram jak najwięcej informacji od osób które bezpośrednio mają pracować przy projekcie. To w sumie kwestia doświadczenia. Nie lubię jak programista mówi mi, że coś mu zajmie 2 dni, a siedzi nad tym 2 tygodnie. Programista powinien wiedzieć z czym jakie zadanie jest związane.
– Powinien być znakomity w swojej dziedzinie i nie być ograniczony. Przykład: programista fizyki jest w stanie ogarnąć AI. Mieszane zadania czasami się zdarzają i fajnie mieć programistę, który jest wszechstronny. Kwestia doświadczenia i samego talentu.
– Nie powinien zmywać testerów z kwitkiem. Nie lubię jak programista mówi testerowi „sorry nie zrobię tego”, wole jak programista wytłumaczy testerowi DOKŁADNIE w czym jest problem i powie mu dlaczego tak a nie inaczej jest to zrobione. Testerzy to nie są debile, można im sporo wytłumaczyć i już nie będą raportować błędów które są z dupy. Programista który pogada z testerem zamiast go spławić jest bliżej idealności dla mnie. To samo tyczy się designerów. Programista, który mówi designerowi „nie zrobię tego” też jest do dupy. W produkcji chodzi o to by wszyscy rozumieli jakie są ograniczenia (tym bardziej designer, który kreuje całą grę) by się ich trzymać. Programista musi takie rzeczy umieć wytłumaczyć
– Idealny programista musi mieć chęć rozwoju, a jego praca musi dawać mu ogromną radość.
– Idealny programista musi umieć wytłumaczyć innym co jak jest zrobione. Przykład: grafik techniczny skalujący grafiki do innej rozdzielczości, musi wiedzieć jak ma to zrobić, czy użyć alphy, jakie odstępy pomiędzy animacjami, co z koordynatami, jaki format.
– Na pewno musi komentować swój kod, nie musi nikt mu o tym przypominać
– Potrafi pracować pod presją. Presja = wydawca właśnie robi review bety, prosi o pare poprawek i mowi, ze w ciagu 30 minut musi zamknąć review. Programista ma 25 minut na tweaki tak by mieć approve Bety dzień wcześniej. Zdarzają się takie sytuacje, które uzależnione są od różnych rzeczy – choroba CEO, bądź producenta od strony wydawcy. Programista który szybko połapie się w kodzie i będzie w stanie poprzestawiać parametry pod wpływem presji = idealny.
– Programista nie powinien narzekać, tylko profesjonalnie podchodzić do swojej pracy, a narzekać tylko wtedy gdy producent spyta się go „co Ci się nie podoba”
– Programista powinien być kreatywny nie tylko w kodzie ale i w designie. Zdarza się ze programista coś implementuje – i nawet nie zajrzy co zrobił. Programista który gra w to co zaimplementował i poprawia swoje błędy (widzi je), jest idealny. Programiści którzy potrafią stwierdzić czy coś jest fun czy nie – są idealni. Zanim tester dostanie gre do reki większość błędów jest już wyłapana przez programistę
– Lubie jak programista potrafi się postawić. Jak daje mu termin 2 tygodnie, on potrafi powiedzieć sorry ale zrobię to w 3 – nie będę siedział po godzinach. Dzięki temu wiem, ze mogę na niego liczyć przez te 3 tygodnie.
– Generalnie powinien być komunikatywny (może się powtarzam)
– Powinien być miły i z pasją podchodzić do każdego swojego zadania 🙂
– Idealny programista zna się troszkę na tworzeniu grafiki 2d/3d – zna zasady, nie wymaga nie wiadomo czego od grafika
– Idealny programista zna wszelkiego rodzaju podstawowe technologiczne aspekty wielu rzeczy (:D) przykład: nitro, XNA, fizyka, xcode, iphone, mobile, psp, pc, ps3, psn, gc, etc etc spytany na przykład o to jaką rozdzielczość ma PSP od razu to wie.
– Idealny programista zna wszystkie podstawowe języki programowania (C, C++, Java, C# – dla mnie) i jest w stanie nauczyć się szybko innego języka na tyle by móc skończyć swoje zadanie.

Jest jeszcze masa pomniejszych rzeczy o których raczej nie chcę pisać bo bym już przeciągał. Generalnie idealni programiści nie istnieją, programistów trzeba odpowiednio dobierać do projektu tak by zachować harmonię 😉 Producent może programiście w tym wszystkim oczywiście pomóc.

No to kolejny projekt skończony. Fajnie było pracować z licensorem tak popularnego serialu jakim jest NCIS. Generalnie projekt był spory, wszystkie platformy mobilne zostały osiągnięte. Jakoś bardzo nie będę się rozwodził, jak ktoś jest fanem serialu NCIS może sobie ściągnąć grę z appstore’a, inne wersje będą dostępne za jakiś czas. Generalnie parę uwag, z których można coś wyciągnąć:

– Jak wiesz, że będziesz pracował z licensorem miej to na uwadze dodając odpowiednie terminy w sprint planie. Pamiętaj o tym, że licensor pomimo wydawcy będzie musiał zaakceptować szereg rzeczy, więc dostosować trzeba plan tak by nie było z tym problemów. Niby nic konkretnego, ale w tym projekcie programiści pracowali na draftach (coś ala placeholder, ale nie do końca), licensor parę razy robił review, uwagi były dostarczane na bierząco. Plan był bardziej ‚pod licensora’ niż pod produkcję, ale jakoś ładnie to zadziałało 🙂
– Robiąc grę dla licensora dowiedz się czego dokładnie on wymaga, możliwe, że będzie chciał mieć wpływ na teksty czy inne aspekty gry – ważne by tym się zajął ASAP, bo różnie z tym bywa…
– To co było zajebiście dobre w tym projekcie to to, że był multum spotkan z całym zespołem, wymienianie się uwagami, oglądanie serialu etc etc – dzięki czemu fani gry tak dobrze teraz oceniają grę (5/5 na app store i 48miejsce w USA). Oczywiście Ci, którzy fanami nie są – będą zawiedzieni, ale dzięki temu, że znaliśmy dokładnie założenia od licensora byliśmy w stanie zajebiscie dopracować tą grę.

– Zostawienie producentowi wolnej reki totalnie przez Szefostwo i pomoc Szefostwa w review, organizacji, problemach = masakrycznie poprawia cały etap produkcji i jakość finalnego produktu.
Sama produkcja (chujowo mi to mówić) akurat przeszła idealnie pod każdym względem, jeszcze żaden projekt nie przeszedł tak gładko i zgodnie z planem. Morale, crunch time (którego nie było), spotkania, kreatywna praca – oby takich projektów było więcej dla wszystkich developerów.

Tak naprawdę ani my, ani wydawca, ani licensor nie jesteśmy w stanie powiedzieć ‚co poszło źle’ i co można by usprawnić, więc w sumie nic konkretnego Wam nie napiszę…

Generalnie w toku jest parę zajebistych tytułów, o których dopiero będę mógł napisać jak będą dostępne dla graczy…Mam już nowego lapka więc można spodziewać się większej ilości wpisów.