5 consigli pratici per sviluppare videogiochi (parte 2)

Nella prima parte di questo prontuario abbiamo visto quanto sia importante ragionare ed agire in piccolo, tenendo a bada le idee. Questa seconda parte si focalizza su un aspetto molto pratico: gli strumenti da usare.

Consiglio #2: usa lo strumento con cui ti trovi meglio

Lo strumento non è in realtà uno solo. Parlando di videogiochi abbiamo una vasta gamma di ambienti e di tool da padroneggiare. Tra questi però ne spiccano almeno tre che meritano attenzione particolare: il linguaggio, le librerie, l’IDE.

1) Il Linguaggio

Prendete un forum di programmazione, uno qualsiasi. Andate nella sezione “Beginner” e cercate il primo post (sì, ce ne è solitamente più di uno) intitolato “Quale linguaggio devo studiare per fare un videogioco?”. All’interno troverete una massa di avatar in guerra, ognuno proclamando il tale linguaggio come migliore per questo o l’altro punto, e additando altri linguaggi come inadatti, brutti, obsoleti o altri giudizi negativi a caso. Una vera guerra di religione. In mezzo a questo marasma vedrete però anche pochi (e inascoltati) illuminati scrivere un semplice messaggio di pace: usa quello che conosci.

Che sia C++, Java, Python, D, C, C#, Pascal oppure, sì, addirittura Visual Basic, ognuno di essi ti potrà portare là dove vuoi andare. Hanno tutti in comune il fatto di essere linguaggi di programmazione, il che vuol dire che hanno superato alcuni esami e che sono stati ritenuti sufficientemente espressivi (la potenza è altra cosa) per descrivere e risolvere problemi informatici. Tutti possono svolgere calcoli, eseguire cicli, confrontare valori. L’unica differenza sta in te. Usa quello che conosci meglio, o che ti diverte di più, o che hai voglia di usare. Se sei fortunato, tutte e tre le risposte punteranno allo stesso linguaggio.

Ricorda però: un videogioco è un programma complesso. Assicurati di padroneggiare almeno i costrutti e le nozioni di programmazione di base prima di cimentarti in un progetto simile. Partire scarsamente equipaggiati porta solo alla frustrazione.

2) Le librerie

Il secondo strumento da scegliere è dato dal malloppone di codice di terze parti che dovrai includere nel tuo progetto. Da questo non si scappa. Anche se vuoi scrivere tutto da zero dovrai per forza partire da qualcosa, fosse anche solo il sistema operativo e le sue API per interfacciarsi a tastiera, mouse e schermo.

Potresti avere bisogno di un vero e proprio game engine: una libreria che ti metta a disposizione funzioni per gestire la grafica, la fisica e la logica del tuo gioco. Questa scelta non è facile come appare. I game engine sono grossi. La loro conoscenza è costosa in termini di tempo. Richiedono esperienza per essere usati al meglio e, spesso, nozioni extra per capire quel che stanno facendo al posto nostro, in modo da risolvere gli inevitabili problemi.

Spaventato da tutto questo, potresti decidere di non utilizzare un game engine. Magari potresti limitarti ad usare un graphic engine, un motore cioè che gestisca solo la parte grafica, e implementare da te gli aspetti di fisica e logica. O una qualsiasi combinazione di questi tre elementi. Il comune denominatore è sempre e solo uno: qualunque cosa tu decida di usare, assicurati di conoscerla.

Se anche non volessi usare alcun engine dovresti comunque scegliere una libreria grafica, ammesso che il tuo gioco coinvolga la grafica. Ce ne sono diverse, per scopi e target diversi. Dovresti conoscerne almeno un paio già da ora, tipo SDL, OpenGL, SFML, DirectX, Allegro o PyGame. Alcune di queste sono pure API grafiche, altre gestiscono anche altri aspetti del sistema. Se stai pensando ad un gioco testuale potresti aver bisogno delle ncurses o altra libreria derivata. Se non sai di cosa hai bisogno... beh, hai un problema a monte. Risolvi prima quello.

Scegli tutto il codice di terze parti di cui hai bisogno e che vuoi usare. Assicurati di conoscerlo, almeno nelle sue componenti fondamentali e nei suoi scopi, e scrivi subito un hello world in cui tutte le librerie compilano e linkano correttamente. Non vuoi sorprese più avanti. Hai pensato alla GUI? Non sottovalutarla, è spesso causa di morte del progetto.

3) L’ambiente di sviluppo

Hai un IDE preferenziale? Il tuo IDE deve accordarsi al linguaggio così come le tue librerie, ma non solo. L’IDE è qualcosa di più. E’ il luogo in cui passi la maggior parte del tuo tempo di sviluppatore. Devi poterlo chiamare casa.

L’IDE migliore non è necessariamente quello più completo e ricco. Anzi.

Il rapporto di uno sviluppatore col proprio IDE è qualcosa di intimo. A volte sfugge alla logica. Ad esempio, c’è stato un periodo in cui il mio IDE preferito era Dev-C++ della Bloodshed. Era già un colabrodo allora e crashava almeno due volte al giorno, ma aprirlo mi dava la netta sensazione di essere a casa mia. Non c’era nulla di ostile in lui. Ancora oggi, sebbene non lo utilizzi più da un pezzo, mi trasmette quelle sensazioni.

Al contrario, IDE più blasonati come Eclipse e NetBeans non sono mai riusciti a conquistarmi.

L’IDE è personale. Ciò significa che si deve adattare anche al nostro carattere. C’è chi si affeziona alle cose o ai marchi e, fatta una scelta, vi rimane fedele. Ci sono i fanboy di questa o quella tecnologia. Ma c’è anche chi si stufa della solita minestra e ama cambiare.

L’IDE è casa tua, abbiamo detto. C’è chi ama i castelli e le ville, chi invece le capanne e le tende. O chi in estate vuole stare in tenda e in inverno in villa.

Non state lavorando per qualcuno. Non state nemmeno lavorando, diamine! Vi state divertendo! Non dovete seguire alcuno standard commerciale, a meno che non lo vogliate. Non date retta a chi vi dice che dovete usare un certo IDE piuttosto che un altro.

L’IDE è un bel vestito messo su un insieme di tecnologie di base: editor di testi, debugger e programmi di compilazione. Iniziate il vostro progetto in un ambiente per voi confortevole e in cui avete voglia di stare per un po’.

4) Tool ausiliari

Non mi dilungherò sugli altri strumenti, ma probabilmente avrete bisogno di un editor di immagini e/o di un ambiente di modellazione 3D. Forse di un editor audio. Se siete veramente organizzati e pignoli avrete magari preso in considerazione anche un sistema di versioning. In tutti questi casi la regola è sempre la stessa: prendete ciò che conoscete.

Tutto questo ha una conseguenza implicita: dovete conoscere le cose. Il che significa informarsi, cercare, provare, sporcarsi le mani, fare esperimenti.

Che è forse il vero consiglio di questo articolo.

Post correlati:

5 consigli pratici per sviluppare videogiochi (parte 1)