Slajdy do wykładu wygłoszonego w ramach kursu Digital Frontier - digitalfrontier.pl

1. Wykład z kursu Digital Frontier – digitalfrontier.pl
WARSZTAT DEVELOPERA
Gdzie, co i jak

2. Co kryje się pod tym pojęciem?
Co to warsztat?

3. Warsztat to:
 Miejsce pracy.
 Niezbędne narzędzia.
 Procesy produkcyjne i sposoby pracy.
 Wiedza niezbędna do ich wykonywania.

4. Dlaczego warsztat jest ważny
Czyli o zaletach dobrego warsztatu

5. Zalety dla nas
 Wpływa na jakość naszych produktów.
 Ułatwia nam pracę.
 Obniża frustrację.
 Daje więcej satysfakcji - szybciej, lepiej, łatwiej.
 Podnosi nam samo-ocenę.
 Podnosi bezpieczeństwo.

6. Zalety dla innych
 Ułatwia współpracę z innymi.
 Czyni z nas atrakcyjniejszego partnera.
 Podnosi bezpieczeństwo współpracy z nami.
 Jest dobrą wizytówką.

7. Miejsce
Inaczej miejscówka

8. Moja hierarchia miejsc
 Gabinet domowy.
 Własne biuro.
 Mały pokój biurowy: 2-5 osób.
 Średnie pokoje: 5-10 osób.
 Open plan office (open space): od 10 do 100+.

9. Samemu czy w grupie

10. Sam (1-5 osób)
 Zalety
 Cisza, spokój, skupienie.
 Customizacja (brak lepszego słowa) wszystkiego:
światło, dźwięk, temperatura, meble, aranżacja, dekor
acja.
 Wady
 Izolacja.
 Gorsza komunikacja, „wypadnięcie z gry”.
 Brak pozytywnej rywalizacji.
 Brnięcie w ślepe zaułki.

11. W grupie (5+)
 Zalety:
 Komunikacja i wymiana doświadczeń.
 Inspiracja pracą innych.
 Pozytywna rywalizacja.
 Wady:
 Hałas, rozpraszanie, światło, temperatura.
 Konieczność dostosowania się do innych.
 Brak możliwości customizacji.
 Furniture Police.

12. Własny kącik
Niezbędne wyposażenie

13. Biurko
 Duże i szerokie, zdolne pomieścić kilka
monitorów, klawiaturę, dodatkowe wyposażenie.
 Solidny blat – nie może się uginać pod ciężarem
sprzętu i/lub developera.
 Materiał, kolor, inne zalety są drugorzędne.
 Podstawki na monitory, szuflady na klawiaturę to
kwestie indywidualnych upodobań.
 Ostatnio: regulowana wysokość pozwalająca na
pracę na stojąco.

14. Biurko

15. Coś pod biurko
 Na rzeczy prywatne:
 Dokumenty.
 Zupki instant.
 Napoje energetyczne.
 Inne rzeczy.
 Kable.
 Bałagan z biurka.

16. Fotel
 Najważniejszy mebel developera.
 Inwestycja na lata – nie warto oszczędzać.
 Zły fotel boli całe życie (oraz rzycie).
 Domagaj się dobrego fotela od pracodawcy.
 Jeśli sam się zatrudniasz, kup sobie dobry fotel –
będziesz sobie sam potem wdzięczny.
 Wygodny, regulowany, podparcie
lędźwiowe, mechanizm „synchro”.
 Bujanie i resor to nie wszystko – najgorszy fotel to
ma.

17. Fotel

18. Oświetlenie
 Kwestia osobistych preferencji:
 Słoneczne
 Żarowe/halogenowe
 Świetlówki
 Bezpośrednie
 Rozproszone
 Biura standardowe sprzyjają: świetlówkom i
bezpośredniemu oświetleniu.
 Biura własne pozwalają na lepsze rozwiązania.

19. Oświetlenie

20. Cała reszta
 Słuchawki!
 Lodówka, ekspres do kawy, czajnik.
 Miejsca spotkań.
 Miejsca wypoczynku/rekreacji.
 Catering/restauracje/bary/jedzenie na wynos.
 Klimatyzacja/wentylacja.
 Czystość i porządek.
 Tablice korkowe i suchościeralne.

21. Jak to wygląda w praktyce

22. Jak to wygląda w praktyce

23. Jak to wygląda w praktyce

24. Jak to wygląda w praktyce

25. Narzędzia
Sprzęt i oprogramowanie

26. Sprzęt
Hardware

27. Komputer
 Microsoft Windows platformą dominującą w
tworzeniu gier:
 Podstawowa platforma do tworzenia gier na inne
platformy.
 Najwięcej aplikacji i najlepsze (z wyjątkami).
 Specjalistyczne aplikacje tylko na Windows.
 Specjaliści czasem mogą próbować zaszyć się na
OS X, ale ogólna gawiedź musi się pogodzić z
Windows.

28. Komputer
 Developer powinien mieć dobry, wydajny komputer.
 Nie musi to być topowa maszyna, ale nie warto też
za bardzo oszczędzać.
 Liczy się wydajność deva, a nie jego gry (to jest
osobny temat).
 Cokolwiek, co podnosi znacząco komfort pracy jest
dobrą inwestycją: dużo RAM, dyski SSD.

29. Komputer
 Stacja robocza to nie wszystko – zespół wymaga
więcej.
 Serwery plików (NAS).
 Serwery niezbędnych usług (np. systemów kontroli
wersji).
 Szybka sieć do połączenia wszystkich nawzajem i z
serwerami.
 Internet.

30. Monitory
 Jeden to za mało. Dwa to dobrze, a trzy też nieźle.
 Wiele monitorów ułatwia pracę i podnosi jej
efektywność.
 Monitory LCD są tanie, warto zainwestować w
minimum 2.
 Typ, rozmiar, jakość – kwestia indywidualnych
wyborów, najlepiej jednak 22-24”, IPS, czasem z
pivotem (dla koderów).

31. Peryferia
 Dobre myszki, wygodne klawiatury. I znów, średnia
półka jest zupełnie wystarczająca.
 Drukarka laserowa (kolor kosztuje). Fajnie, gdy ma
A3.
 Skaner.
 Dyski zewnętrzne na kopie zapasowe.

32. Sprzęt się psuje i starzeje
 Ważna jest gwarancja i serwis:
 Markowe komputery są droższe, ale oferują lepsze
warunku i lepszy serwis (np. NBD).
 Jeśli mamy ważny projekt, warto mieć komputer
zapasowy.
 Kopie zapasowe (o tym dalej).
 Komputery trzeba upgradować – warto to
wkalkulować w rozwój projektu/firmy.

33. Oprogramowanie
Software

34. Oprogramowanie specjalistyczne
 Każda dziedzina ma swoje.
 Często jest bardzo drogie i nie mamy wyboru.
 Warto poznawać alternatywy.
 Nie każde studio/projekt może udźwignąć koszty
wymarzonego softu – dobrze znać te
tańsze/darmowe.
 Trzeba umieć „sprzedać” swoje potrzeby w tym
zakresie – czasem inwestycja jest bardzo
opłacalna.

35. Przeglądarka web
 Internet Explorer jest najlepszą przeglądarką, aby
ściągnąć inną przeglądarkę:
 Google Chrome
 Mozilla Firefox
 Safari
 Opera
 To podstawowe narzędzie do uruchamiania
rosnącej rzeszy aplikacji webowych.

36. Pakiet biurowy
 Najlepszym rozwiązaniem jest Microsoft Office.
 MS Office produkuje „standardowe” dokumenty.
 Arkusz kalkulacyjny przydaje się każdemu:
programiście, artyście, projektantowi, producentowi.
 Duże możliwości tworzenia pięknych dokumentów.
 MS Visio – znakomity program do diagramów
 LibreOffice – też da radę, choć widać, że to
biedniejszy brat, ale za to za darmo.

37. Pakiet biurowy online
 Można wybierać:
 Google Docs (Drive)
 Zoho Office Suite
 Office Web Apps
 Tanio i każdy może je mieć.
 Dostępność z dowolnego miejsca.
 Możliwość łatwego dzielenia
dokumentów, kooperacji oraz publikowania.
 Ciągle powiększane możliwości.

38. Google Apps
 Aplikacje Google we własnej domenie:
 Poczta (z klientem web).
 Kalendarz.
 Komunikator w ramach domeny.
 Pakiet biurowy (Google Drive).
 Limit użytkowników: 10 w wersji darmowej.
 Nie znam powodów, dla których nie powinno się z
tej oferty skorzystać.

39. Programy narzędziowe
 Idealny rozwiązaniem tej kwestii są pakiety
narzędzi portable (przenośnych):
 Liberkey
 PortableApps.com Suite
 Trywialna instalacja, same się aktualizują.
 Można je łatwo przenosić pomiędzy komputerami.
 Można je mieć zawsze przy sobie (pendrive).
 Szeroki wachlarz narzędzi – bez problemu
załatwią 99,9% potrzeb.

40. Aplikacje portable

41. Systemy kontroli wersji
 Niezbędne narzędzie w każdej pracy kreatywnej
oraz pracy grupowej.
 Zapewniają dostęp do poprzednich wersji naszych
plików.
 Oferują mechanizm wymiany zmienionych plików
pomiędzy członkami zespołu.
 Zapobiegają/wykrywają/niwelują konflikty w
dostępie i modyfikacji tych samych plików.
 I mnóstwo innych, o czym później.

42. Systemy kontroli wersji
 Scentralizowane systemy kontroli wersji
(uniwersalne):
 Subversion
 Perforce
 Rozproszone systemy kontroli wersji, głównie do
kodu:
 Git
 Mercurial

43. Narzędzia kopii zapasowych
 Regularne wykonywania kopii w inne
miejsce, choćby poprzez narzędzia standardowe.
 Zautomatyzowane narzędzia do wykonywania
kopii zapasowych (np. przyrostowych).
 Systemu wykonywania kopii zapasowych w chmurę
(np. polecam CrashPlan)
 Systemy archiwizacji kopii roboczych.

44. System archiwizacji kopii roboczych
 Narzędzie, które „śledzi” wybrane pliki/folder i
wykrywa, gdy została zapisana nowa wersja pliku
– wtedy robi jej kopię w innym miejscu.
 Automatyczny system wersjonowania plików, na
którymi pracujemy – możemy nawet mieć wszystkie
poprzednie wersji.
 Zawsze możemy wrócić do poprzedniej wersji i
ocalić zepsuty pomysł, bo mamy dużo kopii
zapasowych.
 Polecane narzędzie – FileHamster.

45. Inne narzędzia
 Kodeki – niezbędne do odtwarzania plików
mediów oraz do tworzenia ich: K-Lite Codec Pack
 Archiwizer – 7-Zip.
 Antywirus i Zapora.
 Szyfrowanie dysków (np. Truecrypt).
 Program katalogujący – jeśli robimy backupy na
fizyczne nośniki.
 Komunikatory – Skype i Miranda
 Dropbox, Google Drive, Box Net, etc.

46. Procesy
I dobre warsztatowe praktyki

47. Porządek w plikach
 Podział dysku na partycje, C: nie wystarcza.
 Folder roboczy, nie desktop.
 Jasna i czytelna struktura folderów.
 System nazewnictwa plików (najlepiej stałej
długości) – znamy i przestrzegany.
 Konsekwencja w używaniu małych/wielkich liter.
 Unikanie znaków diakrytycznych.
 Osobno źródła, osobno rezultaty.

48. Zarządzanie plikami
 Wygodne narzędzia do operacji na plikach: Total
Commander, Altap Salamander.
 Umiejętność wykonywania operacji masowych na
plikach: wybiórczego kasowania/ przenoszenia/
kopiowania dużych liczb plików.
 Umiejętność masowego zmieniania nazw plików.

49. Praca z systemami kontroli wersji
 Systemy te zapewniają:
 Synchronizację pomiędzy członkami zespołu.
 Kopie zapasowe.
 Dostęp do poprzednich wersji.
 Możliwość cofania zmian (bliskich i dalekich).
 Śledzenie zmian.
 Archiwizacja i tagowanie.
 Określanie autorstwa.
 Branch and merge.

50. Praca z systemami kontroli wersji
 Repozytorium (server) i kopia robocze (klient)
 Pierwszy checkout, a potem:
 Zmiany,a potem commit
 Update, oby otrzymać zmiany innych
 I tak w kółko
 Tryby:
 merge
 Lock
 http://betterexplained.com/articles/a-visual-
guide-to-version-control/

51. Kopie zapasowe
 Sprzęt się psuje, ludzie popełniają pomyłki.
 Kopie zapasowe mają chronić przed powyższym.
 Systemy automatycznej archiwizacji i
wersjonowania.
 Kopie do innych folderów, na inne dyski.
 Kopie off-site (wynoszone).
 Kopie w chmurę (cloud).
 Kopie proste i przyrostowe.
 Kopie kopii (np. kopie repozytorium)

52. Kopie zapasowe
 Coraz więcej danych przechowujemy u innych:
 Pocztęelektroniczną.
 Dokumenty.
 Czasem kod i dane (zewnętrzne repozytoria).
 Może zostać pozbawieni dostępu w dowolnym
momencie.
 Musimy robić sobie kopie zapasowe lokalnie, a te
kopie gdzieś sobie dla bezpieczeństwa kopiować.

53. Archiwizacja
 Nigdy nie wiadomo, kiedy wrócimy do rzeczy
sprzed lat.
 Dysponuję kopiami prac sprzed 20 lat.
 Należy stosować standardowe archiwizery.
 Pamiętajmy, że nośniki fizyczne mają ograniczony
czas życia.
 Redundancja pomaga w odzyskaniu danych po
latach.
 Odświeżanie jest dobrym sposobem na utrzymanie
dostępu do starych danych.

54. Automatyzacja
 Wiele procesów wymaga wykonywania
podobnych, albo takich samych ciągów czynności.
 To doskonała właściwość do zastosowania
automatyzacji.
 Tworzenie kopii zapasowych/wersji jest dobrym
przykładem procesu, który może być całkiem
automatyczny – wystarczy dobrać narzędzie.

55. Automatyzacja
 Często proces tworzenia czegoś nie dostarcza
danych w odpowiednim formacie dla gry.
 Trzeba je przetworzyć –
wyeksportować, zaimportować, itp.
 Czasem jest to kilka etapów, podczas których łatwo
o pomyłkę.
 Automatyzacja pozwala unikać pomyłek, oraz
przyspieszyć proces.

56. Automatyzacja
 Skrypty wiersza poleceń – pliki .BAT
 Łatwy język skryptowy do operacji na plikach.
 Możliwość przetwarzania plików poprzez narzędzia
dające się uruchamiać z parametrami wiersza poleceń.
 Języki skryptowe – bardziej zaawansowane języki
typu Perl czy Python, które pozwalają na
wykonywanie bardziej skomplikowanych operacji
na plikach czy wręcz na zawartych w nich danych.

57. Automatyzacja
 Wykonywanie operacji na podstawie reguł:
 Narzędzie budujące – make
 Narzędzie budujące – Apache Ant
 Przetwarzają dane wejściowe na podstawie raz
zdefiniowanych reguł.
 Pozwalają one na tworzenie różnych wynikowych
danych na podstawie zadanych parametrów.
 Głównie używane do tworzenia buildów – lokalnych
lub globalnych.

58. Automatyzacja
 Ciągła integracja i automatyczne tworzenie
buildów dla zespołu wraz z ich dystrybucją:
 Instant
builds
 Daily/nightly builds
 Automatyczne testowanie:
 Testy jednostkowe
 Automatyczne smoke tests
 Testy wydajnościowe

59. Identyfikacja wersji
 System nazewnictwa powinien pozwalać łatwo
rozróżniać podobne dane np. do różnych języków.
 Kolejne wersje gry powinny się różnić – proces
tworzenia gry powinien automatycznie zmieniać jej
oznaczenie wersji.
 Warianty powinny być także jasno oznaczane –
poprzez umieszczania danych wynikowy w
różnych, odpowiednio oznaczonych folderach.
 Dobrze oznaczone wersje łatwiej identyfikować
(raporty), przekazywać (wysyłka) i archiwizować.

60. Zarządzanie dokumentami
 Dokumenty współdzielone online rozwiązują wiele
problemów:
 Zawsze jest aktualna wersja.
 Można współedytować w tym samym czasie.
 Widać kto i kiedy edytował.
 Widać co zostało zmienione.
 Jest historia zmian.
 Łatwo udostępnia się kolejnym uczestnikom.
 Daje się przeszukiwać.
 Dokumenty online oferują ubogie formatowanie i
możliwości, oraz nie wszystkie typy dokumentów.

61. Zarządzanie dokumentami
 Dokumenty tworzone tradycyjnie można dzielić i
zarządzać w systemie kontroli wersji:
 System z wyłącznością edycji zabezpiecza przed
konfliktami.
 Jest zawsze aktualizowany.
 Jest historia zmian.
 Jest dostęp dla każdego.
 Nie można go jednak przeszukiwać.
 Tylko jedna osoba może edytować dokument.

62. Baza wiedzy
 Nie zawsze zbiór dokumentów w serwisie online czy
repozytorium jest dobrym sposobem na
dokumentowanie wiedzy.
 Jest zapewne najprostszym do wypełnienia, ale nie
do użytkowania.
 Wiedza na temat gry czy procesów produkcyjnych
może być lepiej przedstawiona w formie wiki.
 Wiki jest trudniejsze w utrzymaniu (szczególnie
oparte o mark up) i ma ograniczone (znów)
możliwości formatowania.

63. Zarządzanie procesami etapowymi
 Wiele procesów produkcyjnych w grach jest
wieloetapowych, gdzie każdy etap wykonywany
jest przez różnych ludzi.
 Musi istnieć dobry mechanizm przekazywania sobie
prac pomiędzy etapami – np. poprzez
umieszczanie ich w odpowiednich folderach
repozytorium.
 Kolejni wykonawcy muszą wiedzieć, że czeka ich
nowa praca – mogą sprawdzać foldery, ale też
można zorganizować jakiś system informowania się
o zakończeniu etapu.

64. Zarządzanie procesami etapowymi
 Można trzymać wspólny arkusz kalkulacyjny, w
którym oznacza się statusy odpowiednich obiektów.
 Można też mieć tablicę z karteczkami, które
wędrują do odpowiednich przedziałów informując
kolejnych wykonawców, że czeka ich praca.
 Czasem owa praca to akceptacja.
 Można zrealizować tablicę w formie
elektronicznej, choćby w systemie Trello.com
 Warto poczytać o metodyce Kanban.

65. Zarządzanie swoim czasem
 Pamięć jest zawodna – lepiej jakoś zapisywać, co
chcemy robić.
 Najprostsze są choćby listy to-do.
 Większość z nich to aplikacje webowe, dostępne z
każdej przeglądarki i aplikacji mobilnych.
 Nierzadko mogą pomóc nas w zarządzaniu małym
i niemałym zespołem.

66. Zarządzanie swoim czasem
trello.com basecamp.com
todoist.com teuxdeux.com

67. Praca efektywna
 Prokrastynacja
 Stwierdzenie zjawiska
 Walka z nim
 Flow
 Walka z
rutyną, znudzeniem i
wypaleniem.

68. Zbieranie danych
 Zbyt wiele rzeczy ocenianych jest „na czuja” i na
podstawie tych obserwacji wyciągane są wnioski i
wprowadzane zmiany.
 Często obserwacje są błędne, obarczone błędami
psychologicznymi.
 Skuteczność wprowadzonych na skutek błędnych
zmian oceniania jest ponownie błędnymi
obserwacjami.
 Problem pogłębia się zamiast znikać.

69. Zbieranie danych
 Znacznie lepszy sposobem jest zbierania twardych
danych, opartych na obiektywnych pomiarach (tzw.
metrics).
 Obiektywne dane nie oznaczają, że wyciągniemy
właściwe wnioski, ale możemy ponownie
zweryfikować rezultat w oparciu o obiektywne
dane.
 Obróbka statystyczna może być trudna, ale tu
możemy poprosić o pomoc.

70. Zbieranie danych
 Metrics nie muszą dotyczyć gry, ale także mogą
dotyczyć procesów produkcji.
 Możliwość śledzenia czasów produkcji podobnych
elementów umożliwia obiektywne stwierdzenie
wpływu udoskonaleń procesu. Można też wykryć
zjawiska, które wpływają na zakłócanie
procesu, czy potencjalne wąskie gardła.

71. Autopromocja i nauka
 Pokazujmy innym w zespole, co tam robimy:
 Róbmy snapshoty.
 Pokazujmy je i dyskutujmy.
 Chwalmy się i pobudzajmy zdrową rywalizację.
 Mentorujmy młodszym
 Uczmy się od innych w zespole:
 Róbmy regularne przeglądy naszych prac.
 Patrzmy co ktoś zrobił i jak.
 Pytajmy się i uczmy od starszych.

72. Dokumentowanie projektu
 Chodzi o dokumentowanie tego, co się w projekcie
działo.
 Zapamiętywanie zadań z systemu zarządzania nimi
(fajna historia zadań).
 Robienie screenshotów i filmików regularnie co jakiś
interwał, aby móc odtworzyć proces przemiany gry.
 Archiwizacja co jakiś czas gry w jej aktualnym
stanie – znów fajna możliwość prześledzenia zmian.
 Zdjęcia z pracy i zabawy – fajnie do nich wrócić
po latach.

73. Wiedza
Co generalnie warto znać

74. Wiedza
 Stale pogłębiana wiedza na temat specyficznych
narzędzi i procesów w naszej dziedzinie.
 Zapoznawanie się z nowymi/innymi
narzędziami, nawet jeśli ich nie używamy w danym
momencie.
 Podglądanie pracy innych, wymiana doświadczeń.
 Gromadzenie referencji, które mogą się na przydać
w pracy, czy współpracy z innymi.

75. Wiedza
 Wyrażenia regularne – nieocenione w zamianie
nazwa plików, wyszukiwaniu plików czy bardziej
skomplikowanych operacjach na tekstach.
 Składnie skryptów .BAT
 Co to jest CSV, XML oraz JSON i dlaczego w tym
ostatnim warto przesyłać dane.
 Co to są bazy NoSQL i dlaczego fajnie w nich
trzymać dane do analiz (metrics).
 Fajnie wiedzieć coś o metodykach zwinnych (agile).
 Jak zamieniać nasze dokumenty na PDFy!