Quale SceneGraph è ottimale per iniziare per la programmazione di giochi di piccole dimensioni?

Sono uno sviluppatore di applicazioni Web Java (principalmente lato server) da 7 anni che recentemente si sono interessati allo sviluppo del gioco (non so perché, forse sono annoiato). Oggi stavo cercando quadri. Ho letto alcuni grafici di scene e ho dato un'occhiata a jMonkeyEngine . È stato raccomandato qui e qui .

Il mio primo obiettivo era quello di creare un piano semplice e una sfera che potesse essere spostata usando la tastiera. Bene, come ho già detto, sono uno sviluppatore web e non ho mai programmato nient'altro, quindi ho iniziato con i tutorial di jMonkey. Ma non sono riuscito a farli funzionare. Ho dato un'occhiata al wiki ma ho notato che la documentazione sembra essere molto scarsa, almeno rispetto a ciò a cui sono abituato. Ho quindi dato un'occhiata ad alcuni altri grafici di scena (anche per C ++) ma sembrano anche avere una documentazione scadente, obsoleta, incompleta.

Qualcuno può consigliarmi un grafico della scena che è ben documentato con campioni funzionanti? O c'è qualcosa come la "guida definitiva" per entrare in questo argomento? Devo prima sapere come sviluppare il mio grafico di scena per farlo funzionare o è possibile semplicemente capire i principi astratti e usarlo da un punto di vista più elevato?

In qualche modo ho la sensazione di aver bisogno di capire l'interno profondo di un grafico di scena per usarlo bene (come nel caso degli strumenti ORM nel web dev, non puoi usarli bene se non capisci i database)

Mi dispiace se questa domanda è troppo "noobish", ma voglio solo alzarmi in piedi e fare i miei primi passi.

Un grafico di scena è uno strumento. Non è davvero uno strumento adatto per quando hai appena iniziato lo sviluppo del gioco.

Penso che ciò che cerchi non sia un grafico di scena ma solo un quadro di qualche tipo.

Normalmente consiglierei XNA perché è davvero buono (potente, moderno, ben documentato, adatto ai principianti). Ma è C # e posso vedere che sei un uomo Java. Se preferisci restare con Java, forse un buon punto di partenza sarebbero le porte Java dei vecchi tutorial NeHe OpenGL (questo non è un framework - ma è un insieme di tutorial su come fare (a basso livello ) il tipo di cose che fa un framework per te: caricare e renderizzare modelli, caricare trame, ecc.).

Nelle prime lezioni imparerai le matrici di trasformazione, che sono fondamentalmente i grafici di scena (nel caso comune).

Per descrivere brevemente un grafico di scena: supponi di avere un modello di mulino a vento: è definito nel suo spazio. Lo traduci dove desideri che appaia nel tuo spazio mondiale . Quel mulino a vento avrebbe un oggetto figlio per le sue pale rotanti - quindi applicheresti una trasformazione di rotazione alle pale e erediterai anche la traduzione dei suoi genitori per posizionare correttamente le pale nel mondo.

Quando inizi a creare piccoli giochi, non devi preoccuparti così tanto di avere questa struttura di dati complicata e grande. Di solito avrai solo un paio di modelli a cui applicherai direttamente le matrici di trasformazione.

(I grafici delle scene sono usati anche per cose relative alle prestazioni come l'ordinamento per materiale, l'abbattimento, ecc., Tutto non necessario per il principiante e per la maggior parte dei piccoli giochi.)

Il grafico della scena ha leggermente perso il proprio posto come un must. Soprattutto perché un motore incentrato sul grafico di scena è così legato all'idea di uno scenario che si confonde. Il fatto è che varie parti di un motore hanno bisogno di una visione diversa del mondo, mentre un motore incentrato sullo scenario tende a voler imporre la stessa visione su tutte le parti del motore.
Lo scenario come viene tradizionalmente visto, una gerarchia di oggetti padre e oggetti figlio è utile per le trasformazioni, ma potrebbe essere totalmente inappropriato per il rendering, dove sei più interessato a quali materiali vengono utilizzati (bene, anche la posizione conta, ma ci sono diversi modi per affrontarlo e genitore-figlio non garantisce che siano vicini, tendiamo a vederlo in quel modo).
In molti giochi scoprirai che hai una scena-radice con molti bambini, ma quei bambini raramente hanno figli propri. I pochi che hanno figli potresti anche aggiornarti e saltare lo scenario poiché aggiunge complessità e perdite di prestazioni non necessarie (ogni trasformazione controlla se il suo genitore è sporco mentre solo pochi hanno effettivamente un genitore che si sporcherà mai (la radice del mondo raramente si sposta).

Perché non utilizzare un motore di gioco come Unity3d ? È molto noto per essere facile da usare e con un'ottima documentazione. L'ho provato brevemente e sono rimasto colpito da quanto ben documentato fosse l'API e una serie di buoni tutorial. Ho avuto problemi con il braccio e un po 'di palcoscenico e ho dovuto chiedere aiuto a mia moglie. Non ha idea della programmazione ma ha pensato che Unity3D fosse davvero interessante. Puoi ottenere molto con il semplice trascinamento della selezione. È possibile utilizzare diversi linguaggi di script con il motore. Supporta JavaScript tra le altre cose, che immagino che, dato il tuo background, dovrebbe essere attraente. Puoi ottenere una versione gratuita con tutte le funzionalità di cui uno sviluppatore di giochi iniziale avrebbe bisogno.

Se non hai bisogno di 3D, quindi GameMaker è una grande alternativa. È davvero facile entrare e fare giochi. L'ho usato all'università e ci ho fatto un paio di giochi. Gran divertimento. Ti permette davvero di concentrarti sulla realizzazione del gioco e non devi pensare molto alla tecnologia. Puoi mettere insieme un gioco semplicemente con il semplice clic. Ma man mano che avanzi e comprendi come funziona, inizi a scrivere i tuoi script.

Secondo me funziona molto meglio di dire GameSalad che non ha un linguaggio di script. Non appena inizi a fare cose più complicate, diventa davvero fastidioso con solo punta e clicca penso.

Sono completamente d'accordo con Kaj. Per ulteriori approfondimenti su questo argomento, vedi gamearchitect (a proposito, se sei interessato allo sviluppo del gioco, leggi l'intero sito, in particolare quello vecchio)