Skip navigation

Category Archives: Uncategorized

Miałem nic nie pisać przed tym aż skończę arta, ale warto dać Wam update.

Na arta jeszcze poczekacie, to co pierw muszę zrobić to skończyć grę na której opierać będzie się art + chcę tam wrzucić też prototyp innej – tak by przedstawić podejście z różnych stron. Chcę to zrobić konkretnie, musicie być cierpliwi. W pracy do tego mam sporo projektów więc czasu też nie jest za wiele.

To o czym chciałem jeszcze wspomnieć…miałem wczoraj bro wieczór z weteranami gamedevu i mimo tego, że czasami czuć, że ‚zatrzymali się’ po części na tych starych czasach jest w nich coś oryginalnego. To co mnie zaciekawiło to mega pasja, mega exp i co najważniejsze: mega ludzie, bez wywyższania się bez pierdolenia jacy oni to nie są zajebiści. Rzadko kiedy takich ludzi się spotyka. To co do mnie doszło to parę podstawowych chyba rzeczy:

– crunch time. Uważasz, że masz crunch w firmie? Wiesz jak było kiedyś – zapierdalało się 2 tygodnie bez snu i robiło się to z uśmiechem na mordzie. GD to coś więcej i od tych ludzi takie podejście eksploduje. Ja osobiście jestem mega przeciwnikiem crunchu (co zresztą widać po tym blogu), ale parę rzeczy dało mi do myślenia – z innej perspektywy.
– gry coraz bardziej lecą w chuja i coraz bardziej skupiają się na debilach, którzy nie potrafią myśleć. Cieszę się, że są jeszcze ludzie (którzy mogą coś zrobić i mają miliard kontaktów), którzy popierają moje zdanie i liczą na to, że prędzej czy później zatoczymy koło.
– pasja. Mi się wydawało, że ja mam pasje, ale moja pasja jest niczym w porównaniu do tej bomby pasji jaką oni mają. MASAKRA, tyle Wam powiem. Długa droga przed nami wszystkimi i cieszy mnie to, że jeszcze tyle rzeczy jest do rozkminienia/obadania.
– nie narzekają. Nie wiem, może dlatego, że po prostu nie są polakami, ale ani razu nie narzekali. Może praca daje im większą satysfakcje niż nam? Tak naprawdę to nie wiem, ale bardzo mi się to podoba.

Generalnie dla Was to może być wiedzie „co mnie obchodzi ze sobie z kims na piwie andrzej byl”, ale z drugiej strony czuje sie mega respekta do ludzi ktorzy zaczynali ta cala branze w ktorej teraz my mozemy pracowac i zycze wszystkim by mieli mozliwosc porozmawiac z kims takim – mega duzo to daje.

Reklamy

W związku z tym, że sporo osób pyta o arta parę suchych informacji na jego temat.

– Gra stworzona przy pomocy UDK (bez kismeta),
– Gra na iOS z myślą o dalszym rozwoju na PC/PSN/XBLA/NGP,
– Gra stworzona od początku do samego końca – wydania. Art będzie opisywał wszystkie etapy, od kreowania pomysłu po szukanie wydawcy i samo wydanie gry,

Generalnie po arcie spodziewać się możesz:

– Jak zacząć produkcje gry,
– Jak zorganizować produkcje gry,
– Jak szukać pomysłu na grę,
– Na co zwracać szczególną uwagę przy kreowaniu pomysłu,
– Jakie procesy trzeba przejść by stworzyć dobrą grę,
– Na co powinieneś uważać przy produkcji gry,
– Czy optymalizacja jest ważna,
– Jak zorganizować QA,
– Jak zorganizować produkcję assetów,
– Jak stworzyć GDD,
– Jak stworzyć TDD,
– Jak znaleźć wydawcę dla gry,
– Jak wydać grę,

Moim zdaniem art na przykładzie gry da Wam znacznie więcej niż suche dane, nie spodziewajcie się, że dostaniecie kod źródłowy i assety, art ma wymusić myślenie, jeśli myślisz, że przeczytasz arta i będziesz potrafił tworzyć gry – lepiej nie myśl. Art będzie dla ludzi, którzy chcą robić gry i wiedzą ile pracy w grę trzeba włożyć , często odwołuje do google bądź książek, gotowych rozwiązań nie znajdziesz. Duży nacisk będzie na UDK – trzeba dobrze znać technologie na której robi się grę. Mam duże nadzieje, że art wymusi w game developers wannabe myślenie i zabranie się do roboty…

Dlaczego nic nie ma nowego na blogu?

Ano dlatego, że piszę dość dużego arta, który mógłby być w sumie książką…pod niecnym tytułem „Jak zacząć i skończyć komercyjną grę 3d”.  W arcie opisuje fazy od samego początku do samego końca (wydania gry), dodatkowo w arcie dowiesz się jak taką grę zaimplementować, więc nie tylko organizacja pracy/design/processy, ale również programowanie i stworzenie takiej gry od zera do końca.  Art będzie kierowany dla początkujących ludzi jak również dla wyjadaczy, którzy chcieli by zrobić coś samemu, ale jakoś nie mają motywacji, artem pokażę, że się da. Trochę czasu jeszcze zejdzie zanim go skończę, do tego czasu nic tu nowego się nie pojawi.

Tak przy okazji dostałem parę ofert od różnych portali by pisać bloga dla nich, nie martwcie się nie będę się „komercjalizował”. Blog był jest i będzie moją piaskownicą, w której będę pisał co mi się żywnie podoba. Ktoś musi narzekać by w Polsce developerzy się obudzili.

Ile razy chcieliście jebnąć wszystkim pracując w branży.

Pewnie dużo 🙂 Ale warto się czasem zastanowić. Znajomy prosił mnie o parę zdań na ten temat.

Czyli jak przetrwać.

– Czy Twoja praca daje Ci poczucie spełniania się bądź dążenia do celu? Jeśli tak nie masz się co zastanawiać tylko robić swoje i robić to jak najlepiej.

– Ile razy dostałeś zjebe od przełożonych? Pewnie dużo, ale warto zastanowić się do czego projekt dąży. Prawdopodobnie chcecie zrobić dobrą grę, dobra gra wymaga zmian/usprawnień/dodatkowych zadań, które wychodzą po drodze. Nie pierdol gdy po raz 10 ktoś do Ciebie przychodzi i wymaga zmian, tylko staraj się je robić jak najlepiej. Postaraj następnym razem lepiej porozumieć się z przełożonym, tak by unikać wielu poprawek. Ten sam cel pracownika i przełożonego = będziesz zadowolony z pracy. Jak masz z tym problem to nie narzekaj tylko porozmawiaj ze swoim przełożonym.

– Ile razy nie udało Ci się zrobić czegoś na czas? Crunch to jest temat o którym pisałem wiele razy. Zastanów się, może crunch spowodowany jest tym, że firma potrzebuje Twojego zaangażowania by wyjść na prostą? Oczywiście nie mówię tutaj o crunchu przez 2-3 miesiące, ale 1-2 tygodniach. Jeśli lubisz tą robotę i daje Ci ona radość w czasie crunchu masz możliwość wykazania się przed przełożonymi, co będzie miało wpływ na Twoją przyszłość. Game Dev = crunch, tego nie zmienisz. Jak Ci się to nie widzi to zrezygnuj albo zacznij się zastanawiać co możesz zmienić w pracy tak by była bardziej efektywniejsza. Porozmawiaj ze swoim przełożonym zamiast narzekać.

– Czy jest coś lepszego od Tworzenia gier? Może. Chciałbyś kosić trawniki? Chciałbyś być Policjantem? No kurwa, weź się w garść, zastanów się gdzie byłeś zanim dostałeś pracę w game dev. Nie zastanawiaj się czy było warto tylko staraj się robić swoją pracę jak najlepiej.

– Nie podobają Ci się projekty w Twojej firmie? Stary, własne projekty będziesz mógł robić jak będziesz miał własną firmę, ale czy chciałoby Ci się pitolić z wydawcami/kontraktami, cash flowem? Jak Ci się nie podoba – szukaj innej pracy, ale tym czasem: rób swoją robotę jak najlepiej potrafisz bo jest ona Twoją wizytówką w branży. Narzekaniem nic nie zdziałasz, a tylko sobie zaszkodzisz.

 

– Nie lubisz jak ktoś zrecenzował grę, która robiłeś słabo? Tyle ile ludzi tyle opinii, ale zawsze powinieneś czytać uwagi/komentarze odnośnie gier, które zrobiłeś. Twoja racja nigdy nie zawsze może oznaczać ‚tą dobrą’. Postaraj się otworzyć na komentarze innych – zamiast narzekać. Chyba chcesz się rozwijać nie?

– Ktoś Cie zjebał na forum/w pracy i powiedział, że jesteś debilem i nic nie potrafisz? Weź się ogarnij i zlej takie komentarze. Pokaż mu swoją dobrą pracą, że się po prostu myli. Game Dev polega na szlifowaniu swoich zdolności, nie od razu będziesz super guru game developerem. Nikt takim nie jest, każdy się uczy. Ważne byś chciał się uczyć.

Więc co zrobić by być lepszym?

– Skończ narzekać,
– Zabierz się za robotę,
– Rozwijaj swoje umiejętności,
– Czytaj komentarze,
– Czytaj książki o game devie – arty, zbieraj jak najwięcej informacji, które mogą Ci się rozwinąć,
– Jak masz w głowie ‚Chce jebnąć tym wszystkim’ zastanów się i frustracje skup na rozwijaniu swoich specjalizacji,
– Jak zaczynasz już sam robić coś na odpierdol. Znów zastanów się i zbierz siły na powyższe, inaczej Twoja kariera w gej devie może się szybko skończyć,

Game Dev jest dla ludzi, którzy się nie poddają, jak się opierdalasz, nic Ci się nie chce – albo się zastanów i coś z tym zrób, rozwiń się, zrób sobie rachunek sumienia, albo po prostu zrezygnuj, zanim będziesz zmuszony do rezygnacji wypowiedzeniem, a wtedy o pracę będzie Ci ciężko, a chyba nie chciałbyś pracować gdzieś gdzie nie płaci się za ciężką pracę?

Bierz na poważnie swoją pracę, pamiętaj co byś robił jak byś jej nie miał. Skup się i po prostu zapierdalaj.

 

Przy jednym z projektów mieliśmy dość konkretny problem z fizyką. Generalnie chcieliśmy osiągnąć dość skomplikowaną fizykę na J2Me, BlackBerry, Android, BREW – po długich staraniach stworzenia własnej fizyki, okazało się, że musimy skorzystać jednak z gotowego rozwiązania.

Box2d = c++ i jak się okazuje da radę go skonfigurować/skompilować pod BREW – działa, ale może się dusić,
EMINI Physics – fizyka w javie na fixed pointach, działa zajebiście pod J2ME i Androidzie. Port na BlackBerry to nie problem,

Box2d jest znacznie wolniejszy od Emini. Dla tych wszystkich, którzy szukają silnika fizycznego do swoich projektów na platformy z małym performance proponuje zewaluować sobie EMINI Physics. Jego cena też nie jest wygórowana.

Post w stylu mała reklama.

Dlaczego tak często mamy crunch time?

Postaram się odpowiedzieć na to pytanie. Pierw może powiem co myślę o Crunch Timie:
– Crunch zabija kreatywność,
– Crunch rodzi niepotrzebny stres, stres zabija kreatywność,
– Dłuższy Crunch może wypalić pracowników, przez co bardzo trudno będzie im wrócić do swojej przed crunchowej efektywności,
– Crunch niszczy morale,
– Crunch zwiększa ryzyko ‚mam wyjebane’ na wszelkie sprawy, przez co gdy kogoś prosisz o opinię, ma na temat wyjebane,
– Crunch zwiększa ilość popełnionych błędów przy produkcji, które mają ogromny wpływ na to by projekt odpowiednio szedł do przodu,
– Chyba każdy, kto przeżył długi crunch wie, że nie jest on zbyt dobry.

Jednak krótki i dobrze przeprowadzony crunch może spowodować wzrost morale i efektywności, ale ważne jest by cel jaki został obrany został maksymalnie spełniony.
To co wyżej napisałem to jest tylko i wyłącznie moja opinia i może nie być zgodna z prawdą jaką można przeczytać w książkach, bądź wypowiedziach CEO różnych firm.
Dlaczego więc mamy crunch? Rozdzielimy sobie to na 4 elementy, które mogą mieć wpływ:

1. Dający dupy team/jednostka.
– Ktoś w teamie może być niekompetentny, jeśli od jego pracy zależy praca innych istnieje ryzyko, że z czymś sobie nie poradzi i będzie musiał coś robić jeszcze raz = zwiększają się czasy trwania zadań,
– Creative Director zmieniający swoje widzi-mi-się co 180 stopni z dnia na dzień, (można tego uniknąć, jest parę sposobów)
– Programista, który ma w dupie code review i pracę innych. Może się okazać, że ficzer, który zaimplementował działa tylko w pewnych warunkach – trzeba pisać od nowa,

Generalnie w tym punkcie chodzi o kompetencje teamu/jednostek w Teamie – crunch może powstać przez brak kompetencji.

2. Proper Planning
– Producent, który nie zna się na swojej pracy i generalnie planuje crunch time,
– Producent, który nie zna się na swojej pracy, ale tak czy siak planuje crunch time bo chciałby coś widzieć szybciej,
– Producent, który generalnie nie zna się na tym co robi,

W każdej firmie jest coś takiego jak ‚planowanie’, jeśli osoba, która planuje projekt jest niekompetentna sama po prostu planuje crunch time dla innych i siebie.

3. Konkurencja
Generalnie Twoja firma nie jest sama na tym rynku, jest mega konkurencja. Aby dostać projekt trzeba czasami pokazać, że można go zrobić szybciej i taniej niż konkurencja. Ten przypadek jest chyba najczęstszy w początkujących firmach. Pro Firmy raczej liczą na jakość, a nie szybkość/koszt produkcji.
Więc jeśli masz crunch, może to być spowodowane sytuacją finansową Twojej firmy nie koniecznie niekompetencji pracowników/osoby planującej. Normalnie jest by aby stanąć na nogi trzeba się postarać.

4. CEO/Osoby na górze
Zdarza się, że osoby na górze mówią:
– nie da się tego zrobić szybciej?
– czemu to tak beznadziejnie wygląda, zamieńcie to na coś innego?
Pro CEO/Osoby na górze mówią;
– Trzeba nad tym jeszcze popracować, zastanówmy się w jaki sposób możemy zwiększyć fun/gameplay.

W tym i w tym przypadku zadania dochodzą. Ważne aby osoba planująca projekt miała to na uwadze, dlatego robi się ‚ramy czasowe’, w których tak naprawdę nie ma konkretnych tasków, a pojawiają się one gdy gra jest w review wydawcy/ceo/osób wyżej.Istnieje też ryzyko, że nawet jeśli Producent zaplanował taką ramkę, CEO/Osoby wyżej chcą zmienić tyle, że crunch się pojawi. Tutaj potrzeba mieć dobrego negocjatora, który doprowadzi do kompromisu i uchroni team przed crunchem.

Ja nie jestem zwolennikiem crunchu, ale są też sytuacje, że ktoś sam crunchuje – bo nie ma nic innego do roboty, lubi swoją pracę i ma z tego zajawkę. Najgorsze jest to, że o wypaleniu człowiek dowiaduje się dopiero jak już jest mocno wypalony i nic mu nie wychodzi. Trzeba mieć oczy otwarte by nikt nie przesadzał z crunchem. Korporacje najczęściej po prostu wymienią takich ludzi na nowych.

Reasumując jak masz crunch, może to być spowodowane:
– Twoim marnym skillem (dobry dobór pracowników może temu zaradzić),
– Marnym skillem Producenta(osoby planującej), (dobry wybór producenta może temu zaradzić)
– Sytuacją finansową i przyparciem firmy do muru,- Wydawca/CEO zmienia zdanie bez sensownie (dobry producent może temu zaradzić),
– Wydawca/CEO chce zrobić dobrej jakości grę (dobry producent może temu zaradzić),

Pozdrawiam wszystkich crunchujących i tak kurde kochamy swoją pracę nawet jeśli czasem chce się zmienić branżę na koszenie trawników pod blokiem<piwo>

Trudności związane z portowaniem – podstawy.

Jak ciekawi Cię temat warto znaleźć moją prezentacje portowania gry Artist Colony. Gra została sportowana z PC na iPhone. Tam znajdziesz więcej szczegółów. To co chciałbym wytłumaczyć to podstawy. Od razu na wstępie powiem, że nie mam doświadczenia we wszystkich platformach, to co wiem: Bada, WindowsPhone, J2me, Android, iOS, PC, PSP + PSN, Nintendo DSi. To czego mi brakuje to PS3/XBOX więc tu mogę teoretyzować.

A więc o co chodzi z tym portowaniem?
Załóżmy, że tworzysz grę na PC i używasz jakiegoś silnika, który wspiera tylko Windowsa – nie masz do niego źródeł, same binarki. Stworzyłeś fajną grę na PC. Chciałbyś ją ‚sportować’ na inne platformy. Niestety nie możesz zrobić typowego procesu portu albowiem użyłeś silnika, który wspiera tylko Windowsa, do tego silnika który ma tylko binarki. Starasz się dogadać z Twórcami by dali Ci źródła silnika – uda Ci się jakoś dogadać ale okaże się, że silnik jest tak zbudowany (DirectX np i własny system skryptów), że sportowanie go na inną platformę wymagać będzie ogromnej inwestycji. W takim wypadku lepiej jest zrobić grę od początku na inną platforme.

Pierwszy punkt, który musisz brać pod uwagę: Czy technologia, która używam daje mi możliwość łatwego sportowania na inną platformę?

Inny przykład tego typu.
Używasz Unity. Robisz na nim grę na iPhone. Portujesz grę na Mac/PC (silnik udostępnia te platformy) bez problemu. W pewnym momencie dostajesz konkretną propozycje sportowania gry na PSP – niestety już masz ‚lipę’ i musisz inwestować dodatkowe pieniądze.

Kolejny punkt: Dobrze zanalizuj swój pomysł na grę i zastanów się na jakich platformach będzie ona grywalna i fun. Jak zrobisz dobry research będziesz wiedział jakiej technologii użyć. Przyda Ci się też konsultacja z doświadczonym Technical Directorem/Programistą, bądź Producentem z expem technicznym, który będzie w stanie Ci powiedzieć czy wybierać z gotowych technologii czy tworzyć swoją. Generalnie nie zawsze technologia, która wybierzesz będzie tak zajebista jak Ci się wydaje.

Mając te podstawy na uwadze możemy przejść dalej.

Każda platforma czymś się różni, jest parę głównych rzeczy, które trzeba zanalizować:
1. Różna rozdzielczość ekranu. W docelowym projekcie zadbaj o to by nikt nie podawał hardcodowo koordynatów. Inwestycja w code review zmniejszy Twoje koszty i ilość stresu później. Każda platforma ma inne rozdzielczości więc pomysł o tym w jaki sposób implementujesz grafikę i w jaki sposób ją tworzysz. Najlepszym rozwiązaniem jest tworzenie grafiki w hi-res, nawet jak robisz grę tylko na iPhone3g. Później powiem dlaczego.

2. Różne controlsy. Każda platforma ma innego rodzaju controsly. Iphone = touch screen, Mobile = key pad + touchscreen, PC = klawa, XBOX/PSN = dżojstiki, PSN/DSi wbudowane controlsy. W fazie designu zastanów się jak Twój gameplay mógłby być sterowany na różnych platformach. W kodzie staraj się implementować metody controlsów tak, by łatwo było je podmienić na inne.

3. Performance/Pamięć. Każdy device ma inną specyfikacje techniczną. Przy designie zastanów się nad tzw. Drop Features. Do tego potrzeba już niestety doświadczenia, ale możesz wynająć kogoś kto wie jakie dane platformy mają ograniczenia i będzie w stanie powiedzieć Ci jakiego typu drop features można zaproponować do gry.

Przykład Drop Features.
Oryginalny Ficzer: Backgroundy 2d w mojej grze point and click są animowane. Animacja jest osobną warstwą nakładaną na background.
Drop Feature dla tego ficzera: Brak Animacji backgroundów, będą one statyczne (optymalizacja pamięci)
Drop Feature dla tego ficzera: Background 2d zostanie przerysowany wektorowo (optymalizacja pamięci i CPU)

Inny przykład:
Oryginalny Ficzer: W grze używamy języka skryptowego LUA do implementowania levelów
Drop Feature: zastanówmy się czy możemy użyć mniej konsumpcyjnego systemu – choćby XML – czy nasz gameplay jest aż na tyle skompikowany by używać .lua?  Lua sama w sobie waży tyle ile można wrzucić na starego mobile’a. (który de fakto jest wymagany przez wielu wydawców)

Mam nadzieję, że skumacie o co chodzi 😛

Ważne mieć w teamie osobę, która ma doświadczenie z portowaniem. Producent z doświadczeniem też będzie planował Drop Features i czas na taki process. Swoją drogą nie wiem czy słowo Drop Features jest oficjalne w gejdevie, ale parę firm go używa.

4. Support/SDK. Kolejną podstawową i ważna rzeczą jest SDK danej platformy. Przykład: nie zaczniesz implementować swojego silnika/gry nie mając SDK (Nitro) od Nintendo. To samo można powiedzieć o Sony i M$. Całe szczęście SDK do androida/bada/ios/pc/xbla możesz sobie skombinować. Będąc hardcorowcem oczywiście możesz shackować konsolkę i w domu implementować sobie swoje rzeczy 😉

5. Submission Process. Ostatnią podstawową rzeczą o której chciałbym wspomnieć to Submission Process. Wytłumaczę znów na przykładzie:

– Zrobiłeś grę na PSP. Wysyłasz ją do Sony, które przeprowadza szereg testów. (tzw. test cases) Lista test cases jest gigantyczna. Powinieneś brać ją pod uwagę.

Warto jest dogadać się z Sony/MS/Nintendo/Apple/Samsung/etcetc i zarejestrować się po to tylko by mieć dokumentacje, która pozwoli Ci konkretnie planować i przejść kolejne porty BEZ CRUNCHU. Oczywiście Sony i inne grube ryby nie daja ‚certyfikatu’ byle komu, wiec tekst w stylu „Czesc jestem developerem z Polski, nie mam hajsu na Wasze SDK, ale starczy mi na test kity, da rade sie dogadac?” nie przejdzie. Zawsze możesz pogadać z firmami, które mają już umowę z gigantami. Dróg jest wiele.

OK ale koniec tego pitolenia. Te 5 punktów to są podstawy, które musisz brać pod uwagę. Do tego dołączyć trzeba jeszcze z jakieś 200 punktów zasad, które obowiązują w każdej platformie. Ja nie mam zamiaru tego wszystkiego rozpisywać, chyba, że ktoś zainwestuje miliard na to bym napisał książkę. Przedstawię bardzo ogólnikowo jeden przykład gry, która będziemy w teori sobie portować. No to do dzieła.

BREAKOUT.
Załóżmy, że startową platformą dla tego projektu będzie iPhone3g.

1. Iphone3g
– implementujemy silnik w OGLES
– implementujemy obsluge XMLow do rozstawiania bloczkow przez designerow (tak by przyspieszyc tworzenie leveli)
– zalozmy ze mamy 40 leveli
– zalozmy ze mamy 10 rodzajow bloczkow
– zalozmy ze mamy 5 powerupow
– implementujemy core gameplay
– gra 2d
– implementujemy bardzo prosty system kolizji, nie używamy żadnego box2d czy innych podobnych – bo po co
– pilnujemy by wszystkie koordynaty nie byly wrzucane na sztywno, ale relatywnie od szerokosci/krawedzi ekranu – dzieki czemu nie bedziemy musieli np. pisac menu 5 razy na rozne platformy.
– pilnujemy by metody wykrywania toucha ekranu byly gdzies na zewnatrz tak by latwo bylo je podmienic pozniej na cos innego
– wazne aby miec spotkanie na temat proporcji grafiki na roznych rozdzielczościach
– tworzymy sobie klasy rozdzielczości (tak by proporcje sie pokrywały)
– grafiki tworzymy w hi-resie (najwyzszej klasie rozdzielczosci) a assety zapodajemy jako .psdki gdzies na repo
– techniczny grafik skaluje i dostosowuje grafike do klasy rozdzielczosci iphone’a3
– muzyke i sfxy przygotowujemy w .wave’ach, pozniej konwerujemy do potrzebnego formatu.

2. Ipad
– techniczny artysta przygotowuje grafiki w klasie rozdzielczości iPadowej, skalując odpowiednio grafike z najwyższej klasy rozdzielczości
– Programista podstawia, tester testuje

Done and ready.

3. Iphone4
– techniczny artysta przygotowuje grafiki w klasie rozdzielczości iPhone4( mozliwe ze będzie można użyć grafik z klasy iPada, zależy od typu gry i proporcji)
– programista podstawia, tester testuje

Done

4. BADA
– Ściągamy SDK i zapoznajemy się z dokumentacja/kodem
– Aktualizujemy klasy odpowiedzialne za controllsy i renderowanie – tak by pasowały do SDK
– Techniczny artysta przygotowuje grafiki w klasach rozdzielczości które obsługuję BADA (w tym momencie jest to rozdzielczość iphone4, ale coś może sie zmienic)
– Programista podstawia grafy
– Sprawdzamy gotowego builda z test case’ami od Samsunga
– Konwertujemy muze/sfxy
– pliki lokalizacyjne musza byc na nowo zaimplementowane

Done

5. Windows Mobile
– Ściągamy SDK i zapoznajemy sie z dokumentacja/kodem
– Aktualizujemy klasy odpowiedzialne za controllsy i renderowanie tak by pasowały do SDK i telefonow ktore chcemy obsluzyc
– Techniczny artysta skaluje wszystkie grafiki do klas rozdzielczości które chcemy obsługiwać (moze byc tego dużo, ale majac grafiki w hi-res nie trzeba żadnych assetow robic od nowa)
– Programista implementuje flagi na klasy rozdzielczości (rożne device’y obsluguja WindowsMobile) tak by kompilować buildy pod rozne telefony
– Sprawdzamy test case’y
– Sprawdzamy wszystkie glowne device’y i klasy rozdzielczosci
– Konwertujemy muze/sfxy
– pliki lokalizacyjne musza byc na nowo zaimplementowane

Done

6. Konkretne Mobile
– Przepisujemy cale nasze wyświetlanie/controllsy/gameplay na jave
– Techniczny grafik w miedzy czasie skaluje wszystkie pozostale klasy rozdzielczości ktore chcemy obsłużyć
– Programista podstawia grafiki i implementuje flagi na klasy rozdzielczosci – device’ow mobile moze byc z 2 tysiace
– Jesli chcemy obsluzyc stare telefony (czasami trzeba) przerabiamy nasze grafiki na wektory a programista implementuje dodatkowe funkcje do renderowania wektorow i wykrywania z nimi kolizji
– Implementujemy Drop Features i dla crappowatych device’ach wyłączamy polowe leveli, polowe rodzajow bloczkow i powerupow – tak by zmieścić sie w pamieci telefonu
– Testujemy wszystkie główne device’y (sporo telefonow musisz kupic 😛 )
– konwertujemy muze/sfxy – w nich rozniez planujemy drop features
– pliki lokalizacyjne musza byc na nowo zaimplementowane

7. PSP
– Zdobywamy SDK od Sony.
– Przepisujemy klasy odpowiedzialne za controlsy i wyświetlanie pod SDK Sony. Dopisujemy klasy do zarządzania resource’ami pod SDK. Generalnie dodajemy wszystko to co jest wymagane przez Sony – a jest tego sporo
– Zapoznajemy sie z test case’ami i implementujemy wszystkie potrzebne rzeczy
– Grafik przygotowuje brakujaca grafike (buttony, helpy jesli ich nie bylo)
– Grafik skaluje grafike pod klase rozdzielczości PSP
– Testujemy (nie wiem czy moge wiecej tutaj napisac bo w sumie Sony jest restrykcyjne jesli chodzi o NDA i moga mnie generalnie ujebać)
– konwertujemy muze/sfxy
– pliki lokalizacyjne musza byc na nowo zaimplementowane

Done

8. DS/DSi
– Zdobywamy SDK od Nintendo
– Przepisujemy klasy odpowiedzialne za wyswietlanie/controllsy pod SDK Nintendo (tu bedzie troche roboty ze wzgledu na 2 ekrany)
– Zapoznajemy sie z test case’ami i dokumentacja techniczna – dodajemy wszystko to co jest wymagane przez Nintendo
– Grafik skaluje grafiki dla klasy rozdzielczości DS/DSi
– Grafik wykonuje brakująca grafike (gorny ekran trzeba ‚czyms’ zapelnic 😉 )
– Sprawdzamy test case’y
– konwertujemy muze/sfxy (majac nadzieje ze nie bedzie trzeba używać systemu optymalizacji muzyki Nitendo do tego 😉 )
– pliki lokalizacyjne murza byc na nowo zaimplementowane

I generalnie tak to wygląda. To co można w tym przypadku konkretnie zjebac to:
– Robić grafikę TYLKO pod swoja platforme = 5x wiecej roboty pozniej przy portach, bo grafe bedzie trzeba od poczatku tworzyć
– Koordynaty implementować sztywno pod jedna rozdzielczość = 10x wiecej roboty przy portach
– Uzywac box2d do kolizji, czy innego rodzaju bibliotek zewnętrznych = więcej roboty przy niektórych portach
– Zrobić muzę i wypluć ja do .mp3 = parę razy trzeba będzie tworzyć ta sama muze
– Użyć jakiegoś języku skryptowego do ustawiania leveli (w niektórych portach bedzie trzeba gameplay przepisywać – a tak uzywajac XMLow, badz plikow .txt nie bedzie z tym problemów)
– Nie czytac test case’ow i nie implementować rzeczy które sa wymagane przez Sony i inne = parę razy gra moze Ci wrocic z submisji
– Nie testować wraz z test caseami = pare razy aplikacja moze Ci wrocic z submisji

Jak raz przejdziesz ten process masz podstawy swojego silnika na pare platform wiec kolejne porty beda szybciej i beda mniej kosztowaly = mozesz sie skupic na czyms bardziej skomplikowanym niz Breakout. To oczywiście sa OGÓLNIKI, wszystkie platformy mają swoje prawa i możliwości zjebania czegoś jest baaardzo dużo, nie licząc nawet błędów w samej produkcji.

Reasumując portowanie oznacza przygotowanie oryginalnej wersji do pracy z inną platformą. Kwestia XBOX->PS3->PC nie jest mi na tyle znana by się o tym wypowiadać, choć mniej więcej wiem jakie zasady tam panują, a praca wygląda bardzo podobnie jak w przypadku innych platform i portowania.

http://max3d.pl/forum/showthread.php?t=73558 – co sadzicie?

Ktoś się pytał ile kosztuje wyprodukowanie gry. Ciężko jest odpowiedzieć na to pytanie, zleży to od rodzaju gry, silnika jak i samego pomysłu na grę. Postaram się zrobić na-szybko sprint plan takiego projektu razem z budżetem (może komuś pomoże):

– Gra przygodowa 2d na iDevice o srednim skomplikowaniu
– Piszemy silnik od zera
– Facebook/Twitter/Game Center – generalnie social w środku

Nie jest to tak naprawdę finalny sprint plan. Sprint Plan = szczegółowe taski. Ale taki plan da rade ogarnać temat resource’ów i budżetu. Dodatkowo plan zakłada szybki i konkretny feedback prawie day-to-day.

Trochę o samym planie:
– koszt jednego tygodnia = koszt 5 dni pracy danej osoby. Koszty są wzięte z mojej głowy (troszkę to uśredniłem, ale w firmach różnie bywa) więc sami musicie to sobie zaktualizować o to ile będziecie płacić za wykonywaną pracę. NIE SĄ TO OFICJALNE KOSZTY POWIĄZANE Z JAKĄ KOLWIEK FIRMĄ.
– Tester pomaga Designerowi, to samo robi Producent i tak naprawdę reszta teamu w wymyślaniu pomysłu.
– wszystkie tygodnie TRZEBA konkretnie rozpisać po preprodukcji jak już będzie wstępnie gotowy GDD
– GDD powinien być gotowy do Alphy
– Dynamicznie skalowana jest grafika na iPhone i iPhone4 (z grafiki hi-resowej, która skalowana jest w dół do iPada, a później jeszcze niżej)
– Do takiego planu trzeba dołączć checklistę milestone’ów (te rameczki z tekstem Alpha, Beta etc) trzeba wiedzieć co dokładnie zrobić do tego milestone’a.
– 2 tygodnie na silnik = prosty framework dla tej specyficznej gry update’owany ciągle podczas produkcji
– zrobione na szybko

Jak by ktoś chciał zobaczyć plan konkretny – proszę mi po prostu wysłać GDD, albo jakiegoś linka z youtube’a to wtedy będę mógł odwzorować plan i koszty.

Wyszło mi ponad 53 tys zł za taki projekt. Do tego trzeba dodać:
– opłata za prąd
– jest to kwota netto 😉
– opłata za sprzęt
– 100$ dla Apple’a
– rachunki za biuro
– kwotę za SFXy/Muzykę (+1,5k dla średniej wielkości projektu ze specyfikacja iphonea)

Nie chce mi się tego wszystkiego liczyć. Czy Ci się to zwróci? Bardzo mało prawdopodobne. ActionGame_SP – tutaj resource plan.

Wracam do życia. W firmie mam konkretny multitasking więc będzie zwięźle.

Właśnie przeszliśmy Alphę, to co udało się zrobić to:
– Day-by-Day rozmowy z wydawcą na temat gameplayu. Tworzenie ciśnienia i powodowanie wrażenia odpowiedzialności u wydawcy zaowocowało konkretnym feedbackiem.
– Masa testów gameplayu, z nastawieniem na; „Czy jest fun?”, „Czy rozumiesz zasady od ręki?” etc
– Masa zaimplementowanych gameplay type’ów (ciągłe prototypowanie)
– Wybraliśmy tryby, które najbardziej nam i wydawcy odpowiadały
– Przyszłościowo (nie na Alphę): Masa grafik została stworzonych, co więcej zostały one zaimplementowane w grze = wydawca sra z wrażenia = karta przetargowa na przyszłość
– Nie wykorzystaliśmy możliwości dodania czasu do projektu (jeden tydzień) ze względu na implementacje fizyki do jednego z trybów. Programista bez crunchu dał radę to zrobić = krata przetargowa na przyszłość.
– Główny designer codziennie sprawdzał grę i zgłaszał swoje uwagi. Bez mojej ingerencji. Nie mieszam się w design, daje tylko uwagi. (Imho każdy producent powinien tak robić i się nie wpierdalać gdzie nie trzeba)
– Gameplay został odpowiednio rozwinięty, tak by można było grę zacząć/skończyć, w raz z placeholderowymi wynikami

Teraz czas na Betę:
– Finalna grafika
– Muzyka/Dźwięki podpięte
– Animacje
– Gameplay spolishowany
– AI trzeba zaimplementować
– Finalne Menu 😉
– Parę mniejszych rzeczy

Będzie mniej luzu, ale to co mnie cieszy to ekipa, mając konkretną ekipę wszystko można zrobić i zdziałać – bez crunchu.