Il C ++ viene sostituito da C # nei giochi di settore?

Nei giochi di settore intendo come Quake, CoD ecc.

In un certo senso, il C ++ viene davvero sostituito - non solo da C #, ma da una serie di altre lingue. Ma se lo chiedi, verrà sostituito completamente - quindi la risposta è sicuramente no .

Questo perché il C ++ è tradizionalmente usato in due capacità. Innanzitutto, per creare il motore di gioco : i componenti di basso livello che caricano risorse, spingono i poligoni per schermare e sgretolare i numeri nelle simulazioni fisiche. In secondo luogo, codificare la logica del gioco : le regole reali che rendono il gioco.

Questa seconda capacità non richiede i punti di forza di C ++ (come il controllo completo sui dettagli di basso livello), ma soffre dei suoi punti deboli (come la gestione della memoria codificata a mano e soggetta a bug). E in questa seconda capacità il C ++ viene sostituito da diversi linguaggi di scripting. Molti sviluppatori usano Lua; alcuni usano Python. Ma se è disponibile una piattaforma CLI, sotto forma di .NET o Mono, presenta un ottimo candidato host di scripting. Queste piattaforme sono abbastanza veloci, affidabili, offrono un linguaggio ampiamente conosciuto (C #) e una libreria di classi base completa. Non dimentichiamoci degli strumenti: MS Visual Studio e SharpDevelop / MonoDevelop potrebbero non essere i migliori IDE al mondo, ma sono abbastanza buoni.

Detto questo, il motore di gioco non verrà scritto in C # (o Lua, o Python per quella materia). Perché? Perché non sono abbastanza veloci.

Contrariamente a molte credenze popolari, il singolo più grande successo di prestazioni oggi è dovuto alla latenza della memoria . Ciò significa che l'accesso alla memoria è un affare serio. E le lingue gestite non consentono all'utente di controllare l'accesso alla memoria, ecco perché sono "gestite" in primo luogo. Quindi, nessuna lingua gestita consentirà di scrivere un motore di gioco molto veloce. In realtà, tutti i grandi motori "C #" che mi vengono in mente - XNA, MOGRE, Unity - sono basati sul codice C ++ nativo ; ma consenti di scrivere la logica di gioco in C #.

Per riassumere : C # verrà utilizzato al posto di C ++ o di altre lingue. Ma non sostituirà mai il C ++, almeno fino a quando qualcuno inventa la memoria ad accesso istantaneo senza latenza.

La scelta della lingua dipende fortemente dalla piattaforma. In questo momento sembra davvero improbabile che qualsiasi cosa tranne una piattaforma Microsoft richiederebbe effettivamente .NET come implementazione.

La saggezza convenzionale direbbe che una piccola piattaforma dovrebbe essere vicina al metallo per essere performante, ma d'altra parte, le piattaforme gestite sono più sicure . Questo è probabilmente il motivo per cui Windows Phone 7 ti costringe a utilizzare .NET.

Sarebbe sicuramente interessante se la nuova Xbox richiedesse una piattaforma gestita. Se l'hardware di un telefono è in grado di gestirlo (e lo fa), potrei certamente vederli utilizzarlo su una console di dimensioni standard. Stimolerebbe un po 'l'ecosistema della console in quanto sarebbe più difficile scrivere giochi multipiattaforma senza scrivere tutto il codice di gioco in un linguaggio di scripting. In tal caso, C # non sostituirà C ++, ma andrebbe di pari passo.

In questo momento si potrebbe usare Mono come un fine scripting posteriore (simile a quello che fa l'Unità), ma immagino che la maggior parte costruttori di motori dovrebbero o vogliono rotolare il proprio, o l'uso di qualcosa di più compatta come Lua o Python da C #.

In entrambi i casi, si tratta dello strumento giusto per il lavoro giusto. Dovresti davvero imparare entrambe le lingue, dal momento che C # rende più facile fare determinate cose (sviluppo di strumenti, probabilmente sviluppo di server, ecc.) E in alcuni casi non puoi usare altro che C ++.

Non è probabile. Il C ++ ha il vantaggio di essere di basso livello in modo che gli sviluppatori possano effettivamente modificare i minimi dettagli per ottenere le migliori prestazioni possibili.

Con C # e .NET hai la garbage collection che è molto utile, ma quando lavori con piattaforme con memoria e risorse limitate (console portatili e in qualche misura console domestiche) devi avere il maggior controllo possibile sulla memoria per sfruttare al meglio delle risorse. Consentire alle lingue gestite di allocare e liberare memoria per te molto probabilmente causerebbe molti problemi.

Anche la velocità è un problema (anche se probabilmente meno). Nel tempo, sono sicuro che le lingue gestite potrebbero essere rese comparabili ai compilatori C ++.

Complessivamente, nella mia esperienza, gli sviluppatori di giochi tendono ad essere maniaci del controllo in termini di memoria, tempi e risorse della CPU (per ridurre al massimo le prestazioni), motivo per cui C / C ++ sono i linguaggi maggiormente utilizzati.

AFAIK .NET GC soffre ancora di fermare l' algoritmo di stile mondiale . Sebbene ciò possa essere appropriato per un'ampia varietà di applicazioni, è inaccettabile per app in tempo reale come i giochi.

In effetti, è molto difficile usare le lingue gestite in modo efficace per i programmi in tempo reale fino a quando non avremo delle scoperte nel GC.

No. A seconda di .NET implicherebbe enormi riscritture per piattaforme senza Framework disponibile, come la PS3, e gli svantaggi delle prestazioni potrebbero essere perfettamente accettabili sul PC o per i giochi Live Arcade, ma i giochi più grandi avranno bisogno di ogni scarto di prestazioni dalle loro console per funzionare abbastanza rapidamente. Inoltre, in C ++ esistono enormi basi di codice che nessuno può permettersi di aggiornare, anche se lo desidera. Il C ++ è nel settore dei giochi e rimarrà lì per molto tempo.

Nei momenti in cui la potenza del computer era scarsa, tutto doveva essere programmato in C o C ++, semplicemente perché i linguaggi raccolti in modo inutile toglievano il controllo della memoria al programmatore, e quindi le prestazioni potevano diminuire.

Oggi i computer sono più veloci, ma come dice Knuth e per dirla in breve, l'ottimizzazione può essere malvagia:

• è ovvio che le funzionalità di base di basso livello devono essere ottimizzate, poiché il calcolo della geometria 3D, la fisica, le collisioni, l'illuminazione possono gonfiare rapidamente il miglior processore disponibile. Si può facilmente dire che l'aumento della qualità visiva su una macchina uccide quasi sempre in modo significativo le prestazioni.

• Ora, ci sono altre funzionalità, come stati del gioco, intelligenza artificiale, suono, input, rete, che sono ancora importanti in un gioco, ma che difficilmente non prenderanno mai così tante risorse di computer. Queste funzionalità, il più delle volte, non devono essere ottimizzate. Questo è l'obiettivo del linguaggio di scripting e delle immondizie raccolte: non devi pensare alla coerenza della memoria e all'organizzazione dell'applicazione, perché il codice che scriverai con queste lingue, se non stai codificando cose di basso livello, non sarà mai un collo di bottiglia.

Esempio con 2 casi

• Spedisci 500 kg di mobili con un camion.
• Spedisci 30 tonnellate di materiale con una barca.

entrambi sono a 500 km di distanza.

In entrambi i casi è importante velocizzare il processo di carico / scarico per ridurre l'intero tempo di trasporto, sapendo che CANT fa muovere la barca o il camion più velocemente?

La risposta è: importava con il camion, ma non più con la barca, perché hai già fatto molto spostando lo stock con la barca.

Non so se capisci questa metafora, ma in un certo senso può farti immaginare il problema matematico, che è più importante della comprensione della risposta.

I linguaggi di scripting consentono di rendere i giochi più veloci se hai già un motore programmato in C / C ++: il motore 3D risolve i problemi di basso livello, ora devi creare il gioco con i tuoi script.

Ma ricorda: non sarai mai assolutamente in grado di sostituire il linguaggio compilato di basso livello, MAI. I linguaggi compilati staticamente e tipicamente sono il nucleo delle prestazioni e NON PUOI escluderli, sarebbe un kernel, un motore 3D o un driver per scheda grafica.

Ma ovviamente, se il tuo gioco è graficamente semplice e non richiede molto calcolo vettoriale, puoi concentrarti sul gameplay e dimenticare l'ottimizzazione, perché in questo caso non dovrai mai occuparti dell'ottimizzazione poiché la tua macchina è molto veloce per quello

Tranne se si prevede di eseguire il port ir sul DS. Ma mi fermo qui.

Senti, so che questo è un rant ma non sto solo spaccando i capelli. Sento che molti programmatori non lo mettono davvero insieme. Una lingua in sé non ha nulla a che fare con la velocità / le prestazioni della corsa. È il compilatore / framework. Potresti discutere meglio di gcc contro cl (compilatore microsoft precedente al 2010) o msbuild (compilatore c ++ corrente per il 2010). Ogni versione di questi compilatori migliora, quindi devi anche confrontarli con le versioni precedenti di se stessi. Sono molto colpito da .net e funziona bene, ma anche se è stato leggermente migliore, non vedo che prenda il sopravvento, un motivo: la portabilità.

I giochi AAA vogliono essere su Windows, Linux, Mac, XBox, PS3, Nintendo, ecc.