Architektura społecznościowej gry przeglądarkowej multiplayer (backend choice + frontend choice [flash/silverlight]) [closed]

Question

Architektura społecznościowej gry przeglądarkowej multiplayer (backend choice + frontend choice [flash/silverlight]) [closed]

Zastanawiam się nad stworzeniem gry społecznościowej Online multiplayer. Wspólny stan świata wymagałby czegoś szybkiego na backendzie, więc potencjalne rozwiązania wydają się być:

Szybki silnik gry na serwerze (np. c++) oraz jakiś język frontend (php / python/ruby) + flash
Cały stos w Pythonie (przy użyciu twisted lub stackless python) + flash
. NET (asp.net lub asp.net mvc) + flash
. NET + silverlight

Pierwszy może być przesadą z punktu widzenia produktywności (3 warstwy heterogeniczne)

Nr. 4 może być niebem programisty (wspólne środowisko na wszystkich warstwach), ale:

pomimo, że model Flash movie/clip jest krytykowany w porównaniu z architekturą SL full oo czy nie jest to zaleta przy projektowaniu dodatkowych części wirtualnego świata przez zewnętrznych projektantów? Mogą się tylko przygotować .swf z np. 4 perspektywy elementu na 4 klatkach - czy nie byłoby trudniej z SL?

Co o tym myślisz?

[edytuj] sama gra byłaby częścią większego portalu - stąd dobrze byłoby zintegrować silnik z jakimś frameworkiem www.

4

.net silverlight python-stackless multiplayer

Author: Mike Pennington, 2009-03-12

Source

3 answers

Spędziłem rok pracując nad grą massively multiplayer online, używając Silverlight do frontendu i Pythona do backendu (w rzeczywistości użyłem IronPython w Silverlight, aby uprościć rozwój)

Silverlight bardzo dobrze się do tego nadaje, nie zrobiłbym poważnej gry online w niczym innym. Ma już 35% rynku, do czasu, gdy skończysz rozwijać powinien być wystarczająco wysoki, aby nie mieć już większego znaczenia. W przypadku poważnych gier większość ludzi naprawdę nie będzie miała nic przeciwko zainstalowaniu Wtyczka do przeglądarki 4MB. Jeśli chcesz tylko trochę asteroids klon, użyj lampy błyskowej.

Gdybym miał to zrobić, myślę, że zatrzymałbym Pythona na serwerze, ponieważ jest to technologia serwerowa, z którą jestem najbardziej wykwalifikowany, ale myślę, że użyłbym C# na frontendzie i użyłbym JSON do przesyłania danych.

Najlepsza rada jaką mogę ci dać to:

wykorzystuj istniejące biblioteki i kod w jak największym stopniu
nie myśl o wydajności przedwcześnie

Najtrudniejsza część to będzie kończenie gry, korzystać z technologii, które znasz dobrze, i optymalizacji na swój czas, a nie kod. Mam nadzieję, że możesz zrobić to, czego ja nie mogłem-skończyć cholerną grę:)

Edit

Odnośnie tego, dlaczego używałbym C#, gdybym musiał to zrobić jeszcze raz:

IronPython miał swoje wady i zalety. Świetnie, że mogłem udostępniać pliki kodu (stałe, modele, itp.) między serwerem i klientem. Dokonywanie zmian i odświeżanie przeglądarki, aby zobaczyć to było niesamowite. Debugowanie nie było jak przyjazny jak C#.

Ale w pewnym sensie jest to obywatel drugiej klasy do C#, wiązanie danych nie działa i nie można używać klas IronPython w xaml. Czas ładowania był problemem, więc naprawdę poświęciłem wiele wysiłku, aby skonfigurować importowanie równolegle na wątkach tła, aby przyspieszyć to. Ze względu na drugi status obywatela, w którym chodzi o xaml, użyłem języka szablonów do generowania xaml tak, jakby był to html, który faktycznie działał lepiej niż wiązanie danych, ale nie szablon Pythona języki pracowały w Ironpythonie, więc sam pisałem (innym razem.)

Aby umożliwić udostępnianie modeli musiałem napisać własny ORM. To było dość łatwe. Ale aby je przenieść przekazałem JSON i zrobiłem zoptymalizowany format binarny, który działał między IronPython i Python. To był kolejny zlew czasowy.

Z perspektywy czasu nie powinienem był rozpraszać się tymi wszystkimi śladami królików.

6

Author: Eloff,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-11 21:01:06

Twisted został użyty w tym celu z powodzeniem. Bazując na wywołaniach asynchronicznych, jest bardzo wydajny dla aplikacji wymagających trwałych połączeń. Ma również ładną implementację RTMP do użytku z Flashem. Sprawdź chesspark, jest zbudowany z Twisted:

Http://www.chesspark.com/

Poza tym silnik gry nie musi być w c / C++. Zależy od złożoności i rodzaju gry. Ale jest też biblioteka pygame, która jest ładna dobrze.

Osobiście zniechęcałbym Cię do używania silverlight. Wtyczka flash jest znacznie lepiej przyjęta i nadal będzie w przyszłości, szczególnie w systemach operacyjnych innych niż ms. Nie bierz tego do serca, ale nie zainstalowałbym silverlight tylko po to, żeby zobaczyć Twoją grę.

5

Author: Vasil,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-06-25 19:47:20

score 3 · Accepted Answer

Option 2 -- using stackless Python -- is what Eve Online uses.

Http://support.eve-online.com/Pages/KB/Article.aspx?id=128

Edit

Dopóki nie masz prawdziwego oprogramowania, oczywiście nie można stworzyć architektury, która będzie działać w miarę dobrze. Więc, każdy osąd tutaj jest tylko bezsensowną spekulacją.

Rozważ jednak, co następuje.

Zawartość statyczna (.Pliki js,css,png itp.) mają tendencję do dominowania swoich przepustowość sieci. Będziesz musiał użyć odwrotnego serwera proxy (np.
Squid musi skądś pobrać zawartość. Potrzebujesz lekkiego serwera plików dostarczającego statyczną zawartość do squid. Nginx albo lighttpd czy coś. Apache zadziała na to, ale do pewnego stopnia może to być przesada.
Twoja dynamiczna zawartość -- wygląda -- będzie w dwóch formach.
- JSON do obsługi gry.
- HTML do wesprzyj portal.
Do tego najszczęśliwszy byłby silnik mod_wsgi. Apache z pewnością to robi; ngingnx i lighttpd również mogą działać.
- Twoje rzeczy JSON powinny być jednym zestawem URI. reszta to dobry wzór. Poprzez mod_wsgi, łączą się one z serwerem zorientowanym na grę za pomocą -- jeśli to konieczne -- stackless Python. Twój front-end (na przykład Apache) ma lokalizację, katalog lub virtualhost, aby filtrować te URI i kierować je do mod_wsgi daemon, który służy do gry. Spójrz na Wekzeug Aby to zbudować.
- Twój HTML to kolejny zestaw URI. poprzez mod_wsgi łączą się one z serwerem Django z tradycyjnym Pythonem. Twój front-end (na przykład Apache) ma lokalizację, katalog lub virtualhost, aby filtrować te URI i kierować je do demona mod_wsgi.