Odpowiedzi:
Osobiście nie sądzę, aby były jakieś dobre przykłady, głównie dlatego, że definicja „systemu opartego na komponentach” gier jest tak luźno zdefiniowana, że może oznaczać prawie nic.
Część dyskusji w tej odpowiedzi może okazać się pomocna: Jak wdrożyć system oparty na komponentach dla przedmiotów w grze internetowej
Ogólnie rzecz biorąc, podejście polega po prostu na zmianie dowolnego GameObject lub Actor z dużej klasy, która obsługuje wszystkie zachowania, na prostszą klasę, która przechowuje obiekty, które zachowują się. Myślę, że samodzielna praca nad tym i tworzenie różnych komponentów pasujących do Twojej gry będzie często najlepszym sposobem na kontynuację.
Oto niektóre zasoby, które mogą ci się spodobać:
jest ten niesamowity wątek. To nie jest sam silnik gry, ale konstrukcja i dyskusja są świetne.
Pytanie o StackOverflow na bardzo podobny temat.
Aby odpowiedzieć na pierwotne pytanie, środowisko Elephant w C # jest dokładnie tym, czego chcesz: zostało przerwane, ale nadal istnieje tutaj w celu odniesienia do implementacji.
Ta strona zaczyna się od podstawowej implementacji.
Większość powyższych inspiruje ten artykuł w T = Machine
Zacząłem od podstawowej implementacji zainspirowanej powyższymi dwoma linkami. Jestem prawie pewien, że bardzo odstąpiłem od czystej teorii systemów składowych i niewątpliwie są tam błędy, ale może się to przydać, jeśli szukasz prostych przykładów.
Bricle (C # / XNA)
W tej chwili ładuje tylko niektóre podstawowe elementy, obsługuje niektóre zdarzenia itp. Główne lokalizacje, których szukasz, to folder Engine.EntitySystem i prawdopodobnie PlayScreen, w którym elementy są tworzone.
Tworzenie prostego magazynu komponentów opartego na typach i ukrywanie go za wspólnym EntityManager było stosunkowo proste.
Pierwszym wyzwaniem, na jakie natknąłem się, było to, że pojedyncze systemy mogą wymagać wielu typów komponentów (tj. Komponentów fizycznych i InputMoveable). Aby użyć języka relacyjnej bazy danych, musiałem znaleźć sposób na wykonanie zapytania JOIN. W tym celu stworzyłem inny typ kolekcji dla encji zbudowanych z pasujących zapytań o typ komponentu - każda kolekcja encji łączy się ze zdarzeniem OnEntityCreate i sprawdza, czy pasuje. Nadal są tam jakieś błędy.
Drugim wyzwaniem było stworzenie „obiektu gry” - nazwałem je szablonami. Tutaj prawdopodobnie nie jestem bardzo czysty według specyfikacji T = Machine, ale wydaje się, że działa. Szablony grupują razem instancje komponentów i umożliwiają łatwiejsze komponowanie elementów (tj. Kula jest rysowalna i fizyczna).
Nadzieja, która jest pomocna - systemy jednostek / komponentów mogą stanowić wyzwanie w pokonaniu początkowych przeszkód.
Kolejnym, którego nie użyłem, ale przejrzałem nieco kod, jest Artemis . Dobrze skomentowane i dość aktywne. Pierwotnie framework Java, ale został przeniesiony do C # / XNA.