Slajdy z wykładu na konferencji WGK 2013

1. czyli jak dokumentować swoją pracę, aby
po 20 latach móc napisać o tym książkę
Maciej Miąsik, WGK 2013

2. Projekty pomniejsze:
 2013: Big 2 Bonanza
 2011: Call of Juarez: The Cartel
 2010: Jodie Drake and the World
in Peril
 2011: Wiedźmin 2: Zabójcy Królów
 2008: Wiedźmin (Edycja
Rozszerzona)
 2007: Overclocked: A History of
Violence
 1997: Wyspa 7 Skarbów
 1997: Katharsis
 1996: A.D. 2044
Projekty główne:
 2012: Neuroshima Apocalypse
 2007: Wiedźmin
 2004: Sentinel: Descendants in
Time
 2003: Mysterious Journey II:
Chameleon
 2003: Codename: Nina
 2001: Schizm: Mysterious
Journey
 1998: Reah: Face the Unknown
 1996: Fire Fight
 1994: Heartlight PC
 1994: Robbo
 1992: Electro Body (aka Electro
Man)

3. O prawdę, bo prawda jest
najciekawsza, czyli kwestie
historyczne, czyli jak to tam było.
O sentymenty, czyli powroty do gier
młodości.
O nowe możliwości, czyli nowe
edycje, remake’i oraz nowe platformy.
O dobre pomysły, które zawsze można
wykorzystać ponownie.

5. Czasem ktoś naprawdę chce napisać
książkę/artykuł o naszych grach.
Zostaniemy zaproszeni na wspominkową
konferencję.
Chcemy powspominać stare czasy.
Uczymy innych na naszych błędach.
Chcemy przypomnieć sobie dawnych
kolegów i zapomniane projekty.

6. Poczta elektroniczna jest łatwa w
archiwizacji.
Archwizujemy i backupujemy.
Dbajmy o ponadczasowe formaty (np.
mbox).
Nie kasujemy poczty, poza spamem.

7. From: "Tim Sweeney" <TIM@epicgames.com>
To: mail@xland.krakow.pl
Date: Wed, 29 Mar 1995 02:56:49 EST
Subject: Excessively Excellent!
Hi, Mark just sent me Excessive Speed a few minutes ago. This game is
*EXCELLENT*. Very impressive work, guys! This is going to be the
best-looking driving game on the PC -- it looks *much* better than
anything else I've seen.
This game is going to be a big hit!
We'll start playing through it and writing down suggestions. This
game needs a lot of fine-tuning, but it's not really very far away
from completion.
Thanks! Keep up the great work!
-Tim
---------------------------------------------------------------------
Tim Sweeney (tim@epicgames.com), Epic MegaGames, Inc. FTP:ftp.uml.edu

8. Archiwizujemy co się da:
 Dokumenty designerskie.
 Dokumenty marketingowe.
 Dokumenty biznesowe, koniecznie umowy!
 Dokumenty menedżerskie –
plany, harmonogramy.
 Dokumentacja fotograficzna.
 Inne: notatki, notatniki, koncepty, serwetki.

10. Działające wersje gry przy ważnych
milestone’ach.
Regularne snapshoty – gry jako
całości, oraz działań poszczególnych
ludzi.
Filmiki z prototypów oraz postępów
rozgrywki.
RSS czy inny zapis historii prac z
programów wspierających zarządzanie
(jeśli to możliwe).

11. Zdjęcia i filmiki:
 Z pracy w biurze i poza nim.
 Z integracji i zabawy.
 Z premier i innych powiązanych wydarzeń.

14. Gramy, by powróciły wspomnienia.
Ktoś inny poprosi o możliwość zagrania w
naszą „vintage” grę.
Będziemy chcieli pochwalić się przed
znajomymi lub rodziną (szczególnie
dziećmi).
Będziemy chcieli użyć własnej gry jako
przykładu w edukacji/prezentacji.

15. Działające wersje (buildy) gry, wolne od
zależności i dziwnych systemów, np. DRM.
Emulatory czy wirtualne maszyny.
Czasem oryginalny hardware.
Będą problemy:
 Kłopoty z emulacją i wirtualizacją –
konfiguracja, brak akceleracji.
 Nie zawsze łatwo stworzyć build bez
zależności, szczególnie w przypadku gier
online.
 Klucze i certyfikaty.

17. Nowe platformy ożywiają stare schematy
rozgrywki.
Czasem drobny facelifting to wszystko,
czego trzeba – bo reszta daje radę.
Częściej jednak musimy dokonać
większych zmian – remake, ale
zachowując sedno starej gry.
Mamy też okazję „uwolnić” grę spod
reżimu praw autorskich – prawdziwe
abandoware.

18. Kody źródłowe oraz biblioteki zależne.
Środowisko programistyczne –
edytory, kompilatory, skrypty buildujące.
Dane gry (assets), najlepiej także w
wersjach źródłowych
Często także emulacja lub wirtualna
maszyna ze starym systemem
operacyjnym.

20. Odrzucone prototypy z jednej gry mogą
przydać się w innej.
Oszczędzajmy sobie ponownego
prototypowania.
Mechanizmy rozgrywki można
recyklingować.
Historie raz opowiedziane można
opowiedzieć ponownie.

21. Trzymajmy odrzucone
prototypy, najlepiej w działającej
formie, bez zależności.
Jeśli powyższe nie jest
możliwe, przynajmniej zgrywajmy z
prototypów filmiki.

22. Archiwizować trzeba umieć!

23. Dobre systemy nazewnictwa.
Eleganckie źródła, trochę komentarzy.
Dobra struktura plików i bibliotek.
Zależności archiwizowane ze źródłami.
Skrypty buildujące (automatyzacja).
Źródła assetów, najlepiej w osobnym
eleganckim repozytorium.
Regularnie archiwizowane działające
buildy.

24. Trzymamy pełne historie – kto wie, co
może się przydać.
Systemy się zmieniają – migrujmy
repozytoria na nowe wersje.
Archiwizujmy całe serwery z
oprogramowaniem i danymi – fizycznie
lub wirtualnie.

25. Archiwizacja kompilatorów.
Archiwizacja innych narzędzi.
Archiwizacja kompletnych środowisk w
obrazach maszyn wirtualnych.

26. Backup, backup i jeszcze raz backup!
 On site.
 Off site.
 Cloud.
Backupy trzeba weryfikować – testy
odzyskiwania, testy buildowania.
Rozmnażajmy backupy i
archiwa, szczególnie przy rozstaniach.
Nośniki nie są wieczne! Odświeżanie.

27. IANAL!

28. Najlepiej zachować je dla siebie.
Trzeba wiedzieć, kto po dekadzie je
posiada (jeśli nie my).
Jeśli prawa przysługują grupie, po
rozpadzie warto kogoś umocować do
łatwiejszego dysponowania.
Unikajmy blokady przez jednostki.
Przenosimy prawa majątkowe, ale dzieła
mogą zostać u nas (sprawdzić umowę).

29. To umowa zachowania poufności, a nie
umowa wymazania pamięci.
Zadbajmy, aby umowa NDA kiedyś
wygasała (5, 10 lat).

30. Firmy upadają i w raz z nimi giną nasze
dzieła (Sprawdzić, czy to nie Beretta
istniejąca od 1526).
Zadbajmy o własne kopie, nawet jeśli to
nie będzie w100% zgodne papierami.

32. Trzeba proces dokumentowania prac i
archiwizacji efektów uwzględniać w
harmonogramach, bo zajmuje to czas.
Koniec projektu/produkcji powinien
obowiązkowo kończyć się porządną
archiwizacją z myślą o odległej
przyszłości.
Dbajmy, aby archiwa mogły przetrwać.
Nie oszczędzajmy na przestrzeni
dyskowej, nieustannie przecież tanieje.

33. Designerom
Producentom
Artystom
Koderom
Właścicielom praw autorskich

34. Dobre archiwa to kopalnia wiedzy
designerskiej, produkcyjnej, edukacyjnej i
historycznej.
Niech ta wiedza nie ginie bezpowrotnie.
Nie możemy polegać na innych w kwestii
archiwizacji naszych dzieł – to nasz
obowiązek.

36. Praktycznie abandonware.
Wciąż grane i wspominane.
W 2006 roku zaproponowałem
„uwolnienie” gier na licencji CC-BY-SA.
Miałem źródła, dane i biblioteki zależne.
Znalazłem kompilator Borland C++ 3.1.
Przekompilowałem w emulatorze DOSBox
zmieniając stosownie notę copyright.
Puściłem w świat.

37. Aktywiści projektu ScummVM wyrazili
chęć sportowania gry na ten system i
wiele platform go wspierających.
Nie było problemu ze zgodą właściciela
praw autorskich.
Nie mam źródeł. Być może ma je jedyny
programista, ale nie zgodził się ich
udostępnić.
Nie udało się ocalić projektu od
zapomnienia.

38. Niedoceniona, bo dobra, pierwsza
polska gra dla Electronic Arts.
Jest kompletny backup, danych i źródeł.
Nie udało mi się uruchomić samej gry –
konieczna wirtualizacja Windows 95.
Nie wiadomo, kto właściwie ma do gry
prawa autorskie – Epic nie ma umowy w
archiwach elektronicznych, EA ma to w
nosie, ja nie zatrzymałem kopii umowy.
„Modernizacja” tkwi w zawieszeniu.

39. Taka zabawa – wierny port gry Electro
Man w Pythonie, open source.
Wprawka programistyczna po
godzinach.
Koszmarny kod źródłowy – brak
praktycznie komentarzy, sprytne
makra, choć jest bardzo bazowa
dokumentacja.
Próba analizy kodu to prawdziwa męka –
nie starczyło mi cierpliwości.

40. Ukończona – pełna beta – ale nie
wydana gra platformowa.
Doskonały przykład edukacyjny.
Nietypowe narzędzie (3D Game Studio).
Nie uruchamia się poprawnie we
współczesnych systemach.
Wirtualizacje bez akceleracji nie dają
rady.
Nie wszystko stracone.

41. Społecznościowa gra online.
Aplikacja rozproszona – serwer i klient.
Serwer – Java, Frontend – Flash, Core –
Unity 3D.
Zależna od Facebook API.
Różne repozytoria, różne środowiska.
Nie mamy koncepcji na
archiwizację, szczególnie z
uwzględnieniem przyszłego upadku FB.

42. maciek@miasik.net
Twitter: @tosiabunio