Przystępuję do tworzenia silnika gry typu MMOG w technologii Java EE. Dla tych, którzy nie wiedzą, co to za gatunek, wyjaśniam. Na pewno znacie takie tytuły jak Travian, Plemiona, OGame, Duma Szlachecka. Chcę nieco zmienić koncepcję, ale o tym później. Dlaczego Java? Otóż aplikacja działa cały czas, jest obsługa wątków i liczników. Rozgrywka będzie toczyć się w czasie rzeczywistym.
Jak do tego podejść? Jak prawidłowo zaprojektować architekturę silnika?
Przykład 1. Kiedy stawiacie budynek, w przeglądarce trwa odliczanie czasu do końca. Kiedy rozbudujecie pola uprawne, zwiększacie produkcję, np. co 5,5 sekundy liczba jednostek pszenicy zwiększy się o 1. Docelowo zboże ma przyrastać nieliniowo (w zimie nie ma żniw). Czy dla każdego gracza tworzyć osobne liczniki? Będzie ich kilka razy więcej niż graczy (osobny licznik dla pszenicy, wojska, każdego budowanego budynku) o ile Java na to pozwoli. Wraz ze zmianą pory roku trzeba zmieniać interwały (znacie lepszy sposób?). Inna koncepcja to 1 wielki timer (ewentualnie kilka timerów), gdzie iterujemy po wszystkich graczach i ich dobytku. Taki timer musiałby taktować z dużą częstotliwością, co mocno obciąży procesor i pamięć. Trzecia koncepcja to obliczać stan surowców, kiedy takie informacje są potrzebne.
Przykład 2. Kiedy będę chciał osadzić grę w innej epoce, w całkiem innym świecie, mogą zmienić się surowce, może zmienić się ich ilość, mogą całkowicie zmienić się założenia. Myślę, że silnik powinien być uniwersalny, a wszystkie obiekty konfigurowalne. W praktyce takie założenie zwiększy złożoność kodu, a co za tym idzie, mocno obniży wydajność aplikacji. A może się mylę?
// Na przykładzie Traviana - podejście nr 1 - sztywna aplikacja
class Village {
private int wood;
private int clay;
private int crop;
}
// Podejście uniwersalne (zakładamy, że jest jakieś globalne terytorium)
class TerritoryItem {
private Position position;
private TerritoryItemType type; // luźna fantazja
private List<Item> items; // ma jakieś atrybuty
}
Do tego trzeba ustalić jakieś warunki typu „wioska może mieć max N atrybutu A”. Czy warto rozważyć zwiększenie skomplikowania aplikacji, aby nie pisać na sztywno w kodzie wszystkich reguł, zasad gry, surowców, jednostek, miejsc na mapie, a konfigurować je np. w bazie danych?
Serwer będzie odpowiadał wyłącznie za logikę biznesową. Komunikacja z klientem za pomocą REST lub WebSocket.