Paradygmat programowania gier opartych na komponentach staje się coraz bardziej popularny. Zastanawiałem się, czy są jakieś projekty, które oferują strukturę komponentów wielokrotnego użytku? W każdym języku, chyba nie dbam o to. To nie jest mój własny projekt, jestem po prostu ciekawy.
Mówiąc konkretnie, czy istnieją projekty, które zawierają Entityklasę podstawową, Componentklasę podstawową , a może jakieś standardowe elementy? Byłoby o wiele łatwiej rozpocząć grę, jeśli nie chcesz wymyślać koła na nowo, a może chcesz, GraphicsComponentktóry robi duszki z Direct3D, ale uważasz, że zostało to już zrobione kilkanaście razy.
Szybki Googling pojawia się Rusher . Czy ktoś o tym słyszał / czy ktoś go używa? Jeśli nie ma popularnych, dlaczego nie? Czy zbyt trudno jest stworzyć coś takiego do wielokrotnego użytku i wymagają one dużych dostosowań? W mojej własnej implementacji znalazłem wiele płyt kotłowych, które można wrzucić do ramy.
źródło
Odpowiedzi:
Ponieważ nic nie przypomina konsensusu co do tego, jak takie ramy mogłyby działać.
W wątku na Gamedev.net ustaliłem, że kiedy ludzie mówią o systemach gier opartych na komponentach, faktycznie istnieje co najmniej 8 możliwych kombinacji tego, w jaki sposób oczekują, że będą działać, w oparciu o 3 różne czynniki:
Wbudowany a zaburtowy - czy komponenty powinny być agregowane w całość, czy powinny być częścią podsystemu i kojarzone tylko za pomocą identyfikatora jednostki?
Kompozycja statyczna vs. dynamiczna - jeśli jednostki składają się ze znanego zestawu komponentów (np. 1 fizyki, 1 animacji, 1 AI, itp.), Które mogą komunikować się w kodzie za pośrednictwem dobrze znanych interfejsów, lub też jednostki mogą mieć dowolne ilości komponentów dodanych do je (wraz z powiązanymi strategiami lokalizowania innych interesujących elementów)
Dane dotyczące składnika a dane dotyczące podmiotu - czy dane powinny być przechowywane przez składnik, który przede wszystkim na nim działa? A może dane powinny być przechowywane w jednostce we wspólnej przestrzeni, dostępnej dla wszystkich komponentów?
Poza tym istnieją dalsze pytania dotyczące tego, w jaki sposób komponenty powinny się komunikować (za pośrednictwem wspólnych danych? Przez wskaźniki funkcji? Przez sygnały / gniazda? Lub wcale?), W jaki sposób powinny się aktualizować (w ustalonej kolejności na podstawie typu komponentu? - kolejność istotności zdefiniowana w czasie tworzenia? na podstawie topologicznego rodzaju współzależności składników?) itp.
Każda z tych opcji jest całkowicie dowolna, a wszystko, co możesz zrobić z jednym systemem, można zrobić z drugim. Ale sposób, w jaki musisz go kodować, jest różny w każdym przypadku. A ludzie wydają się mieć mocne opinie na temat tego, który sposób najlepiej im odpowiada.
W tej chwili ludzie wciąż są zbyt pochłonięci pomysłem, że komponenty w jakiś sposób zastępują orientację obiektową (której nie są), a także wyobrażają sobie, że są ogromną zmianą w stosunku do tradycyjnego tworzenia gier (które znowu nie były - ludzie od dawna rozróżniają różne podsystemy w swoich bytach), więc jest dużo hiperboli i mało zgody. Być może za kilka lat wszystko się uspokoi i ludzie ustalą jedno lub dwa dość standardowe podejścia.
źródło
Istnieje wiki, która gromadzi przykłady tych wszystkich:
http://entity-systems.wikidot.com/
... wraz z wyjaśnieniem różnic między różnymi podejściami.
źródło
Sprawdź te frameworki, które znalazłem związane z tą architekturą ...
www.burgerengine.com
PushButtonEngine
Arthemis Framework - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis
Spojrzenie na Unity Api. Można znaleźć wiele rzeczy dotyczących architektury opartej na komponentach. (Zaktualizuję listę, jak tylko ją znajdę ...)
Aktualizacja:
To dobrze wyjaśnia systemy encji ... http://piemaster.net/2011/07/entity-component-primer/
źródło
Istnieje silnik Push Button dla Flash: http://pushbuttonengine.com/
I jest Panda3D dla c ++ / python: panda3d dot com (przepraszam, mogę tylko 1 URL na post jako n00b)
Jestem pewien, że jest tam mnóstwo więcej :)
źródło