Czy istnieją istniejące ramy oparte na komponentach FOSS? [Zamknięte]


25

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.


4
Powinieneś być pierwszy, który napisze! :)
Ricket

1
Cóż, napisałem jeden w języku C # dla mojego własnego projektu. Może wszyscy moglibyśmy przyczynić się?
Tesserex,

Byłbym całkowicie gotowy do pracy nad tym projektem C #. Tak, nie ma wielkiego porozumienia co do tego, jak powinien działać standardowy, ale może moglibyśmy skupić się na XNA (cokolwiek płynie twoją łodzią). To, że gromada gigantów nie zadeklarowała najlepszego sposobu, nie oznacza, że ​​nie możemy próbować / eksperymentować.
Michael Coleman,

Może dlatego, że projektowanie oparte na komponentach przyciąga kierowników projektów bardziej niż programistów
M. Utku ALTINKAYA

Odpowiedzi:


45

Jeśli nie ma popularnych, dlaczego nie?

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.


1
Doceniam, że ta odpowiedź jest stara, ale teraz jest zła: istnieją popularne ramy i jest bardzo mało debaty na ten temat. Pisząc gry, większość powyższych pytań nie ma znaczenia: albo nie mają one wpływu na projekt kodu, albo jedno podejście jest szybkie i można je wykorzystać, gdy inne nie. W praktyce istnieje kilka popularnych frameworków - wiki, do których link znajduje się w jednej z innych odpowiedzi, jest dobrym punktem wyjścia (wielu z nas utrzymuje go, aby ułatwić znajdowanie faktycznie dostarczonych gier + frameworków)
Adam

1
@Adam: Chciałbym link do szczegółów na temat podejścia, które wygrało wtedy mecz ewolucji darwin. kiedy mówię szczegóły, nie chcę słyszeć o wewnętrznych i zewnętrznych silnikach, chcę usłyszeć o mapach skrótów, wektorach, alokatorach, prywatnych, publicznych, pętlach, stałych ... szczegółach NISKIEGO poziomu.
v.oddou

@ v.oddou ktoś opublikował link do wiki jako odpowiedź już (patrz poniżej). Chcesz szczegółów? Jest pełen kodu źródłowego .
Adam

10

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.


Ash i Artemis (oba na wiki) rzeczywiście okazały się popularne, oba używane do tworzenia komercyjnych gier, wraz z twórcami gier hobbystycznych.
Adam

4

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:

      https://code.google.com/p/spartanframework/

To dobrze wyjaśnia systemy encji ... http://piemaster.net/2011/07/entity-component-primer/


2

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 :)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.