Duszki jako aktorzy

Nie mam doświadczenia w kwestiach związanych z tworzeniem gier, ale jako programista. W języku Scala możesz mieć skalowalne wielozadaniowość z aktorami, bardzo stabilną, jak słyszę. Możesz nawet uruchomić setki tysięcy z nich bez problemu.

Pomyślałem więc, że możesz użyć ich jako klasy podstawowej dla duszków 2D, aby wyrwać się z pętli gry, która wymaga przejścia przez wszystkie duszki i przeniesienia ich. Zasadniczo poruszaliby się sami, sterowani zdarzeniami.

Czy miałoby to sens w przypadku gry? Mając tak wielozadaniowość? W końcu będzie działał na JVM, choć w dzisiejszych czasach nie powinno to stanowić większego problemu.

EDYTOWAĆ:

Po dłuższej pogawędce zauważyłem, że ten pomysł ma tylko jedną prawdziwą zaletę: obsługa wielu rdzeni. Prosta pętla gry będzie działać tylko na jednym rdzeniu i będzie działać przez wszystko sekwencyjnie.

Ponieważ współczesne komputery, nawet w domu, mają obecnie wbudowane dwa lub więcej rdzeni, myślę, że dobrym pomysłem jest umożliwienie programistom gier efektywnego korzystania z innych rdzeni. W końcu myślę, że zwykle gracz będzie miał tylko grę uruchomioną na swoim ośmiordzeniowym komputerze, więc czemu nie.

Inną zaletą, którą widzę, jest to, że w Scali możesz mieć RemoteActors, który można traktować w ten sam sposób, ale uruchomić na innym komputerze. Może to może uprościć również gry sieciowe.

Zamierzam to jak najszybciej wbudować w mój silnik Scala 2D.

Nie próbowałem, ale jestem programistą Scala i powiedziałbym, że to nie jest najlepsze podejście. Duszki muszą być animowane synchronicznie. Aktorzy nie mają gwarancji, że zostaną one wykonane sprawiedliwie - niektóre duszki mogą być szybsze od innych, co nie jest tym, czego chcesz. Możesz użyć bariery do ich synchronizacji, ale potem - po co używać aktorów. Jeśli polegasz tylko na przekazywaniu wiadomości, wdrożenie tego rodzaju synchronizacji (wdrożenie bariery dla ponad 1000 aktorów) jest przesadą.

Kolejnym problemem jest - do czego używałbyś przekazywania wiadomości? Czy potrzebujesz swoich duszków do komunikacji? Możesz wysłać wiadomość od głównego aktora, informującą każdego duszka, aby przejść do następnej klatki, ale pod względem wydajności jest to o wiele więcej niż bezpośrednie wywoływanie metod i iterowanie przez zestaw duszek.

Wydaje mi się, że to, czego tu potrzebujesz, to bardzo lekka wielozadaniowość i żadna wiadomość nie jest przekazywana. Wdrożenie własnej implementacji przypominającej aktora, która zapewnia uczciwość, jest prawdopodobnie najlepszą drogą, jeśli chcesz to zapewnić, ale to za dużo pracy dla zbyt małego zysku. Kolejną rzeczą, na którą należy zwrócić uwagę, jest funkcjonalne programowanie reaktywne i scala.reactuważam, że lepiej pasuje do tego przypadku użycia.

W Scali zaimplementowałem izometryczny silnik gry 2d. Użyłem tylko 1 aktora globalnego, aby zaktualizować widoczne duszki, które były animowane.

Możesz zaimplementować logikę gry za pomocą aktorów - na przykład, aby rozpowszechniać obliczenia na różnych częściach mapy gry wśród różnych aktorów, aby równolegle aktualizowali stan gry - i uzyskać wzrost wydajności. Nie użyłbym jednego aktora na obiekt gry, a raczej aktora na region. Jeśli pójdziesz zbyt drobnoziarnisty, wydajność spadnie.

Mimo to, gdybym był tobą, spróbowałbym tego, aby zobaczyć, co się stanie.

Pomyślałem więc, że możesz użyć ich jako klasy podstawowej dla duszków 2D, aby wyrwać się z pętli gry, która wymaga przejścia przez wszystkie duszki i przeniesienia ich. Zasadniczo poruszaliby się sami, sterowani zdarzeniami.

Jakie wydarzenie je poruszy?

Czy byłoby to wydarzenie emitowane raz na klatkę?

A jeśli tak, to jak to zmieniło system w praktyczny sposób?

Kiedy początkowo badałem orientację obiektową w kontekście C ++, dowiedziałem się, że niektórzy lubili myśleć o stwierdzeniu takim jak xyz.doThis(x)„wyślij wiadomość doT do tej wiadomości xyz (z ładunkiem x) i czekaj na natychmiastową odpowiedź”. Patrząc na tym poziomie, nie ma istotnej różnicy między systemem opartym na zdarzeniu lub komunikacie a normalnym systemem proceduralnym.

To fajne podejście do myślenia o aktualizowaniu obiektów w grze. Nie znam Scali, ale mówię, daj jej szansę i zobacz, jak to się potoczy, a jeszcze lepiej opublikuj swoje wyniki!

Główne pytania, które przychodzą mi do głowy, to: Jak zarządzasz częstotliwością aktualizowania niektórych obiektów gry w porównaniu do innych? Czy będziesz musiał się martwić, że aktorzy spriterzy podejmą zbyt wiele cykli, tak że system renderujący nie będzie miał czasu rysować ramki co 1/60 | 30 | 24 sekundy?

Inną rzeczą do rozważenia jest to, jak wpłynie to na rozdzielczość interakcji gracza z AI, które zależą od kolejności sekwencji bardzo szybkich zdarzeń. W zależności od rodzaju gry może to nie mieć większego znaczenia.

Cóż, nie jestem też zbytnio programistą, ale nie widzę żadnego problemu w twojej propozycji. Nawet nie myślałem o takim sposobie rozwijania aktorów.

Może to być nie lada wyzwanie, ponieważ ocena skutków musi być bardzo dokładna, aby uniknąć nieoczekiwanego zachowania, ale poza tym widzę, że jest to całkiem dobra propozycja

Jeśli przez duszka masz na myśli byt gry, to na pewno.

Podmioty z gry nigdy nie powinny się rysować. Powinny zaktualizować uchwyt graficzny, który opisuje, gdzie i jak należy je narysować. System renderowania lub wykres sceny lub cokolwiek robi rzeczywisty rysunek. Jest jedna karta graficzna, ponadto karta graficzna musi być synchronizowana co 16 ms. Taka konfiguracja po prostu nie działa dobrze w przypadku rozproszonego przetwarzania asynchronicznego.

System renderowania powinien być jednym aktorem (lub być może parą, jeśli jesteś podstępny). Gdy podmioty gry aktualizują uchwyt grafiki, wysyła wiadomości do systemu renderowania. System renderowania może podejmować wszelkiego rodzaju decyzje i / lub optymalizować, np. Renderowanie partii, okluzja, wygładzanie jittera fizyki itp.

Nie jestem programistą Scala, ale sporo zrobiłem z Erlangiem. Więc jeśli część mojej terminologii Scala jest niepoprawna, proszę wybacz mi.