Questo post è apparso originariamente sul forum di Indie Vault a opera del sommo Tommo, lo riproponiamo qui (con qualche piccolo editing e aggiornamento) a imperitura memoria!
Sarebbe un po' da aggiornare (magari anche da parte di altri, perché no?), ma comunque rimane una buona base di partenza da linkare a chiunque chieda "da dove inizio?"
A voi!
Come inizio a programmare videogiochi?
Apro questo thread in risposta alle decine di thread sullo stesso argomento che vengono aperti continuamente, e finiscono sempre con mezzi consigli imprecisi, flame aggravati e gente bannata.
D'ora in poi i "beginners" che vogliono qualche consiglio su che strada prendere, possono postare qui!
WARNING: ogni altro thread "concorrente" verrà terminato senza pietà alcuna!
Non esiste la strada giusta
Per iniziare, rispondo con una domanda: cos'è che vuoi fare, esattamente?
Esistono giochi grandi, piccoli, retro, AAA, artistici etc... ogni tipo di gioco ha diversi requisiti, richiede diverse capacità e tempo di realizzazione.
Allo stesso modo il "programmatore di videogiochi" non è una figura indistinta, ognuno si specializza in ciò che preferisce.
C'è la carriera "tecnica" di chi punta a lungo termine nell'industria, c'è chi vuole fare soldi coi giochi Flash della domenica, chi vuole raccontare qualcosa, chi vuole solo fare il gioco che ha sempre sognato, etc.
Un po' come in un RPG, prima di partire si sceglie la classe, e come si vuole giocare. 🙂
Fatto? Fatto.
Google is your best friend
E se fare videogiochi è un'attività così multiforme, allora come faccio a trovare tutorial che mi spieghino che devo fare?
La risposta è una sola e categorica: non esistono!
Però sapendo cercare e sapendo chiedere, si trova sempre qualcuno che ha già affrontato un problema simile nel vasto internet.
Saper cercare e saper modificare ogni soluzione a proprio vantaggio è il requisito #1 per qualsiasi gamedev che si rispetti.
Saper trovare la direzione giusta per realizzare quello che si vuole è importantissimo, e questo thread nasce proprio per scongiurare i tanti thread tipo "voglio iniziare a fare videogiochi, ditemi come si fa" e le loro conclusioni pirotecniche 😃
In questo post provo a linkare tutte le soluzioni più importanti spiegando il loro livello, ma è solo un riassunto da integrare con le proprie ricerche... La pigrizia non è ammessa!
But he speaks English
Se saper cercare è il requisito #1, il requisito #2 è sicuramente sapere l'inglese da paura, perché tutto quello che si trova di veramente utile su internet è regolarmente in inglese!
Si può anche provare ad andare avanti con l'italiano, con i vari libri universitari di informatica e con quel poco che arriva tradotto, ma senza l'inglese si è programmatori di serie B, poco da discutere, nemmeno su un sito .it.
E poi non facciamo i soliti italiani, suvvia. 😃
Gli attrezzi del mestiere
Qualcuno avrà fatto caso che, arrivato al quarto paragrafo, ancora non ho proferito le parole sacre, quelle che ogni nabbo (detto in maniera affettiva, sia chiaro) ama ripetere: il famigerato "miglior linguaggio".
Ebbene, il linguaggio è uno strumento, anzi lo strumento base, e come tale va scelto per ultimo. EBBENE SÌ. Il linguaggio non è importante.
Quello che conta, sono i problemi che bisogna risolvere, e quelli li risolvono i famosi "tools", cioè i famosissimi Game Engines, Graphic Libraries, DirectX, OpenGL eccetera.
Ogni tipo di tool ha diverse potenzialità e si trova ad un livello più o meno "alto": i tool ad alto livello sono quelli più completi ma anche meno flessibili (ad esempio limitati a poche tipologie di gioco in cui eccellono) e "chiusi" (aggiungere feature particolari può rivelarsi impossibile), mentre i tool a basso livello non bastano da soli per fare un gioco, ma sono flessibili e fanno capire molto di più come funzionano le cose.
It is dangerous to go alone, take this
AKA tool di sviluppo rapido.
Con questi tool si possono realizzare giochi molto velocemente e concentrandosi sul lato gameplay/grafica senza grandi conoscenze di programmazione, ma attenzione perchè @TheCrib vi odierà se li usate. 😃
Ocio, un tool completo non vi leva la responsabilità di risolvere i vostri problemi: il cervello serve sempre!
Tool di sviluppo "rapido" popolari
Storicamente, i tool di sviluppo rapido erano una buona soluzione per sviluppare un prototipo del gioco, e per provare se le idee fondamentale di gameplay potevano funzionare, ma non per realizzare l'intero prodotto finale (un esempio possono essere le vecchie versioni di GameMaker). Ad oggi, esistono tool completi che permettono uno sviluppo abbastanza rapido, ma sono anche abbastanza solidi da poter essere usati per lo sviluppo del gioco intero - anche se non sempre.
Ecco una breve lista di tool disponibili anche in versione gratuita:
Unity: tool molto flessibile che permette lo sviluppo di giochi di quasi ogni tipologia, sia in 2D che in 3D. Usa C# (o meno spesso JavaScript) per la parte di programmazione. Ha un asset store dove componenti prefatti (modelli o anche script) possono essere comprati o venduti. Permette di creare binari per PC/Mac/Linux/Android/iOS e alcune console.
Unreal Engine: altro tool molto popolare e generico quanto Unity. Storicamente migliore sul lato rendering (ma la cosa è discutibile oggigiorno), ha un sistema chiamato "blueprints" che permette di creare script con un editor visuale che non richiede la conoscenza di linguaggi di programmazione.
Godot Engine: tool simile a Unity, ma meno stabile e/o con meno features. È però totalmente gratis e open source.
GameMaker: Studio: storico tool abbastanza maturo, orientato ai giochi 2D.
Construct: tool limitato al 2D, ma ben fatto. Ha un sistema di drag'n'drop che non necessita di conoscenza di linguaggi di programmazione.
Stencyl: altro tool prettamente 2D, abbastanza semplice ma completo, che permette anch'esso di creare la logica degli oggetti senza scrivere codice, ed è inoltre disponibile in italiano.
RPG Maker: tool specifico per creare RPG in 2D/isometrici, contiene molti elementi già pronti per sviluppare rapidamente questo tipo di giochi. Diventa molto limitato se si vuole uscire dal "seminato".
Twine: tool (open source) che permette di creare facilmente storie interattive, anche complesse.
Real Programmers write engines
AKA tool di sviluppo lento.
Generalmente, nella mente del giovane smanettone, vige l'eguaglianza videogioco = engine. E questo è SBAGLIATO. Almeno quanto fare sesso con un rinoceronte che non ti ama più (cit.).
Potrei dire che partire a sviluppare costruendo il proprio motore sia un buon esercizio didattico, che è un'esperienza formativa, che... ma sarebbero tutte ca##ate. 😃
Un motore proprietario non dovrebbe essere scritto prima del gioco, a meno che non si abbia una grande esperienza, e si stia leggendo questo post per passare un due orette visto quanto è lungo.
Un motore di gioco è un pezzo di software che deve bilanciare una MAREA di vincoli e di sfide tecniche che difficilmente chi è alle prime armi saprà individuare a priori, portando a design sballati che fanno tutto e niente... e soprattutto, il "design a priori" non porterà mai a un motore funzionante e completo alla prova dei fatti!
Il mio consiglio è di essere umili e partire seguendo un motore fatto da altri, magari uno di quelli del paragrafo sopra, oppure preso da un buon libro, il tutto mentre si è ben ancorati alla realtà da un gioco che si sta provando a finire. Non iniziare, FINIRE. che è ben diverso.
In questo modo, finito il gioco è possibile trovarsi tra le mani un bel motore semplice e riutilizzabile, e un sacco di soddisfazione.
Qualsiasi altro modo vi porterà a mostruosità così mostruose da sembrarvi errori di gioventù già a 21 anni. Ve lo garantisco. 😃
Va detto anche che se si vuole tentare una vera carriera di game developer dal lato "programmazione", affrontare almeno una volta la costruzione di un motore con gli strumenti giusti mette un livello sopra a chi smanetta con i motoracci tanto odiati dai pro, perché permette di capire davvero che cosa è importante quando si sviluppa un gioco.
Le vie di mezzo
Esistono anche innumerevoli vie di mezzo, cioè librerie più o meno open source e più o meno flessibili, che forniscono un sacco di roba, ma devono comunque essere integrate per realizzare un gioco.
Personalmente non gradisco questo approccio: anche se probabilmente è più didattico, porta tuttavia con grande facilità a risolvere problemi schiaffando dentro librerie e complicando sempre di più il proprio codice, ed è l'antitesi del Keep It Simple.
Però appunto è didattico, perché obbliga a imparare come le diverse parti di un motore di gioco comunicano tra loro e sono integrate.
Esempi in questo senso possono essere Ogre3D (libreria C++ utilizzabile come renderer), pygame (libreria Python per fare semplici giochi 2D) o Box2D (libreria C++ per gestire fisica in 2D).
Keep it simple
A volte, per certi tipi di gioco non è nemmeno necessario usare o costruirsi un framework...
A volte se il gioco è abbastanza semplice si può direttamente programmare quello, senza passare dal via. 🙂
È una pratica che probabilmente porta a codice sporco, confuso e poco riusabile, ma è un'opzione che viene fin troppo spesso accantonata, anche quando sarebbe la soluzione migliore e la più rapida!
Da consigliarsi per giochi 2D semplici in linguaggi di altissimo livello tipo Flash, Java, HTML5 etc, dove il linguaggio di per sé è già abbastanza espressivo e "grafico" senza bisogno di usare altro.
È anche la cosa migliore per fare un prototipo di gameplay!
TO DO linguaggi adatti a lavorare senza engine.
Requisiti consigliati
Anche se nel resto del post la faccio praticona, aggiungo che una solida preparazione sulla struttura dei processori/memoria, sulle proprietà degli algoritmi, e sull'algebra/geometria lineare è un grande aiuto, e anche se si può tranquillamente fare un gioco senza sapere niente di tutto ciò, essere ferrati su questi argomenti merita sicuramente in termini di qualità di quello che si scrive.
Il posto migliore per studiare quelle cose è l'università, che non è così inutile come si ama dire in giro. 😃
CODAREEE!!!
Quindi, abbiamo scelto la direzione da prendere, il tool da usare, e di conseguenza il linguaggio. E ora?
Ora, bisogna sbatterci la faccia e provare, senza troppa paura di sbagliare.
L'esperienza si fa con gli errori, i primi giochi non saranno entusiasmanti e i primi motori saranno delle robe contorte.
Ma conta il viaggio, non la meta, quindi codareee!!!
~fin~
@tutti: consigliatemi tutti i software e i cambiamenti che vi pare, facciamo una cosa fatta bene. 🙂
