Które funkcje należą do silnika, a które do gry?

W tej chwili wdrażam i testuję nowe funkcje dla mojego silnika gier 2D, bezpośrednio kodując je do silnika. Jednocześnie mam grę pokazową z obsługą skryptów, która powinna wywoływać funkcje silników. Załączam np. Naprawiony ruch kafelków do klasy Entity w silniku, zamiast skryptować to specjalnie dla gry. To zdecydowanie łamie pomysł ogólnego silnika używanego w więcej niż jednej grze.

Czy są jakieś najlepsze praktyki, aby skupić się na poprawnej implementacji we właściwych częściach (tj. Silnik vs. gra)?

Istnieje kilka sposobów myślenia na ten temat. Jednym z nich jest wyszczególnienie konkretnych funkcji, które powinien mieć silnik (o co tutaj pytałeś). Innym sposobem jest po prostu rozpoczęcie tworzenia gier bez martwienia się zbytnio o „silnik”, a następnie funkcje, które znajdziesz, są ponownie wykorzystywane między wieloma gry (w szczególności funkcje używane w każdej grze) należy przeprowadzić migrację ze źródła dla określonej gry do wspólnej bazy kodów o nazwie „silnik”.

Ponieważ ostatecznie chcesz, aby dana funkcja była dostępna w silniku, a nie w grze, dlatego, że jest ona dzielona między wiele gier. Zazwyczaj będą to takie polecenia, jak rysowanie poleceń, kontrolery wejściowe i kod sieci. Silnik gier 2D będzie miał wiele funkcji graficznych 2D, takich jak ładowanie obrazów, hierarchia wyświetlania z kolejnością Z, obsługa arkuszy sprite, animacji itd. Wiele gier wymaga symulacji fizyki, choć z drugiej strony wiele nie. Tymczasem więcej „pod maską” rzeczy używanych w prawie każdej grze obejmuje timery, powiadamianie o zdarzeniach, a nawet funkcje matematyczne specyficzne dla rozwoju gry (np. DistanceToTarget ()

Krótko mówiąc:

A) Silnik powinien mieć funkcje wspólne dla większości gier.

B) Dowiesz się, które funkcje są wspólne, tworząc kilka gier.