[IMPORTANTISSIMO] Programmare videogames

[tomminno]

Originariamente inviato da 71104

dipende, parli di VB 6 o VB.NET?

Rimane sempre la sintassi barbara del linguaggio e il modo poco professionale di fare le cose.
Con C# in circolazione VB non ha proprio più senso di esistere.

puoi farlo anche con il garbage collector:

lastReference = null;

con questo pseudo-esempio in Java sei tu che decidi di distruggere un certo oggetto; se non eseguissi quella istruzione l'oggetto invece rimarrebbe in vita

Sei sicuro che la memoria che hai allocato venga rilasciata nel momento che il program counter ha superato quell'istruzione?
Oppure viene deallocata quando il GC si attiva per i cavoli suoi?
Esistono anche librerie per la GC in C/C++ ma sono un controsenso.

[0rph3n]

Originariamente inviato da tomminno

Rimane sempre la sintassi barbara del linguaggio

perchè?

e il modo poco professionale di fare le cose.

poco professionale? con che criteri la stabilisci la professionalità?

Con C# in circolazione VB non ha proprio più senso di esistere.

questa è già un'altra storia.

'iao

[trallallero]

Io ho iniziato col C. Sara' che ho avuto un ottimo insegnante che prima di passare al C ha spiegato in maniera dettagliata come e' fatto e come funziona un PC. Non ho avuto nessun problema a capire i puntatori ... c'e' la RAM con indirizzi di memoria ... il puntatore e' una variabile che contiene un indirizzo, punto. Ovvio che tra il capirli e l'usarli (magari array o matrici di pointers) ne e' passato di tempo, ma, personalmente, non mi sembra che sia un discorso cosi' complicato. Da dire poi che ho iniziato a 28 anni, un corso privato C e VB ... ecco, ho avuto piu' problemi a capire il VB, la logica della MS
Quindi, concludo, non penso si possa dire "e' giusto iniziare con X linguaggio" ma che dipenda dalla persona. C'e' chi dice: e' mejo er VB, ce pensa tutto lui ... du' righe e fai tutto.
E c'e' chi invece preferisce controllare tutto e dover fare anche le memset e le delete ...
Pero' vista la quantita di esempi e manuali online per il java, un pensierino su quest'ultimo, se fossi un novello, lo farei ... si fa sempre in tempo a cambiare livello

[trallallero]

Originariamente inviato da 71104

azz, che ironia pungente, sei stato fulminante mi hai proprio distrutto

guarda che non e' una sfida personale
Sto solo dicendo che se lo vuoi veloce lo fai in C, tutto qua.

Mi sembra presto pensare di poter affidare alla macchina il compito di gestire al meglio
tutte le operazioni di gestione memoria.
memoria intesa anche come memoria video, memoria audio ...

[k0nt3]

sempre il solito discorso... IMHO gli oggetti sono un argomento troppo avanzato per iniziare, ma ognuno è libero di fare come vuole. è inutile dare consigli in questo caso... se uno ha la passione impara il C senza fare troppa fatica, e lo stesso vale per java.. dipende da cosa ti stimola. cioè se vuoi capire come funzionano le cose o se vuoi avere risultati immediati. comunque se uno vuole programmare giochi è difficile che non sappia cosa sia un puntatore... tra l'altro la cosa è anche peggio in java o linguaggi a oggetti perchè i puntatori non li vedi ma ci sono! e in quel caso sono problemi se non sai come funzionano perchè non capisci qual'è il problema del tuo codice che in teoria deve funzionare, ma qualcosa punta a qualcos'altro ecc...

[tomminno]

Originariamente inviato da 0rph3n

perchè?

Intanto l'esigenza di distinguere a livello di codice tra un funzione che ritorna qualcosa da una funzione che non ritorna niente, utilizzo di Set per impostare alcuni tipi di variabili (non basta l'operatore di assegnamento?), Call per chiamare una funzione (non basta invocarla?), se però assegni il valore di ritorno ad una variabile allora Call non serve più, il non utlizzo delle parentesi così che ogni costrutto ha una propria parola chiave di chiusura, variaibli senza scope...

poco professionale? con che criteri la stabilisci la professionalità?

Il fatto che il codice che sottintende a tutto quello che disegni (e in VB se vuoi una cosa devi disegnarla) sia completamente oscurato ti dice niente?
Il VB è un linguaggio nato per chi non ha voglia di studiarsi seriamente la programmazione, che magari di mestiere fa altro, quindi vuole scrivere un programma in fretta e senza troppe conoscenze.
Un pò come se io mi mettessi a disegnare circuiti stampati con il primo programma che trovo in circolazione e pretendessi di essere uno sbrogliatore professionista!
Poi data l'elevata cultura informatica che contraddistingue l'Italia, VB è usatissimo da noi.
Pensa sto mettendo mano ad un programma in VB il cui sviluppo è cominciato nel 1999 (a parte il fatto che è scritto da cani, ma questo è un altro discorso), oggi nel 2006 si parla di riscriverlo da 0 ancora in VB6 perchè tutti i vari OCX relativi alla cartografia che girano intorno a questo programma, con C# (e .NET in generale) non funzionano correttamente, mentre in C++ non danno nessunissimo problema (dal 1999 C++ non è cambiato molto, VB6 invece non è praticamente più supportato). Siccome al cliente non puoi vendere nuove licenze cartografiche certificate per .NET, allora via a cominciare un nuovo sviluppo in un antiquato VB6 (non sia mai di usare il C++, in azienda si usa VB6!).
Quel era la scelta migliore? VB6 o C++? Solo che la bassa cultura informatica e la voglia di avere un programma subito funzionante alla lunga ha portato a questo. Poi ti farei vedere che schifezza di codice c'è, funzioni di centinaia di righe, variabili globali in quantità, informazioni come latitudine e longitudine conservate in formato stringa non ultimo un database di riferimento con tabelle senza chiavi primarie e niente foreign keys.

[sydarex]

Originariamente inviato da dnarod

il consiglio di python è altrettanto buono, ma calcola che lui è orientato ai giochi e, anche se java non ti piace, è oggettivamente piu utilizzato di python (al momento) per i games...

Ovviamente anche il mio era un consiglio personale, condito da considerazioni personali.
Comunque per iniziare consigliavo Python per la semplicità, non certo per farci videogiochi.
Secondo me anche Java è un pò ostico per cominciare.

Originariamente inviato da 71104

vogliamo i numeri

Orea i numeri non li ho.
Parlavo per esperienza personale: quando lo provai io, ed era la prima release decente, mi parve più lento di java.
In ogni caso, rimane più lento di C++, concorderai su questo spero.

se devi fare un device driver serve il C o il C++, ma se devi fare un videogioco basta il C#

Ma il C++ resta più veloce e imho flessibile.

esempio pratico?

Non conosco C# abbastanza per sapere cosa esattamente non può fare.
Puoi dirmelo tu, no?

vogliamo i numeri, ah e devono essere riproducibili.

Spero tu non mi venga ora a dire che C# è veloce più di C++, eh.

ROTFL!!

Prego?
C++ è il linguaggio compilato più portabile.
Java e C# sono più portabili, è vero.

non è vero, il linguaggio più all'avanguardia che io conosca è Java (è affiancato da una comunità di programmatori e da una set di modernissimi strumenti e librerie che sono tra i più vasti che io conosca)

Non esiste un conteggio diretto, ma credo che ad oggi siamo lì.

personalmente io e altre 10 persone ci stiamo facendo un gioco in Java in 2D senza aver studiato un bel cavolo (e sono anche sicuro che il nostro è molto meglio del tuo )

Cioè, stai facendo un gioco senza sapere nè Java nè usare le librerie grafiche che usate?
Scherzi a parte, lo spero per voi, il mio è una cosa fatta per spremere le SDL

probabilmente non sei in grado di scegliere lo strumento migliore per qualcosa.

Non capisco cosa vuoi dire.
Se intendi che quei linguaggi non li conosco a fondo, hai perfettamente ragione - non per niente rimango un programmatore PHP e C++.
Ho cominciato a studiarli ma non mi sono piaciuti per nulla e li ho mollati.

non ne dubito, ma certe cose non servono veramente mai... a che ti serve l'aritmetica dei puntatori? a che ti servono gli includes quando puoi sostituirli con un sistema di packages? a che ti servono le macro se non ad ingannare sulla sintassi del codice? a che ti serve delete? e potrei continuare per molto...

L'aritmetica dei puntatori non è affatto inutile, nei progetti avanzati è una pacchia.
Sono esattamente la stessa cosa, nel senso che svolgono la stessa funzione.
Rimane il fatto che sono utili.
Delete serve a liberare memoria allocata, ovviamente, e ad evitare memory leak.

stesso discorso di prima: tutte cose che puoi eliminare a meno che non hai la necessità del controllo totale, e di certo non è il caso di un videogioco (forse ti do una brutta notizia ma probabilmente in futuro anche i device drivers verranno scritti in linguaggi di livello più alto: Microsoft si è avviata verso l'approccio Object Oriented nel campo)

Beh, per un videogioco serio il controllo totale serve, eccome.
Comunque, niente da dire: se non interessa la potenza del C++ nè la sua velocità, Java e C# vanno benissimo.
Io ho solo espresso la mia opinione, non ho certo annunciato verità nascoste .

[shinya]

Originariamente inviato da tomminno

Quel era la scelta migliore? VB6 o C++? Solo che la bassa cultura informatica e la voglia di avere un programma subito funzionante alla lunga ha portato a questo. Poi ti farei vedere che schifezza di codice c'è, funzioni di centinaia di righe, variabili globali in quantità, informazioni come latitudine e longitudine conservate in formato stringa non ultimo un database di riferimento con tabelle senza chiavi primarie e niente foreign keys.

Da quello che dici, non sembra un problema di vb, ma di competenze generali.

[fek]

Originariamente inviato da trallallero

ma te l'immagini videogiochi pesanti, "costosi" come FIFA, HalfLife senza l'aritmetica dei puntatori e senza la delete ???

Me l'immagino si'. Ed e' un pensiero meraviglioso

[fek]

Originariamente inviato da MSciglio

Questo dato non mi risulta. Sicuramente c'e' la tendenza a cercare di utilizzare quando possibile C# per i tool ma al momento attuale e' assolutamente fuori discussione un gioco interamente in C#. La situazione potrebbe cambiare nei prossimi anni ma attualmente il C++ e' la sola e unica possibilita' per fare un gioco di un certo livello.

Maurizio, qui ti devo correggere. Ormai (quasi) la maggioranza dei progetti appena partiti o in partenza relegano il C++ quasi al solo engine e parti del game code. C'e' una fortissima tendenza a scrivere la stragrande maggioranza del gamecode in linguaggi come Lua/Python. In futuro la tendenza non puo' che aumentare.

Anche qui scrivendo il gamecode in Lua abbiamo (hanno, perche' io sono ancora relegato al C++ grrr) riscontrato un aumento di produttivita' enorme (nell'ordine del 3/400%). Il codice Lua non appare mai nel profiling.

Sono invece d'accordo nel dire che un gioco interamente in C# e' fuori discussione perche' limiterebbe enormente le possibilita' di porting verso console e la virtual machine .NET offre ancora poco controllo sul garbage collector. .NET 2.0 ha pero' in gran parte risolto il secondo problema, si puo' caricare e ospitare il CLR da un'applicazione nativa avendo il quasi totale controllo del garbage collector e delle policy di allocazione/disallocazione/controllo degl'oggetti managed. Il primo problema e' ancora ovviamente irrisolto

[fek]

Originariamente inviato da trallallero

E c'e' chi invece preferisce controllare tutto e dover fare anche le memset e le delete ...

Ma e' ovvio, i gusti personali sono insostituibili. C'e' chi preferisce piantare un chiodo dandogli le capocciate (e digli che fa male a farlo), oppure spingendo con le dita, e qualcun altro preferisce piantare un chiodo col martello perche' fa prima e con meno fatica. Il risultato e' identico: un chiodo nel muro.

[trallallero]

Originariamente inviato da fek

Ma e' ovvio, i gusti personali sono insostituibili. C'e' chi preferisce piantare un chiodo dandogli le capocciate (e digli che fa male a farlo), oppure spingendo con le dita, e qualcun altro preferisce piantare un chiodo col martello perche' fa prima e con meno fatica. Il risultato e' identico: un chiodo nel muro.

quindi, se ho capito bene, con questa poetica nonche' sarcastica metafora, stai cercando di convincere qualcuno che:
martello = Java Lua/Python
testa = C/C++

bah fino a quando non verra' uno che fa videogiochi "pesanti" di professione, a dirmi:
noi, alla Valve, Eidos, Pinco Pallo, facciamo giochi 3D NON in C/C++, non cambiero' idea.

[MSciglio]

Originariamente inviato da fek

Maurizio, qui ti devo correggere. Ormai (quasi) la maggioranza dei progetti appena partiti o in partenza relegano il C++ quasi al solo engine e parti del game code. C'e' una fortissima tendenza a scrivere la stragrande maggioranza del gamecode in linguaggi come Lua/Python. In futuro la tendenza non puo' che aumentare.

Anche qui scrivendo il gamecode in Lua abbiamo (hanno, perche' io sono ancora relegato al C++ grrr) riscontrato un aumento di produttivita' enorme (nell'ordine del 3/400%). Il codice Lua non appare mai nel profiling.

Sono invece d'accordo nel dire che un gioco interamente in C# e' fuori discussione perche' limiterebbe enormente le possibilita' di porting verso console e la virtual machine .NET offre ancora poco controllo sul garbage collector. .NET 2.0 ha pero' in gran parte risolto il secondo problema, si puo' caricare e ospitare il CLR da un'applicazione nativa avendo il quasi totale controllo del garbage collector e delle policy di allocazione/disallocazione/controllo degl'oggetti managed. Il primo problema e' ancora ovviamente irrisolto

Tu stai parlando di linguaggi di scripting interfacciati con l'engine scritto in C++. Quello lo davo per scontato considerando che sono anni che e' ormai la prassi per qualunque gioco di un certo livello.

Io mi riferivo ad un gioco scritto interamente in un linguaggio che non sia C++.

Quando dico che non puoi scrivere un gioco interamente in C# mi riferisco principalmente al calo prestazionale che nell'utilizzo delle DirectX sembrerebbe ammontare a circa il 5% rispetto al C++. Ovviamente il 5% per un gioco 3D e' un'infinita' considerando che entrambi non dormiamo la notte inseguendo i singoli fps

Concordo sul fatto che il .NET 2.0 sembra promettere molto bene e sono convinto che il futuro dei videogiochi passera' per la tecnologia .NET.

Come portabilita' non saprei. Mono sembra fare un eccellente lavoro sotto Linux e supporta praticamente tutto il framework.

[MSciglio]

Originariamente inviato da trallallero

bah fino a quando non verra' uno che fa videogiochi "pesanti" di professione, a dirmi:
noi, alla Valve, Eidos, Pinco Pallo, facciamo giochi 3D NON in C/C++, non cambiero' idea.

Non lo vedrai... per ancora un paio di anni

[tomminno]

Originariamente inviato da shinya

Da quello che dici, non sembra un problema di vb, ma di competenze generali.

Chi non ha competenze usa VB, chi le ha lo evita.
Il problema è proprio insito nei concetti che stanno alla base del VB.

A parte il mio caso specifico, se anche quel codice fosse stato scritto in maniera decente i problemi di manutenibilità del codice sarebbero rimasti.
Il C/C++ ti dà garanzie di manutenibilità del codice per programmi con una vita utile che supera i 10 anni, Java ancora non ha ancora quell'età (o quasi) e C# non è altrettanto stabile come linguaggio visto che passando dalla versione 2003 alla 2005 di .NET praticamente tutti i programmi che ho visto utilizzano già metodi deprecati. Cosa succederà tra altri 5 anni? Tutto quel codice sarà da buttare?
Il fatto di appoggiarsi ad un framework sottostante ha il difetto che se cambiano le specifiche il tuo codice lo puoi pure buttare e siccome le specifiche .NET le fa Microsoft a suo piacimento nessuno ti garantisce che con una ipotetica versione 3 del framework non ti obblighi a pesanti revisioni (che potrebbero comportare per il cliente l'acquisto di una nuova licenza di qualche software correlato).

[fek]

Originariamente inviato da MSciglio

Tu stai parlando di linguaggi di scripting interfacciati con l'engine scritto in C++. Quello lo davo per scontato considerando che sono anni che e' ormai la prassi per qualunque gioco di un certo livello.

Io mi riferivo ad un gioco scritto interamente in un linguaggio che non sia C++.

Assolutamente si', un gioco di un certo spessore interamente non in C++ e' impensabile.

Secondo me si tratta di definire quanto C++ c'e' oggi in un gioco, e quanto ce ne sara' in futuro. Malissimo che vada il driver della scheda video conterra' alcune parti in C++/asm

Ormai non faccio piu' la distinzione fra linguaggio di scripting e non, per me Lua /Python/C# sono linguaggi a tutti gli effetti, pari dignita' del C++. Si tratta anche qui di capire quale strumento usare nel giusto contesto: rigiro l'affermazione di prima, un gioco di un certo spessore interamente in C++ e' impensabile ormai. Troppo complesso, nessuno vuole piu' spendere nottate alla ricerca di quel double delete o dell'altro memory scribbler. Meglio spendere quelle nottate a guadagnare il 5% di prestazioni oppure ad aggiungere qualche elemento di gameplay, o giocare il gioco e renderlo piu' divertente.

Quando dico che non puoi scrivere un gioco interamente in C# mi riferisco principalmente al calo prestazionale che nell'utilizzo delle DirectX sembrerebbe ammontare a circa il 5% rispetto al C++. Ovviamente il 5% per un gioco 3D e' un'infinita' considerando che entrambi non dormiamo la notte inseguendo i singoli fps

Non so, le prestazioni del framework non sono il mio problema. Malissimo che vada posso isolare il codice che mi cala quel 5% di prestazioni e riscriverlo in un paio di serate in C++ (il giusto strumento per questo lavoro). Sono piu' preoccupato del garbage collector non deterministico, che puo' decidere lui per quanto tempo deve girare. Ancora non ho visto un API, neppure nel 2.0, per dire al GC di NON impiegare piu' di un certo tempo per la sua esecuzione. Questo mi preoccupa.

Concordo sul fatto che il .NET 2.0 sembra promettere molto bene e sono convinto che il futuro dei videogiochi passera' per la tecnologia .NET.

Come portabilita' non saprei. Mono sembra fare un eccellente lavoro sotto Linux e supporta praticamente tutto il framework.

In realta' mi riferivo alle console, mi piacerebbe vedere .NET sul 360 ma non sembra ne abbiano intenzione

[fek]

Originariamente inviato da trallallero

quindi, se ho capito bene, con questa poetica nonche' sarcastica metafora, stai cercando di convincere qualcuno che:
martello = Java Lua/Python
testa = C/C++

In molte situazioni, si', questa e' la metafora.

bah fino a quando non verra' uno che fa videogiochi "pesanti" di professione, a dirmi:
noi, alla Valve, Eidos, Pinco Pallo, facciamo giochi 3D NON in C/C++, non cambiero' idea.

Noi alla Lionhead facciamo giochi 3D non interamente in C/C++. Ora cambi idea?

[trallallero]

Originariamente inviato da MSciglio

Non lo vedrai... per ancora un paio di anni

molti di voi parlano di "fra un po'" ... "tra qualche anno" ...

ma cosa sta per succedere ? io sono un po' fuori dal mondo MS e .NET perche' ormai e' qualche anno che lavoro su Sun ...

io comunque sto parlando di videogiochi INTERAMENTE non fatti in C/C++

e' ovvio che se fai un qualcosa in C# o vattelapesca che usa le DirectX o OpenGL allora non vale!
Togliere completamente il C dalle balle adesso non e' possibile, per me.

Dai che succede tra 2 anni ?

[fek]

Originariamente inviato da trallallero

molti di voi parlano di "fra un po'" ... "tra qualche anno" ...

ma cosa sta per succedere ? io sono un po' fuori dal mondo MS e .NET perche' ormai e' qualche anno che lavoro su Sun ...

io comunque sto parlando di videogiochi INTERAMENTE non fatti in C/C++

e' ovvio che se fai un qualcosa in C# o vattelapesca che usa le DirectX o OpenGL allora non vale!
Togliere completamente il C dalle balle adesso non e' possibile, per me.

Dai che succede tra 2 anni ?

Questo pero e' un ragionamento capzioso

Il task scheduler del sistema operativo sara' molto probabilmente per sempre in assembly se e' per questo, come alcune parti dei driver, e non puoi scrivere un gioco che non usi il task scheduler o i driver.

Secondo me il discorso piu' corretto da fare e' questo: quanti programmatori in un team di sviluppo che fa giochi usano il C++ oggi e quanti lo useranno domani? Nel team dove lavoro io adesso, 6 o 7 programmatori scrivono in C++ (me compreso), il resto, circa una ventina, scrivono in Lua/Python/C# a seconda di quello che stanno facendo.

Fra qualche anno vedrai molti team di sviluppo in cui probabilmente non ci sara' un programmatore C++.

[trallallero]

Originariamente inviato da fek

Noi alla Lionhead facciamo giochi 3D non interamente in C/C++. Ora cambi idea?

eh no! non vale ... qualcosa di C usate se ho capito bene
Lionhead ? citami un gioco plz ... non posso navigare liberamente, solo qualche sito.

P.S.: vi serve un prog C++ ? mi son rotto le balle di Sun e ... dell'Italia