View Full Version : Quale linguaggio per apprendere l'arte della programamzione videoludica?
American horizo
05-08-2011, 12:33
Premetto che è una cosa che più che altro vorrei imparare per semplice passione e curiosità, perchè essendo appassionato di VG, vorrei capire com'è che viene gestito, cos'è che genera i poligoni, le texture, i moviementi di un personaggio etc etc..
Dal punto di vista della programmazione ho qualche esperienza ma per il rendering grafico assolutamente no!
Vorrei capire da dove iniziare. Cercando su google mi è parso di capire che i giochi vengono solitamente realizzati con C++ che a sua volta si appoggia alle DirectX.
C++ è un linguaggio che va bene per realizzare programmi tipo gestionali, ma per realizzare invece applicazioni grafiche complesse, come appunto un videogioco, deve per forza appoggiarsi alle librerie DX.
Quindi per prima cosa dovrei avere un'infarinatura generale sul C++, poi approfondire il discorso sulla loro interpellazione da parte del C++.
Confermate?
pabloski
05-08-2011, 13:14
Non è un problema di linguaggio, dovresti studiarti come funziona il rendering 3D. Il linguaggio viene dopo ed è una scelta pratica, dovuta alla necessità di avere elevate performance.
DirectX non è l'unica libreria 3D, c'è anche Opengl che è altrettanto diffusa.
Puoi cominciare da qui http://nehe.gamedev.net/ studiandoti i legacy turorials. A quel punto avrai un'idea di come funziona il processo indipendentemente dalla libreria grafica usata.
Il linguaggio è davvero l'ultima cosa e nessun linguaggio di programmazione supporta nativamente il 3D, ma si appoggiano tutti a librerie esterne.
se ti dicessi che c'è più algebra lineare che programmazione nel mondo videoludico, ci crederesti?
banryu79
05-08-2011, 13:44
Per non parlare poi di come vengono realizzati e gestiti gli asset grafici, quella sì che è la parte effettivamente "artistica" della questione.
Per non parlare poi di come vengono realizzati e gestiti gli asset grafici, quella sì che è la parte effettivamente "artistica" della questione.
asset grafici?
asset grafici?
immagini sprite texture ecc ecc
immagini sprite texture ecc ecc
e parlate liscio :D
Non è un problema di linguaggio, dovresti studiarti come funziona il rendering 3D. Il linguaggio viene dopo ed è una scelta pratica, dovuta alla necessità di avere elevate performance.
This.
Ci sono un mucchio di modi per fare un videogame, e dipende tutto da cosa vuoi ottenere.
Cè Flash, FlashPunk, Unity, C++/OpenGL, C++/DX, C++/Ogre3D, ObjC/OpenGL, Python, Cocos2D, UDK, C#/XNA e che cavolo, pure Java :asd:
Ogni set di tool ha diversi punti di forza, diversi costi, diversi obiettivi. Ci sono quelli semplificati adatti al 2D (cocos, flash) quelli low level adatti a tutto (C++/OGL/DX), e un bel numero di vie di mezzo.
Quello che devi decidere quindi è prima di tutto cosa vuoi tu, quindi se vuoi imparare "come lo fanno i pro", oppure vedere un tuo gioco funzionante, oppure fare soldi con un gioco qualsiasi etc...
parti dal presupposto che imparare come fanno i pro E ANCHE fare qualcosa di utile nei primi mesi/anni è impossibile.
Nello specifico C++ è la cosa più difficile in assoluto (senza andare nei linguaggi esotici :D) specie in accoppiata con OpenGL.
Anche C# + XNA te lo sconsiglio, perchè viene spacciato per un game engine ma in realtà è un'API a basso livello (devi gestirti matrici e shader a mano, per dire).
Io credo che per imparare si debba prima capire il problema e capire come l'hanno risolto gli altri, quindi ti consiglierei di imparare le cose più semplici prima, come Flash + Flixel o Flashpunk o Python + Pygame/Pyglet/Cocos2D, e quando hai capito come si fa un gioco, approfondisci.
Sbattere la faccia contro C++ senza sapere nemmeno dove devi andare non ha mai aiutato nessuno :D
@Freaxxx: non ci crederebbe e farebbe proprio bene :asd:
This.
Ci sono un mucchio di modi per fare un videogame, e dipende tutto da cosa vuoi ottenere.
Cè Flash, FlashPunk, Unity, C++/OpenGL, C++/DX, C++/Ogre3D, ObjC/OpenGL, Python, Cocos2D, UDK, C#/XNA e che cavolo, pure Java :asd:
Ogni set di tool ha diversi punti di forza, diversi costi, diversi obiettivi. Ci sono quelli semplificati adatti al 2D (cocos, flash) quelli low level adatti a tutto (C++/OGL/DX), e un bel numero di vie di mezzo.
Quello che devi decidere quindi è prima di tutto cosa vuoi tu, quindi se vuoi imparare "come lo fanno i pro", oppure vedere un tuo gioco funzionante, oppure fare soldi con un gioco qualsiasi etc...
parti dal presupposto che imparare come fanno i pro E ANCHE fare qualcosa di utile nei primi mesi/anni è impossibile.
Nello specifico C++ è la cosa più difficile in assoluto (senza andare nei linguaggi esotici :D) specie in accoppiata con OpenGL.
Anche C# + XNA te lo sconsiglio, perchè viene spacciato per un game engine ma in realtà è un'API a basso livello (devi gestirti matrici e shader a mano, per dire).
Io credo che per imparare si debba prima capire il problema e capire come l'hanno risolto gli altri, quindi ti consiglierei di imparare le cose più semplici prima, come Flash + Flixel o Flashpunk o Python + Pygame/Pyglet/Cocos2D, e quando hai capito come si fa un gioco, approfondisci.
Sbattere la faccia contro C++ senza sapere nemmeno dove devi andare non ha mai aiutato nessuno :D
@Freaxxx: non ci crederebbe e farebbe proprio bene :asd:
poi mi fai sapere come calcoli luci, movimenti e renderizzi i frame e fai tutto ;)
American horizo
05-08-2011, 14:57
This.
Ci sono un mucchio di modi per fare un videogame, e dipende tutto da cosa vuoi ottenere.
Cè Flash, FlashPunk, Unity, C++/OpenGL, C++/DX, C++/Ogre3D, ObjC/OpenGL, Python, Cocos2D, UDK, C#/XNA e che cavolo, pure Java :asd:
Ogni set di tool ha diversi punti di forza, diversi costi, diversi obiettivi. Ci sono quelli semplificati adatti al 2D (cocos, flash) quelli low level adatti a tutto (C++/OGL/DX), e un bel numero di vie di mezzo.
Quello che devi decidere quindi è prima di tutto cosa vuoi tu, quindi se vuoi imparare "come lo fanno i pro", oppure vedere un tuo gioco funzionante, oppure fare soldi con un gioco qualsiasi etc...
bhe come hai detto successivamente, meglio partire dal basso, quindi con cose "semplici" realizzate in flash + flixel.. fortunatamente alcue cose dell'actionscript 3 già le conosco quindi non dovrei trovare problemi ad interpretare il singificato di alcuni algoritmi..
Poi se proprio ci tengo approfondire come i PRO... partire subito con l'obiettivo di imparare da PRO è assurdo!
pabloski
05-08-2011, 15:14
bhe come hai detto successivamente, meglio partire dal basso, quindi con cose "semplici" realizzate in flash + flixel.. fortunatamente alcue cose dell'actionscript 3 già le conosco quindi non dovrei trovare problemi ad interpretare il singificato di alcuni algoritmi..
Poi se proprio ci tengo approfondire come i PRO... partire subito con l'obiettivo di imparare da PRO è assurdo!
Ecco, questo è il punto....bisogna decidere in che modo si vuole affrontare il problema.
C'è la possibilità di affrontarlo dal lato "matematico" oppure da un un punto di vista più "alto".
Se si parte con directx o opengl, allora si sta lavorando ad un livello abbastanza basso ed è fondamentale conoscere la logica che sta dietro la creazione, gestione e trasformazione degli oggetti 3D.
C'è pure la grafica 2D da cui si può partire e che è decisamente più potabile rispetto alla controparte 3D.
Ma rimane il punto che il linguaggio è quello che c'entra di meno in tutto questo.
American horizo
05-08-2011, 15:34
Ecco, questo è il punto....bisogna decidere in che modo si vuole affrontare il problema.
C'è la possibilità di affrontarlo dal lato "matematico" oppure da un un punto di vista più "alto".
Se si parte con directx o opengl, allora si sta lavorando ad un livello abbastanza basso ed è fondamentale conoscere la logica che sta dietro la creazione, gestione e trasformazione degli oggetti 3D.
C'è pure la grafica 2D da cui si può partire e che è decisamente più potabile rispetto alla controparte 3D.
Ma rimane il punto che il linguaggio è quello che c'entra di meno in tutto questo.
Per livelli "basso" ed"altro" intendi i livelli di programmazione, ovvero, che più si va in "basso" più si scende al linguaggio macchina ergo più è difficile?
Cmq sto dando un'occhiata a Flixel, siccome in testa ho un po di casino, partendo dal presupposto che conosco abbastanza il funzionamento di AS3, facciamo chiarezza prendendo proprio questo come esempio: L'AS3 sta Flixel come C++ sta a dirextx/openGL?
E' di questo che stiamo parlando?
In flash queste classi tipo Flixel (che non conoscevo, fino ad oggi ho utilizzato solo le caurina e greensock per degli effetti di transizione) sono una sorta di librerie esterne a cui aggiungo per applicare effetti a determinati oggetti. Questo perchè Flash non prevede questo tipo di effetti di default.
Quindi è questo il concetto del rapporto tra il C++ e DirectX?
Poi ho ancora un altro dubbio circa questo punto:
Se si parte con directx o opengl, allora si sta lavorando ad un livello abbastanza basso ed è fondamentale conoscere la logica che sta dietro la creazione, gestione e trasformazione degli oggetti 3D.
La creazione degli oggetti 3D viene programmata munualmente? No perchè proprio vedendo i programmatori SUPER-PRO quali quelli che fanno giochi commerciali per PS3, i modelli 3D li creano tramite degli editor tipo Maya3D, o almeno questo è quanto ho intravisto in un documentario sull'argomento :confused:
AGGIUNGO: ad esempio, nella grafica 2D di flash ho due possibilità per creare un semplice quadrato dal colore uniforme: realizzarlo tramite codice oppure tramite l'editor di Flash.. Nel primo caso in AS3 inizializzo uno shape di tipo rettangolo e comunico la destinazione che dovrà avere ciascun lato della figura, nel secondo ci metto due secondi a farlo tramite l'apposito tool dell'interfaccia flash.
banryu79
05-08-2011, 15:42
La creazione degli oggetti 3D viene programmata munualmente? No perchè proprio vedendo i programmatori SUPER-PRO quali quelli che fanno giochi commerciali per PS3, i modelli 3D li creano tramite degli editor tipo Maya3D, o almeno questo è quanto ho intravisto in un documentario sull'argomento :confused:
Per l'appunto:
Per non parlare poi di come vengono realizzati e gestiti gli asset grafici, quella sì che è la parte effettivamente "artistica" della questione.
Prendi un gioco tripla A moderno, e vai a vedere quante sono le persone dedicate alla creazione e gestione dei contenuti grafici rispetto a quelle che programmanno e basta.
American horizo
05-08-2011, 15:58
Per l'appunto:
Prendi un gioco tripla A moderno, e vai a vedere quante sono le persone dedicate alla creazione e gestione dei contenuti grafici rispetto a quelle che programmanno e basta.
bhe quindi la mera "programmazione" in cosa si applica nel contesto della creazione di elementi 3D poligonari? Avrei capito se non ci fossero stati editor appositi come maya, in quel caso sarebbe stato un inferno e di sicuro i vg oggi avrebbero tutt'altra qualità visiva
poi mi fai sapere come calcoli luci, movimenti e renderizzi i frame e fai tutto ;)
Faccio così (https://bitbucket.org/tommo89/dojo) ;)
Le luci (senza shaders) e il "renderizzare i frame" (che intendi?) fa tutto la GPU, che c'entra la matematica lineare?
Certo, i vettori sono poco meno comuni degli int nel codice... ma te la puoi cavare benissimo con una conoscenza superficiale, e di sicuro la matematica lineare non è il primo problema da risolvere.
Assume un'importanza minima solo nel momento in cui stai scrivendo una tua engine, ma in finale tutto si riassume in moltiplicazioni di matrici 4x4.
Conoscere la matematica lineare aiuta un sacco se ti trovi a fare grafica 3D avanzata (shaders) ma consigliarlo a qualcuno che sta a 0 è del tutto fuori luogo imo.
@American: si e no. AS3 è il linguaggio come C++, e fin qui ci siamo.
Poi è abbastanza diverso:
DirectX è una "System API", cioè è una libreria di sistema che fornisce un'insieme di roba per il gaming, quindi grafica ma anche input, sonoro, e altro, il tutto molto a basso livello con gran trafficare di memoria e algebra lineare. Niente collisioni, fisica, salvataggi, gameplay, caricamento delle risorse etc.
OpenGL è ancora peggio, perchè è un pò più spartana di DX nella parte grafica e manca completamente di tutto il resto.
Flixel e Flashpunk non li ho mai usati, ma da quello che so sono game frameworks, quindi sempre librerie più o meno passive ma che idealmente forniscono ad alto livello tutto quello che ti serve per fare il gioco, quindi sprites, salvataggi, animazioni, collisioni, etc.
Se dovessi fare un paragone in C++, direi che sono al livello di Ogre3D e simili.
Più in alto ci sono le "game engines" cioè motori precostruiti che eseguono il tuo codice (non vengono semplicemente chiamate) e forniscono tutta la suite di tool per gli artist, fisica, collisioni, sonoro, tutto.
La più potente e completa è sicuramente UDK ma è anche un casino da usare, e un'altra scelta comune è Unity3D che si scripta in C#.
American horizo
05-08-2011, 16:49
ok, diciamo che fixel è più user-friendly di directx, ma pur sempre di librerie esterne stiamo parlando no?
Devo capire almeno il concetto, che poi direcx sia di più basso livello rispertto a fixel è un altro discorso
C++ a parte STL non ha "librerie interne", quindi si, sono tutte librerie esterne, di terze parti :D
fa tutto la GPU
e secondo te la GPU che fa se non calcolo matriciale nel 99% dei casi? e secondo te tu che programmi se non algebra lineare? Il fatto che ti viene nascosto cosa avviene, almeno usando linguaggi di alto livello, non significa che ha ragione il linguaggio di alto livello e torto quelli che hanno progettato la GPU.
American horizo
05-08-2011, 16:57
Ok, e invece per il discorso della matematica lineare applicata alla questione della modellazione 3D, perchè nel documentario di god of war III presente nel disco di gioco, il team lavora con software come maya 3D per creare quelli che sono appunto i modelli poligonari del gioco? Quando e come entra in gioco l'applicazione della matematica lineare?
Ok, e invece per il discorso della matematica lineare applicata alla questione della modellazione 3D, perchè nel documentario di god of war III presente nel disco di gioco, il team lavora con software come maya 3D per creare quelli che sono appunto i modelli poligonari del gioco? Quando e come entra in gioco l'applicazione della matematica lineare?
in tutto, la matematica gestisce qualsiasi cosa:
- gli shader
- i movimenti
- il rendering e il calcolo di ciò che va spedito al framebuffer
- le luci
- i materiali
qualsiasi cosa è matematica, non lo dico per dire, i migliori libri per sviluppatori sono inzuppati di matematica.
ad esempio una rotazione di un oggetto qualsiasi è data da un sistema lineare di funzioni armoniche ( seno e coseno )
cosa renderizzare, cioé quale parte considerare, per poi produrre un frame, cioé una immagine in 2D, lo decidi sempre con del calcolo matriciale e proiezioni sugli assi; se tu hai una macchina su schermo messa di lungo, ad esempio, il fatto che tu veda solo 2 ruote e il fianco della macchina lo devi alla GPU che calcola la posizione dell'oggetto, calcola la posizione della telecamera, fa una proiezione dell'oggetto e te la mostra come frame.
è improprio dire che quello su schermo è il tuo oggetto, è più corretto dire che è una sua proiezione.
luci, materiale e tutto il resto seguono sempre leggi matematiche e valori numerici, dal colore alla forma fai tutto con la matematica.
cdimauro
05-08-2011, 17:10
DirectX non è l'unica libreria 3D, c'è anche Opengl che è altrettanto diffusa.
Non nell'ambito dei videogiochi, che è ciò che interessa in questo thread.
Inoltre, come dice Tommo, è più grezza e di più basso livello, e manca di tanta roba.
Anche C# + XNA te lo sconsiglio, perchè viene spacciato per un game engine
Spacciato da chi? :confused:
Io credo che per imparare si debba prima capire il problema e capire come l'hanno risolto gli altri, quindi ti consiglierei di imparare le cose più semplici prima, come Flash + Flixel o Flashpunk o Python + Pygame/Pyglet/Cocos2D, e quando hai capito come si fa un gioco, approfondisci.
Sbattere la faccia contro C++ senza sapere nemmeno dove devi andare non ha mai aiutato nessuno :D
Concordo.
American horizo
05-08-2011, 17:12
in tutto, la matematica gestisce qualsiasi cosa:
- gli shader
- i movimenti
- il rendering e il calcolo di ciò che va spedito al framebuffer
- le luci
- i materiali
qualsiasi cosa è matematica, non lo dico per dire, i migliori libri per sviluppatori sono inzuppati di matematica.
ad esempio una rotazione di un oggetto qualsiasi è data da un sistema lineare di funzioni armoniche ( seno e coseno )
cosa renderizzare, cioé quale parte considerare, per poi produrre un frame, cioé una immagine in 2D, lo decidi sempre con del calcolo matriciale e proiezioni sugli assi; se tu hai una macchina su schermo messa di lungo, ad esempio, il fatto che tu veda solo 2 ruote e il fianco della macchina lo devi alla GPU che calcola la posizione dell'oggetto, calcola la posizione della telecamera, fa una proiezione dell'oggetto e te la mostra come frame.
è improprio dire che quello su schermo è il tuo oggetto, è più corretto dire che è una sua proiezione.
luci, materiale e tutto il resto seguono sempre leggi matematiche e valori numerici, dal colore alla forma fai tutto con la matematica.
Quindi la proiezione di un modello devi calcolarla tu tramite formule matematiche... credevo che, conoscendo la distanza della telecamera, la rotazione del modello e gli input dell'utente, l'engine facesse tutto automaticamente
Quindi la proiezione di un modello devi calcolarla tu tramite formule matematiche... credevo che, conoscendo la distanza della telecamera, la rotazione del modello e gli input dell'utente, l'engine facesse tutto automaticamente
dipende da che accoppiata scegli tra linguaggio e librerie/framework, certo se usi C# e XNA farai molte meno cose che con C e OpenGL, però è anche vero che potrai mettere mano a molti meno parametri.
comunque sia, se non hai studiato l'algebra lineare e programmazione ad un buon livello è come se non ti avessi detto niente, devi capire i concetti che stanno alla base della grafica prima di fare valutazioni del genere, altrimenti spari sul mucchio e peschi un framework qualsiasi.
se vuoi un inizio facile usa XNA.
American horizo
05-08-2011, 17:24
dipende da che accoppiata scegli tra linguaggio e librerie/framework, certo se usi C# e XNA farai molte meno cose che con C e OpenGL, però è anche vero che potrai mettere mano a molti meno parametri.
comunque sia, se non hai studiato l'algebra lineare e programmazione ad un buon livello è come se non ti avessi detto niente, devi capire i concetti che stanno alla base della grafica prima di fare valutazioni del genere, altrimenti spari sul mucchio e peschi un framework qualsiasi.
se vuoi un inizio facile usa XNA.
non sarebbe meglio, come suggerito addietro, iniziare a capire prima la logica alla base dei giochi 2D, utilizzando ad esempio flash/AS3 + fixel ?
Quindi la proiezione di un modello devi calcolarla tu tramite formule matematiche... credevo che, conoscendo la distanza della telecamera, la rotazione del modello e gli input dell'utente, l'engine facesse tutto automaticamente
-gli shader: ok alcuni shader richiedono conoscenze di geometria pesanti. ma sono del tutto ignorabili da un principiante.
-i "movimenti" li calcoli con banali somme e sottrazioni di vettori, di solito. Basta avere un vettore posizione su cui operi.
Poi se te muovi l'omino moltiplicando matrici sei te che sbagli, non è "la matematica" :asd:
Se intendevi le trasformazioni, ci sono un mucchio di librerie che lo fanno per te, inclusa OpenGL.
-"il calcolo di ciò che va spedito al framebuffer" non significa nulla, il "rendering" lo fa la scheda video.
Se intendevi le drawcalls, quelle non vedono la matematica nemmeno da lontano
-le luci, le fanno gli shader. Se non le fanno gli shader, una luce è un vettore posizione che dai in pasto all'API e te ne dimentichi. Illustrami dov'è che sta la matematica in
glLightf( GL_LIGHT0, GL_POSITION, coords );
-i materiali: sono sempre gli shader, e sempre senza shader sono parametri float del tutto arbitrari, sono colori... che c'entra la geometria?
Fidati che so di che sto parlando, non sarò una cima ma qualche giochino l'ho pubblicato :D
#cdimauro: MS ha "spacciato" nel marketing XNA come la migliore scelta per i principianti... ma non è vero, perchè è un'API piuttosto complessa e a basso livello.
Infatti si vede dal livello tristissimo dei giochi XBLIG :asd:
XNA è precisamente DirectX wrappata in C# con appiccicata sopra la gestione delle risorse. Niente di più, niente di meno.
American horizo
05-08-2011, 17:39
insomma mi pare di capire che avere opinioni altamente constrastanti :D
non sarebbe meglio, come suggerito addietro, iniziare a capire prima la logica alla base dei giochi 2D, utilizzando ad esempio flash/AS3 + fixel ?
e perché io di che ti sto parlando? e gli altri?
che logica intendi? è tutta matematica, più ti scegli un linguaggio e un framework di alto livello e meno matematica vedi, e ti illudi come il buon Tommo che la matematica non c'entri nulla, più di abbassi con il linguaggio e il framework e più vai a gestire anche i singoli punti.
presumo che tu non sia interessato a questo, quindi fai una ricerca su Google del tipo "AS3 libreria giochi" e bon.
-gli shader: ok alcuni shader richiedono conoscenze di geometria pesanti. ma sono del tutto ignorabili da un principiante.
-i "movimenti" li calcoli con banali somme e sottrazioni di vettori, di solito. Basta avere un vettore posizione su cui operi.
Poi se te muovi l'omino moltiplicando matrici sei te che sbagli, non è "la matematica" :asd:
Se intendevi le trasformazioni, ci sono un mucchio di librerie che lo fanno per te, inclusa OpenGL.
-"il calcolo di ciò che va spedito al framebuffer" non significa nulla, il "rendering" lo fa la scheda video.
Se intendevi le drawcalls, quelle non vedono la matematica nemmeno da lontano
-le luci, le fanno gli shader. Se non le fanno gli shader, una luce è un vettore posizione che dai in pasto all'API e te ne dimentichi. Illustrami dov'è che sta la matematica in
glLightf( GL_LIGHT0, GL_POSITION, coords );
-i materiali: sono sempre gli shader, e sempre senza shader sono parametri float del tutto arbitrari, sono colori... che c'entra la geometria?
Fidati che so di che sto parlando, non sarò una cima ma qualche giochino l'ho pubblicato :D
#cdimauro: MS ha "spacciato" nel marketing XNA come la migliore scelta per i principianti... ma non è vero, perchè è un'API piuttosto complessa e a basso livello.
Infatti si vede dal livello tristissimo dei giochi XBLIG :asd:
XNA è precisamente DirectX wrappata in C# con appiccicata sopra la gestione delle risorse. Niente di più, niente di meno.
la stai buttando quasi in caciara, o non ti rendi conto di quello che scrivi o sei brillo ...
American horizo
05-08-2011, 17:45
e perché io di che ti sto parlando? e gli altri?
hai detto che conviene inziiare dall'XNA, e non credo che sia una libreria dedicata prettamente al rendering 2d, tant'è se se non sbaglio è la libreria su cui si affidano i live arcade della 360, o comunque gli indie games che non sempre sono 2D
hai detto che conviene inziiare dall'XNA, e non credo che sia una libreria dedicata prettamente al rendering 2d, tant'è se se non sbaglio è la libreria su cui si affidano i live arcade della 360, o comunque gli indie games che non sempre sono 2D
guarda che tutto il rendering odierno è in 2D fino a prova contraria, non mi risulta altro ... a meno che non abbiano inventato monitor capaci di riprodurre in 3D come gli ologrammi in guerre stellari.
American horizo
05-08-2011, 18:23
guarda che tutto il rendering odierno è in 2D fino a prova contraria, non mi risulta altro ... a meno che non abbiano inventato monitor capaci di riprodurre in 3D come gli ologrammi in guerre stellari.
ma per "rendering 2D" intendo il rendering dei giochi bidimensionali in cui ci si può muovere solo sugli assi X e Y del sistema cartesiano, mi sembra ovvio...
pabloski
05-08-2011, 18:38
Per livelli "basso" ed"altro" intendi i livelli di programmazione, ovvero, che più si va in "basso" più si scende al linguaggio macchina ergo più è difficile?
il basso è più matematico e meno automizzato
per esempio puoi creare un gioco con ogre ( che un 3d engine ) e pur dovendo conoscere alcune cose riguardo la gestione degli oggetti 3d è comunque molto molto più semplice di usare direttamente directx o opengl
Cmq sto dando un'occhiata a Flixel, siccome in testa ho un po di casino, partendo dal presupposto che conosco abbastanza il funzionamento di AS3, facciamo chiarezza prendendo proprio questo come esempio: L'AS3 sta Flixel come C++ sta a dirextx/openGL?
E' di questo che stiamo parlando?
si e no, nel senso che flixel è una libreria di gaming scritta in as3 ma sotto il cofano sfrutta opengl e/o directx per gestire gli oggetti 3d
solo che tutto questo tu programmatore non lo vedi, ma vedi una realtà semplificata è molto più ricca di strumenti per svolgere funzioni complesse in 2 righe di codice
La creazione degli oggetti 3D viene programmata munualmente? No perchè proprio vedendo i programmatori SUPER-PRO quali quelli che fanno giochi commerciali per PS3, i modelli 3D li creano tramite degli editor tipo Maya3D, o almeno questo è quanto ho intravisto in un documentario sull'argomento :confused:
la mesh in genere è stoccata in un file e viene letta dal 3d engine per essere usata per gli scopi più svariati
ovviamente nessuno è tanto folle da creare un oggetto da milioni di poligoni scrivendo glVertex a go-go
i programmi come maya, blender, 3ds sono capaci di esportare le mesh in vari formati importabili dagli engine 3d
AGGIUNGO: ad esempio, nella grafica 2D di flash ho due possibilità per creare un semplice quadrato dal colore uniforme: realizzarlo tramite codice oppure tramite l'editor di Flash..
è proprio quella la differenza, ovvero o chiami delle funzioni per disegnare il quadrato o li disegni tramite un editor e poi lo esporti tramite un file in un certo formato
American horizo
05-08-2011, 19:02
e negli editor tipo maya vengono realizzate pure le varie animazioni dei vari modelli poligonari?
Quand'è che poi tutto passa alla fase di pura programmazione?
darkito85
05-08-2011, 19:19
e negli editor tipo maya vengono realizzate pure le varie animazioni dei vari modelli poligonari?
Quand'è che poi tutto passa alla fase di pura programmazione?
La fase di pura programmazione è creare il motore grafico che ti permette di importare i modelli creati con l'editor (tipo maya).
E qui inizia la via crucis. A seconda della libreria di cui fai uso devi gertirti in maniera più o meno di basso livello le rotazioni, le trasformazioni, illuminazioni etc etc.
Se proprio vuoi iniziare a programmare un videogioco inizia con un gioco 2D. Ovviamente devi avere una minima conoscenza di algebra lineare.
American horizo
05-08-2011, 19:46
La fase di pura programmazione è creare il motore grafico che ti permette di importare i modelli creati con l'editor (tipo maya).
E qui inizia la via crucis. A seconda della libreria di cui fai uso devi gertirti in maniera più o meno di basso livello le rotazioni, le trasformazioni, illuminazioni etc etc.
Se proprio vuoi iniziare a programmare un videogioco inizia con un gioco 2D. Ovviamente devi avere una minima conoscenza di algebra lineare.
Uhm forse ho capito :stordita:
partendo dal basso verso l'alto abbiamo:
assembly-->directX o OpenGL-->engine grafico
L'engine grafico è dunque un "motore" realizzato sulla base delle directx/OpenGL atto a semplificare la vita dello sviluppatore. Presupponendo che esso sia già pronto, è lui che gestisce le rotazioni, trasformazioni e illuminazioni dei modelli poligonati, non è che devo programmarmele io da 0
Dunque presupponendo che io mi metta a programmare un gioco basato sul Source Engine per esempio, è lui che si interfaccia con le directX/openGL al fine di gestire le trasformazioni, rotazioni, illuminazioni e via discorrendo.
Sarebbe assurdo pensare di programmare ogni gioco "dialogando" ogni volta direttamente con le directX. D'altra parte pure le grandi SH riciclano i propri engine su più prodotti e talvolta si affidano addirittura ad engine relizzati completamente da terzi..
c'ho azzeccato??
pabloski
05-08-2011, 22:00
Uhm forse ho capito :stordita:
partendo dal basso verso l'alto abbiamo:
assembly-->directX o OpenGL-->engine grafico
L'engine grafico è dunque un "motore" realizzato sulla base delle directx/OpenGL atto a semplificare la vita dello sviluppatore. Presupponendo che esso sia già pronto, è lui che gestisce le rotazioni, trasformazioni e illuminazioni dei modelli poligonati, non è che devo programmarmele io da 0
Dunque presupponendo che io mi metta a programmare un gioco basato sul Source Engine per esempio, è lui che si interfaccia con le directX/openGL al fine di gestire le trasformazioni, rotazioni, illuminazioni e via discorrendo.
Sarebbe assurdo pensare di programmare ogni gioco "dialogando" ogni volta direttamente con le directX. D'altra parte pure le grandi SH riciclano i propri engine su più prodotti e talvolta si affidano addirittura ad engine relizzati completamente da terzi..
c'ho azzeccato??
si la faccenda è questa
guarda ad esempio ogre che funzionalità supporta http://www.ogre3d.org/tikiwiki/Current+Ogre+Features
ad esempio:
- Flexible fog control
- Particle Systems
- Terrain plugin allows you to render geo-mipmapped terrains
- Skeletal animation ( è una delle migliori tecniche per l'animazione dei personaggi 3d )
tutto questo ti costa praticamente zero, altrimenti dovresti svilupparlo tu ( compresa tutta la parte matematica che ci sta sotto )
la stai buttando quasi in caciara, o non ti rendi conto di quello che scrivi o sei brillo ...
Sono contento che tu la pensi così, ricambio caldamente con una pessima opinione su di te :D
Impara a discutere e a ascoltare gli altri, fai un favore al forum. Thxbye,
Per il resto quoto gli altri che hanno dimostrato di sapere che dicono.
cdimauro
06-08-2011, 05:35
#cdimauro: MS ha "spacciato" nel marketing XNA come la migliore scelta per i principianti... ma non è vero, perchè è un'API piuttosto complessa e a basso livello.
Infatti si vede dal livello tristissimo dei giochi XBLIG :asd:
XNA è precisamente DirectX wrappata in C# con appiccicata sopra la gestione delle risorse. Niente di più, niente di meno.
OK, ma non ha mai detto che fosse un engine, che io ricordi.
@American horizo: visto che sei proprio terra-terra, al momento segui il consiglio di Tommo. Quindi parti con qualche gioco 2D e poi passa al 3D.
Su Appunti Digitali sono stati scritti diversi articoli in proposito, basandosi su PyGame, che hanno coperto tutto quello che riguarda il 2D (compresa l'isometria e il parallasse), e da poco si è iniziato a parlare di 3D con un engine estremamente semplice da usare (Panda3D, realizzato dalla Disney tra l'altro).
American horizo
06-08-2011, 05:59
si la faccenda è questa
guarda ad esempio ogre che funzionalità supporta http://www.ogre3d.org/tikiwiki/Current+Ogre+Features
ad esempio:
- Flexible fog control
- Particle Systems
- Terrain plugin allows you to render geo-mipmapped terrains
- Skeletal animation ( è una delle migliori tecniche per l'animazione dei personaggi 3d )
tutto questo ti costa praticamente zero, altrimenti dovresti svilupparlo tu ( compresa tutta la parte matematica che ci sta sotto )
ok ma allora perchè tutti hanno cominciato a parlare di algoritmi matematici per gli shader, le telecamere e via discorrendo? Essendo praticamente a 0 è inopportuno parlare di come si sviluppa un vero e proprio engine, ovvio che come minimo dovrei affidarmi ad uno già bello che pronto
cdimauro
06-08-2011, 08:19
Beh, è facile che si parta per la tangente, ma dipende anche da quello che scrivi. :)
Diciamo che, appurato che tu parti proprio da zero, è meglio che segui il percorso che ti ho indicato qui alla fine.
In questo modo ti concentri sui concetti che devi assimilare, e vai avanti imparando prima a realizzare giochi 2D e poi 3D.
Una volta che ti sarai formato il giusto bagaglio culturale, potrai poi passare a complicarti la vita con C++ et similia. :D
American horizo
06-08-2011, 12:16
Ma pygame è un engine?
Poi giusto per capire la gerarchia delle cose, semmai arriverò a programmare in c++, da questo dovrei comunque interfacciarmi con un engine che a sua volta si interfaccia alle dx, è corretto?
Quindi avrei: c++--->engine--->directX
cdimauro
06-08-2011, 12:27
Ma pygame è un engine?
No, è una libreria per Python che semplifica molto la vita a chi vuol realizzare giochi 2D.
Nei giochi 2D diciamo che il concetto di engine non esiste o comunque non è forte come quello dei giochi 3D, data la notevole semplicità dei primi.
Poi giusto per capire la gerarchia delle cose, semmai arriverò a programmare in c++, da questo dovrei comunque interfacciarmi con un engine che a sua volta si interfaccia alle dx, è corretto?
Quindi avrei: c++--->engine--->directX
Parlando astrattamente e rimanendo legati ai giochi commerciali, diciamo di sì.
Considera, comunque, che anche l'engine e le DirectX sono scritte in qualche linguaggio, che generalmente è il C++ (magari con qualche pezzo di assembly).
American horizo
06-08-2011, 12:55
No, è una libreria per Python che semplifica molto la vita a chi vuol realizzare giochi 2D.
quindi il pygame è una sorta di directx?
cdimauro
06-08-2011, 13:47
Sì, ma nasconde tanti dettagli di basso livello, facilitandoti molto la realizzazione di videogiochi (in particolare 2D).
ma per "rendering 2D" intendo il rendering dei giochi bidimensionali in cui ci si può muovere solo sugli assi X e Y del sistema cartesiano, mi sembra ovvio...
non ti è chiaro cos'è un processo di rendering, il processo di rendering inizia dalle informazioni che hai e che vuoi applicare al tuo oggetto, il suo modello 3D, gli shader, le luci, e finisce all'arrivo al framebuffer, ovvero lo schermo.
su quali assi muoversi è ininfluente, la pipeline di rendering è sempre la stessa, le formule matematiche sono più facili e quindi l'unico risultato è che un gioco con un mondo in 2D è più facile da programmare e richiede meno risorse ( tipicamente ) di un gioco 3D.
Sono contento che tu la pensi così, ricambio caldamente con una pessima opinione su di te :D
Impara a discutere e a ascoltare gli altri, fai un favore al forum. Thxbye,
Per il resto quoto gli altri che hanno dimostrato di sapere che dicono.
qualsiasi testo e grafico su anche una semplicissima pipeline per il rendering 3D/2D ti riporta accenni alla matematica e si fonda sulla matematica, è semplicemente così, e così funziona.
di dare una brutta opinione dal punto di vista umano su un forum me ne può interessare di meno visto che di tutto si tratta tranne che di rapporti umani, ci si deve comportare bene questo si, ma da qui a poter valutare una persona ce ne passa.
persino wikipedia ne fa accenno http://it.wikipedia.org/wiki/Rendering
La matematica usata nel rendering include: algebra lineare, calcolo numerico, analisi numerica, analisi digitale di segnali, metodo Montecarlo
con questo mi sembra di aver concluso dato che già hai buttato la discussione su un altro livello e su altri argomenti, meglio finirla qui.
con questo mi sembra di aver concluso dato che già hai buttato la discussione su un altro livello e su altri argomenti, meglio finirla qui.
Abbi pazienza, ma mi sembra che non sai di che stai parlando... è ovvio e scontato che quel tipo di argomenti è fondamentale per il "rendering", cioè se vuoi implementare un render da zero.
Tuttavia la stragrande maggioranza degli argomenti trattati da wiki vengono utilizzati nella scheda video, nell'API o nel motore di turno, e il risultato finale è che per fare un gioco 2D tipico, puoi permetterti di ignorarli quasi del tutto.
Ovvio che man mano che vuoi creare gameplay complessi etc ti servirà sapere sempre più cose, ivi compresa la matematica.
Ma consigliarlo a uno che deve ancora iniziare è del tutto fuori luogo, perchè NON serve nella pratica.
E ti ripeto la domanda, quanti giochi hai completato? così, per sapere. E spero che la risposta non sia zero.
American horizo
06-08-2011, 15:02
non ti è chiaro cos'è un processo di rendering, il processo di rendering inizia dalle informazioni che hai e che vuoi applicare al tuo oggetto, il suo modello 3D, gli shader, le luci, e finisce all'arrivo al framebuffer, ovvero lo schermo.
si ma tu hai tirato in ballo gli ologrammi, che c'entra
questa è un'immagine renderizzata in 3D
http://upload.wikimedia.org/wikipedia/commons/c/c1/Staunton_set4.jpg
e non è mica un ologramma
Abbi pazienza, ma mi sembra che non sai di che stai parlando... è ovvio e scontato che quel tipo di argomenti è fondamentale per il "rendering", cioè se vuoi implementare un render da zero.
Tuttavia la stragrande maggioranza degli argomenti trattati da wiki vengono utilizzati nella scheda video, nell'API o nel motore di turno, e il risultato finale è che per fare un gioco 2D tipico, puoi permetterti di ignorarli quasi del tutto.
Ovvio che man mano che vuoi creare gameplay complessi etc ti servirà sapere sempre più cose, ivi compresa la matematica.
Ma consigliarlo a uno che deve ancora iniziare è del tutto fuori luogo, perchè NON serve nella pratica.
E ti ripeto la domanda, quanti giochi hai completato? così, per sapere. E spero che la risposta non sia zero.
ok.
si ma tu hai tirato in ballo gli ologrammi, che c'entra
questa è un'immagine renderizzata in 3D
http://upload.wikimedia.org/wikipedia/commons/c/c1/Staunton_set4.jpg
e non è mica un ologramma
ho tentato di spiegarti che cosa avviene in fase di rendering e che cos'è una immagine renderizzata, dopo che tu hai affermato che è possibile renderizzare in 3D ti ho fatto l'esempio degli ologrammi.
visto che non ci riesco mi sembra inutile andare avanti, compra un libro sul linguaggio che ti interessa e buono studio.
ok.
ok non è un numero :asd:
banryu79
06-08-2011, 17:32
ok non è un numero :asd:
Magari l'ha espresso in ascii -> o -> 111, k -> 107, dunque ben 111107 giochi, mi sa che ti ha stracciato :D
se ti dicessi che c'è più algebra lineare che programmazione nel mondo videoludico, ci crederesti?
Non sono assolutamente d'accordo.
Hai idea di quanto sia difficile portare avanti una applicazione c++ multipiattaforma di grandi dimensioni?
Ci sono difficoltà enormi a tutti i livelli. Innanzitutto ci sono problemi organizzativi e legati alla metodologia di sviluppo. In italia ci sono team che lavorano su grandi applicazioni c++ senza utilizzare controllo di versione e senza sapere cosa sia uno unit test. Ovviamente falliscono miseramente.
Anche solo il cosidetto physical design, ovvero l'organizzazione del sorgente in file e directory è assolutamente non banale e sono stati scritti libri in proposito.
E poi addentrandoci sulla programmazione guarda che un game engine non è solo grafica. Al giorno d'oggi si investe tantissimo sui tool e son software di una complessità inaudita che pongono problemi architetturali piuttosto complessi.
L'architettura interna del game engine non è assolutamente semplice. Mai letto qualcosa sull'entity component o altri modelli tipicamente utilizzati in un game engine? Al giorno d'oggi poi gli engine sono applicazioni che usano pesantemente il multithreading con tutta la serie di problemi che ne consegue. Progettare una applicazione multithread è di una complessità inaudita, è necessario avere un forte background teorico e una notevole esperienza per uscirne vivi.
Non parliamo poi della gestione della memoria che è uno dei problemi più complessi. Chi programma videogiochi non perde certo tempo perchè non riesce a calcolarsi una matrice di proiezione, perde tempo perchè magari in tutto il codice critico non può usare neanche una new per allocare la memoria ma deve andare a creare allocatori custom per fare ogni cosa.
Parliamo poi delle ottimizzazioni legate alla località spaziale?
Per tornare alla computer grafica, non c'è niente di più complesso di una inversa di una matrice a livello matematico. Se invece non si sa programmare BENE e non si conosce bene come funziona la gpu si rischia di uccidere una ge force da 500 euro per scrivere "ciao mamma" sullo schermo.
Anche i problemi matematici più complessi che si possono trovare in un videogioco (ad esempio la matematica legata alla cinematica inversa) non vanno oltre quanto si fa in un corso di laurea in informatica, invece a livello di programmazione è necessario recuperare un abisso di roba.
Non sono assolutamente d'accordo.
Hai idea di quanto sia difficile portare avanti una applicazione c++ multipiattaforma di grandi dimensioni?
Ci sono difficoltà enormi a tutti i livelli. Innanzitutto ci sono problemi organizzativi e legati alla metodologia di sviluppo. In italia ci sono team che lavorano su grandi applicazioni c++ senza utilizzare controllo di versione e senza sapere cosa sia uno unit test. Ovviamente falliscono miseramente.
Anche solo il cosidetto physical design, ovvero l'organizzazione del sorgente in file e directory è assolutamente non banale e sono stati scritti libri in proposito.
E poi addentrandoci sulla programmazione guarda che un game engine non è solo grafica. Al giorno d'oggi si investe tantissimo sui tool e son software di una complessità inaudita che pongono problemi architetturali piuttosto complessi.
L'architettura interna del game engine non è assolutamente semplice. Mai letto qualcosa sull'entity component o altri modelli tipicamente utilizzati in un game engine? Al giorno d'oggi poi gli engine sono applicazioni che usano pesantemente il multithreading con tutta la serie di problemi che ne consegue. Progettare una applicazione multithread è di una complessità inaudita, è necessario avere un forte background teorico e una notevole esperienza per uscirne vivi.
Non parliamo poi della gestione della memoria che è uno dei problemi più complessi. Chi programma videogiochi non perde certo tempo perchè non riesce a calcolarsi una matrice di proiezione, perde tempo perchè magari in tutto il codice critico non può usare neanche una new per allocare la memoria ma deve andare a creare allocatori custom per fare ogni cosa.
Parliamo poi delle ottimizzazioni legate alla località spaziale?
Per tornare alla computer grafica, non c'è niente di più complesso di una inversa di una matrice a livello matematico. Se invece non si sa programmare BENE e non si conosce bene come funziona la gpu si rischia di uccidere una ge force da 500 euro per scrivere "ciao mamma" sullo schermo.
ma l'utente che ha aperto il topic vi ha chiesto una valutazione? uno studio di fattibilità?
ma l'utente che ha aperto il topic vi ha chiesto una valutazione? uno studio di fattibilità?
No, rispondevo a te.
Non puoi entrare in un topic, fare una sparata di quel tipo, chiederti cosa siano gli asset dimostrando di non aver molta confidenza col mondo dei videogiochi e poi metterti a spiegare l'abc della computer grafica a Tommo che è il piccolo john carmack italiano :-)
Dal punto di vista della programmazione ho qualche esperienza ma per il rendering grafico assolutamente no!
Un videogioco comunque non è solo rendering.
Vorrei capire da dove iniziare. Cercando su google mi è parso di capire che i giochi vengono solitamente realizzati con C++ che a sua volta si appoggia alle DirectX.
Più altre librerie o framework esterni. Ad esempio fmod o miles per l'audio, granny per le animazioni, havok per la fisica etc....Sono pochi oramai quelli che fanno tutto in casa.
C++ è un linguaggio che va bene per realizzare programmi tipo gestionali, ma per realizzare invece applicazioni grafiche complesse, come appunto un videogioco, deve per forza appoggiarsi alle librerie DX.
Il c++ deve appoggiarsi a librerie esterne per fare qualsiasi cosa praticamente.
Quindi per prima cosa dovrei avere un'infarinatura generale sul C++, poi approfondire il discorso sulla loro interpellazione da parte del C++.
Confermate?
Si. Il punto è che c++ è molto molto difficile. Con c++ più directx ti ci vorrà un pò anche solo per disegnare un cubo capendo realmente quello che avviene. Inoltre ti servirà tantissimo tempo per fare delle cose che non hanno un riscontro visivo particolarmente interessante.
Secondo me ti conviene imparare a usare unity 3d.
>>The Red<<
07-08-2011, 01:48
This.
Ci sono un mucchio di modi per fare un videogame, e dipende tutto da cosa vuoi ottenere.
Cè Flash, FlashPunk, Unity, C++/OpenGL, C++/DX, C++/Ogre3D, ObjC/OpenGL, Python, Cocos2D, UDK, C#/XNA e che cavolo, pure Java :asd:
Ogni set di tool ha diversi punti di forza, diversi costi, diversi obiettivi. Ci sono quelli semplificati adatti al 2D (cocos, flash) quelli low level adatti a tutto (C++/OGL/DX), e un bel numero di vie di mezzo.
Quello che devi decidere quindi è prima di tutto cosa vuoi tu, quindi se vuoi imparare "come lo fanno i pro", oppure vedere un tuo gioco funzionante, oppure fare soldi con un gioco qualsiasi etc...
parti dal presupposto che imparare come fanno i pro E ANCHE fare qualcosa di utile nei primi mesi/anni è impossibile.
Nello specifico C++ è la cosa più difficile in assoluto (senza andare nei linguaggi esotici :D) specie in accoppiata con OpenGL.
Anche C# + XNA te lo sconsiglio, perchè viene spacciato per un game engine ma in realtà è un'API a basso livello (devi gestirti matrici e shader a mano, per dire).
Io credo che per imparare si debba prima capire il problema e capire come l'hanno risolto gli altri, quindi ti consiglierei di imparare le cose più semplici prima, come Flash + Flixel o Flashpunk o Python + Pygame/Pyglet/Cocos2D, e quando hai capito come si fa un gioco, approfondisci.
Sbattere la faccia contro C++ senza sapere nemmeno dove devi andare non ha mai aiutato nessuno :D
@Freaxxx: non ci crederebbe e farebbe proprio bene :asd:
Puoi spiegarmi bene questo concetto? Parti dal presupposto che ho 18 anni e volevo e voglio anche io imparare a programmare giochi...
E calcola anche che sono le 2:46 di notte e ho letto solo meta della prima pagina di questo topik :asd:
Grazie in anticipo :D :P
khelidan1980
07-08-2011, 09:53
Puoi spiegarmi bene questo concetto? Parti dal presupposto che ho 18 anni e volevo e voglio anche io imparare a programmare giochi...
E calcola anche che sono le 2:46 di notte e ho letto solo meta della prima pagina di questo topik :asd:
Grazie in anticipo :D :P
è un concetto che si applica a tutti i lavori, per arrivare a fare qualcosa di serio ci vogliono anni di esperienza, che tu sia un informatico, un chirurgo o altro...
se tu studi medicina al primo anno mica andrai a fare un trapianto di cuore, o no?
è un concetto che si applica a tutti i lavori, per arrivare a fare qualcosa di serio ci vogliono anni di esperienza, che tu sia un informatico, un chirurgo o altro...
se tu studi medicina al primo anno mica andrai a fare un trapianto di cuore, o no?
Questo :D
Con la differenza che nei videogiochi, se impari i cosiddetti "rapid tools", non farai mai trapianti di cuore, ma almeno la tua prima appendice la esporti dopo pochi mesi :D
khelidan1980
08-08-2011, 08:26
Questo :D
Con la differenza che nei videogiochi, se impari i cosiddetti "rapid tools", non farai mai trapianti di cuore, ma almeno la tua prima appendice la esporti dopo pochi mesi :D
si in effetti l'esempio calzava per quanto riguardava i "PRO" :D
>>The Red<<
10-08-2011, 11:10
Ok, non apro un altro thread dato che l'argomento interessa anche a me.:)
anche io vorrei iniziare con la programmazione di giochi, da dove parto? Da quello che ho capito dovrei partire dai giochi flash in 2D giusto? Quale linguaggio di programmazione utilizzare?
American horizo
10-08-2011, 12:42
Si. Il punto è che c++ è molto molto difficile.
E' difficile per fare qualsiasi cosa, anche un programma gestionale?
cioè, se io volessi creare un bottone cliccando sul quale esce scritto "heyla!", so che devo crearmi il bottone, aggiungere un evento che intercetti il click del mouse, inizializzare un campo di testo e scriverci dentro "heyla!". Questo almeno è quanto fare in Actionscript. Ora la difficoltà del c++ sta nel fatto che "comunicare" al linguaggio tali operazioni è poco intuitivo? E' questo che intendi per "linguaggio difficile"?
La mia teoria sui linguaggi di programmazione è che alla fine, a patto di avere le idee ben chiare su cosa si intende realizzare, bisogna solo trovare il modo di comunicarlo al linguaggio tramite le opportune sintassi, che in parte già conosci di default (una base bisogna pur averla), in parte le cerchi su internet all'occorrenza..
Almeno io ho imparato l'AS3 in questo modo, ovvio non è che lo conosco al 100% ma attualmente tutto ciò che m'ero prefissato di realizzare, sono riuscito a a farlo senza problemi e questo per me è già sufficiente (non sto parlando di semplici bottoni che visualizzano testo, ma anche di template altamente personalizzabili a discrezione dell'utente per i più svariati usi multimediali)
American horizo
10-08-2011, 12:47
Ok, non apro un altro thread dato che l'argomento interessa anche a me.:)
anche io vorrei iniziare con la programmazione di giochi, da dove parto? Da quello che ho capito dovrei partire dai giochi flash in 2D giusto? Quale linguaggio di programmazione utilizzare?
da quanto ho dedotto da questo topic, è meglio iniziare da qui
http://www.appuntidigitali.it/11630/sviluppare-un-gioco-con-python-i-rudimenti/
va bene anche studiarsi il funzionamento di flash + fixel, tuttavia non ho trovato alcuna guida adeguata quanto quella linkata sopra, quindi tantovale seguire quella (e le successive)
>>The Red<<
10-08-2011, 13:18
da quanto ho dedotto da questo topic, è meglio iniziare da qui
http://www.appuntidigitali.it/11630/sviluppare-un-gioco-con-python-i-rudimenti/
va bene anche studiarsi il funzionamento di flash + fixel, tuttavia non ho trovato alcuna guida adeguata quanto quella linkata sopra, quindi tantovale seguire quella (e le successive)
Python...bene, tempo fa avevo anche comprato il libro "imparare Python"! E' molto buono e in questo caso potra' tornarmi utile :)
E' difficile per fare qualsiasi cosa, anche un programma gestionale?
cioè, se io volessi creare un bottone cliccando sul quale esce scritto "heyla!", so che devo crearmi il bottone, aggiungere un evento che intercetti il click del mouse, inizializzare un campo di testo e scriverci dentro "heyla!". Questo almeno è quanto fare in Actionscript. Ora la difficoltà del c++ sta nel fatto che "comunicare" al linguaggio tali operazioni è poco intuitivo? E' questo che intendi per "linguaggio difficile"?
C++ è un linguaggio grande e molto potente, ma questo lo rende in parte più difficile rispetto ad altri linguaggi.
In secondo luogo, la maggior parte dei linguaggi, nel linguaggio in se, non hanno concetti come grafica, o anche input/output; viene tutto realizzato da librerie esterne.
C++ è così: non ha concezione di input o output su console, grafica, o anche file se è per questo; tutte queste funzioni sono realizzate da librerie esterne, che possono essere standard e distribuite insieme al compilatore (es. iostream, cstdio, cmath etc.), oppure esterne (tipo librerie per la matematica avanzata, per la grafica 2d/3d, per gestire una gui etc.).
Molti linguaggi non hanno la possibilità di gestire grafica anche solo 2d, così "out of the box".
Altri invece, mi viene in mente BlitzBasic, aveva il concetto di grafica in se, quindi avevi il comando "line" o "circle", ad esempio.
Quindi, se vuoi fare qualcosa con un linguaggio: 1) Devi vedere se il linguaggio da solo può farlo, e se non lo fa, 2) Trovare una libreria adatta, e imparare le funzioni della libreria.
Ad esempio, per il C++, io ho usato e mi piace usare di tanto in tanto la libreria "Allegro", che ti mette a disposizione comandi per fare grafica 2D veramente semplici, e anche funzioni per gestire audio, input (tastiera, mouse), per fare semplici videogiochi insomma. Un gradino più basso livello c'è SDL, che è un po' più potente ma di minor livello, quindi non ha funzioni come "drawline", ma devi gestire i pixel manualmente.
Io la sto usando in questo periodo in abbinamento a OpenGL per scrivere un videogioco, simile a Minecraft ma non un clone. La scelta della grafica su OpenGL la ho fatta per garantire la massima portabilità, e non avevo problemi di basso livello perchè la grafica non è molto complessa, e SDL per gestire gli eventi (timer, mouse, tastiera etc.).
Se tu volessi fare un gioco più complesso, ti puoi affidare a un motore già pronto, come Ogre3d, Irrlicht, Panda3d etc.
Altrimenti puoi basarti su un intero SDK, come appunto Source, dove in quel caso avrai poco da programmare il "programma" principale (come dovresti fare con uno dei motori sopra, o direttamente con le librerie), ma dovrai solo preoccuparti di creare i contenuti (texture, modelli, suoni etc.), e dei semplici script (tipo: "se il giocatore raggiunge il punto x,y,z, allora riproduci il suono abc e avvia lo script 123"), scritti in un linguaggio completamente dedicato a quello, che viene poi interpretato dal programma principale.
Quindi, come vedi, ci sono tantissime possibilità, su diversi livelli.
Puoi cominciare con un approccio bottom-up, cioè cominci dalle basi dell'hardware (la pipeline di rendering etc.) per poi salire con i livelli, oppure puoi partire a creare un mod su un SDK come Source, per poi, una volta imparati i concetti di quel livello, scendere e imparare concetti un po' più avanzati, per poi finire a gestire direttamente l'hardware con OpenGL o Direct3D.
Io i giochini su WP7 li faccio comodamente in c# e XNA oppure anche in silverlight... non sono impossibili da imparare e secondo me è un ottima base per IMPARARE
Poi che discorsi sono ... se volete fare un nuovo COD dovete avere un motore tipo CryEngine :muro:
American horizo
11-08-2011, 17:05
Quindi, come vedi, ci sono tantissime possibilità, su diversi livelli.
Puoi cominciare con un approccio bottom-up, cioè cominci dalle basi dell'hardware (la pipeline di rendering etc.) per poi salire con i livelli, oppure puoi partire a creare un mod su un SDK come Source, per poi, una volta imparati i concetti di quel livello, scendere e imparare concetti un po' più avanzati, per poi finire a gestire direttamente l'hardware con OpenGL o Direct3D.
Secondo me conviene a prescindere partire dall'alto per poi addentrarsi sempre in livelli più bassi (se proprio si intende farlo)... partire dal basso senza capirci un'emerita mazza non ha senso, ci si scoraggerebbe subito.
Inoltre neanche mi interessa programmarmi un engine del tutto mio, anche perchè sarebbe un aspetto della programmazione del videogioco che non mi affascina più di tanto. Se mai volessi fare un gioco complesso, come hai detto, mi affiderei ad engine già rodati per poi divertirmi con aspetti della programmazione che più mi intrigano, come la creazione dei modelli poligonari, le texture e gli script
partire dal basso senza capirci un'emerita mazza non ha senso, ci si scoraggerebbe subito.
Mi pare ovvio che quando parti a imparare qualcosa, non capisci un'emerita mazza! :asd:
E' per questo che ci sono le guide e i tutorial.
Inoltre neanche mi interessa programmarmi un engine del tutto mio, anche perchè sarebbe un aspetto della programmazione del videogioco che non mi affascina più di tanto.
Partire dal basso non significa per forza che alla fine devi creare un motore intero. Puoi sempre provare a fare programmini (anche senza un'utilità), però capendo come funziona, e questo ti permette di costruire elementi di alto livello con una conoscenza di come alla fine sotto lavoreranno. Ad esempio, è facile costruire un modello con un dettaglio poligonale elevatissimo, o usare un effetto speciale complicatissimo e darlo in pasto al motore, solo per risultare in un calo tremendo in velocità e nessun dettaglio apprezzabile. Se conosci almeno in generale come lavora una scheda video, puoi progettare i tuoi modelli e le tue texture in modo più efficiente (un esempio che mi viene in mente è quello di usare un texture atlas, cioè invece di avere tante piccole texturine ognuna separata, si fa una texture grande con tutte le immaginine dentro; questo aiuta la s.v. perchè non deve switchare texture).
Se mai volessi fare un gioco complesso, come hai detto, mi affiderei ad engine già rodati per poi divertirmi con aspetti della programmazione che più mi intrigano, come la creazione dei modelli poligonari, le texture e gli script
Questo è ovvio. :)
programmazione che più mi intrigano, come la creazione dei modelli poligonari, le texture e gli script
Questi non sono aspetti della programmazione e si fanno con tutte altre conoscenze e tools ;)
djmatrix619
12-08-2011, 20:46
Mi inscrivo alla discussione siccome sono molto interessato.
Io vorrei partire con l'accoppiata C# + XNA siccome lo vedo abbastanza fattibile per un principiante come me. Ho seguito alcuni seminari Microsoft e l'ho trovato parecchio interessante, anche se l'ascolto della parola "Quaternione" mi ha letteralmente spaventato. :asd:
Ho rimandato già tante volte l'inizio di questo studio per via dell'università, ora mi sono procurato il libro "Xna Learning 4.0", sperando di fare entrambe le cose nel migliore dei modi..
Più che altro sono spaventato dalle possibilità di far carriera in questo campo. Tutti mi scoraggiano dicendo che se si vuole proseguire devi essere o un genio, oppure devi avere un team che ti faciliti la cosa, e io non sono ne uno, ne ho l'altro. Mah.. ma una cosa è certa, l'argomento mi è sempre piaciuto... se avessi più tempo libero.. :rolleyes:
American horizo
14-08-2011, 12:36
Questi non sono aspetti della programmazione e si fanno con tutte altre conoscenze e tools ;)
però gli script rientrano nella programmazione
però gli script rientrano nella programmazione
Solo in termini accademici. I linguaggi di scripting possono essere linguaggi di programmazione (se si usa Lua, Python, Unity usa proprio C#) tuttavia il motivo d'essere dello scripting è proprio fornire uno strumento di configurazione del gioco a chi programmatore non è.
Quindi nei giochi moderni, di solito chi usa lo scripting sono i vari designer e i grafici, che sono gli stessi che fanno modelli, concepts e textures.
Quindi se eri interessato fin dall'inizio a questo lato della produzione di videogiochi, mi sa che ti abbiamo fatto perdere un mucchio di tempo :D
Fai meglio a dare un occhio a Blender, 3DSMax, Maya, Photoshop etc, e relativi forum!
Più che altro sono spaventato dalle possibilità di far carriera in questo campo. Tutti mi scoraggiano dicendo che se si vuole proseguire devi essere o un genio, oppure devi avere un team che ti faciliti la cosa, e io non sono ne uno, ne ho l'altro. Mah.. ma una cosa è certa, l'argomento mi è sempre piaciuto... se avessi più tempo libero.. :rolleyes:
Ci sono tanti sviluppatori indipendenti che sono talvolta singoli programmatori, eppure fanno dei bei giochi (molto più interessanti rispetto a i giochi "veri"), e fanno anche buoni soldi.
djmatrix619
14-08-2011, 20:44
Ci sono tanti sviluppatori indipendenti che sono talvolta singoli programmatori, eppure fanno dei bei giochi (molto più interessanti rispetto a i giochi "veri"), e fanno anche buoni soldi.
Beh ma immagino son progettoni dalla durata di anni.. non credo sia roba da poco progettare un gioco interessante da solo. Con l'università in mezzo non lo finirei mai.. :( ed ho tanta paura di perder solo tempo.
Beh ma immagino son progettoni dalla durata di anni..
E perchè dovrebbero essere dei progettoni? Cosa vuol dire progettone? Io chiamo Call Of Duty, Forza Motorsport dei progettoni, non certo Minecraft, World Of Goo...
E' ovvio che poi non puoi svegliarti la mattina con un'idea, e il giorno dopo fare i milioni. Ma un giochino divertente lo puoi fare anche in mesi, o settimane se sei già pratico.
Con l'università in mezzo non lo finirei mai.. :( ed ho tanta paura di perder solo tempo.
Qualsiasi cosa tu faccia, il tempo non sarà perso: imparerai i concetti della grafica, che si possono usare anche in altre applicazioni; farai pratica con il linguaggio, conoscendolo meglio; imparerai a gestire un progetto medio-basso, quindi come gestire i sorgenti, magari lavorare in gruppo etc.
Anche trovando un solo amico che può aiutare, diventa più divertente perchè si può discutere, scambiare idee etc.
Se poi proprio non riuscirai a finirlo, va bene, potrai lasciarlo perdere per sempre o tenerlo magari per riguardarlo in futuro.
Un' altra cosa mi sembra importante da dire: non devi iniziare a creare un gioco, solo con lo scopo di venderlo. Il gioco che svilupperai deve essere un gioco che a te personalmente piacerebbe giocare, solo in questo modo riuscirai a fare un bel gioco. E se la fortuna vuole, potrai anche venderlo e farci qualche soldo, oppure darlo gratis.
Come dicevo prima, personalmente sto scrivendo un gioco, ispirato a Minecraft, ma con blocchi di dimensione diversa e orientato alla costruzione di marchingegni vari, quindi con l'elettricità, dei sistemi meccanici etc.
E tutto questo lo abbiamo iniziato (siamo in 2), perchè volevamo un gioco così, per giocarlo noi stessi; pensiamo anche, in futuro, di venderlo, ma se non dovesse funzionare, non ci sarebbe nessun problema, e continueremo a giocarci e a migliorarlo per noi, o renderlo open source. E intanto avremo imparato l'OpenGL, migliorato la conoscenza del C++, ripassato un po' di geometria tridimensionale etc.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.