Archiwa autora: Hacah

Nie takie oczywiste modern C++ oraz ECSy, Job Systemy i inne rzeczowniki, czyli nowości w Unity 2018

5 Grudnia 2018 na Polygonie odbyły się 2 wykłady

Najpierw zaczęliśmy od Quizu przygotowanego przez @kazik12344

wystąpiły gry w mrocznych klimatach jak S.T.A.L.K.E.R oraz Darksiders, jak również wyróżniające się jaskrawymi kolorami jak the Crew.

Pierwszy z wykładów:

Nie takie oczywiste modern C++ by @Celeborth

Prelegent niezwykle szczegółowo opowiedział nam o nowościach w języku C++.
Porady, których udzielł nam wykładowca pomagają zapobiegać problemom takim jak wycieki pamięcie, oraz usprawniają pracę z danymi.

Podczas wykładu zostały wymienione wady języka jak potrzeba pisania dużej ilości kodu aby zrealizować swój pomysł, oraz zalety jak niskopoziomowość.

Całą prezentację znajdziecie pod tym linkiem!

Na PolygonHype

@OmumbOrOmbOngO oraz @Silent zaprezentowali swoją grę z Game Jamu Ludum Dare 43!

Drugi z wykładów:

ECSy, Job Systemy i inne rzeczowniki, czyli nowości w Unity 2018 by @Proboszcz777

Prelegent przedstawił nam wady standardowego zarządzania dostępnymi zasobami komputera w silniku Unity, między innymi brak wielowątkowości oraz bardzo słaba wydajność systemów cząsteczkowych. 

Następnie został przedstawiony sposób optymalizacji, który trzeba było stosować do tej pory. Omówiona została implementacja oraz zysk wydajności, jak również wpływ na zużycie zasobów w wbudowanym profilerze Unity.

Ostatecznie przeszliśmy do implementacji ECS w naszej scenie demonstracyjnej. Choć niektórym będzie ciężko się przestawić na nowy sposób programowania, wyniki były niesamowite. Osiągneliśmy 27-ktorny zysk wydajności w porównaniu do standardowej sceny.

Po wykładzie wszyscy poszliśmy na Piwo 🙂

@HACAH

GAME DEV FEST 7.4

28 Listopada na Polygonie odbyło się czwarte, już ostatnie spotkanie 7 edycji Game Dev Fest

Najpierw zaczęliśmy od Quizu przygotowanego przez @xyz

Wystąpiły bardzo humorystyczne gry, stawiające na kompletny chaos jak Saints Row 4 oraz wymuszające obmyślanie planu (oraz jego chaotycznej egzekucji) jak Styx: Master of shadows.

@Celeborth główny organizator GDF na Polygonie przypomniał wszystkim na czym polega ten specjalny czas na Polygonie. Jeśli ktoś byłby zainteresowany to odsyłam do wpisu z pierwszego spotkania GDF 7 Klik!

Harmonogram 7 edycji GDF

Harmonogram 7 edycji GDF

Plan czwartego spotkania:

  • Tomasz Winiarski – Jak być sprzątaczką storytellingu? Podstawy narzędzi narracyjnych.
  • Polygon Hype
  • Marta Ziółkowska – Czy przygodówki capią trupem?
  • PIWO

Jak być sprzątaczką storytellingu? Podstawy narzędzi narracyjnych by Tomasz Winiarski

Plan wykładu:

  • Co to są assety narracyjne.
  • Jak je generować.
  • Jak tworzyć narzędzia do ich obróbki.
  • Pyszne praktyki.

Co to jest asset narracyjny?

Building block z których składamy grę, np. mesh, dźwięki, informacje

Gracz wchodzi w interakcję z grą, na podstawie swoich decyzji, oraz jego decyzje zależą od interaktywności gry.

Pomiędzy tymi etapami występują informacje, to są właśnie assety narracyjne. wszystko co jesteśmy wstanie wykorystać do zmiany decyzji gracza, oraz jego interakcji z grą.

Trzeba jednak pamiętać że gra składa się w większości z elementów interaktywnych, nie z informacji. „You never an outbook a book, you never can outmovie a movie”.

Tworzenie narzędzia narracyjnego.

Etap 1

Zbierz wszystkie informacje jakie masz na designu gry i je posortuj

  • Koncept – Wiadomość którą chcesz przedstawić
  • Theme – kontekst dla głównej tematyki
  • Fantasy – główne motywacje target audience w konsumpcji historii
  • Corefantasy – główne założenia, zależne od naszego target audience

Etap 2

przefiltruj informacje z Etapu 1

  • informacja do przekazania (czy gracz dostaje informacje takie jakie chcemy)
  • uczucie do wywołania (czy gracz czuje to co chcemy żeby czuł)
  • eksplorowane pytanie lub teza (czy nie odbiegają od tematu, który chcemy przedstawić w naszej grze)
  • warunek tematyczny lub stylistyczny (czy pasuje to do naszego świata)

Następnie zostały wprowadzone pojęcia dużego i małego kwantyfikatora

duży kwantyfikator – wszystkie wątki dążą do tej samej informacji

mały kwantyfikator – conajmniej jeden asset wykorzystuje ta informację

Etap 3

zidentyfikuj możliwośc i ograniczenia mechanizne

jedyne co usłyszeliśmy w tej kwestii to „Powodzenia!”

Etap 4

Tworzymy epistemologię naszej gry, czyli w jaki sposób mechaniki opowiadają historię naszej gry

zostały wydzielone 2 typy

  • Ekspozycja bezpośrednia
    • Bezpośrednie przekazanie jakiejś informacji, np za pomocą dialogu postaci
  • Ekspozycja mechaniczna
    • tu za przykład zostało podane sterowanie w grze Brothers: a tale of two sons. każdy z braci jest sterowany jedną połówką kontrollera. Gdy umiera jeden z nich, ta część kontrollera jest „martwa”. 

Etap 5

porównaj etap 2 oraz 4

co mogę zrobić vs co chcę zrobić

pod uwagę warto brać

  • budżet
  • siły przerobowe / skill
  • ilość iteracji
  • target
  • marketing

Etap 6

przeskaluj filtry

jeśli nasza gra będzie podzielona należy zastanowić się co chemy opowiedzieć w danej części.

Etap 6.1

dokonaj ewaluacji

na podstawie informacji zawartych w danej części gry, druga osoba powinna zrozumieć co chemy przekazać.

Etap 7

Na podstawie obecnej zawartości zrób prototyp

Etap 8 

Chunking

  • każdy podmiot powinien jednoznacznie odpowiedać jakiejś akcji
  • każdy obiekt powinien mieć jednoznaczne właściwości
  • każdy aktor (NPC) powinien mieć jednoznacznie określone akcji

Etap 9

jeszcze raz sprawdź wszystko, zgodnie z swoimi filtrami (kwantyfikatorami)

Etap 10

analizuj i iteruj

  • czy małe kwantyfikatory otrzymały conajmniej 1 asset który się do nich odwołuje
  • czy wątki ostatecznie dążą do dużych kwantyfikatorów
  • czy założenia Theme-u zostały utrzymane
  • ile informacji przekazujesz ekspozycją mechanizną, a ile bezpośrednią
  • uzupełnij kwantyfiaktory
  • wyrzuc nieużywane albo słabe
  • Stwórz Proof of Concept dla ekspozycji mechanicznej
  • Stwórz scenariusze do testów

Dobre praktyki i protipy

  • Zawsze uważaj na scope
    • hajs
    • długośc iteracji
    • dostępność na zewnątrz
    • zdolność do prezentacji
    • skolowalność
  • Kill your Darlings (nie robicie dobrych narzędzi narracyjnych, robicie dobre gry)
  • Zawsze coś mówisz, nawet gdy nic nie mówisz
    • Ksiażka „Emotional design” Don Norman
  • Handshake z graczem
    • ty tworzysz graczowi świat/grę on za to zawiesi poczucie realizmu i skorzysta z tego świata
      • trzeba trzymac się okreslonych zasad, gracz w coś wierzy i nie powinniśmy łamać określonych zasad
    • Nie bądź głupi
      • traktuj tematy poważnie
        • nie wrzucaj broni z wojny w wietnami do gry o drugiej wojnie światowej
      • nie kłam
        • jeśli stabilizujesz jakąś zasadę, nie łam jej, jeśli jedna postać zawsze jest zła, to nie może nagle stać się dobra, gdyż zepsuje to immersję/narrację. Gracz musi mieć możliwość spodziewania się tak drastycznych zmian, musi dostać jakieś wskazówki, nawet jeśli za pierwszy razem ich nie zauważy
      • nie trzymaj głowy w pupie
        • toole tworzymy nie dla siebie, ale po to by zrobić dobrą grę
        • musimy współpracować z reszta zespołu
        • traktuj target poważnie
          • jeśli tworzysz grę dla 14 latków, nie wykorzystuj trudnych pojęć

Czy przygodówki capią trupem by Marta Ziółkowska

Jak wygladają przygodówki obecnie? Jak wyglądały kiedyś? Co jest złe? Co dobre? Co myślą o nich ludzie? Porównanie do innych gatunków.

Historia Przygodówek

  • 1972 – Collosal Cave – tekstówka
  • 1980 – Mystery House – pierwsza grafika (70 rysunków 2D)
  • 1980 – Adventure
  • 1984 – King Quest 1
  • 1986 – Labirynth
  • 1987 – Maniac Mansion – pierwszy point’n’click
  • 1990 – King Quest V – wprowadzenie akcji dla prawego przycisku myszy

Co poszło nie tak

  • Kiedyś przygodówki były demkiem technologicznym, świetnie zrealizowane, duży budżet, bardzo dopieszczone.
  • Spadek popularności 2D – nowe karty graficzne 3D
  • Komputery stają się bardziej przystępne – zmienia się publiczność gier, nie wszyscy są już „majsterkowiczami”
  • Ogromny sukces gry Myst (1993) – każdy chciał powtórzyć sukces, po serii nieudanych gier, wydawcy wstrzymali finansowanie dalszych gier przygodowych

co naprawdę poszło nie tak

wiki mówi – gra przygodowa to gra wideo w której gracz przyjmuje rolę protagonisty, w interaktywnej opowieści poprzez eksplorację i rozwiązywanie zagadek.

co mówią gracze

  • główną motywacją jest analiza
  • nikt nie powiedział że rozwiązywania zagadek samo w sobie stanowi ich zainteresowanie

Wniosek: ludzie mają traumę z powodu designu przygodówek z lat 90

Nowoczesne przygodówki mają problem w komunikacji z graczem

developerzy którzy kochali stare przygodówki kopiują zawarte w nich błędy

Złote zasady designu gier przygodowych

  • Końcowy cel gry musi być jasny dla gracza
    • nie ma nic gorszego niż kręcenie się w kółko gracza, który nie rozumie gry
    • Wszystkie sidequesty
      • powinny być zorzumiałe
      • powinny wynikać z celu głównego
      • nie powinny spowalniac progresji
  • Puzzle
    • Jasna przeszkoda: gracz wie dokładnie jakie wyzwanie się przed nim stawia
    • Jasna motywacja: po drugiej stronie daj graczowi coś czego bardzo pragnie
    • Odpowiedź na złe rozwiązania: gracz musi wiedzieć co robi źle
    • Nagroda za zbliżanie się do rozwiązania: daj graczowi poczuć satysfakcje
  • Jak urozmaicić quest
    • zadanie otwórz drzwi
    • za drzwiami niech będzie zagadkowa postać, aby gracz czuł się zmotywowany do otwarcie drzwi, oby odkryć kto to jest
    • daj w pokoju wskazówki dotyczące osoby za drzwiami
  • Rosnąca nagroda
    • gracz musi wiedzieć co osiąga i czuć satysfakcję
    • nagrody
      • nowe obszary na mapie
      • nowe postaci
      • postęp fabuły
  • Śmierć
    • niebiezpieczeństwo jest nieodłączną częścią dramaturgii
    • śmierć nie powinna być obligatoryjna
    • jeżeli gracz jest sprytny, spostrzegawczy, ostrożny – zawsze powinien mieć możliwośc przetrwać
    • śmierć nie powinna uczyć mechanik w grze – nie powinna uczyc czego nie robić w przyszłości
    • nie powinna karać gracza za nie zrozumiałość systemów
  • Zawieszenie niewiary
    • kiedy gracz hest tak wciągnięty w fabułę że zapomina o relanym świecie
    • główny cel designera
    • z rytmu wybijają
      • śmierć, podczas stanu immersji nagła śmierć kompletnie wybija, uświadamia że to tylko gra
      • zapisywanie gry, obawa, impulsywny save-scumming
        • nie powinieneś być w stanie robić coś tak głupiego że musisz natychmiast wczyta grę
      • frustracja, blokowanie się na jednym zadaniu
  • unikać odwrotnych puzzli
    • rozwiązanie pojawia się przed problemem, jest złe
    • jeżeli najpier pojawia sie porblem, umysł gracza zaczyna zastanawiać się nad rozwiązaniem
    • zapobiega to zbieraniu wszystkiego o gracz znajdzie na ziemi
  • unikać arbitralnych puzzli
    • nie narzucac swojego sposobu myślenia
    • unikać nie logicznych rozwiazań puzzli
    • rozwiązywanie problemów nigdy nie powinny być wykonywane metodą prób i błędów
    • puzzle i ich rozwiązania musza mieć sens
    • puzzle powinny miec wiele rozwiązań

Następnie Prelegenta poleciła nam kilka nowoczesnych przygodówek:

  • Dead Air
  • Night in the woods
  • Oxenfree
  • Firewatch
  • Lamplight city
  • Unavowed
  • Shardlight
  • What remains of Edith Finch
  • Life is Strange
  • Last Day of June

Po wykładzie wszyscy poszliśmy na Piwo 🙂

@HACAH

GAME DEV FEST 7.3

21 Listopada na Polygonie odbyło się trzecie spotkanie 7 edycji Game Dev Fest

Najpierw zaczęliśmy od Quizu przygotowanego przez @Pavko

Większość gier, które zostały wymienione na quizie pochodzi z tak zwanych „Starych dobrych czasów”. Są to „Sąsiedzi z piekła rodem”, „deluxe ski jump”, „GTA Vice City” oraz wiele innych…

@Celeborth główny organizator GDF na Polygonie przypomniał wszystkim na czym polega ten specjalny czas na Polygonie. Jeśli ktoś byłby zainteresowany to odsyłam do wpisu z pierwszego spotkania GDF 7 Klik!

Harmonogram 7 edycji GDF

Harmonogram 7 edycji GDF

Plan trzeciego spotkania:

  • Łukasz Miądowicz – Hyper-casual jako nowa kategoria oraz kilka rad od Tap Tap Games.
  • Polygon Hype
  • Michał Kłoś – Rendering w Polyengine
  • PIWO

Hyper-casual jako nowa kategoria oraz kilka rad od Tap Tap Games by Łukasz Miądowicz

Prelegent jest pracownikiem studia Tap Tap Games, wydziału Huuuge Games, zajmującego się grai z kategorii „Hyper-Casual”. Są to proste, szybki i zapewniające dużo rozrywki gry. Posiadają minimalistyczny design, skupiają się na jednej, maksymalnie dwóch mechanikach. Gry Hyper-Casual charakteryzują się sterowaniem za pomocą jednego palca, oraz bardzo krótkich sesjach, około 20-30 sekund „podczas jazdy autobusem”, nie powinny więc wymagać obrócenia urządzenia do pozycji poziomej! Powinny być „youtube-able” czyli zapewniające wystarczająco dużo ciekawostek, aby potencjalny youtuber z dużym zasięgiem się naszą grą zainteresował. Elementy interfejsu należy ograniczać do minimum, powinny być max 3 na ekranie: przycisk od pauzy/menu, progress bar, który wskazywał by graczowi że ten nie stoi w miejscu, oraz wskaźnik waluty, za którą gracz może wykupić permanentne perki, lub ją zakupić.

Ponad 2,5 miliarda ludzi gra w mobilne gry free to play, które można podzielić na kategorie:

hyper-casual | casual | midcore | hardcore

Wraz z przemieszczaniem się w stronę hardcore, rosną koszty uzyskania użytkownika, wydłuża się potencjalna żywotność gry, oraz zmniejsza się ruch organiczny (wpływ pozycjonowania w sklepie na ilość sprzedanych kopii). Zatem gry z omawianej kategorii mają bardzo niski koszt uzyskania użytkownika, około 0,5$, żywotność na poziomi poniżej kilku miesięcy, oraz ich sukces jest niesamowicie zależny od pozycjonowania w sklepie.

Stworzenie gry hyper-casual wymaga przejrzenia obecnego rynku gier moblinych, sprawdzenia co działa, a co nie, czym charakteryzują się topowe tytułu. Po uzyskaniu tych informacji możemy wprowadzić własną wariację do gameplay-u, zmienić mechanikę oraz szatę graficzną. Ważne jest aby zachować przy tym kontrolę jednym palcem. Tutorial do gry powinien praktycznie nie istnieć, musi zmieścić się w jednym, bardzo krótkim zdaniu, np. arcade-owa gra „Pong” miała napisane jedynie „odbij piłkę”.

Cykl produkcyjny gry polega na koncepcie, omówionym powyżej, pre-produkcji: stworzenia prototypu i zobaczenia czy daje dużo frajdy. Właściwej produkcji w której dokańczamy projekt. Soft launch, polegającego na wypuszczeniu gry do mniejszej liczby odbiorców aby dzięki zebranemu feedbackowi poprawić błędy. Wreszcie następuje właściwe premiera, oraz gra żyje własnym życiem.

Podczas cyklu produkcyjnego bardzo ważny jest deadline, nie powinniśmy robić projektu dłużej niż będzie on funkcjonował w sklepie. Należy więc wyrobić sobie sposób na zabijanie projektów, wyznaczeniu parametrów, które musi spełniać każda nasza produkcja i w przypadku gdy obecny projekt wychodzi poza wyznaczony czas, oraz nie spełnia naszych kryteriów, należy go zostawić.

Aktualizacje do gier hyper-casual zależą od aktywności graczy, jeśli projekt został już zapomniany, duża aktualizacja będzie gorszym rozwiązaniem niż wydanie zupełnie nowej gry, natomiast jeśli projekt cieszy się popularnością, należy wydłużyć jego żywotność zapewniając nowości dla graczy.

Reklamy naszej gry powinny skupiać się na zachęceniu użytkownika do natychmiastowego zainstalowania naszej gry, dobrymi miejscami na umieszczanie reklam są platformy Facebook, oraz Google.

Poznanym z doświadczenia prelegenta sposobem na określenie naszego sukcesu jest sprawdzenie statystyk, jaki % graczy wraca do gry po pierwszym dniu.
Jeśli następnego dnia wróci ponad 50% stworzyliśmy arcydzieło.
Jeśli 40% stworzyliśmy dobrą grę.
Jeśli 30% nasza gra jest przeciętna.
Jeśli 25% nasza gra wypadła bardzo średnio.
Jeśli poniżej 20% nasza gra jest słaba.

Pełna prezentacja dostarczona nam przez Prelegenta dostępna jest na naszym dysku google klik!

Na PolygonHype

@Mantis przedstawił swoją grę z jamu, którą zrobił w 4 godziny. Zupełnie przypadkiem była to gra Hyper-Casual, do której odwoływał się prelegent pierwszego wykładu

@Arputikos przedstawił swoją grę z jamu na „Filmówce”. Jest ona połączeniem wiedźmina oraz Left 4 Dead, polega na przechodzeniu między wymiarami i zabijaniu zombie / żołnierzy. Gra nosi Nazwę Hobbit Effect możecie ją znaleźć na itch.io.

Rendering w Polyengine by Michał Kłoś

  • Prelegent przedstawił nam czym jest polyengine
    • projekt open source
    • dostępny na github-ie
    • tworzony jest aby zdobyć doświadczenie
    • posiada własny coding guideline
      • napisany od zera
      • c++ 17
      • minimalne zależności
  • Jak wyglądał rozwój renderera.
    • jak renderować w 2 krokach
      • załaduj model biblioteką i narysuj go
      • napisz resztę
      • profit
    • oświetlenie PBR
    • cienie
    • Milestone-y
      • Slavic game jam 2017
      • Polyjam 2018
      • Slavic game jak 2018
      • Konik 2018
  • Jak działa renderer.
    • układ współrzędnych
      • right handed
      • oś pionowa to Y
    • backendy i platformy
      • SDL2 + OPENGL 4.3
      • platformy docelowe
        • win64
        • linux
        • support na maca się nie udał ze względu na brak opengl 4.3 na macu

Planowane jest wsparcie dla API Vulkan.

Po wykładzie wszyscy poszliśmy na Piwo 🙂

@HACAH

GAME DEV FEST 7.2

14 Listopada na Polygonie odbyło się drugie spotkanie 7 edycji Game Dev Fest

Najpierw zaczęliśmy od Quizu przygotowanego przez @b0dz1o

Wystąpiły gry, które wymuszają na nas ciągłą, przepełnioną adrenaliną, walkę o przetrwanie jak NieR: Automata, oraz tytuły dla tych, którzy wolą na spokojnie planować każdy krok, jak Banner Saga.

@Celeborth główny organizator GDF na Polygonie przypomniał wszystkim na czym polega ten specjalny czas na Polygonie. Jeśli ktoś byłby zainteresowany to odsyłam do wpisu z pierwszego spotkania GDF 7 Klik!

Harmonogram 7 edycji GDF

Harmonogram 7 edycji GDF

Plan drugiego spotkania:

  • Tom Grochowiak – Projektowanie Przegrywu
  • Polygon Hype
  • Tom Tomaszewski – Crunching Koalas – historia prawdziwa
  • PIWO

(nie mogłem nie wykorzystać okazji do podzielenia tak długiego wpisu na tomy)

-·=»‡«=·- 𝓣𝓸𝓶 𝓟𝓲𝓮𝓻𝔀𝓼𝔃𝔂 -·=»‡«=·-

Tom Grochowiak: Twórca indie i game designer z ponad 10 latami doświadczenia. Założyciel studia MoaCube. Autor Cinders, Solstice i Bonfire. Dał nam kilka porad jak projektować przegraną w grach.

Najpier została wprowadzona prosta definicja „failstate” – jest to moment w którym przegrywamy grę.

W wielu obecnych grach nie istnieją pojęcia „wygrana” oraz „przegrana”. Obecnie grę można przejść, ale ciężko przegrać np. w „Skyrim”. Obecnie gry skupiają się na progresji. Failstate w takich grach nie oznacza przegranej gry, a „jedynie” wyraźny brak postępu. Trzeba zwrócić uwagę na słowo klucz „wyraźny”, ze względy na to że np. w Red Dead Redemption 2, łowienie ryb jest brakiem progresji, nie jest failstatem. Utrata życia w Mario, polegająca na „zgubieniu” grzybka, który wyjdzie poza ekran również nie jest failstatem. Natomiast utrata bohatera w Darkest Dungeon już jest.

Failstate dzielimy na 2 typy

  • Kanoniczne (mające wpływ na narrację gry)
    • np. utrata żołnierza w X-COM ma wyraźne echo w historii danej sesji gry
  • Nie Kanoniczne
    • Śmierć bohatera w Uncharted, gra nie przyjmuje śmierci do wiadomości i cofa nas do momentu, w którym wszystko jeszcze da się zmienić.
    • Najlepszym przykładem jest seria Assasins Creed w której failstate jest jednoznacznie nazwany desynchronizacją z fabułą.
  • W każdej regule jest wyjątek
    • Dark Souls miesza oba typy failstate, śmierć bohatera jest wpisana w fabułę i gra stara zrobić się wszystko by gracz umarł „chociaż raz”, jednak pozwala „zebrać” stracony postęp, wymazując wpływ naszej śmierci na fabułę.

Implementacja failstate jest bardzo ważna. Kanoniczne są częścią historii i powinny się wydarzyć chociaż raz (w samouczku X-COM zmuszeni jesteśmy do utraty prawie całego oddziału). Nie kanoniczne dodają napięcia, jednak ich wydażenie przerywa historię i nie powinny się zdarzyć (Uncharted robi wszystko by gracz cięgle bał się śmierci, jedznocześnie starając się by nie była ona możliwa, zwiększając naszą odporność gdy nasze życie jest na wyczerpaniu, oraz zmuszając wrogów do strzelania niczym szturmowcy z Star Wars).

Failstate nie jest karą!!! Ma zachęcać gracza do grania dalej, w dawnych czasach, do wrzucenia do arcade-a kolejnej monety.

Jak zrobić zachęcający failstate?

  • Musimy dobrze go umiejscowić, zadać sobie pytanie czy w ogóle powinien występować? W grze Prelegenta, failstate był sekretnym poziomem, nagrodą dla sprytnych i wytrwałych.
  • Musimy zadbać o jego przejrzystość, failstate powinien mieć jasno określone zasady np. w mafii 3 w misji musimy uciec przed policją, ale nie możemy opuścić dzielnicy, w której się znajdujemy, o czym gra nas nie informuje. Dobrym przykładem przejrzystości jest ściemnianie ekranu w grach fps. Gracz zawsze musi wiedzieć czemu zginął, np. w Overwatch możemy obejrzeć powtórkę naszej śmierci.
  • Failstate musi być fair, gracz zawsze musi czuć że robi postęp, np. w Dark Souls, przeciwnicy atakują nas z zaskoczenia, ale idąc odzyskać dusze, już wiemy gdzie jest przeciwnik oraz będziemy wiedzieć że gra stosuje zabieg ataku z zaskoczenia.
  • Musimy ustalić cenę failstate, cofanie gracza do checkpointu lub zabieranie waluty to popularny sposób, należy jednak wiedzieć że gracz za każdym razem traci jedynie czas. Nigdy nie powinniśmy zabierać graczowi więcej jak 10 minut „farmowania”, gdyż zniechęci go to do dalszej rozgrywki. Polecaną przez Wykładowcę wartością jest 5 minut ze względu na to, iż będzie to odczuwalna strata, jednak nie na tyle by gracz natychmiastowo wyłączył grę.
  • Nie możemy dopuścić do występowania efektu „Downward Spiral” (Polecany przez prelegenta album zespołu Nine Inch Nails). Przykładem tego efektu jest X-COM: Doświadczony żołnierz umiera, inny spanikował, misja nie udana, kraj spanikował, kraj nie wypłaca pieniędzy, nie stać nas na ulepszenia, nie ulepszeni żołnierze umierają w starciu z coraz to silniejszymi przeciwnikami, powtórz aż gracz przegra ponieważ 20 godzin temu „rzut kostką” nie skończył się unikiem naszego żołnierza.
  • Aby temu przeciwdziałać należy doprowadzać do „Recovery Stories”, odbicia się od dna. Gracz musi mieć możliwość odzyskania straconego postępu w ostatnim momencie, np. w Shadow of Mordor/War możemy skontrować śmiertelny dla nas atak, lub w cywilizacji po oblężeniu, w którym stracimy 90% naszej armii, cudem zdobywamy miasto, uzyskując dostęp do zasobów, dzięki którym możemy sprawnie odbudować naszą armię.
  • Możemy wykorzystywać też „Rubber Banding”, poziom trudności skalujący się na podstawie prędkości postępu gracza, oraz jego umiejętności. W Dark Souls wracając po swoje dusze ulegamy recovery stories oraz rubber bandingowi, odzyskujemy swoje dusze, oraz zdobywamy nowe, bez problemu zabijając wrogów na swojej drodze, gdyż już wiem gdzie się znajdują.
  • W grach z gatunku rougelite, pomimo śmierci postaci zawsze osiągamy postęp, zdobywając permanentne ulepszenia dla każdej przyszłej postaci.
  • Możemy też rozważyć możliwość pominięcia fragmentów gry, które sprawiają graczowi trudność np. W L.A. Noire możemy pominąć pościg gdyż nie na nim polega główny gameplay i gracze nie posiadający odpowiednich umiejętności nie powinni tracić możliwości ukończenia gry.
  • Możemy również stosować absurdalną częstotliwość checkpointów, w Spider-Manie grając jako Mary Jane mamy checkpoint bo każdym zbirze, którego potrafimy uniknąć, sprawiając że gracz nie powtarza elementów, które udowodnił że potrafi wykonać.
  • W niektórych grach multiplayer możemy stosować szybki powrót do zabawy, w PUBG gracz może natychmiast przejść do innego meczu, podczas gdy w Overwatch czas potrzebny na odrodzenie oraz dojście do obecnego miejsca walk często zajmuje ponad minutę.
  • Powinniśmy unikać długich loadingów, wszystkie elementy techniczne również są game designem. W Bloodborne pierwotnie respawn zajmował niesamowicie dużo czasu, jednak po pierwszym patchu gra trzymała lokację w której nastąpi odrodzenie w pamięci operacyjnej, aby przenieść nas do niej natychmiast po śmierci.
  • Bayonetta pozwalała ćwiczyć sekwencje combo aby gracz nie wyszedł spod wpływu adrenaliny, i aby mógł ćwiczyć do zmierzenia się z momentem swojej śmierci jeszcze raz.
  • Należy unikać sytuacji, która promuje „Save Scumming”, unikać efektu domina, a polegać na recovery stories.

Na PolygonHype

@Dos oraz @Danon zaprezętowali swoje gry z Game-Jamu na „Filmówce”. Obydwie gry można znaleźć na stronie itch.io.

Gra @Dos o nazwie DYGNHP? (Do You Guys Not Have Phones ?), polega na wysyłaniu sms-ów przez użytkowników, oglądających akcję na wpsólnym ekranie (w naszym przypadku, projektorze). SMS-y bowiem są jedynym interfejsem służącym do sterowania. Obecnie ich wysyłanie jest silnie odradzane gdyż skończył się pakiet darmowych sms. Klik!

Gra @Danon o nazwie HateTube imituje interfejs YouTube, polega na naprzemienym „dis lajkowaniu” filmów „memów” wybranych wcześniej przez graczy. Sterowanie wymaga arcymitrzowskiej koordynacji ruchowej, gracze mogą bronić swoich filmów poprzez wypychanie kursora przeciwnika. Wygrywa gracz, który zbierze najmniej hate-u. Klik!

-·=»‡«=·- 𝓣𝓸𝓶 𝓓𝓻𝓾𝓰𝓲 -·=»‡«=·-

Tom Tomaszewski – Crunching Koalas historia prawdziwa „Przypowieść o Koalach”

Historia zaczyna się na przełomie lat 2009/2010, „Koali” jeszcze nie było, jedynie 3 osoby chcące coś zrobić. Najpierw wykonywali zlecenia polegające na stworzeniu stron internetowych, lub interaktywnej wycieczce po budynku. Szybko narodził się pomysł założenia własnej firmy, wykonywali prototypy własnych projektów oraz pierwsze zlecenia związane z grami np. urząd miasta Ustka zażyczył sobie grę o syrence. Korzystając z dotacji Prelegent uczęszczał na kursy „Jak prowadzić własną firmę”, jednak sama dotacja polegała na konkursie na najlepszy pomysł, który udało się wygrać za drugim podejściem.

W roku 2011 powstała firma „Shinra Games” przyjmująca kolejne zlecenia. Te lepiej wspominane jak „Neuroshima Apocalypse”, dzięki którym zdobyli doświadczenie o współpracy z klientem, gdyż dostawali feedback związany z swoją pracą. Były też bardziej przyziemne prace jak gra dla firmy „BYŚ” oraz „Żywiec Zdrój”. Wzięli udział w „konkursie na pomysł na grę”, w którym można było wygrać 5 tys złotych, to jednak się nie udało, ale natrafili na „Wydawcę”. Zaoferował budżet 100 tys złotych na stworzenie gry. Gra nosi tytuł „Crystal Tales” i jest klonem „Trine” wykonanym w unity3D (które w tamtych czasach sporo kosztowało). Prototyp gry powstał w październiku, z grafiką opartą na kostkach, miał on również spore problemy z optymalizacją, oraz z działaniem ogólnie (działał tylko na jednym komputerze, który trzeba było do „wydawcy” wozić). Resztę roku spędzili nad grą.

Nadszedł koniec świata, a przynajmniej w popkulturze, rok 2012, w którym zaczęło brakować środków na dalszą produkcję. „Wydawca” złożył propozycję, jednak była ona nie do przyjęcia. Zaoferowano by wraz z wydawcą pojechać na „gamescom” aby tam poszukać inwestora. Po powrocie do kraju (gamescom odbywa się w Niemczech) największym problemem był brak środków, którego skutki starano się minimalizować poprzez kartę kredytową. Założono nową firmę „Crunching Koalas”, która zaczynała z dwoma projektami: „MouseCraft” oraz „Worldtrap dungeon”.

Rok 2013 zaczął się od udostępnienia pre-alfy Worldtrap oraz alfy MouseCraft zawierającej 20 poziomów. Kolejna podróż na gamescom zaowocowała dużym zainteresowaniem MouseCraft, który spotkał się z dziwną sytuacją przy portowaniu na PS Vitę. Wydawca który chciał się owym portem zająć zażądał projektu unity, następnie przez 2 miesiące nie odezwał się ani słowem. Okazało się że bez zgody Koali natychmiastowo rozpoczęły się prace, które właśnie skończono. Projekt Worldtrap musiał zostać zawieszony. MouseCraft wygrał również Steam Greenlight, który wtedy oznaczał praktycznie darmową reklamę, gdyż na platformie Valve nie było jeszcze tak wielu premier.

Rok 2014 okazał się być ciężki dla zespołu, ze względu na pracę nad portem na PS Vita, oraz PS3 i PS4 które znowu zostały wykonane bez zgody Koali, oznaczało to jednak przesunięcie premiery. Kolejne przesunięcie nastąpiło ze względu na Steam Summer Sale. Członkowie zespołu oczekiwali jednak wydania gry już dawno temu, nie mogąc znieść kolejnych przesunięć daty premiery, postanowili odejść. Sama premiera spotkała się z bardzo pozytywnymi recenzjami, które jednak nie miały odzwierciedlenia w sprzedaży.

Rok 2015 polegał głównie na marketingu MouseCraft, prób sprzedania go na Humble Bundle, PS Plus, Indie Piñata oraz Indie Box.

W roku 2016 zapadła decyzja by na pół roku wstrzymać pracę w studiu, pozostali członkowie zespołu poszli do pracy w 11 Bit Studios oraz Fat Dog Games. Po powrocie nastąpiła zmiana kierunku, rozpoczęto prace nad „Sky Force” oraz „Lichtspeer”.

Lata 2017 oraz 2018 polegały na zleceniach nad grami takimi jak: „Butcher”, „Regalia: Of Men and Monarchs”, „My Memory of Us” oraz na wzmożonej współpracy z 11 Bit.

Po wykładzie wszyscy poszliśmy na Piwo 🙂

@HACAH

GAME DEV FEST 7

7 Listopada na Polygonie zaczął się Game Dev Fest

Najpierw zaczęliśmy od Quizu przygotowanego przez @Asteriks

Wystąpiły znane gry AAA, o których obecnie głośno jak Red Dead Redemption (dokładnie dodatek do gry „Undead Nightmare”), oraz ukryte skarby Indie jak West of Loathing.

Oficjalnie rozpoczęła się 7 edycja Game Dev Fest organizowanego przez Polygon.

Są to spotkania z weteranami branży Game Dev, którzy chcą się podzielić zdobytym w pracy doświadczeniem, oraz opowiedzieć fascynujące historie z Ich życia. Głównym organizatorem Game Dev Fest jest @Celeborth, jego zastępcą jest @Koxen.

Harmonogram 7 edycji GDF

Harmonogram 7 edycji GDF

Więcej informacji na temat wykładów i linki do wydarzeń na Facebook-u znajdziecie na stronie Klik!. Wszystkie wykłady, na których nagrywanie pozwolił prelegent, będą udostępnione na naszym kanale na YouTube.

Plan pierwszego spotkania:

  • Łukasz Śpierewka – Golf Peaks od Kuchni
  • Polygon Hype
  • Tadeusz Zieliński – Emergent Storytelling
  • PIWO

Golf Peak od Kuchni by Łukasz Śpierewka

Prowadzący wykład pracował wcześniej w

  • Super Hot
  • Wastelands Interactive
  • CD Projekt Red

Następnie założył własną firmę Afterburn

Plan wykładu

  1. Historia Golf Peaks
  2. Projekt
  3. Prowadzenie Firmy
  4. ???

1 oraz 2 – Historia Golf Peaks oraz projekt gry

Pierwotny projekt był prosty: golfowa gra podzielona na kwadraty z mechaniką kart, styl wizualny wzorowany na „Hidden Folks” oraz „Monument Valley”.

Prelegent Przedstawił błędy w Interfejsu użytkownika, Interakcji i Gameplay-u. Następnie stwierdził że jeśli my jako twórcy gier przyzwyczailiśmy się do sposobu interakcji z grą to nie znaczy że jest to najlepsze rozwiązanie. Dużo pomagają testy przeprowadzane przez ludzi nie związanych z produkcją gry.

Wykładowca przedstawił najnowsze demo swojej gry w silniku Unity. Zaprojektował i wykonał własne edytory w unity, służące do tworzenia poziomów oraz zarządzania nimi.

Do tłumaczenia treści wszystkich opcji w Menu wykorzystany został asset „simple loalization”, oraz dysk google, jak również znajomość języków pośród członków community zainteresowanego produkcją gry na Discordzie.

3. Podpowiedzi do prowadzenia firmy

  • ZAWSZE PODPISUJCIE UMOWY.
  • Komunikacja wewnętrzna w firmie jest bardzo istotna.
  • Discord – świetne narzędzie do komunikacji z testerami i resztą załogi, można znaleźć darmowych tłumaczy.
  • Współpraca – outsource. Szczególnie przydatne w współpracy z dźwiękowcami.
  • Ostatnie 10% zajmuje 90% czasu pracy.
  • Na targi nie jedzie się sprzedać grę, a po to by nawiązać kontakt z wydawcami oraz zebrać feedback.
  • Na targi należy jeździć w kilka osób, jedna to po prostu za mało by wszystko ogarnąć.
  • Sklepy pochłaniają bardzo dużo czasu.
  • Marketing również zabiera bardzo dużo czasu.
  • Nie bójcie się wyrzucać rzeczy do kosza jak nie działają.
  • Prace nad grą zajmą wam dłużej niż myślicie.
  • Społeczność fanów bardzo pomaga w niektórych aspektach.
  • Zakładajcie że wasza gra sprzeda 0 kopii – nie bierzcie kredytów.

4. Następnie był czas na zadawanie Prelegentowi pytań.

Na PolygonHype

@mantis pochwalił się swoją grą „Roarrr!” właśnie wydaną na Nintendo Switch-a Klik!

Emergent Storytelling czyli jak opowiadać historię bez scenariusza by Tadeusz

Zieliński

Każdy z nas ma swój „Battlefield Moment”, doświadczenie które pisze się same dzięki gameplayowi, nie jest oskrypytowane lub wymyślone przez twórców gry. Emergent Storytelling polega właśnie na takich momentach.

Emergent gameplay – [ang] wyłaniający się.

Zdarzenia powinny być:

  • Proste
  • Wpływać na gracza
  • Przypadkowe
  • Mechaniki mogą być proceduralne

typy Emergent Gameplay

  • AI Based
    • AI Director z left 4 dead.
    • Rim World – AI director wrzuca zestaw eventów graczowi.
    • każda rozgrywka jest unikalna.
    • akcje gracza wpływają na działania SI.
    • SI wpływa na mechaniki.
    • SI tworzy gotowe scenariusze.
    • To bardzo unikalne rozwiązanie pojawia się świadomie w niewielu tytułach.
  • Proceduralny
    • gry mocno oparte o systemu proceduralne.
    • częste przypadkowe interakcje.
    • słabo zarysowane story.
    • liczne zadania poboczne.
    • Sid (autor civ) bardzo często wykorzystuje ten system.
  • Human Generated
    • najlepiej współpracuje z pvp.
    • Sea of Thieves i Rust.

Niezwykle haryzmatyczny prelegent przez większość wykładu opowiadał nam o swoich historiach z wspomnianych wcześniej gier (Oczywiście nawiązując do tematu). Twitch

Po wykładzie wszyscy poszliśmy na Piwo 🙂

@HACAH