Machine Learning (pol. uczenie maszynowe, samouczenie się maszyn, systemy uczące się) jest jedną z aktualnie najlepiej prosperujących dziedzin w świecie IT.

W 1959 Alan Turing i Arthur Samuel amerykańscy pionierzy w dziedzinie gier komputerowych i sztucznej inteligencji ukształtowali współczesny termin machine learning .

The field of study that gives computers the ability to learn without being explicitly programmed.

~ Arthur Samuel

Oznacza to możliwość nauki programu komputerowego na podstawie wcześniej przygotowanych danych w celu rozwiązania konkretnego problemu bez znania sposobu na osiągnięcie go, czyli wcześniejszej listy kroków którą ma wykonać program. Oparte jest to o zestaw gotowych algorytmów z podanych dziedzin matematyki:

• algebra liniowa
• rachunek prawdopodobieństwa
• statystyka

Sieć neuronowa

Machine Learning działa w oparciu o sieci neuronowe wzorowane na ludzkich. Powyższy schemat sieci neuronowej pokazuje jej uproszczony sposób działania. Składa się ona z neuronów . Każdy neuron jest wprowadzany przez dendryty od innych neuronów przenosząc sygnały otrzymywane z innych neuronów przez synapsy . Na grafice powyżej czerwone neurony stanowią warstwę wejściową, niebieskie – warstwę ukrytą, a zielone – warstwę wyjściową. Ilość ukrytych warstw jest zależna od tzw. głębokości , im głębsza tym bardziej skomplikowane są połączenia między nimi.

Podczas trenowania własnej sieci neuronowej dane są przekazywane od neuronu do neuronu, każdy kolejny może zapamiętywać (Recurrent Neural Network) wynik poprzedniego i przekazywać coraz to lepsze dane. Im więcej razy będziemy trenować taką sieć tym mniej błędów i lepszy wynik.

Rodzaje sieci neuronowych w jednym zdaniu

Feedforward Neural Network

Ta sieć bardzo dobrze klasyfikuje proste rzeczy, ale nie pamięta o poprzednich czynnościach/zmianach oraz ma nieskończone warianty wyników.

Recurrent Neural Network

W tym przypadku sieć pamięta poprzednie zmiany i ma skończony wariant wyników.

Sposoby uczenia

Uczenie nadzorowane (supervised learning)

Ten sposób uczenia polega na stworzeniu modelu danych, wejściowych czyli próbek (samples) wraz z modelem wyjściowym na przykład etykiet. Gdy wytrenujemy naszą sieć będziemy mogli prawidłowo przypisać wyjście dla obiektu którego dotychczas nie było na wejściu. Nasza sieć uczy się w oparciu o nasz model tzw. dataset .

Uczenie nienadzorowane (unsupervised learning)

Tym razem sieć nie otrzymuje danych wyjściowych (etykiet), więc sama musi znaleźć odpowiedni sposób, aby uzyskać dane wejściowe.

Uczenie przez wzmacnianie (reinforcement learning)

W uczenie przez wzmacnianie sieć działa bez określonych danych wejściowych i wyjściowych. Jedyne informacje jakie otrzymuje to tzw sygnał wzmocnienia, który może być pozytywny (nagroda) w przypadku podejmowania trafnych decyzji lub negatywny w przypadku mylenia się (kara). Jest to całkiem niezły sposób na naukę naszej AI grania w proste gry bez pomocy człowieka czy nawet zostania mistrzem świata w Go i tworzenia własnych skomplikowanych strategii. Jest to niestety najbardziej wymagający czasu jak i mocy obliczeniowej sposób nauki.

Rodzaje problemów

Dwa najpopularniejsze rodzaje problemów to klasyfikacja oraz regresja.

Klasyfikacja (classification)

Nasze wejściowe dane łączone są w model na podstawie którego jest określane czy spełnione są odpowiednie warunki czy też nie. Wynik z największym prawdopodobieństwem zostanie nam zwrócony. Na przykład rozpoznawanie ręcznie narysowanych cyfr, w tym przypadku mamy dataset w którym są próbki z zdjęciami narysowanych cyfr oraz etykiety dla każdego z nich. Podajemy nasze dane (zdjęcie) oraz trenujemy sieć używając naszego datasetu i otrzymujemy wynik.

Regresja (regression)

Działa to tak jak wyżej, lecz z jedną różnicą, a mianowicie tutaj otrzymujemy ciąg wyników/tablice z wynikami, a nie tylko jeden wynik. Przykładem problemu regresji może być przewidywanie ceny bitcoina w zależności od jego aktualnego kursu oraz w oparciu o dane z poprzednich miesięcy.

Podsumowując, Machine Learning ma wielki potencjał niemal w każdej dziedzinie, myślę, że ten wstęp powinien przybliżyć Ci jak mniej więcej to działa.

Źródła:

• https://en.wikipedia.org/wiki/Artificial_neural_network
• http://scikit-learn.org/
• http://itcraftsman.pl/wstep-do-machine-learning/

Nazywam się Adam Jachowicz , jestem z Nastoletnimi od ich początków (dołączyłem do grupy 3 maja 2015, mogę się już chyba nazywać weteranem?). Większość z Was kojarzy mnie (jeżeli w ogóle, bo apogeum aktywności osiągnąłem bardzo dawno ) z bycia głównym redaktorem bloga http://programistycznepieklo.pl . No i jak możecie się domyślać – to mnie przypadło podsumowanie wyników ankiety. Sama przyjemność!

Przeciętny członek NP jest mężczyzną (cóż za zdziwienie) , ma 15-17 lat. Jego głównym obszarem zainteresowań jest desktop , zwykle ma też jakieś doświadczenie z webdevelopmentem . Zna też C++ , oprócz tego zwykle PHP i JS , rzadziej Javę , SQL i C# . Nigdy nie pracował ani nie wykonywał żadnego zlecenia. Ocenia swoją satysfakcję z programowania na 8.5 w skali od 1 do 10. Jeżeli przyszedłeś tylko po to co obiecywał tytuł – to tyle, możesz już zamknąć tę stronę.

Jeżeli jednak chcesz zobaczyć coś więcej…

Analiza danych pochodzących od respondentów – czyli coś dla chcących WIĘCEJ

Czas odpowiedzieć na pierwsze pytanie jakie może nasuwać się uważnemu czytelnikowi – skąd wiem, że większość osób będących członkami NP nie wiedziało o ankiecie? Albo konkretniej, że większość osób jej nie wypełniła ?

Ankietę (na dzień 01.04.2017) wypełniło 388 osób (ale pod uwagę wziąłem tylko 372, dalej okaże się czemu) – to mało jak na 5754 członków… Tak na dobrą sprawę to bardzo mało – dokładnie 6.47% grupy. Można by dyskutować, czy taka próbka nadaje się do analizy, ale to jedyne do czego mam dostęp, więc… ¯\_(ツ)_/¯

Płeć

Myślę że nie będzie tu niespodzianki, więc nie ma się co rozpisywać:

W sumie może i jest co napisać na ten temat… Oczywiście no offence i te sprawy, ale… kobiety wyglądają trochę jak błąd statystyczny ( ͡° ͜ʖ ͡°)

Wiek

Tu już na szczęście robi się trochę ciekawiej . Znaczy, no, kobiety nadal wyglądają jak błąd statystyczny ( ͡° ͜ʖ ͡°) ale widać tu już jakieś ciekawsze powiązania. Przykładowo, kształt wykresu powinien być dla niektórych znajomy… Tak, to bardzo ładna krzywa normalna. Co prawda przesunięta nieco w stronę młodszych, ale nadal normalna.

Krzywa normalna (dzwonowata) – jedna z ważniejszych krzywych w statystyce ze względu na jej częste występowanie w naturze (m. in. krzywa wykresu obrazującego rozkład wartości IQ czy wzrostu lub nawet błędu pomiarowego). Posiada pewne ciekawe właściwości, ale ich tłumaczenie nie wchodzi jednak w zakres tego artykułu.

Jest jeszcze jedna rzecz która powinna się rzucić w oczy po analizie etykiet słupków… Jeżeli to zauważyłeś – moje osobiste gratulacje . Jeżeli nadal tego nie widzisz – istnieje słupek 20 jak i „>20”, ale pary „13” i „<13” już nie widać . Jak to się stało? No, nie chcę przywoływać nazwisk i imion, ale pewien z administratorów którego imię zaczyna się na A i kończy na lbert zapomniał dodać takiej opcji w ankiecie ( ͡° ͜ʖ ͡°) No nic, na potrzeby tego artykułu musimy założyć że każde „<13” jest tak naprawdę odpowiednikiem „<14”.

Technologia

W ankiecie trzeba było wybrać technologię na dwa sposoby – podać swoją główną oraz wszystkie znane technologie. Najpierw zajmiemy się tą główną:

Wartości procentowe odnoszą się do ogółu respondentów.

Co tu widzimy? Połowa członków NP jako target swoich programów wybiera głównie desktop, a 1/3 pisze stronki. Także nic zaskakującego, w końcu C++ i JS jest jednym z najbardziej ooops, jeszcze tu nie dotarliśmy Pod Innymi kryją się odpowiedzi takie jak:

konsolka,
Inne, (???)
asm, ale reverse engineering różnych technologii,
Teamspeak.

Skoro mamy dane dotyczące wieku jak i dane dotyczące technologii, możemy je skorelować – to dwa z ciekawszych wykresów:

Jak widać – wraz z wiekem więcej osób dryfuje z desktopa do innych technologii. Czemu tak się dzieje? Ano dlatego, że im młodszy jesteś, tym większe prawdopodobieństwo że dopiero się uczysz. A od czego zwykle zaczynają młodzi adepci programowania? Od C++. Potem dopiero zaczyna się odkrywanie technologii która jest ci bliska – najpierw zawsze jest ten proces nauki. Nie dziwi też to że nie przechodzą do webdevu – tak właściwie to następuje tu rotacja w obie strony, ponieważ drugim zestawem języków od którego często zaczynamy przygodę z programowaniem jest HTML, CSS i JS. A czemu wzrósł udział mobilek i mikrokontrolerów, i to akurat względem desktopa? Proste – programując na desktop, łatwiej jest się potem przerzucić na którąś z tych technologii niż na webdev.

Ten trend łatwiej będzie zauważyć na tym wykresie:

Wartości procentowe obu słupków przy wieku nie sumują się do 100%, ponieważ są to wartości żywcem wyciągnięte z takiego jak powyżej wykresu kołowego – ważne są tu różnice w wysokości słupków, które wraz z wzrastającym wiekiem utrzymują w miarę stały trend malejący. Błędy, małe skoki w górę czy wielki skok nie pasujący do tezy przy grupie 20 czy >20 jest spowodowany wielkością próbki – tak jak mówiłem, jest trochę za mała by wyciągać z niej dokładne wnioski bezpośrednio, jednak pewnych rzeczy jako człowiek z doświadczeniem w takich rzeczach mogę się domyślić na podstawie nawet i takich danych

Wyniki drugiego związanego z technologią pytania nie powinny być zaskoczeniem po przeczytaniu wcześniejszego tekstu:

Tutaj wartości nadal nie sumują się do 100%, ale tu powód jest prostszy – pytanie było pytaniem wielokrotnego wyboru i dotyczyło wszystkich znanych technologii. Ogólnie to nic ciekawego, ale mogę przywołać to co tym razem znalazło się pod pojęciem Inne :

Skryptowanie gier,
LUA (Multi Theft Auto: San Andreas),
dużo, (???)
Serwery, bazy danych,
Games,
Teamspeak,
STM32.

Po technologii czas na to co dla mnie osobiście jest najciekawszym zbiorem wektorów danych…

Języki

Zanim pokażę pierwszy wykres związany z tym działem muszę was ostrzec – praktycznie każdy wykres tutaj może dla was wyglądać tak samo. Muszę was jednak zapewnić że nie są takie same – wrażenie takie może się wziąć z tego, że próbują one pokazać jak najwięcej danych w jak najmniejszej/najefektywniejszej/najczytelniejszej postaci. No i kolorki są podobne.

Nie przedłużając, pierwszy kolos:

Może na początku wytłumaczę co dokładnie ten wykres tak właściwie przedstawia. Po lewej mamy języki. Na dole jest liczbowa reprezentacja zaawansowania – wygodniej było się z tym obchodzić w kodzie, myślę że jest też bardziej przejrzyście na wykresach. Cyfry oznaczają:

• 0 – Nie znam,
• 1 – Nowicjusz,
• 2 – Amator,
• 3 – Średnio zaawansowany,
• 4 – Zaawansowany,
• 5 – Ekspert.

W ten sposób mogę traktować zaawansowanie w języku jako ciągłe, liniowe pasmo a nie jako zbiór 6 stopni – wygodniej

Wykres na górze przedstawia procent wszystkich respondentów mających dane zaawansowanie w danym języku. Przykładowo: 83 procent wszystkich respondentów nie zna Assemblera, 11 procent w jakiś sposób się z nim zetknęło ale tylko około 6 procent może się pochwalić pełniejszą wiedzą.

Możecie zauważyć, że na wykresie procenty dla Assemblera sumują się nie do 100, a do 101 procent – powodem są błędy zaokrągleń, niestety :/

Oprócz tego wykres posortowany jest tak, że język z największym średnim poziomem znania jest na górze, a ten z najmniejszym – na dole. Dzięki temu bardzo łatwo jest zobaczyć jakie języki są najpopularniejsze wśród członków naszej grupy – są to C++ , PHP , JS , SQL , C# , Java , Python i C . Trzeba jednak nadmienić że C++ ma nad nimi znaczącą przewagę, jak zresztą widać na wykresie. Można powiedzieć że języki od Perla w dół są językami nieznanymi na NP.

Osobiście mi trochę smutno że języki nowatorskie czy niestandardowe (Haskell, Go, Clojure, Scala, Groovy) lub specjalistyczne (Prolog, R) są pomijane przez członków NP – wiadomo, rzadko przyjdzie pisać większy projekt z ich udziałem ale ich znajomość może wiele rzeczy wyjaśnić, pokazać inne podejście do programowania. Ale cóż, co ja mogę ¯\_(ツ)_/¯

Co ciekawe, mamy raczej skromnych programistów, mało osób zaznaczało w ankiecie ekspercki poziom znania języka. Nawet w przypadku C++ było to tylko 3 % ankietowanych. Kochani, więcej pewności siebie ^^

Następny wykres (Wyk. 8) może być ciekawszy ze względu na to, że pokazuje on średnią znajomość danego języka wyrażoną w procentach w danej grupie wiekowej – oczywiste jest że wartości nie mogą się tu sumować do 100 %.

Na tym wykresie bardzo ciekawie widać jedną rzecz – to, że z wiekiem umiemy coraz więcej. Niby taki banał, a tak ładnie zwizualizowany

Ciekawym ewenementem są członkowie w wieku 20 i >20 lat – zacznijmy może od dwudziestek.

Z danych jednoznacznie wynika… że są głupsi. Tak naprawdę to jedyny rocznik który nie podąża za trendem wzrostu wiedzy wraz z wiekiem. Czym może być to spowodowane? Właściwie to nie mam bladego pojęcia. W następnym wykresie ten spadek będzie widoczny jeszcze bardziej.

Chociaż właściwie to jest jedna rzecz w której trzymają się trendu – w językach, które zwykle są ignorowane przez programistów ;-; Ciekawe, prawda? Popularność języków wśród danych grup wiekowych także będzie przedmiotem jednego z następnych wykresów, więc będzie można ładnie zobaczyć tę zależność.

Osoby posiadające ponad 20 lat na karku są za to z niektórymi językami aż za bardzo do przodu (Pascal, Swift). Pierwszy z nich łatwo wytumaczyć – starsze roczniki często w szkołach uczyły się Pascala czy Delphi więc konsekwencją tej nauki musi być wyższy poziom poznania języka. Swift za to nie jest już taki banalny do wytłumaczenia – co tu się stało?

Na wynik wpłynęło to, że >20 to większa zasięgowo grupa niż na przykład takie 14 . Wśród osób zaznaczających tą odpowiedź mogły znajdować się zarówno dwudziestojedno jak i dwudziestopięciolatkowie. A jeżeli zakładamy że z wiekiem wiedza rośnie, to w wynikach grupy >20 nie ma nic dziwnego.

Czternastolatków przywołałem tu nie bez przyczyny – z jakiegoś dziwnego powodu są za bardzo zaawansowani w C# jak na swój wiek… Ma ktoś jakiś pomysł jak to wyjaśnić? Komentarze są wasze .

Co ciekawego jeszcze widzimy? Dziewiętnastolatkowie wychodzą poza szereg jeżeli chodzi o języki inne niż C++. To z kolei może oznaczać dwie rzeczy:

• Nastolatkowie po skończeniu liceum nabywają dużo wiedzy programistycznej, albo…
• …po prostu nie wyłapałem wszystkich trolli.

Pamiętacie co pisałem na początku? Z 388 odpowiedzi wziąłem pod uwagę tylko 372. Dlaczego? Właśnie z tego powodu – dane od trolli bardzo zakrzywiały różne korelacje/wyniki.

Myślę że można już przejść do kolejnego, obiecanego wykresu:

Cyferki mało tutaj znaczą – ten procent to średnia z kolumn z poprzedniego (Wyk. 8) wykresu. Ważne są zależności i trendy, które tutaj widać bardzo wyraźnie.

Pierwsze co się rzuca w oczy – wyraźny ubytek przy słupku opisanym 20 . Wcześniej już o tym pisałem – na tym wykresie można to zauważyć dokładniej. Jakieś pomysły? Znaczy, to zawsze może być błąd statystyczny, bo przy grupie badanych równej 13 osobom… No ale o małej wielkości próbki już pisałem…

Skok u dziewiętnastolatków również widać tutaj doskonale, przyczyny również opisałem wcześniej. Ten wykres służy właściwie podsumowaniu danych z tamtej mapy ciepła, nic szczególnego za sobą nie niesie.

W tym momencie podczas pisania tego artykułu się zadumałem. Czy ktokolwiek dojdzie do tego momentu? – myślałem. Licznik słów przekręcił się na magiczną liczbę 1720. Była we mnie nutka zwątpienia, ale także i ciekawości. Jeb^CChędożyć to! – powiedziałem w myślach. I zacząłem pisać dalej, zostawiając pytania o sens mojej egzystencji gdzieś na później.

Kolejny wykres również jest mapą ciepła. Znowu wartości w rzędach nie sumują się do 100%. Czemu więc? Wykres przedstawia procentową znajomość danego języka w danych grupach wiekowych.

W tym wykresie ważne jest, żeby przedstawić założenia na których opierałem się żeby zaliczyć dany język do „znanego” przez respondenta czy też nie. Problem w tego typu wykresach jest taki, że nie da się jednoznacznie, obiektywnie określić czy dany język jest przez kogoś znany. Bo jak określić znajomość?

Teoretycznie mogę nie programować w danym języku, ale mimo to znać go, chociażby tylko z nazwy. Chyba nie będzie sporów, gdy powiem że znam taki język? Niestety w tej ankiecie nie miałem szansy wdrożyć takiego podejścia przez sposób zadania pytania o języki – ewidentnie kładło ono nacisk na poziom poznania języka, a nie na jego znajomość .

Musiałem więc posłużyć się uproszczoną metryką znajomości i założyć, że każdy kto zaznaczył przy danym języku poziom zaawansowania przynajmniej 1 ( Nowicjusz ) zna ten język, a reszta która zaznaczyła 0 tego języka nie zna .

Przechodząc do analizy… Jest taki język który zna każdy. Niezależnie od grupy wiekowej. Małe odchyłki w liczbach właściwie nic nie znaczą, mapa ciepła mówi sama za siebie – pasek przypisany C++ jest w całości gorący .

Nasz poprzedni fenomen, dziewiętnastolatkowie, nadal wyróżniają się w tabeli, głównie za sprawą języków stricte webowych – JS’a i PHP . Co ciekawe – kosztem Javy .

Starsi, grupa >20 jak można było przewidzieć cechuje się najszerszą znajomością języków. Można też zobaczyć że moja hipoteza o Pascalu potwierdza się – na mapie widać, że starsze roczniki umieją go w znacznie większym procencie osób niż inne.

Dwudziestolatkowie mają z kolei problemy z… C#’em . W sumie oni mają ze wszystkim problemy (jak mogliśmy zobaczyć na wcześniejszych wykresach)… Ale to i tak dziwne jak na ogół. Za to znają Assemblera i Haskella na najlepszym poziomie ze wszystkich badanych grup wiekowych – zawsze coś ( ͡° ͜ʖ ͡°)

Ostatni już wykres (Wyk. 11) pokazuje rozkład procentowy znajomości danego języka w zależności od wybranej technologii głównej.

Skróty na dole pochodzą od nazw technologii:

• W – Web ,
• D – Desktop ,
• M – Mobile ,
• A – AVR/ARM.

Widać tu pewne silne trendy – przykładowo, 79% wybierających AVR/ARM zna C. Nie powinno być tu zaskoczenia, tak samo jak przy fakcie posiadania największej procentowej znajomości C++ wśród wszystkich grup technologicznych . Znają też dobrze Pythona , PHP i JS’a . Co do tego PHP i JS’a – podejrzewam że wynika to z błędu statystycznego, mała grupa badanych. Pythona dałoby się wytłumaczyć tym, że to popularny język skryptowy, jednak nadal myślę że nie usprawiedliwia to jego popularności w tym zestawieniu.

Co ciekawe, Webowcy znają Pascala niż inne grupy technologiczne – kto spodziewał się takiego wyniku? Mimo to, uzasadnienie istnieje – w szkołach obok Pascala jako języka stricte desktopowego nauczany jest też HTML razem z elementami CSSa i (czasem bo czasem, ale jednak) JSa. Wiadomo, że jakaś część uczniów wybierze Web jako swoją główną technologię, druga część wybierze Desktop. A jak mogliśmy zobaczyć na wykresach 3, 4.1 i 4.2 istnieje tendencja do wyrównywania się ilości osób mających za swoje główne technologie Web i Desktop wraz z końcem procesu kształcenia szkolnego. Więc zagadka rozwikłana

Wysoka znajomość Javy wśród Mobilnych chyba nie dziwi, tak jak najmniejsza ze wszystkich grup znajomość C++’a . Ciekawi najniższa wśród wszystkich grup znajomość Objective-C . Tak, wiem że teraz wszyscy w Swift’cie piszą, ale jednak – w ankiecie było pytanie o znajomość, a nie o używanie danego języka. W porównaniu do innych grup wygląda to słabiutko… No, ale za to wspomniany już wyżej Swift znają najlepiej ze wszystkich.

Trochę dziwi taka monotematyczność wśród Desktopowców – można to jednak tłumaczyć tym, że wśród desktopowców dużą przewagę mają młodsi, dopiero uczący się adepci programowania. Java czy C# nie są tu znane tak bardzo jak porównywalne języki w innych grupach, za to C++ trzyma się na stałym, wysokim poziomie znajomości wśród reprezentantów grupy Desktopowej.

I na tym niestety muszę zakończyć.

Post zrobił się nieco długi, powstawał też masę czasu – niestety, ale muszę go podzielić na dwie części. W następnej – dalsza część ankiety, czyli satysfakcja badanych kontra różne czynniki oraz praca i jej szczegóły takie jak typ umowy czy średnia płaca za godzinę. Będzie ciekawie! A do czasu pojawienia się następnej części zapraszam serdecznie do komentowania i zadawania pytań – na każde postaram się odpowiedzieć

A – no i w następnej części udostępnię kod generujący wykresy (jest konfigurowalny) oraz dane na których pracuję – stay tuned!

No hej.

Zwę się Maks, vel themorfeus. Robię gry, i trochę wam dziś poopowiadam o jednej z najlepszych rzeczy w gamedevie. Zdarza mi się spotykać z programistami z różnych dziedzin niezwiązanych z tworzeniem gier. Zazwyczaj podczas poznawania się rozgaduję się o swojej pasji – tworzeniu gier. I zazwyczaj pojawia się wtedy zdanie „Uwielbiam jeździć na game jamy. Wiesz co to game jamy, nie?”. No i ku mojemu zdziwieniu, większość nie wie. Albo myśli, że wie, czyli nie wie.

Kilkunastu nerdów siedzi przed kompami i robią gry aż padną.

Kilkoro z ludzi którym zadałem pytanie o jamy odpowiedziało mi mniej więcej tak. Sam tak myślałem zanim sam nie uczestniczyłem w tego typu imprezie. Nic bardziej mylnego. Jadąc na mój pierwszy jam byłem poddenerwowany. Nie wiedziałem czego oczekiwać, nie wiedziałem jak to będzie wyglądać. Zastanawiałem się z kim będę w zespole, jaki będzie temat, jaką zrobię grę, i jak bardzo zbłaźnie się na prezentacji. Bałem się, że zapomniałem jakiejś ważnej rzeczy, że będzie brakować mi jakiegoś sprzętu i przez to nie dokończę gry. Slavic Game Jam 2016, czyli pierwszy jam na jaki pojechałem, odbywał się w Warszawie. Organizowali go świetni ludzie z Koła Naukowego Twórców Gier Polygon, działającego przy Politechnice Warszawskiej. Nadszedł w końcu dzień jamu. Dotarłem na miejsce, wziąłem swoją plakietkę, i poszedłem się rozstawić przy kilku znajomych którzy tam byli. Nadeszły prelekcje, potem obiad, potem wreszcie ogłoszenie tematu. I zaczęło się.

Nie róbcie gier na game jamach! – Sos Sosowski

I wtedy dowiedziałem się o najważniejszej rzeczy o game jamach jaka jest. Na game jamy nie jeździ się robić gier. Gry powstają ewentualnie przez przypadek, ale game jamy to przede wszystkim jedna wielka impreza. Z jednej strony karaoke, z drugiej strony ktoś na czymś gra, z trzeciej Sos robi grę o grabkach w VR, i ze wszystkich stron ukulele (ukulele to oficjalny instrument polskiego gamedevu). I wszyscy jakoś przy okazji wymyślają i robią gry. Jeśli chcesz robić grę, to zostajesz w domu.

I to jest właśnie esencja jamów, po to się tam jeździ. Żeby pobyć w gronie tych świetnych ludzi, żeby się z nimi zintegrować, pobawić i zawiązać nowe znajomości. Slavic nie był moim jedynym game jamem, ale poza tematem na który robi się grę, wiele różnic nie ma. Wszystkie są cudowne.

I właśnie dlatego będę na nich na was czekać!

Najlepszym rozwiązaniem jest oczywiście poprosić kogoś, aby wam zrobił wizualną część gry, lecz nie zawsze jest taka możliwość. Zwłaszcza gdy nie wiemy czy gra w ogóle coś zarobi. Ale szukajcie . Mi się udało znaleźć tylko gościa od muzyki w tle. Ale jeśli jednak nie ma to co? Może jakieś stronki z darmowymi grafikami/dźwiękami? Nie najgorsze rozwiązanie, ale często są to takie bardzo oklepane, typowe materiały wykorzystywane w wielu grach. Zresztą każdy woli być oryginalny i nie kopiować. W takim razie czemu by nie spróbować swoich sił w stworzeniu zarówno efektów dźwiękowych jak i grafik? Opowiem to na przykładzie mojej gry o nazwie kodowej Cyber Attack.

A więc polecam zaczynać od mądrego konceptu. Rozplanujcie sobie wszystko! Od mechaniki, fizyki aż do grafikę i dźwięki. Policz ile plansz chcesz stworzyć, czy aby na pewno tworzenie ich nie zajmie dużo czasu (zwłaszcza gdy są to gry logiczne, gdy często generator plansz nie wystarcza, potrzebne są mądrze skonstruowane przez człowieka plansze). Jako jeden programista musisz to wszystko ogarnąć, więc postaraj się żeby nie było tego za dużo . Ile to się spotyka ciekawych projektów, które giną przez to że po prostu nudzimy się tworzeniem ich, mamy już tego projektu dosyć! To zły nawyk !

Ja chciałem stworzyć grę o tematyce survivalu. Czy to oryginalne ? Wiadomo, temat survivalu jest bardzo oklepany, jednak bardzo wciągający i jest dużo możliwości, żeby był w miarę możliwości oryginalny. Nie chcę tutaj rozdrabniać na szczegóły, jak moja gra będzie wyglądać potem, bo to byłoby nie na temat. Moim (nie)skromnym zdaniem nie będzie to kolejna nudna gra survivalowa z craftingiem i po prostu przechodzeniem plansz z domieszką zombie.

Plan rozpisany, więc zaczynamy! Zacząłem od stworzenia algorytmu wyznaczania trasy. Zaimplementowałem algorytm A*, który wydaje się być łatwym i wydajnym dla mojej gry. Stworzyłem także prostą fizykę, która odpycha zombie jeśli są obok siebie, oraz wylicza kolizję obiektów ze ścianami.

Działa. Następnym elementem jaki zrobiłem to specjalną fizykę przeznaczoną dla pocisków, ponieważ są szybkie i w czasie jednej klatki mogą przeniknąć przez całą ścianę:

Działa! Wydaje się że wygląda to koszmarnie, ale szkielet przecież mamy zrobiony! Teraz najgorsza część dla programisty czyli upakowanie grafiki i dźwięków na tym szkielecie.

Grafika. Coś czego nienawidzę i nie mogę tego ogarnąć. Pamiętajcie – nie dawajcie sobie zbyt dużych celów. Gry z gorszą ale zrobioną z serca grafiką także zdobywają szacunek wśród graczy. Polecam pixelart lub coś w stylu flat design! Proste ale jak chociaż trochę popracujecie to wyniki będą zadowalające. Do tworzenia grafiki polecam Inkscape, lub jeśli macie pieniądze (lub klient Torrent) Adobe Illustrator. Inkscape zdecydowanie wystarczy, poszukajcie paru poradników, w których nauczycie się wielu operacji na ścieżkach, co znacznie przyspieszy pracę.

Plansza. Jako pierwsze chciałem zrobić planszę. Postanowiłem, że będzie ona… sześciokątem. Od tak – pierwsza plansza, więc powinna być prosta i dla gracza i dla mnie, aby ją dobrze zaprojektować. Oto etapy tworzenia planszy:

Jak widzicie zaczęło się od malutkiego sześciokąta, potem dodałem ich więcej aby dodać głębi planszy, a na sam koniec dodałem trójkąty, wpasowujące się w stylistykę gry oraz stanowiące miejsca „rodzenia się” przeciwników.

Główny bohater. Niełatwo czasem wymyślić fajnego bohatera. Czasem warto zapytać znajomych. Zwłaszcza tych co zazwyczaj mają „głupie” pomysły. Ja zapytałem i zaproponował mi zrobić klauna na wózku inwalidzkim który będzie uciekał przed policją . Na początku pomyślałem „Boże, co za debil”, ale to nie jest przecież zły pomysł. Zawsze lepiej być oryginalnym niż tworzyć kolejną zwykłą, typową, oklepaną setki razy postać.

Gorzej z rysowaniem owej postaci. Nie jestem w tym dobry . Na szczęście kamera w grze ma być dość oddalona, także gracz nie będzie się wpatrywać w tą beznadzieję, którą zrobiłem. Przynajmniej wózek w miarę ładnie wyszedł.

Bronie. Chyba jeden z prostszych elementów. Polecam znaleźć obrazek w Google i po prostu go przerobić. Efekt jest dobry:

Przeciwnicy. Planuję na każdą mapę dać innych przeciwników. To dużo roboty, jednak gracze doceniają takie rzeczy. Przeciwników oczywiście też zrobiłem w flat design, aby wszystko komponowało się w jedną całość. Pierwsza plansza ma przedstawiać współczesne + trochę fikcyjne elementy, do których flat design bardzo pasuje:

Bonusy. W tym stylu bardzo łatwo narysować różnorodne bonusy:

Edytor plansz. Grę piszę w frameworku LibGDX. Nie ma w nim żadnego edytora plansz czy coś na jego wzór, dlatego musiałem sobie stworzyć swój prosty edytor plansz. Napisałem go w Javie wykorzystując standardową bibliotekę GUI Swing. Nie wygląda on jakoś świetnie, ale sprawdza się w roli pomocy do tworzenia plansz. Wygląda on mniej więcej tak:

O edytorze nie będę za dużo mówić, bo to trochę nie na temat. Powiem tylko że jest bardzo pomocny, szczególnie gdy zamierzacie robić kilka map do gry – nie wyobrażam sobie umiejscawiać każdego obiektu bezpośrednio w kodzie, zwłaszcza jak mamy dużą mapę. Edytor pełni u mnie tylko funkcję pomocy, do umiejscawiania obiektów, cała reszta (skrypty itp.) dzieje się już w kodzie. Zerknijmy jeszcze na to, z czego składa się edytor:

• Points – punkty, używane do tworzenia ścian, węzłów nawigacji,
• Navigation Nodes – węzły nawigacji, potrzebne do algorytmu A* (wyznaczanie trasy przez przeciwników). Składają się z kilku punktów, tworzą wielokąt (koniecznie wypukły),
• Walls – ściany. Po prostu ściany w grze – każdy taki obiekt składa się z dwóch punktów,
• BackgroundTex / Tex – tekstury. Tex wyświetlają się nad graczem, BackgroundTex pod graczem,
• Spawners – oznaczają punkt w którym mogą pojawić się przeciwnicy.

Całą resztę mam zrealizowaną w kodzie. Wszystkie elementy interakcji, Easter Eggi teraz można łatwo wyłapać, po prostu pobierając punkt z pliku edytora i na przykład sprawdzając jego odległość od gracza.

Okej, mamy już planszę. Nie wygląda najgorzej, co nie?

Ale brakuje dźwięków – i to bardzo. Przecież nie będę ogarniać FL Studio – zajęłoby mi to parę tygodni, zresztą i tak nie mam słuchu muzycznego. Ale Audacity chyba każdy zna. Mikrofon też wiele osób ma. Ja użyłem bezprzewodowych mikrofonów Singstar do nagrania efektów dźwiękowych (siostra je używała do gry na PS3, teraz się kurzą, więc czemu by im nie nadać drugiego życia?).

Brzmi mało profesjonalnie, co nie? Pamiętajcie, gracze to nie audiofile, nie potrzebują wszędzie formatu *.flac ani idealnej jakości dźwięku. W takim razie możemy przystąpić do nagrań!

1. Wybuch
   Oryginalne nagranie (po prostu dmuchanie w mikrofon):
   
   Po drobnej edycji (m. in Paulstretch, zmiana tonu):
   
2. Strzał z shotguna
   Oryginał (zrobione ustami + przeładowanie):
   
   Po drobnej edycji:
   
3. Śmierć bohatera:Oryginał/po drobnej edycji:
   
4. Uderzenie w jednego z robotów ( pistolet na kulki + strzelanie w garnek )
   

Jak widać efekty dźwiękowe można samemu zrobić w domu. Wystarczy chcieć !

Muzyka. Muzykę w tle ogarnęli moi koledzy. Pozdrawiam Marcina Marszałka i Huberta Rzeszótko ;-). Jednak jeśli nie macie kogoś, kto by wam zrobił utwór muzyczny, to możecie skorzystać z opengameart.org . Tylko szukajcie dosyć „głęboko”, aby utwór nie powtarzał się często w innych grach. Efekt końcowy wygląda tak:

Czy to już koniec? Nie.

W planach mam dużo bardziej skomplikowane plansze, których stworzenie będzie teraz już dużo szybsze dzięki edytorze oraz dobrze napisanym kodzie programu, w którym łatwo dodawać i oskryptowywać plansze. Zamierzam dodać fabułę, zmienić styl na jeszcze bardziej arcade i stworzyć masę Easter Eggów i pobocznych misji . Oczywiście multiplayer (lokalny + sieciowy) też by się przydał.

Podsumowanie

Samemu da się stworzyć przyzwoitą grę. Jeżeli nie masz ekipy to nie jesteś od razu skazany na porażkę. Wyliczcie dobrze swoje umiejętności, nie twórzcie dużych projektów, które od razu są skazane na porażkę, gdyż znudzicie się podczas ich tworzenia. Lepiej jest robić coś mniejszego , ale równie dobrego – zawsze są to też jakieś projekty które na pewno przydadzą się wam w waszym portfolio. Często spotyka się ambitnych młodych programistów, którzy nie mają tak naprawdę żadnego projektu skończonego . Czasami trzeba się wziąć w garść i dokończyć jakiś projekt mimo, iż wam się nie chce. Jak to mówił św. Benedykt z Nursji: Ora et labora (łac. módl się i pracuj). Przecież w pracy też nie będziecie mogli sobie wymyślać. Dzięki małym projektom nauczycie się wiele, dopełnicie portfolio oraz zyskacie szansę na zarobek (bo czemu niby takiej gry nie wrzucić do serwisu Google Play lub Steam?).