Un nuovo Team

[Elpropax]

Salve ragazzi scrivo qui perchè in realtà quello che voglio scrivere non so dove metterlo.

Volevo chiedervi se qualcuno di voi (oltre ai ragazzi di Little Briar Rose) abbia pensato di creare un Team di sviluppo che puntasse a sviluppare un gioco con i contro ca*** . Insomma un gruppo di ragazzi/ragazze che si mettono a tavolino o su un gruppo di WA dove esprimono le loro idee per un videogioco da sviluppare, con dei ruoli specifici ecc...

Si può pensare anche di andare oltre a RpgMaker no?

Tutti possono creare e modificare la storia, tutti possono modificare le mappe ecc... che poi verranno valutate dal team stesso.

Io non sono bravo, non voglio creare un team per un mio progetto.

Anzi per un Team del genere non deve esserci un progetto iniziale.

Sono capace di fare 2 cose : Storia (che va oltre alle classiche storie fantasy/medievali (che nemmeno mi piacciono)) e in parte il mapping. Quindi non sono tanto capace.

Con questo non voglio reclutare gente a caso per cose a caso.

Ho chiesto un vostro parere.

Voi cosa ne pensate?

[Old Pat]

Volevo chiedervi se qualcuno di voi (oltre ai ragazzi di Little Briar Rose) abbia pensato di creare un Team di sviluppo che puntasse a sviluppare un gioco con i contro ca*** .

Sì, più e più volte, e penso che siano tanti qui ad averci provato. E' un evergreen quello del "oh, ma un team per fare il gioco della vita?"

Ci sono dei casi in cui la cosa funziona e altri in cui no. Lavorare in team non è qualcosa di semplice e banale come molti pensano.

 

Basta un niente per mandare tutto a quel paese. Un membro del team che non porta più avanti le sue mansioni, un conflitto di idee e visione generale del progetto, una pessima gestione del team e dei lavori in generale... hai voglia.

E' un'enorme responsabilità, aggregarsi ad un team e/o, soprattutto, portarne avanti uno.

 

Andare oltre RPG Maker si può fare, certo, perché no?

Ma ripeto, non è tutto rose e fiori. Fuori da RPG Maker, poi, le cose si complicano a livello tecnico. E non sarà certo il numero di individui nel team a rendere tutto più semplice, anzi. E' un'arma a doppio taglio.

 

Tuttavia mi sorge un dubbio su questo post, che non vorrei aver frainteso.

Vuoi un'opinione su cosa voglia dire lavorare in team o vuoi CREARNE uno?

 

Perché dal post sembra tu voglia un'opinione, ma poi il titolo è "Un nuovo team", che mi fa pensare che tu ne voglia creare uno.

 

In ogni caso, in sintesi, il mio parere è questo:

Provare a collaborare, a tirare su un team, ci sta. E' una buona cosa, sviluppare un videogioco è difficile e richiede di destreggiarsi in una moltitudine di campi, dalla programmazione al game design.

Tuttavia, anche in team conviene puntare molto in basso e non pensare troppo in grande. E soprattutto avere bene in mente problematiche come quelle che ho esposto poc'anzi.

E, ancor meglio, evitare di creare team con persone che non si conoscono minimamente. Meglio cominciare a provare con gente con cui si ha già un certo livello di confidenza o di cui si conoscono, perlomeno, le capacità.

Inutile raccattare il primo che passa per poi scoprire che è uno che non ha a cuore l'idea e abbandona tutto o si dimostra poco utile, no?

Edited June 23, 2017 by Old Pat

[Bric-à-brac]

*Agita la manina*

 

Io un team ce l'ho, e ti dico che partire con idee come "per un Team del genere non deve esserci un progetto iniziale." e "tutti possono modificare le mappe" è il modo migliore per mandare tutto all'aria entro due mesi.

I motivi:

 

• "Nessun piano" significa che sarà molto più difficile sviluppare un'idea avvincente, perché libertà illimitata significa anche non avere il minimo spunto a cui aggrapparsi.
• Superato l'entusiasmo iniziale, la maggior parte della gente ha notoriamente l'iniziativa di un criceto.
• Non avere un capo significa rischiare che il progetto si areni perché il team sarà incapace di prendere una decisione definitiva su certi aspetti.

 

Guarda le storie di progetti finiti male come Mass Effect Andromeda: nel 90% dei casi questi difetti accadono perché il team non aveva una chiara direzione interna, e soprattutto non avevano un fottuto producer.

[Testament]

Ci vuole un capo, che stia col fiato sul collo degli altri e che sappia più o meno destreggiarsi con tutto.

La democrazia non è fatta per i team di sviluppo.

[Lusianl]

Provato e riprovato.

Diverse vedute

Problemi di gestione

Ruoli marginali

Tempistica diversa

Mancanza di lavoro a braccietto

E tutto va all'aria!

Bisogna fare come flame! Sai disegnare? Accalappiati un programmatore! XD

[Elpropax]

No ragazzi se avete letto ho scritto che ci sono vari ruoli...quindi dal Game Director allo sviluppatore, grafico compositore ecc...

Edited June 23, 2017 by Elpropax

[Testament]

Tutti possono creare e modificare la storia, tutti possono modificare le mappe ecc... che poi verranno valutate dal team stesso.

è questo che sbagli. Se ci sono ruoli specifici, come dici, vanno rispettati.

Il grafico deve fare grafica, il programmatore deve programmare e generalmente nessuno deve mettere bocca nel lavoro degli altri o nella storia decisa dal capo.

 

Se tutti potessero dire la loro e avere stesso peso su tutte le decisioni, non vi mettereste d'accordo probabilmente su nulla.

[Arctic]

Volevo chiedervi se qualcuno di voi (oltre ai ragazzi di Little Briar Rose) abbia pensato di creare un Team di sviluppo che puntasse a sviluppare un gioco con i contro ca*** .

 

Io ho pensato di creare un bel (J)-Rpg con una bella storia e dei personaggi interessanti, senza la pretesa di fare tutto con risorse originali e di pubblicarlo chissà dove.

 

Io vedo il "making" come ai vecchi tempi su questo forum (e in molte altre community internazionali). Questo mi permette più libertà nello sviluppo (non dovendomi preoccupare di avere risorse al 100% originali), e di non perdere di vista le due ragioni che mi hanno portato a iscrivermi su questo forum: (1) la passione per i J-Rpg; (2) il desiderio di crearne uno con una storia inventata da me.

Molti dei giochi più belli sviluppati da utenti di questo forum sono stati creati con questa visione.

 

Quindi, se intendi creare un bel gioco con una bella storia, allora collaborare con altre persone può bastare, senza dover creare un team vero e proprio.

Se invece anche tu non vedi più il "making" come ai vecchi tempi, e vorresti seguire la tendenza di diventare uno sviluppatore indie, allora in questo caso il Team diventa fondamentale (se non sei in grado di fare tutto da solo) ed è chiaro che i ruoli al suo interno dovranno essere chiaramente definiti (tutti non potranno creare e modificare tutto).

[Mino]

Volevo chiedervi se qualcuno di voi (oltre ai ragazzi di Little Briar Rose) abbia pensato di creare un Team di sviluppo che puntasse a sviluppare un gioco con i contro ca*** . Insomma un gruppo di ragazzi/ragazze che si mettono a tavolino o su un gruppo di WA dove esprimono le loro idee per un videogioco da sviluppare, con dei ruoli specifici ecc...

Si può pensare anche di andare oltre a RpgMaker no?

 

Io ci ho pensato in passato, volevo creare un piccolo team, ma cercavo gente che non abitasse molto lontano, per poterci incontrare di persona e come dici "mettersi a tavolino ed esprimere le nostre idee, ruoli ecc....".

Purtroppo non sono riuscito a trovare collaboratori, e quindi alla fine ho quasi sempre lavorato da solo o in team con mio fratello.

[Dax]

i team migliori sono nati da piccole collaborazioni e con esperienze pregresse. Si comincia a collaborare per un contest, poi magari per qualcosa di più, e allora può nascere un grande amore come Pro e Flame xD Gli unici team che ho visto funzionare sono persone che già si conoscevano e si stimavano ed avevano collaborato in passato.

No team tra sconosciuti xD

[Zuppo]

Per questo, per quel che dice Dax, io non ritengo che tentare di fare esperienza in un team di sbandati sia necessariamente male, ne una perdita di tempo.

Il Rhaxen (il progettooooone del forum di RpgShrine, antenato di Rpg2s) è stato fondamentale per me, dapprima come grafico marginale, poi come persona chiave e poi come capo del Team. Ho vissuto i vari ruoli in una scalata involontaria (il ruolo di capo me l'han praticamente appioppato XD), con la fortuna che una fetta dei collaboratori ci credevano davvero (quindi averne persi il 90% per strada era relativamente non importante).

 

E poi si arriva ad un limite che non si conosce (Nel mio caso, non ero in grado di sostituire il grafico che se ne era andato, ma non ero capace di abbassare le aspettative del progetto ne avevo capito che quello era il problema, facendolo arenare per troppo tempo)

 

In quel periodo non dubito che la mia direzione sia stata ottima, sul livello del tenere le persone ancorate al progetto, e terribile sul riuscire ad avere un'idea realistica delle problematiche del progetto. La convinzione e la parlantina non me mancavano manco allora. XD

Quell'esperienza mi ha fatto vivere con persone creative e, tra di loro, ho legato di più con alcune che con altre. E' li che conobbi Pro e che fui costretto a collaborarci in maniera stretta, imparando a conoscere le sue capacità, i suoi limiti ed il suo metodo per superarli. Io facevo il ruolo di quello che chiede nuove feature e lui che mi malediva perché gli chiedevo i salti mortali.

 

Il fatto che io stia creando dei progetti con ProGM è dovuto alla fiducia che ho nella sua tenacia e razionalità, molto utili ad affrontare progetti più ambiziosi di RpgMaker ed ottimi nell'apprendere come migliorarsi.

Tuttavia ci siamo conosciuti in un progettone. Non demonizzerei, dunque, i progettoni. Sono destinati a fallire ( XD ) ma sono, quelli come qualsiasi altra occasione di lavorare in team, un modo per scoprire nuove persone e mettersi tutti alla prova.

 

Può succedere che da un team immenso, ci si riduca a 4 individui affiatati e che alcuni di loro sopravviveranno all'esperienza del progettone, finendo col diventare un vero team.

 

 

 

Per quanto riguarda la divisione dei ruoli... qui le regole sono labili. Dipende. Quante persone si è nel team? Più si è, più la divisione dei ruoli è di aiuto al riuscire ad ottenere qualcosa dal team in tempi utili. Meno si è, più è tollerabile che le divisioni di ruoli non siano così nette, anche per compensare il fatto che si è troppo pochi per ricoprire tutti i ruoli.

 

Sempre con l'esempio di io e ProGM, che siamo appena in due (e con il nuovo progetto, in 4), io sono assolutamente specializzato in grafica e lui assolutamente specializzato in programmazione. Ma poi?

Tra la programmazione e la grafica c'è il game design, l'user interface, delle mansioni che perdono la loro specializzazione e finiscono col mescolarsi.

Lì abbiamo banalmente imparato "Cosa siamo in grado di fare? A chi dei due esce meglio questa cosa?"

 

Non è raro che ProGM pensi ad alcuni aspetti grafici del gioco (Ad esempio, l'idea di fare un gioco a vetrate è sua) o pensi a come fare un menù decente. Io faccio schifo nei menù, ma proprio tanto. E quindi lui è grafico, in quel frangente.

 

Più il Team è piccolo, meno ha senso limitare il lavoro delle persone a delle specializzazioni stringenti. Specializzarsi serve solo a diminuire la mole di lavoro alla persona E ad evitare che troppe teste arenino una scelta.

Se però la scelta è di trama o è sul decidere la morale/visione del gioco, per me ha senso parlarne con il resto del Team. Con quella parte del team che desidera essere partecipe aldilà della mansioncina.

 

Una gerarchia chiara, però, è utile. Se in un team di 4 persone, esiste una fetta di queste che possono "decretare quando si chiude il discorso", come fosse un direttivo, allora non ci si può arenare. Se l'idea esiste, è stata detta, e tutto ciò che si fa è solo avere ripensamenti casuali, quelle persone o persona a cui si è data più autorità, è di aiuto a bloccare l'idea così com'è ed andare avanti.

 

Una cosa che ha senso usare solo in casi di emergenza, quando serve. E... come si fa a capire quando serve e quando invece sarebbe un'inutile prepotenza?

 

Ecco perché è bene conoscere le persone con cui si lavora. Devono essere lucide ed avere in mente il bene del progetto, non il bene delle proprie turbe. Inoltre aiuta avere una linea guida, tipo una parola chiave che il progetto deve rispettare. Aiuta a capire quando la strada sta deragliando e quindi quando usare il pugno duro.

Sempre nel rispetto di chi collabora con te, però, perché avere autorità non significa comandare, significa aiutare il team a, mentalmente, lasciarsi alle spalle una questione che non ha una sola risposta ma alla quale si deve decidere arbitrariamente una risposta unica.

 

 

 

Probabilmente non amplierei mai il mio team con persone che non hanno avuto un'esperienza amatoriale in un team. Non avrebbero il desiderio di seguire delle regole, perché dovrebbero ancora vivere la frustrazione di non averle. XD