NJ sta per Nocche-Jak da cui è venuto fuori il marchio NJGames e visto che suonava bene ne ho fatto il mio ufficiale poichè nocode il suo ce l'ha già.
In questo progetto il lavoro lo faccio praticamente tutto io tuttavia anche nocode ha la sua parte di lavoro fornendomi aiuto con texture, modelli, testing e robe di vario genere.
Ma lasciamo questi dettagli e passiamo al fulcro dell'argomento, "cosa è l'NJine".
Inizialmente non doveva essere rivelato niente a nessuno fino a qualcosa di concreto e leggermente testabile/guardabile così da evitare i "problemi di vapore" ma appena nocode ha formato quell'immagine non ho resistito
L'NJine è ufficialmente un creatore di giochi molto simile a game maker però concentrato esclusivamente sul 3d.
La mia scelta è dovuta da tanti fattori molti dei quali sono i pareri dei vari utenti di GMI.
Probabilmente vi romperà sentire tutta la storia ma è per far capire il perchè delle mie varie scelte visto che in un topic in cui avevo chiesto consigli a riguardo le vostre risposte erano propense a tutta un'altra direzione.
Inizialmente l'NJine era nato come sotituto personale di game maker con qualche cambiamento personalizzato per renderlo più veloce/potente e sopratutto multipiattaforma... questo fino all'arrivo di game maker studio.
Game maker è un'ottimo programma, probabilmente il top per fare giochi bidimensionali, il suo punto di forza è la semplicità di utilizzo permettendogli di avere la sua fetta tra i nuovi engine graficamente superpompati come UDK con un semplice tool per giochi bidimensionali.
Tuttavia game maker ha un punto debole, molti utenti avanzati voglio fare il cosiddetto "passaggio al 3d" cercando di utilizzare al meglio il d3d o dll quali ultimate 3d o gmogre.
Da questo punto nasce l'illuminazione, da una parte game maker con semplicità e giochi 2d, dall'altra engine professionali per fare giochi 3d di ultima generazione dedicati a chi è esperto nel settore e provvisto di computers ultimo modello. Scegliendo una parte o l'altra mi metterei sempre a confronto con qualcosa di probabilmente imbattibile sotto tutti gli aspetti fu così che in breve tempo abbandonai l'idea di fare un qualcosa di personale...
Arrivarono nel frattempo nuovi utenti su GMI che per quanto all'inizio sembravano dei gasati si sono rivelati gente con voglia di fare e capacità superiore alla media(considerando che il 99% degli utenti fa fatica con le icone...) Paro di gente come prometeo ed enick che, per quanto non sono all'altezza di gente esperta del forum, hanno imparato molta roba in poco tempo ed hanno dimostrato una incredibile voglia di fare sotto qualunque difficoltà. Concentrandomi su questi due esempi(poichè li ho seguiti da vicino) prometeo ha sbattuto la testa per imparare ad usare il d3d prima del previsto quando ancora faceva fatica ad usare le icone, ma è riuscito tuttavia ad ottenere ottimi effetti grafici ed IA attraverso peripezie riguardanti le limitazioni e difficoltà del d3d. Enick invece è passato anch'esso a dover risolvere i problemi del d3d nonchè anche i problemi di gmogre tra le varie limitazioni e bug dovuti al porting che gli hanno dato/stanno dando non pochi problemi.
Molti altri utenti hanno provato a "passare di categoria" cercando di imparare ad usare la grafica tridimensionale, guidox, nocode, ecc ma senza troppo successo, poichè da una parte game maker è pensato esclusivamente per il 2d quindi per usare il 3d bisogna fare delle considerazioni che in genere con game maker non si fanno come il disegno manuale anzichè automatico e l'uso della terza coordinata oppure la mancanza completa di interfaccia, anche con le varie dll la situazione è simile vista la scarsa usabilità di game maker al di fuori del 2d.
Dall'altro lato si ritrovano ad usare engines professionali con un sistema di utilizzo completamente differente nonchè ben più difficili rendendo il salto veramente troppo grande.
Lavorando con questi utenti o anche solo leggendo i loro problemi su questo forum credo di aver capito cosa è che veramente manca, cosa veramente vuole un programmatore di medio livello per fare quello che vuole fare.
Ciò a cui punto è che l'engine possa essere iniziato ad essere usato da qualcuno che ha da poco smesso di usare le icone quindi più semplice possibile,
Nasce così l'idea dell'NJine, un creatore di giochi che prende la grafica tridimensionale e la rende semplice come game maker(o quasi, è pur sempre una coordinata in più da gestire) integrandosi perfettamente col programma.
Per ora l'engine è ancora in alto mare per una beta testabile tuttavia ho deciso/risolto gran parte della roba su carta quindi il lavoro difficile è fatto, ora manca solo la parte "lunga".
Ma parliamo ora più dettagliatamente di questo motore.
L'NJine, come ho già detto, è ufficialmente un sostituto di game maker riscritto interamente da zero in c++ usando le librerie grafiche opengl. Il mio intento è quello di renderlo il più possibile semplice e veloce rendendolo più adatto possibile ad un programmatore di basso livello quindi cerco di utilizzare il meno possibile librerie professionali di vario genere e di rifarmi tutto da me così da avere più controllo possibile su ciò che sto facendo, tuttavia le utilizzerò specialmente dove ancora non sono molto esperto in quel campo, attualmente utilizzo freeglut(finestre), glew(estensioni opengl) e zlib(per comprimere i file così da far pesare meno le risorse), e probabilmente(quindi non sicuro) userò una libreria per l'audio(da decidere) e physX per la fisica e gestione delle collisioni.
Inizialmente svilupperò solo per windows ma sto cercando di evitare come la peste ogni riferimento a windows poichè il mio intento è avere un programma multipiattaforma che possa essere usato su svariati OS e perfino dispositivi mobili.
Cominciamo a dare alcuni dettagli un po più precisi.
-L'interfaccia: la pecca più grande di game maker riguardante il 3d(ma anche il 2d solo che avendo meno problematiche si sopravvive anche con un'interfaccia più limitata e banale) è sicuramente la mancanza completa di interfaccia. La progettazione di mondi e visione delle varie risorse è impossibile senza che ci si faccia un buon editor personalizzato che rende comunque le cose più difficili da utilizzare vista la scarsa versatilità nella memorizzazione dei dati di game maker nonchè è difficile crearlo un'editor personalizzato richiedendo molto più tempo per farsi una libreria di funzionalità piuttosto che fare il gioco vero e proprio.
Lavorando con prometeo, massimo ed altri ho capito quanto invece sia importante avere una buona e completa interfaccia grafica così che il grafico possa gestire da se gran parte delle cose senza necessariamente chiedere aiuto al programmatore o imparare a programmare.
Uno che sa programmare avrà difficoltà ad aiutare un grafico e viceversa quindi l'obiettivo è quello di lasciare il più possibile che ognuno faccia quello che sappia fare meglio cercando di evitare il più possibile di interferire con il lavoro degli altri membri.
Un grafico che programma qualcosina va anche bene ma cosa necessaria è che si sappia arrangiare in qualche modo.
Di conseguenza ho intenzione di fare un'approccio più visivo quindi ad esempio scegliendo un modello fra molti utilizzando la preview piuttosto che il nome, stessa cosa con le texture, materiali ecc.
Anche nella creazione dei codici ho intenzione di mettere la possibilità di scegliere le varie risorse tramite interfaccia così da evitare di doversi riguardare ogni volta una lista infinita di risorse(ricordatevi che nel 3d saranno facilmente molte di più come quantità rispetto al 2d) dove magari avete nominato ognuna "alberoA, alberoB, alberoC, alberoEcc" e doverci giocare per accorgersi dell'errore.
L'interfaccia è quindi una cosa molto importante e probabimente una delle cose che cambierò maggiormente rispetto a game maker nonchè la cosa più difficile ed ancora meno studiata dell'engine a livello di struttura interna anche se ho già delle idee piuttosto chiare del risultato finale.
-La grafica: Un'altro punto fondamentale di un motore è senza dubbio la grafica. Tuttavia non aspettatevi cose tipo questa
Spoiler
Ma neanche lontanamente
Poichè fare una buona espandibilità grafica è molto difficile per ora farò degli effetti preimpostati, voi semplicemente per ogni materiale dovrete scegliere gli effetti da usare, le texture, i vari parametri del materiale ecc.
Vorrei tanto fare una cosa espandibile con tanto di shader personalizzati tipo ogre ma è una cosa troppo lunga e complessa e per ora preferisco avere qualcosa di utilizzabile.
Non aspettatevi quindi niente di più complesso di bumpmap od offset mapping per ora, tuttavia è sicuramente più di quanto potete fare con game maker, anche usando dll come gmogre, senza sbatterci la testa ed imparare gli shader.
Cercherò comunque di fare un sistema più flessibile possibile in modo da darvi costanti aggiornamenti per nuovi effetti e forse un giorno la possibilità di una maggiore personalizzazione dei materiali, magari con un sistema simile a quello ad icone di UE3 così da darvi una certa flessibilità pur tenendo conto di valori predefiniti.
-Il codice: Per quanto riguarda il codice ho intenzione di prendere molto spunto dalla semplicità del gml ma facendo qualche leggero cambiamento per renderlo più veloce da eseguire e da scrivere.
A parte qualche aggiunta come una maggiore possibilità nell'uso degli array non ho intenzione di cambiarlo moltissimo tranne due semplici punti:
-Avrà una struttura più rigida quindi non a scelta come game maker dove potrete fare castroni di vari linguaggi, se decido di metterci i ; ci devono andare altrimenti non ci devono andare, fine. Questo a mio parere non farà altro che ridurre il numero di errori sintattici da parte degli utenti nonchè sarà più facile aiutarsi a vicenda senza mescolamenti tra il linguaggio più comodo per ognuno.
-Avrà la tipizzazione dei dati quindi ogni variabile dovrà avere un tipo impostato all'inizio dall'utente. Probabilmente alcuni di voi che si erano interessati al topic stavano già imprecando all'idea di ciò ma la mia scelta è giustificata da molti fattori. Un motivo è probabilmente quello di evitare errori dovuti alla differenza dei tipi, in parole più semplici capita molto spesso che utenti inesperti facciano casino tra numeri e stringhe provocando molto frequentemente errori. Con i tipi di dati scelti fin dall'inizio non ci saranno problemi di confusione di questo genere. Altro motivo, forse anche il più importante, è quello dell'interfaccia. Grazie ai tipi dei dati posso offrire molti aiuti nel code editor con un sistema simile all'intellisense di visual studio. Potrete avere sempre sott'occhio il tipo di dato, le sue caratteristiche, le funzioni utilizzabili, le variabili degli altri oggetti e molto altro. Insomma sviluppare il codice con le variabili tipizzate provoca meno errori, un codice più pulito e velocità nella scrittura. Tutto di guadagnato
Il codice è studiato per essere semplice e compilabile, tuttavia non ho alcuna intenzione di studiarmi l'asm e farmi un compilatore, specialmente vista la mole del programma.
La mia intenzione è quella di fare una specie di linguaggio semiinterpretato, in una maniera simile al java. Ancora non ho ben deciso come svilupparlo se compilare proprio in un linguaggio a basso livello come il java oppure tenere in memoria informazioni relative ai vari elementi del codice così da renderne forse anche più veloce l'esecuzione.
Non pretendo di raggiungere prestazioni simili al java tuttavia la struttura molto semplice e poco personalizzabile del linguaggio(che come ho detto è molto simile al gml, niente classi o cose strane definibili dall'utente, è un vero e proprio linguaggio di scripting) lo renderà veloce da interpretare quindi non si sa mai
Un'opzione suggeritami da slascio è stata quella di convertire il linguaggio in c++ quindi di compilarlo. Tuttavia anche se ciò rende più veloce e semplice da creare il sistema preferisco il linguaggio interpretato.
Un gioco in sviluppo necessita di molto testing e molto spesso poche modifiche apportate cambiano notevolmente il risultato finale, di conseguenza compilare per ore il tutto per ogni piccola modifica renderebbe snervante produrre qualcosa con il mio engine. Lo sviluppo sarebbe infinitamente più lento. Altro motivo infine è il doversi adeguare con i vari compilatori lasciando del lavoro da svolgere da parte dell'utente per le varie piattaforme anzichè un semplice launcher, uno per ogni piattaforma, che darà gli stessi risultati finali. Ultima cosa è la possibilità di poter modificare/aggiungere le varie risorse direttamente dal gioco anche se non ho intenzione di fare cose come execute_string() che rendono più complesso e buggabile il tutto, al massimo permetterò di cambiare/aggiungere eventi/oggetti/script.
Detto ciò a mio parere è sicuramente meglio fare un linguaggio interpretato(o meglio semiinterpretato) che, per quanto sia più lento e necessita di più lavoro da parte mia, offre una notevole quantità di vantaggi. Dopotutto essendo semiinterpretato non sarà lento come game maker ed ho intenzione di aggiungere un po di sintassi per velocizzare l'utilizzo di grosse moli di dati e per un linguaggio pensato allo scopo di esecuzione di eventi di vario genere la lentezza non si nota. Già non si nota con game maker se non per cose complesse che prevedono grosse quantità di dati come una struttura alla minecraft o motori di vario genere, qui prometto prestazioni sicuramente migliori. La sintassi più rigida e controllata solo una volta permetterà anche di avere una minore necessità di controllo degli errori del programmatore, che a mio parere rallenta moltissimo game maker, quindi non è un buon punto di riferimento per capire le prestazioni finali, solo il tempo potrà dirlo.
-La struttura interna:
Scendiamo quindi un po più nel dettaglio a vedere come ho pensato di gestire le varie parti del programma e darvi un'idea più dettagliata di ciò che ho in mente. Pensandoci bene sto post rischia di diventare 10 volte più lungo se scrivo tutto di tutto quindi cerco di limitarmi a dire i punti fondamentali, i dettagli li dirò solo a richiesta.
Il programma utilizzerà opengl 3.2, cosa significa ciò? Significa che se la vostra scheda video non supporta opengl 3.2 o superiore non potrete utilizzare il mio programma. Se avete una radeon dovete possedere almeno una ati radeon hd serie 3000. Dalla 2000 in giu è possibile che non sia compatibile tuttavia cè la possibilità che schede video che supportano opengl 3.0, 3.1 possano supportare opengl 3.2 ad eccezzione di certe limitazioni come il numero di texture units che potrebbe dare problemi.
"OMG! OMG!!! Quindi io non posso usare il tuo programma perchè ho una scheda troppo vecchia?"
Esatto, mettiti il cuore in pace.
"OMG! OMG!!! Ma quindi netbook e cellulari che hanno una shceda video non proprio potente non potranno utilizzare il tuo programma?"
E' qui che ti sbagli
Da opengl 3.0 in poi è entrato in atto il cosiddetto "deprecation model" che indica l'eliminazione di numerose vecchie funzionalità.
Con opengl 3 e 4 le vecchie funzionalità esistono ancora ma sono sconsigliate da utilizzare in quanto entro breve tempo verranno completamente eliminate e non sarà più possibile far girare vecchi programmi.
Io chiaramente preferisco tagliare fuori quei pochi che hanno una scheda video dell'anteguerra piuttosto che ritrovarmi con un programma inutilizzabile.
In secondo luogo dispositivi mobili di vario genere usano opengl es 2 che equivalgono ad opengl 3 con l'eccezione che sono già state eliminate le funzioni deprecate quindi se usassi le vecchie funzionalità non potrei più avere il supporto a cellulari di ultima generazione.
Sarò presuntuoso, ma io voglio guardare al futuro.
"OMG! OMG!!! Ma così facendo non appesentirai il tutto? Poi sui pc scrausi non funge più niente"
E qui ti sbagli di nuovo. Le nuove funzionalità non sono necessariamente poichè nuove, anzi!!! Le prestazioni aumenteranno notevolmente rispetto ad un sistema che utilizza il vecchio modo di fare nel campo della grafica.
"OMG! OM..."
Zitto! so quello che faccio!
Attualmente l'NJine lo svilupperò usando opengl 3.0 tuttavia per molte cose come il wireframe o il billboarding devo usare i geometry shader presenti solo da opengl 3.2 in poi(anche se è possibile usarli tramite alcune estensioni quindi potrebbe avere una discreta compatibilità con opengl 3.0 lo stesso)
Attualmente l'NJine è ancora in una fase primitiva, per ora sto cercando di farmi la libreria delle varie funzionalità che per ora testerò usando il c++ quindi il linguaggio di scripting sarà il lavoro finale in quanto si dovrà adattare alla struttura del resto del programma per poter essere utilizzato al meglio.
Una beta testabile sarà godibile tra parecchio tempo tuttavia vi terrò aggiornati su qualche risultato "guardabile" quindi senza possibilità di metterci le mani voi.
Il mio obiettivo è quello di fare un nuovo programma per lo sviluppo di giochi tridimensionali che prende spunto dalla semplicità di game maker e spero di portarlo su varie piattaforme.
Sono ancora indeciso sulla "licenza" che avrà questo programma fatto sta che il lavoro è immenso e lunghissimo e, almeno per ora, lo sto facendo interamente da solo. Detto ciò il programma è pensato per essere venduto, non nego che voglio guadagnarci sopra. Tuttavia è possibile che faccio una cosa simile a game maker con lite e pro edition, oppure programma gratuito se non vendete il gioco, a pagamento(soldi o percentuale) se mettete in vendita, oppure sarà da comprare e basta. Ancora non ho deciso che formula utilizzare e credo che sia inutile pensarci ora sappiate solo che non dimentico quindi mi sembra ovvio che coloro che mi aiuteranno nello sviluppo o nel testing o in qualche modo riceveranno una copia gratuita. Magari estendibile a tutti i gmitaliani così mi fate pubblicità
Tralasciando questo discorso io ho le idee ben chiare su cosa sto facendo ma chiaramente se avete idee su come migliorare il programma in qualche modo son ben disponibile ad ascoltare le vostre richieste. Ovviamente non ora visto che non sono sceso molto nel dettaglio e non avete idea di come verrà fuori il programma tuttavia se avete qualche suggerimento abbastanza generale o domande dite pure.
Avrei ancora moltissime/troppe cose da dire quindi ho deciso di fermarmi qua se non delucidazioni a richiesta.(qua sul topic intendo, non via pm, non vorrei ripetere mille volte le stesse cose
)Il programma è nato dalle vostre richieste e dalle vostre problematiche che io ho assimilato, molti di voi mi hanno aiutato indirettamente finora quindi sentitevi pure partecipi di dire la vostra. Come ho detto questo programma è pensato per essere semplice ed utilizzabile da chiunque quindi ogni richiesta è ben accetta.
) con linguaggio interpretato con un codice molto lungo e pesante perfino su dispositivi mobili.
è compresso.