Esistono framework basati su componenti FOSS esistenti? [chiuso]


25

Il paradigma di programmazione del gioco basato su componenti sta diventando molto più popolare. Mi chiedevo, ci sono progetti là fuori che offrono un framework di componenti riutilizzabile? In qualsiasi lingua, immagino che non mi interessi. Non è per il mio progetto, sono solo curioso.

In particolare intendo che ci sono progetti che includono una Entityclasse base , una Componentclasse base e forse alcuni componenti standard? Sarebbe quindi molto più semplice iniziare una partita se non volessi reinventare la ruota, o forse vuoi una GraphicsComponentche fa sprite con Direct3D, ma pensi che sia già stato fatto una dozzina di volte.

Un veloce googling rivela Rusher . Qualcuno ha sentito parlare di questo / qualcuno lo usa? Se non ce ne sono di popolari, allora perché no? È troppo difficile rendere qualcosa di simile riutilizzabile e hanno bisogno di personalizzazioni pesanti? Nella mia implementazione ho trovato un sacco di boilerplate che potevano essere inseriti in un framework.


4
Dovresti essere il primo a scriverne uno! :)
Ricket,

1
Bene, ne ho scritto uno in C # per il mio progetto. Forse potremmo tutti contribuire?
Tesserex,

Sarei totalmente pronto a lavorare su quel progetto C #. Sì, non c'è un enorme consenso su come dovrebbe funzionare uno standard, ma forse potremmo concentrarci su XNA (qualunque cosa galleggi la tua barca). Solo perché un gruppo di giganti non ha dichiarato il modo migliore per farlo non significa che non possiamo provare / sperimentare.
Michael Coleman,

Forse perché la progettazione basata su componenti attira più i project manager che i programmatori
M. Utku ALTINKAYA,

Risposte:


45

Se non ce ne sono di popolari, allora perché no?

Perché non c'è nulla che assomigli a un consenso su come un tale quadro funzionerebbe.

Su un thread su Gamedev.net ho stabilito che quando le persone parlano di sistemi di gioco basati su componenti ci sono in realtà almeno 8 possibili permutazioni su come si aspettano che funzionino, sulla base di 3 diversi fattori:

Entrobordo vs fuoribordo : i componenti devono essere aggregati in un'entità o dovrebbero far parte di un sottosistema e associati solo a un ID entità?

Composizione statica vs. dinamica : se le entità sono costituite da un insieme noto di componenti (ad es. 1 Fisica, 1 Animazione, 1 AI, ecc.) Che possono comunicare in codice tramite interfacce ben note, oppure alle entità possono essere aggiunte quantità arbitrarie di componenti a loro (con strategie associate per localizzare altri componenti di interesse)

Dati sul componente vs dati sull'entità : i dati devono essere conservati dal componente che opera principalmente su di esso? O i dati devono essere archiviati sull'entità in uno spazio condiviso, accessibile da tutti i componenti?

Oltre a ciò ci sono ulteriori domande su come i componenti dovrebbero comunicare (tramite i dati condivisi? Tramite i puntatori a funzione? Tramite segnali / slot? O per niente?), Come dovrebbero aggiornarsi (in un ordine fisso basato sul tipo di componente? -ordine di identità definito al momento della creazione? basato su una specie topologica di interdipendenze componenti?), ecc.

Ognuna di queste scelte è completamente arbitraria e tutto ciò che puoi fare con un sistema può essere fatto con l'altro. Ma il modo in cui devi codificare è abbastanza diverso in ogni caso. E le persone sembrano avere opinioni forti su come funziona meglio per loro.

In questo momento le persone sono ancora troppo prese dall'idea che i componenti siano in qualche modo un sostituto per l'orientamento agli oggetti (cosa che non sono) e immaginano anche che siano un enorme cambiamento rispetto al modo in cui i giochi sono stati tradizionalmente realizzati (che, di nuovo, non lo erano - le persone hanno preso in considerazione i vari sottosistemi nelle loro entità per secoli), quindi c'è molta iperbole e poco accordo. Forse tra qualche anno le cose si saranno sistemate e le persone si sistemeranno su uno o due approcci abbastanza standard.


1
Apprezzo che questa risposta sia vecchia, ma ora è sbagliata: ci sono quadri popolari e non c'è molto dibattito rimasto sull'argomento. Quando si scrivono i giochi, la maggior parte delle domande precedenti non ha importanza: o non hanno alcun effetto sulla progettazione del codice o un approccio è rapido e riutilizzabile dove gli altri non lo sono. In pratica, ci sono un sacco di popolari Frameworks - il wiki collegato in una delle altre risposte è un buon punto di partenza (un gruppo di noi lo mantiene per facilitare la ricerca di giochi + framework effettivamente spediti)
Adam

1
@Adam: Vorrei un link sui dettagli dell'approccio che ha vinto la partita di evoluzione di darwin allora. quando dico dettagli, non voglio sapere di dentro e fuori, voglio sapere di mappe hash, vettori, allocatori, private, pubbliche, loop, dettagli di livello BASSO.
v.

@ v.oddou qualcuno ha già pubblicato un link al wiki come risposta (vedi sotto). Vuoi dettagli? È pieno di codice sorgente .
Adam,

10

C'è una wiki che sta raccogliendo esempi di tutti questi:

http://entity-systems.wikidot.com/

... insieme a spiegazioni delle differenze tra i diversi approcci.


Ash e Artemis (entrambi nella wiki) si sono rivelati davvero popolari, entrambi in uso per lo sviluppo di giochi commerciali, insieme allo sviluppatore di giochi per hobby.
Adam,

4

Dai un'occhiata a questi framework che ho scoperto relativi a questa architettura ...

www.burgerengine.com

PushButtonEngine

Arthemis Framework - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

Dai un'occhiata a Unity Api. È possibile trovare molte informazioni sull'architettura basata su componenti. (Aggiornerà l'elenco non appena avrò trovato qualcosa ...)

Aggiornare:

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

Questo spiega in modo positivo i sistemi di entità ... http://piemaster.net/2011/07/entity-component-primer/


2

Esiste un motore a pulsante per Flash: http://pushbuttonengine.com/

E c'è Panda3D per c ++ / python: panda3d dot com (mi dispiace, ho solo 1 url per post come n00b)

Sono sicuro che ce ne sono molti altri là fuori :)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.