Koduję swoją grę za pomocą modelu klient-serwer. Podczas gry w trybie dla jednego gracza gra uruchamia lokalny serwer i współpracuje z nim tak samo, jak zdalny serwer (multiplayer). Zrobiłem to, aby uniknąć kodowania oddzielnego kodu dla jednego gracza i dla wielu graczy.
Właśnie zacząłem kodować i napotkałem poważny problem. Obecnie rozwijam grę w Eclipse, mając wszystkie klasy gier zorganizowane w pakiety. Następnie w kodzie serwera po prostu używam wszystkich klas w pakietach klienckich.
Problem polega na tym, że te klasy klienta mają zmienne specyficzne dla renderowania, które oczywiście nie byłyby wykonywane na serwerze.
Czy powinienem utworzyć zmodyfikowane wersje klas klienta do użycia na serwerze? Czy powinienem po prostu zmodyfikować klasy klienta za pomocą wartości logicznej, aby wskazać, czy używa go klient / serwer. Czy są jakieś inne opcje, które mam? Zastanawiałem się, czy może nie wykorzystać klasy serwerowej jako klasy podstawowej, a potem rozszerzyć ją o renderowanie?
źródło
Odpowiedzi:
Powinieneś raczej trzymać kod renderowania oddzielony od logiki gry , ponieważ są to osobne problemy .
Jeśli oddzielisz kod renderujący od kodu klienta / serwera, uzyskasz kilka korzyści:
updatefazę odrenderfazy i uruchamiać je w różnym czasie.const, redukując błędy.źródło
Myślę, że powinieneś dokładnie oddzielić kod klienta i kodu serwera. Kod serwera i kod klienta nie powinny wiedzieć o sobie, z wyjątkiem funkcji udostępnianych przez interfejsy. Serwer nie powinien wiedzieć nic o renderowaniu, rejestrowaniu klientów, śledzeniu pozycji, czasie itp. Jeśli masz wyraźnie oddzielone obawy, łatwiej jest utrzymywać i rozwijać grę. Mam nadzieję, że to trochę pomoże.
źródło
Rozdzielenie problemów FTW, jak powiedzieli inni, ale jeśli Twoim celem końcowym jest posiadanie oddzielnych aplikacji klienckich i serwerowych, musisz pójść o krok dalej. Musisz określić, co jest specyficzne dla klienta, co jest specyficzne dla serwera i co jest udostępniane. Dla wszystkiego, co jest współużytkowane, podziel je na klasy kodu udostępnianego wyłącznie; klasy specyficzne dla klienta lub serwera mogą następnie odpowiednio podklasować lub odwoływać się do klas współdzielonych. Przenieś wspólne klasy do oddzielnego projektu, budując plik JAR „biblioteki współdzielonej” i dołącz ten plik JAR do projektów klienta i serwera.
Ma to kilka zalet: sprawia, że separacja problemów jest krystalicznie czysta, aby utrzymać wszystko w osobnych projektach; zapewnia, że klient i serwer zaczynają od tego samego wspólnego kodu (o ile używają tej samej wersji wspólnego pliku JAR); i uniemożliwia „przypadkowe” zmodyfikowanie współdzielonego kodu, nie zdając sobie z tego sprawy. Jeśli kod współdzielony jest w swoim własnym projekcie, będziesz wiedział, że kiedy edytujesz w nim coś, musisz wiedzieć, w jaki sposób zmiany wpłyną zarówno na klienta, jak i na serwer.
źródło