Czy silnik ewentualnej gry internetowej powinien zacząć się jako usługa internetowa?

Niedawno postanowiłem napisać silnik do gry karcianej. Nie jestem wielkim graczem w karty, ale znajomy wprowadził mnie do gry (jest to gra duńska) i zakochałem się.

Chcę rozwinąć grę w 3 segmentach:

1. Podstawowy silnik, obsługuje karty / talie / gamestate itp.
2. Interfejs użytkownika (w formie aplikacji mobilnej / stacjonarnej).
3. Sztuczna inteligencja z różnymi strategiami / trudnościami itp.

Są to bardzo różne projekty, moim zdaniem ... i mam problem z tym, aby zobaczyć, jak wszystkie będą pasować do siebie na dłuższą metę. Na początku nie chcę nawet „grać” w grę za pomocą silnika. Silnik będzie testowany przede wszystkim przez testy jednostkowe. Testowanie gry nie rozpocznie się, dopóki nie będzie klienta. Jest więc coś w rodzaju relacji klient-serwer.

Silnik to bardzo duży element układanki. Chciałbym wiedzieć: jak poszedłbyś opracować „publiczny interfejs API” dla tego silnika?

Myślałem, że silnik może być bardzo podstawową usługą internetową, która zwraca swój stan poprzez zapytania do API RESTful, ale martwię się, że sam rozwój silnika jako aplikacji internetowej może prowadzić do złych decyzji programistycznych. (Na przykład, jeśli wybiorę mikroukład MVC, cóż, ten interfejs API nie miałby naprawdę widoków ... po prostu zwraca serializowane obiekty za pośrednictwem JSON lub coś w tym rodzaju. Czy używanie MVC do takich usług jest złe to?)

Innym moim pomysłem było to, że silnik byłby po prostu aplikacją na konsolę, a później napisałem jakiś mostek, aby przesyłać dane między nim a aplikacją internetową. (Most może naprawdę być wszystkim. Mam na myśli, że serwer sieciowy i silnik gry mogą pracować bezczynnie na serwerze IRC i udostępniać swój stan na kanałach.)

Jakie podejście byś podjął (rozwinął się jako usługa internetowa lub rozwinął się jako samodzielna aplikacja i pomost później) i dlaczego?

Dzięki, Robbie.

EDYCJA: Myślę, że należy to do rozwoju gier. Aby to wyjaśnić, napiszę silnik gry karcianej. Próbuję znaleźć najlepszy sposób na ujawnienie interfejsu API silnika, aby można go było w przyszłości zintegrować z klientem internetowym i klientem AI.

Nie miałem tu nawet konta, więc cześć :)

Trasa usługi internetowej jest prawdopodobnie najlepsza i najbardziej skalowalna.

Widzę też absolutnie ŻADNY problem z wykorzystaniem frameworka MVC do zwrócenia JSON (asp.net mvc jest w tym świetny). Jeśli kontrolery zwracają tylko JSON na początku, to jest w porządku, możesz przeprowadzić test jednostkowy bez żadnych widoków. Gdy będziesz gotowy dodać interfejs gry, możesz dodać widoki. Jeśli ich zwykły HTML / CSS lub Flash / Silverlight, nie ma to znaczenia, ponieważ, jak już powiedziałeś, masz już wbudowany silnik bazowy.

Nie jestem pewien, jak wyglądają twoje środowiska programistyczne lub hostingowe, ale nie przepełniłbym tego zbytnio. Prosty zestaw plików php zwracających JSON może być wszystkim, czego potrzebujesz. Nie jestem zaznajomiony z grą, którą budujesz, więc nie jestem pewien, jak skomplikowana będzie.

Moim zdaniem, jeśli jesteś początkującym w tworzeniu gier i sam to robisz, gorąco polecam, abyś dostał coś, co można zagrać jak najszybciej, ponieważ pomoże ci to zmotywować Cię do ukończenia gry i dopracowania jej do dobrego poziomu.

Widok to jednostka, która rejestruje się w modelu, aby otrzymywać powiadomienia o wystąpieniu zmian.

Jeśli Twój model znajduje się na serwerze WWW, masz problem, ponieważ HTTP nie implementuje jawnego sposobu, aby pozwolić serwerowi na rozpoczęcie komunikacji. Możesz poradzić sobie z tym za pomocą websocket, ale poświęcisz trochę swojego „RESTfulness” ... Myślę, że dobrym rozwiązaniem może być pozwolenie twojemu adresowi URL na identyfikację modelu i użycie serwera HTTP do wysyłania powiadomień o twoich widokach kiedy był potrzebny.

Powiedzmy, że masz uruchomioną grę

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

możesz użyć adresu URL

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

zmodyfikować model i

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

czekać na powiadomienia.

Powiadomienie zaczeka - przez pewien czas - na otrzymanie wiadomości od modelu: jeśli coś się stanie, wiadomość zostanie wysłana (jakie dane zostaną zmienione, jakie wydarzenie się wydarzy lub cokolwiek innego).

Klient może wykonać długie żądanie ajax do / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / powiadomić i zarejestrować wywołanie zwrotne powiadomienia, które zarówno zaktualizuje widok, jak i opublikuje następne żądanie powiadomienia.

Jeśli gry / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / powiadomią o przekroczeniu limitu czasu na kliencie, nowe żądanie zostanie wykonane, jeśli przekroczy limit czasu na serwerze, przydzielone zasoby zostaną zwolnione.

Możesz zbudować dość ogólny system powiadomień na serwerze i bibliotekę powiadomień na swoich klientach, dzięki czemu możesz zbudować spójny MVC na przezroczystej warstwie powiadomień.

Jeśli szukasz technologii, możesz rozważyć zbudowanie silnika gry na serwerze Couchdb. Couchdb to nierelacyjny RMS DBMS, który używa HTTP jako protokołu i JSON jako formatu dokumentu. Może także PUT i GET pliki binarne lub HTML jako załączniki, dzięki czemu możliwe jest napisanie pełnej aplikacji webowej przy użyciu tylko DBMS (couchApp).

Istnieje biblioteka javascript, która umożliwia między innymi reagowanie na aktualizacje bazy danych. CouchdbApp to po prostu baza danych, dzięki której można skopiować aplikację na inny serwer przez synchronizację: klienci mogą skopiować aplikację na swój lokalny serwer, a następnie odtwarzać ją w sieci LAN z kontem.