11 febbraio 2012

Come diventare un game programmer

Mi ero ripromesso di non parlare di programmazione sul mio blog, per evitare di trasformarlo in un austero elenco di tutorial in attesa di qualche scrupoloso esaminatore di curriculum a caccia di informazioni aggiuntive. Blog tristissimi, in cui la gente comune si interessa tutt'al più ad un solo post trovato su google, prima di dimenticarlo del tutto.
Ecco, non sarà un tutorial questo post, né un articolo da sfoggiare durante un colloquio, ma avrà un target ben mirato.

Così hai deciso di diventare un programmatore di videogame, magari sai già smanettare, hai scritto qualche programmino e aspetti il momento giusto per contattare le grandi aziende. Su internet tutti parlano di shader, gpu, poligoni... figata, ma cosa occorre sapere per diventare davvero in gamba? Ecco i miei consigli, derivanti dalle mie esperienze personali.
  • Imparate l'inglese. Dapprima sarà sufficiente saper leggere bene, in seguito vi sarà molto utile saperlo scrivere, parlare e comprendere, e con tutti gli accenti che esistono non è così facile. Se avete la possibilità di fare dei viaggi di lavoro/studio all'estero approfittatene, ma approfittate anche degli studenti inglesi o americani che studiano in Italia.
  • Imparate il c++. Questo non significa imparare a scrivere le tre/quattro keyword più usate, ma significa imparare lo standard. Su google potete facilmente trovare dei pdf da scaricare, tipo questo. Lo standard non va usato come testo da studiare dalla prima all'ultima pagina ma va tenuto come riferimento. Se vi serve una guida al c++ potete fare riferimento allo Stroustrup. Lo standard attuale è il c++98, con il c++2003 che ne apporta correzioni. Imparare il nuovo c++11 è sicuramente molto utile, ma pochi compilatori lo supportano per il momento, e comunque molto scarsamente.
    Molti compilatori (tutti?) non rispettano lo standard al 100%. Visual Studio, specialmente nelle vecchie versioni, è uno dei peggiori: usandolo rischiate di imparare cose sbagliate. A scopi didattici, il Comeau è ottimo e costa appena 50$. Potete anche usare il compilatore online per piccoli test.
  • Imparate un secondo linguaggio. ObbjectiveC, D, Eiffel, per esempio, sono linguaggi più permissivi rispetto al c++, ma è possibile linkarli insieme. È molto utile anche conoscere un linguaggio di scripting: Ruby e Python sono entrambi molto moderni e molto facili da imparare. A volte potete usarli per generare codice c++, o fargli fare task ripetitivi.
  • Allenatevi a leggere il codice degli altri. Per quanto noioso, vi sarà utilissimo per capire come funziona qualcosa quando la documentazione è scarsa. Dalla facilità con cui si riesce a leggere il codice si capisce l'esperienza del programmatore.
  • Evitate i trick anni '80 che spesso insegnano all'università o che i programmatori di bassa lega citano per far bella mostra: shiftare un intero invece che dividerlo era utile 20-30 anni fa, oggi tutti i compilatori sanno tradurre una divisione in shift quando è possibile. L'unico risultato che otterrete è codice offuscato. Stesso discorso per quelli che usano lo xor invece dell'assegnazione a 0.
  • Evitate Milestone, di Milano, come la peste. Finché Martinoli e altri soggetti saranno al comando, l'unico risultato che otterrete lavorando per loro sarà odiare la programmazione. Evitate qualsiasi azienda legata a BlackBean in generale: sono famosi per pagare in ritardo, il che ha già causato licenziamenti improvvisi per mancanza di soldi.
  • Siate pronti ad andare a vivere all'estero.
  • Seguite le news, e se ne avete la possibilità, partecipate agli eventi. GamesIndustry.biz è un'ottima risorsa. Se partecipate alle discussioni, tenete a mente che le persone che vi leggono potreste trovarvele davanti al vostro colloquio, un giorno. Pensate prima di offendere o di sparare cavolate.
  • Studiate i testi più importanti: Modern c++ design, di Alexandrescu e More effective c++ di Meyers sono dei must. Il red book di openGL è un'ottima guida per impare a fare grafica.
  • Trovate un forum dove chiedere quando avete dubbi: gameprog.it è in ristrutturazione e gamedev.net è sempre un'ottima risorsa.
  • Imparate a scrivere senza guardare i tasti. Una blank keyboard può essere un ottimo incentivo. Di preferenza, lasciate stare la qwerty italiana: è un ibrido malriuscito fra tastiera francese e americana. Provate piuttosto la tastiera americana o, a detta di molti, la dvorak. gtypist è un ottimo tool per imparare.
    All'inizio, forse anche per un anno, avrete l'impressione di essere più lenti e di stancarvi molto, ma non avete idea dei mal di testa che vi risparmierete evitando di fare su e giù con la testa fra tastera e monitor. E alla fine sarete più veloci e vi stancherete di meno.
  • Cercate di capire come funzionano i repository più diffusi. Git e Mercurial ve li consiglio tantissimo. Svn e Perforce sono molto di moda, ma sono alternative più antiche. Non perdete tempo con TFS e SourceSafe.
Tanti consigli possono sembrare astratti e poco utili, ma quando vi troverete ad un colloquio e vi faranno delle domande, sapere certe cose sarà molto utile. Ancora di più lo sarà una volta ottenuto il lavoro, quando dovrete mettervi al lavoro.
Alcune domande, per farvi un'idea, possono essere:
  • "da dove iniziereste se doveste ottimizzare una parte di codice, e che soluzioni adottereste"
    Le micro-ottimizzazioni sono altamente inutili, spesso anzi peggiorano le cose. Sapere come rimpiazzare un algoritmo con uno più efficiente in quel caso specifico, o come modificare le strutture di dati vi tirerà fuori dalla domanda.
  • "scrivete un algoritmo per mescolare il contenuto di un array"
    Ho visto le soluzioni più cervellotiche a questa domanda, ma la soluzione classica è molto semplice e più che sufficiente per un colloquio.
  • "questo codice contiene un bug, sapete correggerlo?"
    Capire al volo cosa sta cercando di ottenere la funzione e come è essenziale. Di solito avrete varie domande a cui rispondere e il tempo non sarà illimitato.
  • "elencatemi tre pattern di design"
    Chisto a bruciapelo può cogliere impreparati. Aver letto libri di tecniche di programmazione e non solo di sintassi vi ripagherà ampiamente.
A volte capita anche di sentirsi chiedere come scambiereste due variabili senza usarne una temporanea o altri giochetti, tipo come incrementereste di 1 un intero senza usare + né -. A volte i test sono preparati da gente che non sa niente di informatica, portate pazienza e cercate di riflettere o di puntare su altre domande. Altre volte è indice dello stile di programmazione dell'azienda in cui vi trovate. In base a quanto vi sentite ottimisti nel procurarvi un altro colloquio, potrebbe essere un motivo per rifiutare il posto. Dover lavorare con codice oscurato, scritto da programmatori vecchio stile, vi stancherà e vi farà imparare assurdità che potreste portarvi dietro per molto tempo.

Nessun commento:

Posta un commento

Scrivimi per aggiungere cosa ne pensi