Jak pozwalasz na pisanie kodu sieciowego na późniejszych etapach rozwoju?

Obecnie jestem na wczesnym etapie pisania gry, którą w końcu będę chciał poprawić w większości aspektów.
Jak mogę pominąć pisanie kodu sieciowego, pozostawiając go jednak dość łatwo zaimplementowanym, to znaczy, że nie muszę przepisywać całej gry tylko po to, aby ją dodać.
O czym muszę pamiętać?

Mam wzór komponentu, w którym oddzielam od siebie fizykę / wykrywanie kolizji, logikę gry, typy danych oraz animację / rendering.
Jak napisać klienta i serwer, który nie ma jeszcze zaimplementowanego kodu sieciowego, ale można go przetestować lokalnie?
Co powinienem zrobić na kliencie i co na serwerze? Czy powinienem po prostu udawać, że mam gotowy kod sieci i wysyłać wiadomości między serwerem a klientem i kontem za opóźnienia itp., Nawet jeśli ich nie będzie?

Edycja: Planowane jest odgórne RPG. Myślę o prostym trybie wieloosobowym, w którym hostujesz serwer dla swoich przyjaciół, więc oszukiwanie nie jest tak dużym problemem (kto chciałby grać z oszukującymi przyjaciółmi?). Nadal chciałbym zastosować podejście „Serwer zawsze ma rację”.

Edycja 2: Chyba szukam wskazówek na temat tego, jak powinien wyglądać mój umysł. Jak powinienem obsługiwać wprowadzanie z klawiatury, animację itp. Zamiast natychmiastowego stosowania każdego efektu / zmiany. Hmmm, być może będę musiał poprawnie przeczytać o sieci, zanim w ogóle pójdę gdziekolwiek, i od tego chciałem uciec, tworząc szkielet sieci, który mógłby działać lokalnie.

Nie wiedząc więcej o konkretnej grze, którą piszesz, i o tym, jak piszesz, bardzo trudno jest podać ogólne rozwiązania swojego problemu.

Możesz jednak rozważyć tę decyzję dotyczącą pozostawienia kodu sieciowego do końca, w zależności od tego, jak ważne dla Twojej gry jest tworzenie sieci.

Mam na myśli to, że jeśli piszesz ciężką grę sieciową, taką jak MMORPG, pozostawienie sieci do końca może nie być rozsądne.

Biorąc to pod uwagę, jeśli oczekiwany wpływ kodu sieciowego jest niewielki (jak w przypadku braku kodu sieciowego wcale nie jest przełomowy), może być właściwe pozostawienie go na późniejszym (ale nie za późnym) etapie.

Pamiętaj, że -writing- kod sieciowy to nie to samo co -myślenie- o tym. Podejmując decyzje o tym, jak twoja jest gra, powinieneś rozważyć, w jaki sposób wpłynie to na decyzje dotyczące sieci, a jeśli oczekiwany wpływ jest wysoki, być może zaimplementuj go jako kod źródłowy, który zawiera pewne ogólne informacje, a następnie, kiedy nadejdzie czas na napisanie sieci kod, to tylko kwestia włożenia go tam, gdzie zostawiłeś kod pośredniczący.

Na przykład, jeśli tworzysz szachową grę online, możesz mieć wywoływaną funkcję, ExecuteMove()która jest wywoływana w pewien sposób, gdy ruch jest wprowadzany myszą, a w inny sposób, gdy ruch jest wprowadzany za pomocą klawiatury. W tym momencie możesz pomyśleć o utworzeniu kodu pośredniczącego, który po uzyskaniu wymaganych danych z drugiego hosta (tak piszesz w dalszej części), wywołuje ExecuteMove().

W ten sposób, tworząc grę, będziesz wiedział, na które części wpływa kod sieci, a kiedy nadejdzie czas, aby napisać kod sieci, masz kilka kroków do przodu.

Jeśli piszesz grę sieciową po raz pierwszy, zastanów się nad tym, by nie myśleć zbyt dużo o przeciwdziałaniu oszustwom itp. Tworzenie gry sieciowej jest na tyle skomplikowane, że wymaga tego cały zespół wysoce doświadczonych ludzi, aby zrobić to w grze AAA, więc spowolnij ją i najpierw stwórz grę, która działa, zanim skupisz się na bardziej złożonych tematach.

Wreszcie, jeśli tworzysz grę po raz pierwszy, nie łącz jej w sieć, proszę. Tworzenie gry jest tak skomplikowane, że każde wymaganie, które dodasz do gry, uczyni ją wykładniczo bardziej złożoną.

Jestem w podobnej sytuacji, ale staram się przeprowadzić symulację sieciową bardziej niż grę; ale myślę, że moje podejście może pomóc w procesie projektowania.

Moje podejście jest zgodne z komentarzem na temat IPC (komunikacja międzyprocesowa).

Najpierw w tle studiuję książkę „Grafika w sieci” Steeda i Oliveiry. Zapewnia to dobre tło dla różnych architektur sieciowych gier w zależności od różnych kryteriów i typów gier. Zapewnia narzędzie, które pomoże ci zdecydować o architekturze gry i tym, co dokładnie chcesz umieścić w sieci oraz co chcesz zrobić lokalnie.

Po drugie, rozdziel elementy sieciowe na osobny wątek w tle, aby początkowy rozwój gry mógł mieć lokalny kod zakodowany, ale musisz poradzić sobie z rozdzielaniem wątków. Nie łącz ich z żadnymi innymi funkcjami, które później będą „lokalnym tłem”, ale zmuszaj je do tworzenia „potencjalnie odległych” wątków w tle.

Powinno to pomóc w oddzieleniu logiki, a także umożliwić symulację czynników opóźniających sieć w procesie, dzięki czemu można również zobaczyć wpływ opóźnienia.

Jeśli uczysz się o tych wszystkich rzeczach, dlaczego nie napisać prostej wersji dla jednego gracza w wersji 1, a kiedy to zadziała, przy głębszej wiedzy, przemyśl wszystko do końca dla wersji 2, która będzie przeznaczona dla wielu graczy?

Zaimplementuj klasę „fałszywej sieci”, która przekazuje wiadomości między wątkami, która ma ten sam interfejs, co klasa sieci. Później możesz opracować fałszywą sieć, która ma losowe opóźnienia i utratę pakietów. Zawsze łatwiej będzie debugować kod sieciowy z fałszywą klasą niż z prawdziwą siecią.