Skip navigation

Monthly Archives: Luty 2011

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>

Reklamy

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.