Banner
Italian English French German Portuguese Russian Spanish

VideogamesHowTo - by Francesco Cricenti

Valutazione attuale: / 8
ScarsoOttimo 
AddThis Social Bookmark Button


Prefazione

Il seguente articolo vuole essere un aiuto all' orientamento per chiunque voglia approcciare al mondo degli applicativi/ videogames comprendendo come questi siano fatti e potendo approcciare allo studio dello sviluppo ( lato grafico o programmazione ) comprendendo, sapendo cosa aspettarsi e cosa cercare.
Nelle mie esperienze ho incontrato molte persone ( architetti, progettisti, grafici, designers, ecc... ) con curiosità e lacune a riguardo, queste righe vogliono rispondere alle domande che comunemente mi vengono poste sulla creazione di un software interattivo.

PS:  In risposta alla domanda più comune che mi è stata posta.
Per chiunque voglia scaricare dei modelli realistici ( magari presi da laser scanner ) per importarli successivamente in un engine e farli girare  immediatamente su un applicazione mobile:
Se il reticolato è talmente fitto da non farvi vedere il colore del modello, probabilmente non funzionerà.
Sappiate che se non sistemate e semplificate le mesh, riducendo i tasselli ed evitando doppie facce e vertici nello spazio,  andrete incontro ad innumerevoli crash.

Videogiochi ed applicativi
Approccio

Lo sviluppo del videogioco o lo sviluppo di un applicativo tridimensionale, esplorabile e con possibilità di interazione da parte dell'utente è oramai un argomento di cui quotidianamente si sente discutere in università, studi di sviluppo, studi d'architettura, di design, pubblicitari, ecc...
Nuove tecnologie che consentono ancora più interazione attraverso parti del corpo, sistemi in grado di interpretare le espressioni dell'utente, applicativi semplici e divertenti per la vita di tutti i giorni che sempre più ci spingono verso la domanda: Come funzionano ? Da dove devo iniziare per capire come si fa?
Lo sviluppo di un applicativo è in realtà una questione facilmente approcciabile, più di quanto non si possa credere, tramite l'applicazione della semplice logica.
Prima di iniziare poniamoci la domanda, cos'è un software?
Videogioco od applicazione che sia, in ogni caso parliamo di un applicativo che attraverso determinate dinamiche permette all'utente di interagire con l'ambiente ( 2D o 3D ) mostrato dal dispositivo su cui si sta operando.
Già questo ci dice che il software dovrà essere in grado di prevedere ogni nostra mossa, la reazione ad un clic su un dato pulsante, le conseguenze dell'impatto con un albero, la creazione di una curva attraverso il disegno di 3 punti, e così via. Questioni che il computer non è in grado di calcolare autonomamente ammesso che qualcuno non gli abbia precedentemente detto come ed in che condizioni farlo. Come porre rimedio ad una simile condizione? Ragionando e prevedendo noi, prima di iniziare lo sviluppo, cosa l'utente possa effettivamente fare e come l'applicativo debba reagire di conseguenza.


Facciamo un rapido esempio con un banale videogioco:
Ipotizziamo, come nell'immagine sopra riportata, un semplice gioco dove lo scopo sia cliccare i palloncini verdi per scoppiarne il più possibile incrementando quindi il numero di palloncini verdi scoppiati.
La prima considerazione viene sé : se lo scopo è aumentare il numero di palloncini scoppiati l'utente dovrà avere modo di cliccarli ed aumentare conseguenzialmente un valore numerico.
Ma da dove provengono i palloncini?
Per l'occasione abbiamo piazzato un emettitore verde che noi programmeremo ( utilizzando un linguaggio di programmazione come il C, C++, C# ,Java ,Javascript ,Flash , ecc... ) per rilasciare un palloncino ogni unità temporale trascorsa, immaginiamo un secondo.
Per cui un palloncino verde viene emesso, per ogni secondo reale che passa, dall'emettitore a forma di tubo piazzato sul fondo dello schermo.
Il prossimo passo è capire le dinamiche di gioco, se lasciassimo solamente palloncini verdi sarebbe difficile rendere il gioco intrigante. Per questa ragione dobbiamo introdurre ulteriori variabili, ovvero ulteriori elementi in grado di modificare l'esperienza di gioco.
Immaginiamo altri due tipi di palloncini, uno rosso ed uno viola. Avremmo quindi in tutto tre tipi di palloncini diversi di cui tuttavia  solamente uno ha un comportamento: il palloncino verde che se cliccato è  in  grado di aumentare un valore numerico facendo percepire all'utente che ha scoppiato il giusto palloncino.
Ricordiamoci che senza feedback visivo, in questo caso il valore che aumenta, il giocatore non percepirebbe la stessa cosa. Senza valore incrementale avremmo solamente un gioco dove bisogna scoppiare i palloncini che, anche se può diventare divertente, non è il nostro obbiettivo primario.
Decidiamo quindi un comportamento per gli altri palloncini:

- Viola: Il palloncino viola, quando viene cliccato, farà si che dall'emettitore escano ulteriori tre palloncini verdi a distanza di 0.2 secondi l'uno dall'altro.
- Rosso: il palloncino rosso, se cliccato, farà scoppiare tutti quanti i palloncini presenti nel gioco senza dare punteggio alcuno al giocatore.

Quindi in questo momento abbiamo inserito ulteriori due palloncini: un  bonus, quello viola, ed un malus, quello rosso. A questo punto possiamo dire di avere la prima bozza di questo gioco, dove vari tipi di palloncini possono essere scoppiati dall'utente dando per ogni colore un risultato diverso.
A questo punto non sarebbe male inserire un timer che definisca il tempo di gioco,  magari aumentando il livello di difficoltà per la giocata successiva. Potremmo definire che in 120 secondi, per il primo livello, bisogna raccogliere 20 palloncini verdi e che, essendo il primo livello, viene emesso un palloncino di tipo rosso, verde o viola per ogni secondo.
Per il secondo livello potremmo aumetare il numero di palloncini viola e rossi che escono dall'emettitore, aumetare il numero di palloncini richiesti e diminuire generalmente il tempo di emissione dei palloncini.
Quindi per un secondo livello avremmo, per fare un esempio, una partita di 120 secondi dove bisognerà raccogliere 30 palloncini verdi in livello in cui vengono emessi palloncini ogni 0.5 secondi in questa sequenza: 1 verde, 2 viola, 1 rosso.
Ovviamente potremmo rendere il tutto più divertente facendo in modo che il numero di palloncini emessi sia random entro un certo range ( da uno a cinque per esempio ) e facendo scegliere al computer ( sempre con una funzione di tipo random ) il colore del palloncino da emettere, con una tendenza verso il verde.

Programmazione ed engine

Ma come assegnare ad ogni elemento del nostro software una determinata reazione all'interazione con l'utente?
Per fare queste cose subentra la programmazione, dove noi andremo a definire il comportamento di ogni ogetto all'interno dell'applicativo scrivendolo con un linguaggio di programmazione, interpretabile dall'engine che stiamo usando se ne stiamo usando uno, all'interno di uno script ( una sorta di documento di testo scritto in linguaggio di programmazione )  che gestirà gli oggetti interessati in modo da farli agire come noi abbiamo definito.
Da notare come, se io per esempio volessi muovere un oggetto, è raro che esista un comando in linguaggio di programmazione che scrivendo "muoviti avanti" faccia muovere il personaggio.
In ogni caso noi dobbiamo definire cos'è il movimento, per cui dovremo semplificare la questione onde renderla comprensibile ad un computer che , ovviamente, non parla la nostra lingua.
Muoviti avanti si tradurrebbe nella somma di un numero ( facciamo 1 ) con la  posizione attuale dell'asse interessata dell'oggetto ( immaginiamo avanti, quindi l'asse Z )  moltiplicata per il tempo.
Per cui muoviti avanti diventerebbe ( in caso di pressione sul tasto "W" )  1 +  PosizioneAttualeOggetto* il tempo reale( immaginiamo ogni secondo ) .
Per cui mentre sto premendo avanzerò di una unità metrica per ogni secondo che passa.
Programmare un intero gioco manualmente sarebbe quindi questione molto lunga, ragione per cui la stragrande maggioranza degli sviluppatori ed i grandi studi di sviluppo utilizzano un determinato engine. Ma che cosa è un engine ed  a che cosa serve?
Un engine è come un grande interprete, con peculiarità grafiche, che ci consente di scrivere codice, gestire oggetti ( 2D/3D) e lavorare al suo interno con delle scorciatoie facilitando non poco il lavoro.
Parliamo di Api, frasi in linguaggio di programmazione comprensibili dal dato applicativo dentro cui le stiamo usando, in grado di svolgere operazioni che altrimenti  risulterebbero molto più complessi I mpostazioni grafiche come le luci che da programmare a mano sarebbero ostiche, la gestione interna di oggetti 3D/2D ed Animazioni, ambienti predisposti per lo svolgimento di determinate attività e molto altro ancora.
All'interno dell'engine possono essere operate determinati tipi di scelte utilizzando delle scorciatoie programmate apposta per quello che vogliamo fare.
In questa maniera l'operatore dell'engine avrà anche modo di costruire manualmente o proceduralmente ( se programmato ) degli ambienti avendo perfettamente idea di quello che sarà il risultato finale in real time.
Ma quale engine scegliere? Da dove iniziare?
Il mondo tecnologico degli sviluppatori di applicativi e videogiochi ci mette a disposizione tantissime varietà di engine gratuiti od a pagamento.
La nostra scelta dovrebbe comprendere:
La semplicità d'approccio
L'affidabilità della softwarehouse che sviluppa l'engine, la quale dovrebbe garantire costanti aggiornamenti, guide per gli utenti aggiornate ( documentazione, video ed altro ) e supporto di qualità in caso di necessità.
L'utenza legata all'engine stesso ( ovvero il numero di utenti aventi discussioni attive su metodi, funzioni e sviluppi dell'engine e quindi in grado di offrire supporto)
La qualità del motore grafico in relazione a quello che dobbiamo realizzare.
La semplicità di sviluppo legata agli strumenti " scorciatoia" che l'engine offre ( collisori predefiniti, script preimostati, intelligenze artificiali, ecc ... )
Gli strumenti che l'engine può offrire per operare all'interno
Quantitativi di piattaforme  ( in particolare nel caso di videogiochi ) che l'engine ci permette di adottare per esportare il prodotto: Pc, Android, Ios,Xbox,Playstation, ecc...
Le nostre finanze se parliamo di engine non free.
Ultimamente Unity 3D è uno dei software che sta più prendendo piede per la sua semplicità, funzionalità e grande comunity.  Ma ci sono alternative qualitativamente più alte come Unreal Engine, Frostbite e Cry Engine o soluzioni ancora più semplici come ShiVa3D, Panda3D, Ogre, RpgMaker, Cyberix3D.
In ogni caso la programmazione non è una questione semplicissima per cui, nel momento in cui si inizia, è bene tenere presente come sia necessaria costanza, applicazione e tanta logica. Non bisogna pretendere di realizzare l'intelligenza artificale di un soldato in guerra dopo due mesi di programmazione.

3D o 2D cosa cambia?

Fin'ora abbiamo visto cosa vuol dire progettare un gioco/applicativo affinché funzioni. Sappiamo di dover programmare e progettare ogni singola cosa ancora prima di metterci davanti al computer.
Ma cosa cambia sostanzialmente tra il 2D ed il 3D?
Per comprendere la differenza la cosa che più ci interessa è capire il concetto di spazio.
In un mondo 2D ( quindi bidimensionale ) ci muoviamo in uno spazio composto da due assi ( x, y ) che ci consente di spostarci principalmente in quattro direzioni: su, giù, sinistra, destra.
Possiamo simulare la profondità solo rimpicciolendo il personaggio e comunque sarebbe solo una simulzione.
Questo vuol dire che un'ipotetica telecamera/ personaggio potrebbe muoversi solo secondo una o più contemporaneamente delle direzioni sopra citate.
L'asse Z  ( la profondità ) non esiste e come tale non è possibile, per esempio, ruotare intorno ad un oggetto per verderne l'interità anche nella terza dimensione.
Questo vuol dire che quando mi sposterò, o farò muovere qualcosa, questa si muoverà su due valori numerici non interi: (x 0,0 ; y 0,0 )
Definito lo 0x,0y come il punto di partenza del nostro oggetto andremo quindi a sommare o sottrarre valori numerici definendo volta dopo volta la posizione dell'oggetto in considerazione.
Facciamo due esempi pratici:
Il personaggio ha fatto 5 metri ( 5,0x , 0,0 y )
Il personaggio è sospeso a mezz'aria durante il salto sul posto, partendo dalla posizione precedentemente ottenuta ( 5,0x , 0,80 y )
Il personaggio sta quasi per toccare il suolo ( 5,0 x 0,05y ) ;
Il personaggio è sospeso a mezz'aria facendo un  balzo in avanti ( 6,5x, 0,80y)
Inutile dire che se resta fermo resterà allo 0x, 0y
In un mondo 3D avremo invece 3 vettori, tre direzioni diverse ( x,y,z ) che ci permettono di muoverci usando sempre 3 valori numerici non interi. In questa maniera potremmo muoverci intorno a determinati oggetti e più generalmente all'interno di uno spazio tridimensionale.
Da notare bene come l'impostazione del nostro progetto ( 2D/3D) cambi radicalmente i tipi di oggetti da poter importare per costruire il nostro gioco.
Nel caso di 2D agiremo principalmente per immagini, in quanto parliamo di oggetti bidimensionali e quindi piatti che sono sempre ( o quasi ) davanti la telecamera od ai lati o sopra o sotto.
Come nel caso dei palloncini avremo quindi una serie di immagini con cui l'utente potrà interagire.
Per le animazioni avremo una sequenza di immagini organizzata solitamente in una raccolta chiamata, in gergo,  sprite.
Nel caso del 3D la situazione si fa invece un po' più complessa. Avremo bisogno di un modello, in gergo mesh, tridimensionale precedentemente esportato da qualche software di modellazione/animazione 3D . Ammesso che non si vogliano usare delle forme 3D primitive (cubo, sfera, piramide, ecc... ) native dell'engine che si sta usando.  
Questo modello potrà essere di vari formati come il .fbx od  il .obj ... fin tanto che l'engine che stiamo usando è in grado di supportarlo.
Questi modelli saranno poi controllati da determinati script che faranno in modo di attivare un dato comportamento ad una data interazione dell'utente.
Ad esempio: alla pressione del tasto "W" il personaggio manderà in play l'animazione "Corri" e si sposterà sull'asse Z di una unità per secondo, dove l'unità potrebbe essere un metro.
In sintesi la differenza sostanziale tra 2D e 3D sta nel modo in cui dobbiamo scrivere il codice e nell'aggiunta di un' asse ( asse Z ) al nostro ambiente con tutto quello che ciò comporta.

3D quale software e come?

Il 3D può sembrare difficile da approcciare in un primo momento ma non è così, non è diverso dall'imparare a scrivere sulla tastiera. Tutto all'inizio è difficile, bisogna capire solo le fondamenta logiche del software... ovvero come è pensato e come funziona.
Anche qui abbiamo varie opportunità sia free che non... ogni software 3D ha una sua funzione peculiare, ciò per cui è stato principalmente pensato e che al 70% farà meglio degli altri software.
Una volta all'interno del software grafico bisogna trovare il modo migliore di lavorare a ciò che si vuole realizzare ( il miglior workflow, in gergo ) con un rapporto qualità/tempo.
Ciò cui bisogna stare particolarmente accorti quando si lavora in 3D per videogiochi od applicativi è la topologia della mesh ( il wireframe ) che deve seguire determinati dettami:
Morfologia ( deve essere il più possibile attinente alla forma originale anche per consentire la corretta piegatura in fase di rigging per l'animazione )
Tassellazione ( il numeo dei quadrati che compongono la mesh deve essere il più basso possibile cercando di non interferire con la qualità del risultato )
Di seguito due immagini esplicative per dimostrare la differenza tra una tasselazione low-poly ( la prima immagine in altro ) e High- Poly ( immagine in basso )


L'intento del low poly è simulare la morfologia dell'oggetto in creazione utilizzando il minor numero di quadrati possibili.
Questo perchè il motore grafico, ovvero l'engine, impegnerà più risorse per gestire una tassellazione maggiore ed un maggior quantitativo di poligoni e, come tale, per restare fluidi anche su supporti di tipo mobile è necessario pensare per essenziale. Sintetizzare la forma e ricostruirla con il minor numero possibile di quadrati.
Ad intervenire sulla qualità del modello avremo successivamente delle mappe in nostro supporto ( Color map, Normal Map, displacement map, ecc )  che altro non sono che immagini applicabili all'uv mapping del modello ( una sorta di pelle che avvolge il modello, vedi img sotto  ) e che arrotolandosi intorno ad esso permettono di visualizzari dettagli, colori e riflessioni.
Ogni mappa ha un suo compito. Per esempio la normal map, la bump map e la displacement map sono responsabili del rilievo sulla mesh 3D come i pori della pellw, solchi sulla strada, pieghe dei vestiti, deformazioni su di un cuscino e simili.



Di seguito come potrebbe apparire il modello dopo l'applicazione di una color map:



Un altro concetto che bisogna tener presente, più o meno in ogni condizione dello sviluppo, è l'elemento percettivo. Solamente ciò che viene effettivamente visto va creato, se non lo vediamo vuol dire che non c'è.
Se mi sto muovendo in una stanza chiusa non ho bisogno di vedere, e quindi di realizzare, l'ambiente esterno... volendo, se avessi una finestra, potrei mettere un immagine su un piano parallelo al vetro che simuli l'esterno. Alla stessa maniera se il personaggio indossa dei vestiti, sotto non avrà la pelle ma sarà vuoto, ammesso che non debba essere inquadrato mentre cambia i vestiti.
Se un elemento, come potrebbe essere un lampadario, viene visto esclusivamente sulla distanza allora quello che dovremo fare sarà approssimare la forma del lampadario ad un qualcosa che visivamente sia in grado di farmelo identificare come tale, usando meno tasselli possibili, sulla distanza minima cui potrò vederlo .
Un altro modo d'azione potrebbe essere piazzare un immagine con una trasparenza ( canale alpha ) per ottenere quindi un piano con un immagine sulla distanza. Non potendoci girare intorno ed essendo in un contesto interamente 3D sarà difficile percepire quel dato elemento come 2D.
Nel caso di architetture esplorabili sarà bene prevedere quali saranno gli elementi visibili ed a quale distanza per determinare quindi la qualità dei modelli stessi.
Riepilogando possiamo scegliere qualsiasi software 3D vogliamo, alcuni come Zbrush, Maya, 3Dsmax ed altri sono progettati affinché il proprioworkflow sia il più possibile agevolato. Ma questo non toglie nulla a software come Blender e simili che seppur in maniera diversa sono in grado di offrire ottimi strumenti di progettazione quasi a tutti gli effetti paragonabili ai software sopra citati.
Esistono molti corsi di 3D in tutta Italia, le nozioni del 3D per cinema e per videogiochi sono approssimativamente le stesse. La specialistica in cinema o videogiochi dipenderà poi dal tipo di workflow che adotteremo per andare incontro ai nostri progetti ( i quali a loro volta determineranno la propria strada )
Imparare la grafica 3D non è una cosa due giorni ma richiede tempo e costanza, per cui non partiamo con il presupposto di poter realizzare un personaggio perfetto con 30 ore di esperienza.

Videogioco/ Applicazione cosa cambia?

Per affrontare questo tema ricorreremo a due esempi.
A) VIDEOGIOCO: Prendiamo in considerazione il gioco con i palloncini sopra citato
B) APPLICATIVO: Immaginiamo un applicazione dove si voglia permettere all'utenza di esplorare un museo e di visualizzare informazioni sui quadri esposti.
Per prima cosa possiamo ridurre entrambi gli applicativi ad una brevissima sintesi delle loro funzioni, introducendo anche qualche nuovo elemento :

A)
Click su immagine(0) per incrementare un numero
Click su immagine(1) per distruggere oggetti in scena
Click su immagine(2) per emettere altre immagini


B)
Esplorazione tridimensionale con visuale in prima persona
Click su mesh 3D ( quadro ) per visualizzare informazioni

Ora passiamo al fulcro degli elementi necessari:

A)
Immagini dei vari palloncini
Telecamera isometrica ( 2D)
Input di click ( dal lato programmazione )
User Interface ( per far apparire i numeri dei palloncini scoppiati )
Triggers ( Elementi in grado di riconoscere l'interazione utente - macchina )

B)
Mesh ( elementi 3D ) del museo: quadri, colonne, pareti, scale, statue, ecc...
Immagini e descrizione dei quadri con cui si vuol permettere esplorazione
Input di click ( dal lato programmazione )
User Interface ( per far apparire le informazioni )
Triggers ( Elementi in grado di riconoscere l'interazione utente - macchina )

Già a questo punto, pur essendo due cose completamente diverse, vediamo che nell'essenza le differenze non sono poi moltissime.
La differenza sostanziale starà nella presenza di una mesh 3D che nel caso (B) ci richiederà una prima persona, con dei collisori sul pavimento per non far cadere il personaggio ( che potrà anche essere una sfera dietro la camera, data la visuale in prima persona  ) , ed un Input di click su 3D anziché su 2D ( anche qui cambia il lato della programmazione per 2D o per 3D )
In entrambi i casi quando clicchiamo sull'oggetto giusto otteniamo un'interazione, un feedback visivo che ci consentirà di capire di aver intrapreso un'azione.
Ovviamente anche un feedback uditivo è necessario, ma cerchiamo di rimanere su esempi pratici e rapidi per non dilungarci troppo.
Nel caso (A) dobbiamo far salire un numero, nel caso (B) dobbiamo attivare ( rendere visibile ) un riquadro che mostri le informazioni del quadro cliccato.
In entrambi i casi il click comporta un operazione sull'User Interface ( UI ) che al 99% è sempre frontale alla camera in modo da apparire in qualsiasi condizione... permettendo all'utente di manovrare il software a suo piacimento, nei limiti imposti dagli sviluppatori.
Nel caso (A) i palloncini potranno andare fuori dal monitor, allorché verranno distrutti per non appesantire ulteriormente la scena. Nel caso (B) dobbiamo esplorare un ambiente 3D con luci, riflesioni e quanto necessario per il dovuto realismo. Come tale avremo bisogno di collisori sulle pareti e sul pavimento per non consentire all'utente di entrare dentro i modelli 3D.
Nel caso (A) abbiamo la camera ferma, nel caso (B) abbiamo la camera mobile che sarà gestita da uno script che permetterà all'utente di muoverla con la tastiera.
Ma come facciamo riconoscere a questi oggetti di essere stati cliccati?
Tramite gli scripts e degli strumenti chiamati triggers ( peculiari per ogni engine ) in grado di essere programmati per attivare/disattivare determinati eventi al presentarsi di una data condizione a nostra scelta.
Lo script comunicherà al trigger cosa fare quando attivato.
Per fare un rapido esempio immaginiamo una porta ad apertura automatica: si apre solamente quando ci avvicinamo al sensore. Stesso dicasi per il trigger, immaginiamo il sensore come il trigger e lo script come l'istruzione " apri porta" se leviamo lo script dal sensore, una volta avvicinati verremo rilevati ma non accadrà niente come volendo possiamo dirgli di accendere una luce invece che di aprire una porta.
Non c'è differenza abissale ( ammesso che non vogliamo paragonare space invaders a photoshop ) tra giochi ed applicazioni. Entrambi sono un susseguirsi di operazioni logiche che devono essere previste dallo sviluppatore per permettere all'utente utilizzatore di adoperare l'applicativo secondo la ragione per cui lo ha aperto.

Conclusioni

Per concludere possiamo dire che un applicativo ( videogioco o software che sia ) presenta in primo piano la progettazione logica del suo scopo, con tutti i relativi comportamenti, dopodiché si scinde nei seguenti rami:
Progettazione grafica ( 2D/3D)
Programmazione
Assemblamento/gestione in engine
Ovviamente abbiamo semplificato al massimo in quanto abbiamo tralasciato settori come l'audio, lo storyboarding, la regia, il game design, l'exporting, ecc... ma come inizio, sempre nell'ottica di star anticipando uno studio approfondito e della semplificazione per una rapida comprensione, possiamo partire da qui.
Ora è il momento della ricerca, quest'articolo non può essere considerato in alcuna maniera completo della spiegazione su come realizzare un videogioco ma deve essere preso come guida per riuscire ad informarsi sugli strumenti a disposizione per lo sviluppo.  
Esistono alcuni corsi di sviluppo videogiochi in Italia, se si è interessati al discorso frequentarli non è una cattiva idea come non lo è frequentare separatamente un corso di programmazione od un corso di 3D, dipenda da quanto si abbiano le idee chiare a riguardo. In un corso di sviluppo videogiochi avremo il focus sull'engine e sulla strutturazione logica di un videogioco. In un corso di 3D studieremo chiaramente la grafica , illuminotecnica, regia e simili mentre in un corso di programmazione affronteremo dinamiche logiche, susseguirsi e creazione di eventi, creazione di interfacce, intelligenze artificiali ed altro ancora.
È bene ricordare che raramente si sviluppa un applicativo da soli proprio per via del grande quantitativo di nozioni necessarie allo sviluppo e del margine di errore che aumenterebbe notevolmente.  
Imparare a lavorare in Team è un priorità assolutamente se si vuole intraprendere questa strada per farla divenire un mestiere.
Il primo passo per la realizzazione di qualsivoglia progetto è capire di cosa stiamo parlando.
Una volta capito questo, ed indirizzati sulla giusta strada per la ricerca, possiamo cogliere da noi le accortezze che ci servono tramite strumenti come google che, dal momento in cui inizieremo a progettare e sviluppare, potrebbe divenire il nostro migliore amico e più grande suggeritore.
L'importante è  sapere cosa cercare e non abbattersi nemmeno al centesimo errore.
Le dinamiche, le funzioni e le conseguenze di un operato spesso si colgono agendo e lo sbaglio è una delle conseguenze contemplabili e di certo più formative dell'agire.
Mi impegnerò nel tempo a  scrivere guide più specifiche per semplificare ancora di più l'approccio.

Francesco Cricenti

Linkedin: https://www.linkedin.com/in/francesco-cricenti-13b23739


You need to login or register to post comments.
Discuti questa news nel forum. (0 posts)

We use cookies to improve our website and your experience when using it. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our privacy policy.

I accept cookies from this site.

EU Cookie Directive Module Information