Autor Wątek: Wykład o programowaniu funkcyjnym gier  (Przeczytany 1623 razy)

Offline ekhart

  • Użytkownik
    • ekhart.pl

  • +2
# Kwiecień 25, 2017, 12:28:20
Zapraszam wszystkich zainteresowanych z Warszawy w środę wieczorem na swój wykład na KNTG Polygon

"Arkadia Unity, czyli jak programowanie funkcyjne może naprawdę zbawić Twoją grę"
Gdzie znajduje się mityczna kraina Arkadii programistów gier?
I co ma wspólnego z programowaniem funkcyjnym? Czym różni się ono od obiektowego? W czym jest lepsze? Jak można wykorzystać jego moc w Unity? W czym tkwi siła Lispa i jego dialektu Clojure?
Prezentacja eksperymentu dla wszystkich programistów, którzy chcieliby wynieść swój warsztat na wyższy poziom

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Kwiecień 26, 2017, 17:39:09
brzmi interesująco, będą z tego jakieś materiały?

Offline ekhart

  • Użytkownik
    • ekhart.pl

  • +1
# Kwiecień 26, 2017, 17:53:41
Postaram się przygotować nagranie we własnym zakresie i potem je udostępnić. Popełnię też pewnie jakiś post z resztą detali potem na swoim blogu ;)

Offline ekhart

  • Użytkownik
    • ekhart.pl

# Kwiecień 29, 2017, 20:30:32
Zapraszam zainteresowanych do obejrzenia nagrania z prezentacji
Live functional game programming in Unity using Arcadia with Clojure

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Maj 03, 2017, 22:46:10
No ciekawe tylko czy zysk czasowy wynikający z braku potrzeby restartowania projektu nie jest niwelowany 'nieprzyjaznością' lispa w porównaniu z c#?
Miałem z nim niedawno niewielki kontakt przy okazji skryptowania Autocada i to była jakaś masakra :P

Offline ekhart

  • Użytkownik
    • ekhart.pl

# Maj 04, 2017, 14:44:54
Nieprzyjazność? Zapewniam Cię, iż język sam w sobie jest prosty, a nawet i prostszy niż Python. W końcu był uczony w ramach kursu wprowadzającego do programownia na MIT (Structure and Interpretation of Computer Programs).
Jasne, notacja polska może na początku wydawać się obca, ale to kwestia chwili do przyzwyczajenia. Potem nawet nie będziesz na to zwracać uwagi.
Ponadto sam (ponad 50 letni) język udostępnia moc wyrazu (przez system makr) znacznie przewyższającą nawet aktualne języki (które w dużej mierze czerpały większość feature'ów właśnie z Lispa).
Nie wiem czy masz doświadczenie z live codingiem, ale zapewniam, że takie skrócenie feedback loop zwiększa efektywność pracy wielokrotnie, a w związku z tym bardzo, ale to bardzo, uprzyjemnia pracę. ;)
I na koniec - świetnie się go nauczyć, tylko po to, żeby stać się lepszymi w swoim fachu.

Offline koirat

  • Użytkownik

# Maj 05, 2017, 00:37:34
Problem z odwrotną notacją jest taki że w "normalnym świecie" większość równań jest tworzona i zapisywana za pomocą notacji infiksowej w związku z czym jest ciężej odnaleźć potencjalne błędy i łatwiej pomylić się przy przepisywaniu (wiem że można użyć converterów - ale to ciągle pewna niedogodność).

Zastanawiając się przez chwilkę jakiego rodzaju problemy sprawiają mi najwięcej trudności i zajmują najwięcej czasu dochodzę do wniosku iż są to sytuacje zdarzające się w sposób losowy albo w pewnym stanie do którego da się doprowadzić grę pewnymi krokami.
Więc w sumie to i tak muszę zrestartować grę aby wyłapać moment w którym ten problematyczny stan zostaje utoworzony, zazwyczaj jak już zostanie utworzony to i tak jest już za późno na jakiekolwiek działania.

Jak już jesteśmy przy stanach gry, pytanie jest następujące: Czy nie jest ryzykownym nie resetowanie w momencie kiedy nasza gra osiągneła niechciany stan i pomimo tego staramy się go zmieniać za pomocą nowego kodu operującego na tym nieporządanym stanie.

Offline ekhart

  • Użytkownik
    • ekhart.pl

# Maj 05, 2017, 17:56:50
TL;DR;
live functional programming daje nam wiele, nie od razu oczywistych, benefitów przyspieszając i zwiększając jakość naszej pracy!

Problem z odwrotną notacją jest taki że w "normalnym świecie" większość równań jest tworzona i zapisywana za pomocą notacji infiksowej w związku z czym jest ciężej odnaleźć potencjalne błędy i łatwiej pomylić się przy przepisywaniu (wiem że można użyć converterów - ale to ciągle pewna niedogodność).
Notacja odwrotna jest jednoznaczna. Infiksowa nie zawsze. Np.
6/2(2 + 1) = ?
(/ 6 (* 2 (+ 1 2))) = ?
Przy odwrotnej nawiasy jasno wskazują kolejność działań. Przy infiksowej nie jest to explicite.
Ale fakt, faktem - jest popularniejsza. Ale czy lepsza? ;> (-> nie wszystko co popularne jest lepsze)

sytuacje zdarzające się w sposób losowy albo w pewnym stanie do którego da się doprowadzić grę pewnymi krokami
Nieprzewidziany i nieobsłużony zmienny stan jest źródłem większości błędów. Programowanie funkcyjne przez by default immutable data minimalizuje zmiany stanu, przez co minimalizujemy źródła błędów. Oczywiście, możemy wymusić zmienność danych. Ale dzięki takiemu podejściu dwa razy zastanowimy się, czy nie da się być może zrobić tego inaczej, bez side effectów? A jeśli już to daje nam to jasny wgląd w miejsca, gdzie może czaić się w przyszłości błąd.

Czy nie jest ryzykownym nie resetowanie w momencie kiedy nasza gra osiągneła niechciany stan i pomimo tego staramy się go zmieniać za pomocą nowego kodu operującego na tym nieporządanym stanie
Wg mnie osiągnięcie niechcianego stanu jest najlepszym stanem. ;) W takim przypadku najlepszą odpowiedzą jest zapisać implementację ten stan obsługujący - czy to przez zgłoszenie błędu wyżej i jego obsługę, albo być może zapisanie lepszego kontraktu funkcji, testów TDD.
W ten sposób przecież naprawiamy błędy. A pamiętajmy, że im wcześniej znaleziony błąd, tym tańszy (bo na pewno mniej nas kosztować będzie błąd znaleziony podczas implementacji, niż ten znaleziony przez naszych "rozwścieczonych" nim graczy).
Wg mnie sam błąd jest źródłem problemów. Tylko brak jego obsługi, brak reakcji na nieprzewidywany stan. To jest problem.