mcastiello

Quello che vorrei fare in questo post è parlarvi di come mi approccio alla scrittura, del mio metodo e di come ci sono arrivato. Ovviamente ci tengo a sottolineare che questo è il mio metodo, quindi potrebbe non risultare adatto a tutti. Ognuno si rapporta alla scrittura nel modo in cui si sente più a suo agio. Resta il fatto che se qualcuno ancora non ha trovato il suo metodo o magari è solo curioso di conoscere il mio, potrebbe trovare interessante quanto ho da dire.

Chi mi segue fin dall'inizio saprà che di lavoro faccio il programmatore. In un certo qual modo anche lo sviluppo di software ha un ché di artistico, o per lo meno così è quando si ha una certa libertà di azione. Programmare stimola molto la creatività ed è una sorta di punto di incontro tra la risoluzione di problemi matematici e la scrittura creativa come quella che potete leggere in queste mie pagine. Allora la domanda vien da sé, come si legano le due cose?

Effettivamente il lavoro di sviluppo influenza molto il mio metodo di scrittura, tanto che potrei dire di approcciarmi alla stesura dei capitoli con la stessa tecnica con la quale programmo.

Facciamo un passo indietro. Una piccola dissertazione informatica necessaria ad introdurre l'argomento. Ancor prima di scrivere il codice che darà vita ai programmi che ogni giorno girano sui vostri computer, un programmatore deve affrontare una lunga fase di progettazione. In realtà questa fase è la parte più consistente del lavoro perché, una volta terminata, il software in pratica si scrive da sé. Non importa che linguaggio si decida di usare per lo sviluppo, durante la progettazione il software viene analizzato in ogni sua parte e viene organizzato il lavoro che dovrà essere fatto -non come dovrà essere fatto, verrà solo identificato quale è il lavoro da fare- quindi questa metodologia può essere applicata a qualsiasi campo, dalla scrittura creativa all'organizzazione di una cenetta a lume di candela alle vacanze estive con gli amici.

Nello specifico, esistono due metodi principali che vengono utilizzati per la progettazione del software: la Bottom-Up e la Top-Down. Come suggeriscono i nomi, quello che cambia è il senso in cui si decide di muoversi.

Nella programmazione Bottom-Up si parte da un livello di astrazione molto basso, ovvero più vicino al codice macchina e meno orientato alla fruizione, per poi procedere aggiungendo funzionalità che man mano rendano il software adatto all'utilizzo da parte dell'utente finale. Questo tipo di progettazione è utile quando si intende realizzare software di ampio respiro, con finalità generiche e molteplici applicazioni. Si prenda per esempio un sistema operativo come Windows o Linux, la progettazione parte necessariamente dal basso, ovvero dal kernel che è a tutti gli effetti il cuore del sistema operativo e che permette la comunicazione diretta del software con la macchina. Una volta realizzato il cuore, si passa ad aggiungere gli altri organi, i programmi che forniranno le varie funzionalità al sistema ed infine si realizzerà un'interfaccia grafica che permetterà all'utente di gestire il tutto.

Al contrario, la programmazione Top-Down è orientata a software più 'piccoli' di cui si conosce fin dall'inizio la finalità. In questo caso si parte da un'idea e si cerca di trasformarla in realtà procedendo per suddivisioni. Come quando in matematica si scompone un problema per ricondurlo ad operazioni basilari e quindi di semplice soluzione, anche in informatica si cerca di suddividere il software in blocchi sempre più piccoli definendone man mano le connessioni tra le varie parti e rendendo il processo di sviluppo facile e immediato. Questo è il tipo di approccio che utilizzo per scrivere e di cui voglio parlarvi.

Di seguito vi riporterò le varie fasi che partono dall'idea iniziale fino ad arrivare alla stesura del singolo capitolo utilizzando i passi della programmazione Top-Down.

Per scopo in informatica si intende la finalità del software. Nel nostro caso, la finalità che vogliamo raggiungere è scrivere una storia, quindi come prima cosa dobbiamo avere delle idee ben chiare in mente. Non dobbiamo necessariamente conoscere ogni vicenda che porterà dal prologo all'epilogo, in questa fase non ci interessa neanche sapere chi sono i personaggi e cosa faranno. L'unica cosa sulla quale dobbiamo focalizzarci è l'idea.

Una storia nasce sempre da un'idea, che sia vaga o specifica non importa, l'unica cosa che conta è che sia nostra, che la sentiamo dentro e che sia per noi fonte di ispirazione.

Nel mio caso l'idea era quella di un mondo dove convivessero magia e tecnologia e che per una qualche ragione queste venissero separate in modo da non potersi più incontrare.

E' molto generica e a questo punto non si può ancora identificare un racconto, ma è la tela sulla quale dipingere la nostra storia.

Questa è la fase in cui la storia viene 'sbozzata'. L'idea viene applicata in maniera concreta e viene dipinta l'ambientazione del romanzo. In informatica, il significato del termine scenario è un po' diverso da quello che si intende comunemente. Ci si mette nei panni dell'utente e si definisce cosa ci si aspetta dal software. In un programma di video-scrittura, l'idea è di avere uno strumento che permetta di scrivere dei testi, lo scenario è l'interfaccia che ci permetterà di farlo. Ovviamente a questo punto l'interfaccia è solo ipotizzata, il più delle volte non assomiglia per nulla a quella finale che verrà proposta all'utente, ma serve da linea guida per ottenere il risultato.

Avendo a disposizione una bozza di interfaccia, si può immaginare quali azioni vorrà compiere l'utente e quindi iniziare a suddividere le varie funzionalità. Nel nostro caso questo aiuto ce lo fornisce l'ambientazione. Descrivere nella maniera più accurata possibile il mondo all'interno del quale si muoveranno i nostri personaggi ci aiuterà a dare forma alla storia. Badate bene che a questo punto non ho ancora definito cosa dovrà accadere nella storia, ma so in che modo potrà evolversi e posso quindi iniziare a delineare una serie di avvenimenti che potrebbero accadere e ho definito le regole alle quali dovranno sottostare i personaggi.

Ci sarebbe molto da parlare sulle regole, ma finirei per scrivere un altro libro. Diciamo che come nella vita di tutti i giorni, ci sono alcuni aspetti che sono indipendenti dalla nostra volontà e che dobbiamo semplicemente accettare. Ogni giorno il sole sorgerà e tramonterà, la forza di gravità sarà sempre uguale, l'arsenico è una sostanza tossica e l'ossigeno è una necessità per sopravvivere. Non dico che dovrete creare tante regole quante ne esistono nel mondo reale perché altrimenti impazzireste, ma vanno fissati alcuni punti sui quali bisogna essere rigidi e coerenti. Nella mia storia le persone che vengono dal mondo della tecnologia non possono fare uso di magia e viceversa (se a qualcuno è venuto in mente Elliot, vi rimando al capitolo delle eccezioni). Una volta create delle regole generali, si possono definire delle regole più piccole e soggette a restrizioni, come ad esempio nel caso di Kaila che, essendo una discendente degli Edori, ha il potere della preveggenza. In questa fase possiamo definire cosa esiste e cosa non esiste nel nostro mondo -elfi, nani, vampiri, licantropi, mutaforma, cervi con le ali, etc...-, cosa è possibile e cosa non lo è -volare, teletrasportarsi, saltare da una torre senza morire spiaccicati, viaggiare nel tempo e nello spazio in una cabina blu, etc...-

Una volta definite le regole si avranno a disposizione tutti gli strumenti per iniziare e delineare una storia vera e propria.

I casi d'uso sono delle descrizioni sommarie di cosa gli utenti faranno con il software, di come si muoveranno all'interno dello scenario e di cosa ci si aspetta come risultato. Eccola qui la nostra storia. Ora che abbiamo delineato il mondo in cui questa si svolgerà, è giunto il momento di trasformare la nostra idea in qualcosa di più concreto. Ovviamente anche in questa fase non ci servono i dettagli degli avvenimenti, ci basta sapere in maniera per sommi capi cosa vogliamo raccontare e come vogliamo raccontarlo. Butteremo giù poche righe per descrivere la storia, una sorta di riassunto o sinossi che poi andremo man mano ad affinare.

In questa fase può anche avvenire una prima suddivisione. Per identificare i casi d'uso infatti si definisce cosa un utente potrà fare in una determinata schermata, ma non è detto che il lavoro completo potrà essere ricondotto all'interno dello stesso caso d'uso. In poche parole è questo il momento di definire come organizzare la storia in macro-sezioni, libri, saghe o quello che meglio si adatta al nostro genere. A questo punto sarà necessario scrivere accanto alla sinossi della storia completa anche le sinossi dei singoli libri o sezioni mantenendo ben presente la storia generale. In questo modo potremo concentrarci sulla prima parte della storia avendo però un riferimento a ciò che dovrà accadere sia in senso generico sia nello specifico nelle macro-sezioni successive (ad esempio potremo far accadere un evento nel primo libro e spiegarlo solo nel secondo, così si crea curiosità e aspettativa nel lettore). Personalmente cerco di non esagerare, perché ogni parte della storia avrà bisogno di un finale che lasci il lettore soddisfatto, altrimenti potrebbe decidere di non leggere il seguito.

Ogni caso d'uso dovrà fornire diverse opzioni all'utente fornendo così una prima suddivisione in funzionalità. In questa fase di scrittura, riconduciamo la storia ad una serie di eventi. Gli eventi non sono altro che momenti in cui accadono fatti che definiranno l'evolversi della storia. E' utile creare un vero e proprio diagramma di flusso in cui tutti gli eventi sono descritti brevemente e in ordine cronologico, così da avere una scaletta da seguire in fase di scrittura. Il concetto alla base della programmazione Top-Down è di avere un quadro generale ma di specializzarsi sui singoli oggetti di sviluppo. In pratica la cosa più importante è concentrarsi di volta in volta sul singolo evento. E' per questo che definendo una scaletta si dovranno descrivere tutti gli intrecci che avverranno nel libro, così quando si inizierà a scrivere la storia si avranno già a disposizione tutte le informazioni necessarie per poter accantonare temporaneamente il quadro generale.

Per facilità è bene scrivere per ogni evento una lista di avvenimenti che devono accadere fornendo un'ulteriore suddivisione del lavoro all'interno di ogni passo.

In fase di progettazione per attori si intendono quei blocchi di programma che parteciperanno attivamente alla funzionalità in esame. Personalmente non ho ancora chiaro quanti e quali saranno i personaggi di tutto il libro/saga. Di volta in volta mi limito ad esaminare un evento particolare e cerco di immaginare chi vi prenderà parte. Ogni evento ha i suoi protagonisti che si alterneranno sulla scena, è quindi necessario in questa fase buttare giù due righe per dare una descrizione dei vari personaggi, sia fisicamente che psicologicamente, inoltre va descritto cosa faranno mentre saranno presenti in scena. In questa maniera sarà sempre possibile aggiungere nuovi personaggi e lo si potrà fare con metodo e senza troppe forzature. Tra l'altro questo sistema permette di dimenticarsi completamente dei personaggi già introdotti ma non presenti in scena, facendo in modo di rendere più semplice la stesura del testo. Qualora ci venga in mente qualche nuovo evento durante la stesura delle descrizioni (a me capita spesso di voler creare degli eventi che spieghino il cambiamento caratteriale di un personaggio in base a come l'ho descritto) potremo sempre tornare al passo precedente e aggiungerlo, non bisogna mai tenere nulla a mente, la memoria è molto labile e rischieremmo di perdere l'idea.

Quando si parla di oggetti significa che si è in una fase intermedia in cui la progettazione si fonde con lo sviluppo reale. Gli oggetti sono le porzioni di codice che descrivono un attore e che eseguono le azioni. In questa fase quindi si prende in esame un attore alla volta e si definisce cosa può fare e come lo può fare, sempre ovviamente all'interno della funzionalità che si sta analizzando. Prendiamo quindi di volta in volta i nostri personaggi e raccontiamo la loro storia, li facciamo muovere all'interno dell'evento e ne descriviamo le varie interazioni con gli altri personaggi. A conti fatti stiamo stendendo una prima bozza di quello che sarà un capitolo del nostro libro e se le descrizioni dei personaggi, dello scenario e dell'evento sono state adeguatamente approfondite, la storia si scriverà da sola.

Ho scelto questa via perché mi permette di vedere una stessa scena attraverso gli occhi di diversi personaggi, sia buoni che cattivi, con l'intenzione di dare una maggiore tridimensionalità alla storia. In questa maniera nulla è lasciato al caso e si ha la possibilità di spiegare tutte le cause e gli effetti delle varie azioni.

Inoltre, scrivere ogni capitolo dal punto di vista di un personaggio diverso permette di approfondire la psicologia della persona e vivere più intensamente le relazioni che questa crea con gli altri attori.

Quando si studiano i casi d'uso, vanno prese in considerazione anche le cosiddette eccezioni. Queste sono delle condizioni di errore gestite, nel senso che si prevede che possano accadere e quindi si studia il modo di reagire opportunamente. Nel caso della scrittura, è possibile prevedere che alcune regole possano essere aggirate o addirittura infrante, anzi, è importante che ogni tanto qualche regola venga infranta perché vi permetterà di descriverla nel dettaglio e fornire un maggiore spessore all'evento o al personaggio che ha infranto quella determinata regola.

Una volta definiti gli oggetti con le loro proprietà e le loro funzioni, passeremo alla scrittura vera e propria del codice. Per farlo è necessario scegliere un linguaggio appropriato -che può essere C, C++, Java, Assembly, etc...- e non deve essere necessariamente lo stesso per tutti gli oggetti. Non è impossibile trovare librerie all'interno dello stesso software scritte in linguaggi diversi. Anche se in informatica questa pratica è deprecata, in scrittura invece si rivela essere una pratica molto divertente. Permette all'autore di spaziare tra i vari stili e fornisce al personaggio descritto nel capitolo delle peculiarità uniche. Nel mio caso ad esempio ho scelto di narrare in prima persona i capitoli dedicati a Mallory. Questo ovviamente sta alla fantasia dello scrittore, purché poi si mantenga una certa coerenza all'interno del libro (Nel mio caso tutti i capitoli dedicati a Mallory saranno scritti in prima persona).

Spero che questo post possa essere utile a qualcuno, ma ci tengo a ribadire che non esiste un unico metodo e che quello qui descritto è solo quello che uso io e potrebbe anche non essere condiviso dai più. Buona scrittura!

Per chi volesse seguirmi, vi rimando al mio blog: paginenelvento.blogspot.com/