Concluse le presentazione e l'angolo della modestia inizieri a esporre
il mio problema.
Sono approdato su Ogre3d e mi è piaciuto molto, ho iniziato a giocarci
un po e sono rimasto molto soddisfatto da questo motore di rendering.
Il quale è possibile anche adattarlo a un video game;qui arriva il mio
primo quesito.
Per fare un videogame solitamente una software house sviluppa un
editor prima del gioco? o sviluppa l'editor solo se vuole riutilizzare
l'engine/sistema di gioco?
(so che sono domande sciocche ma... per come è fatta la mia testa devo
aver chiare le cose piu stupide)
Una volta che si crea un editor o uno strumento per agevolare la
creazione del gioco, ovviamente l'engine deve sapere come interpretare
quello che è stato creato dal level designer. Poniamo quindi che io
voglia creare un terreno con alberelli e ruscelli. Come devo
comportarmi? (a grandi linee ovviamente)
per ora faccio solo queste due semplici domande ma se avrete pazienza
ne ho molte altre.
Un saluto a tutti.
Guarda, io non lavoro in una software house e non sono nemmeno
programmatore per professione, ma ti spiego la mia esperienza: per
http://fuzzware.altervista.org/lostonesland abbiamo sviluppato un
editor di mappe, uno script per Blender per esportare i modelli ed un
editor per "mettere a posto i modelli", e un generatore di alberi.
Probabilmente molti avrebbero optato per scrivere semplicemente dei
plugin per Blender o 3DStudio o altro, altri un editor completamente
custom. Ognuno fa quello che rientra più nelle proprie conoscenze (non
sai che sudate su quello script per Blender!).
La cosa sicura secondo me è che non si trova nulla che già di
"preconfezionato" ti dà quello che ti serve.
> Una volta che si crea un editor o uno strumento per agevolare la
> creazione del gioco, ovviamente l'engine deve sapere come interpretare
> quello che è stato creato dal level designer. Poniamo quindi che io
> voglia creare un terreno con alberelli e ruscelli. Come devo
> comportarmi? (a grandi linee ovviamente)
Se l'editor viene creato dal programmatore, come è piuttosto facile,
il problema non si pone! Crea l'editor in modo da guidare la mano del
level designer... Comunque i ruscelli mi stanno dando qualche
grattacapo concettuale che non ho ancora risolto e quindi non ho
ancora implementato!
Ciao
________________________
Matteo
http://fuzzware.altervista.org
"A man with a new idea is a crank until the idea succeds" - M. Twain
2) editor di livelli
Anche se puo' sembrare che l'editor di liveli e l'editor di modelli 3D
siano la stessa cosa (e a volte in effetti lo sono), a me piace
differenziarli.
Con l'editor di modelli creo un albero e una casa.
Con l'editor di livelli, creo una scena con 100 alberi (importo il
modello creato) e 100 case.
La differenza è forse sottile e, ripeto, non necessariamente 1) e 2)
sono diversi, ma è bene sottolineare che potrebbero esserlo.
A dire il vero potrei andare avanti ad elencare altri editor ma, se mi
permetti, vorrei darti un consiglio: parti dalle basi.
Crea un mini programma che importa un modello 3d da un editor di tua
scelta, e che lo visualizza a video (magari lo fa anche ruotare....)
Poi aggiungi il controllo tramite tastiera in stile FPS.
Poi magari fagli sparare un proiettile...e verifica se collide contro un
muro.
Una volta fatto questo, secondo me avrai le idee piu' chiare su cosa
serve e cosa non serve perche nel frattempo avrai affrontato e risolto
una serie di problemi di base che a raccontarli sembrano delle
stupidate, ma in sostanza invece sono quelle piccolezze che poi ti
impediscono di terminare un lavoro piu' grosso.
Ciao
Dunque per rispondere a Giallanon quando scrive
>"A dire il vero potrei andare avanti ad elencare altri editor ma, se mi
>permetti, vorrei darti un consiglio: parti dalle basi.
>Crea un mini programma che importa un modello 3d da un editor di tua
>scelta, e che lo visualizza a video (magari lo fa anche ruotare....)
>Poi aggiungi il controllo tramite tastiera in stile FPS."
Attualmente la mia situazione è ben piu avanti di quel che immagini,
utilizzo gia del codice in grado di caricarmi un terreno enorme
utilizando un paged terrain, ho la possibilità in tempo reale di
modificare l'altezza del terreno e la texture in game-time (anche se
ancora non posso salvare le modifiche fatte). Utilizzo la nebbia
volumetrica e l'atmosfera (sebbene abbia dei bei problemi su come
creare un sole realistico). Ho trovato delle interessanti librerie che
mi permettono di caricare piu di 30000 mesh di ottima risoluzione (e
animata) utilizzando sempre una metodica a paging. Ora sto scrivendo/
estendendo delle GUI (il mio incubo). Putroppo tutto questo non è
gestito da un editor e quel che si vede a monitor lo creo usando
qualche ciclo per la randomizzazione dell'ambiente (il che per certi
tratti puo anche adarmi bene) ma se devo creare una citta di certo non
posso farlo a mano o sperare che la macchina abbia gusto :)
Matteo poco sopra mi scrive:
>abbiamo sviluppato un
>editor di mappe, uno script per Blender per esportare i modelli ed un
>editor per "mettere a posto i modelli",
Questo mi sembra molto interessante, attualemente il mio compagno di
avventura "spugna" il grafico pazzo, utilizza maya 2008 il quale ci
da qualche problema nell'export della mappatura dei modelli... per
tanto tutti i modelli sono di un allegrissimo color di plasica bianca.
Tu usi Blender... ho sempre stimato molto quel prodotto ma credo di
detestare la sua interfaccia grafica piu di una supposta al tritolo...
non lo ho trovato intuitivo per tanto mollai subito di guardarlo
(grosso errore lo so). Tu che esperienze hai? E versatile? So che era
stato ideato proprio per lo sviluppo di giochi in un certo verso.
Comunque mi sembra di aver capito che l'editor si puo evitare di
riscriverlo, utilizzando a d.o.c. un po di script per blender and
company... giusto?
Quoto in pieno.
Anche noi siamo passati da un sacco di prove, anche gmax (avevo
trovato il modo di esportare aggirando la limitazione che aveva
sull'output in console... ghgh), milkshape, ma poi Blender si e'
rivelato abbastanza valido, e tra l'altro e' free. Concordo sulla
supposta al tritolo, anche se la mia espressione tipica riguarda un
furetto aggrappato ai... beh si e' inteso!
Uno dei problemi che ci ha dato e' che un paio di volte, per delle
"major changes" da una versione all'altra, abbiamo dovuto adattare lo
script.
Fortunatamente c'e' una grossa comunita' di gente che ci smanetta e
qualche aiuto si trova.
> Comunque mi sembra di aver capito che l'editor si puo evitare di
> riscriverlo, utilizzando a d.o.c. un po di script per blender and
> company... giusto?
Piu' o meno: noi, con lo script, che e' scritto in python, facciamo il
minimo indispensabile. Poi tiro su il risultato dell'importazione e
con un programma scritto nella mia madrelingua (il c++ ovviamente) mi
trovo molto piu' a mio agio per mettere a segno le mie acrobazie.
Inoltre vedi il modello nel tuo motore grafico e capisci se c'e'
qualcosa da correggere.
Un linguaggio di scripting e` un vero e proprio linguaggio, devi crearti
una grammatica, eseguirne il parse, interpretarlo...
Sinceramente ti consiglio di usarne uno gia` esistente ad esempio LUA
(www.lua.org) che e` molto usato in ambito videoludico (ad esempio da
World of Warcraft) o python se vuoi qualcosa di ancora piu` sofisticato
(in realta` puoi fare praticamente di tutto anche con lua che ha un
footprint nettamente inferiore).
Per integrare uno script language in un engine in C++ esistono tool
appositi (ad esempio luabind), oppure si puo` fare manualmente, questa
strada conviene solo se si vuole esporre una minima parte dell'API del
proprio engine.
Bye,
Gabry
Sei Stato illuminante! Avevo sentito nominare questo nome "luabinding"
ma tra le mille cose da comprendere non pensavo fosse proprio quello
che cercavo.
Grazie mille.
Ce ne sono anche altri, come tolua/tolua++ e SWIG.
.Erix.
Alcuni videogames come ad esempio lineage 2 utilizzano uno script di
nome Jython per la creazione delle quest. Questi script vengono
eseguiti nell'init del server quindi solo durante il boot del server,
niente vieta di eseguire script in gametime, vero?
Dipende dal tempo di esecuzione; devi fare qualche prova. Se lo script
va eseguito durante il frame devi riservargli un certo tempo (es. 1 ms)
e fare in modo che ogni chiamata ci stia dentro.
Se lo script e' troppo lento o deve girare di continuo (es. AI) puoi
fargli un thread separato, anche se ovviamente ti ritrovi con un po' di
problemi di sincronizzazione. Oppure, se l'interprete lo consente, fai
eseguire solo n istruzioni di script a ogni frame.
.Erix.