ArsLudica.org Forum
Cogitare => Officina Creandi => Topic aperto da: NEO-GEO - Settembre 19, 2012, 00:36:49
-
come si fa?
Non parlo di programmazzione ma solo di game design. C'è della letteratura in proposito?
bisogna saper disegnare? il linguaggio di programmazione influenza il game design?
Inviato dal mio GT-I9100 con Tapatalk 2
-
come si fa?
Secondo me, parti dal giocarne una quintalata.
Prendi quelli riusciti meglio e valuta cosa di questi ti e' piaciuto di piu'; se hai gia' un'idea per qualcosa di particolare, e' un buon punto di partenza.
Scrivilo. Perche' e' solo li' che ti accorgi che e' sbagliato e cosa (va sempre cosi'), e soprattutto butta a mare le cose di troppo.
Quello che resta e' il tuo concept. Poi aggiungi dettaglio (non feature - dettagli: l'ambientazione, i nemici, tutto il resto).
Non parlo di programmazzione ma solo di game design. C'è della letteratura in proposito?
A tonnellate, cerca su google "platform game design" e guarda quanta roba vien fuori. Ma poi va tutta presa con grano salis.
bisogna saper disegnare?
Non e' necessario, ma - specie se e' un lavoro di team (tu fai il game design, un programmatore, un grafico e un musico fanno il resto) - aiuta.
Nel senso che un documento di game design e' essenzialmente testo. Ma come sempre, se devi condividere un'idea con altre persone, a volte vale di piu' un'immagine di mille parole.
il linguaggio di programmazione influenza il game design?
Assolutamente no.
-
Un platgorm!
-
come si fa?
Secondo me, parti dal giocarne una quintalata.
Prendi quelli riusciti meglio e valuta cosa di questi ti e' piaciuto di piu'; se hai gia' un'idea per qualcosa di particolare, e' un buon punto di partenza.
Scrivilo. Perche' e' solo li' che ti accorgi che e' sbagliato e cosa (va sempre cosi'), e soprattutto butta a mare le cose di troppo.
Quello che resta e' il tuo concept. Poi aggiungi dettaglio (non feature - dettagli: l'ambientazione, i nemici, tutto il resto).
Non parlo di programmazzione ma solo di game design. C'è della letteratura in proposito?
A tonnellate, cerca su google "platform game design" e guarda quanta roba vien fuori. Ma poi va tutta presa con grano salis.
bisogna saper disegnare?
Non e' necessario, ma - specie se e' un lavoro di team (tu fai il game design, un programmatore, un grafico e un musico fanno il resto) - aiuta.
Nel senso che un documento di game design e' essenzialmente testo. Ma come sempre, se devi condividere un'idea con altre persone, a volte vale di piu' un'immagine di mille parole.
il linguaggio di programmazione influenza il game design?
Assolutamente no.
Grazie per le dritte. Però i livelli bisogna disegnarli! E' utile una qualche carta millimetrata?
-
Grazie per le dritte. Però i livelli bisogna disegnarli! E' utile una qualche carta millimetrata?
Guarda, io sto lavorando a un runner-platform, i due game designer hanno lavorato presso.. uh... "un grosso studio francese che fa, nel mucchio, anche platform di successo, uno dei quali uscito di recente su iOS", e non ho mai visto nessuno dei due con una penna/matita in mano.
Quindi, cosi' a spanne, mi sento di dire di no. Anche perche' poi non e' tutto cosi' matematico, spesso si va un po' "a spanne", ed e' piu' facile provare il gioco con un tool e vedere se "funziona" che non fare un progetto su carta, poi spostarlo sui tool, e scoprire che non funziona.
-
Grazie per le dritte. Però i livelli bisogna disegnarli! E' utile una qualche carta millimetrata?
Guarda, io sto lavorando a un runner-platform, i due game designer hanno lavorato presso.. uh... "un grosso studio francese che fa, nel mucchio, anche platform di successo, uno dei quali uscito di recente su iOS", e non ho mai visto nessuno dei due con una penna/matita in mano.
Quindi, cosi' a spanne, mi sento di dire di no. Anche perche' poi non e' tutto cosi' matematico, spesso si va un po' "a spanne", ed e' piu' facile provare il gioco con un tool e vedere se "funziona" che non fare un progetto su carta, poi spostarlo sui tool, e scoprire che non funziona.
Ok grazie mille! :)
-
come si fa?
Non parlo di programmazzione ma solo di game design. C'è della letteratura in proposito?
bisogna saper disegnare? il linguaggio di programmazione influenza il game design?
Inviato dal mio GT-I9100 con Tapatalk 2
Ciao, forse non sono la persona più giusta per dire come progettare un gioco ma negli ultimi 4 mesi sto provando a fare proprio questo.
Lavoro di mio come grafico e ho sempre disegnato, per di più gioco tantissimo su tutto, dal PC alle console al mobile.
La progettazione per me nasce sempre dall'idea, dal soggetto.
Poi si cerca di mettere su carta le idee con bozzetti e disegni preparatori e si cerca di capire se l'idea c'è.
Successivamente si sceglie il programma da usare...ce ne sono molti ormai in circolazione magari anche se non si conosce tanto o nulla di programmazione.
Io ad esempio sto usando principalmente Stencyl e Gamesalad con il mio socio.
Si parte con la grafica e si scelgono i punti principali...poi man mano le cose vengono da se...
-
il linguaggio di programmazione influenza il game design?
Assolutamente no.
Su questo non sono d'accordo... o meglio, correggo: la tecnologia che usi influenza il game design.
Esempio, uno su tutti: se non hai a disposizione collisioni per-pixel (perché magari il tuo gioco ha il gameplay in 2D ma gestisce i tile come poligoni in una scena 3D) ma solo poligonali, i tuoi asset dovranno avere delle forme squadrate o quantomeno componibili da forme di base.
Poi ovvio, se uno VUOLE le collisioni pixel perché il proprio platform è in pixel art, allora forse è meglio scegliere un'altra tecnologia, e lì potremmo dire che il design influenza la tecnologia. Però a volte la scelta è obbligata, e si verifica l'inverso. Dipende.
-
collisioni per pixel...platform... qualcuno sta sbagliando qualcosa?
E comunque tecnologia e linguaggio di programmazione sono due robe un pò diverse.
-
Esempio, uno su tutti: se non hai a disposizione collisioni per-pixel (perché magari il tuo gioco ha il gameplay in 2D ma gestisce i tile come poligoni in una scena 3D) ma solo poligonali, i tuoi asset dovranno avere delle forme squadrate o quantomeno componibili da forme di base.
Questo per fare un esempio fra tanti.
Bell'esempio proprio.
Le collisioni per pixel sono qualcosa di totalmente scorrelato da un platform. E se proprio dovessero servire, oggi come oggi una occlusion query dovrebbero bastare.
Comunque, anche sui vecchi hardware che supportavano la CD per pixel, le bounding box erano decisamente meglio. (Nota di colore: gioca a Strider II per Sega Master System per capire quanto danno possono fare le collisioni "pixel perfect" su un platform).
La progettazione per me nasce sempre dall'idea, dal soggetto.
Poi si cerca di mettere su carta le idee con bozzetti e disegni preparatori e si cerca di capire se l'idea c'è.
Successivamente si sceglie il programma da usare...ce ne sono molti ormai in circolazione magari anche se non si conosce tanto o nulla di programmazione.
Io ad esempio sto usando principalmente Stencyl e Gamesalad con il mio socio.
Si parte con la grafica e si scelgono i punti principali...poi man mano le cose vengono da se...
Credimi, ho lavorato con troppi game design documents in cui le cose erano definite tipo "X punti" o "TOT" invece che valori numerici o percentuali precise, per non parlare del fatto che quando hai troppi punti in "forse, vediamo come va nei playtest" non hai un GDD ma un colabrodo. La gente spende un sacco di tempo e risorse per implementare cose che verranno poi eliminate.
Prima si stila il game design e si fanno dei prototipi, senza investire su grafica e amenità varie, per testare il funzionamento delle dinamiche (ed eventualmente riconsiderarle), POI si pensa al resto.
Altrimenti, buona fortuna per il tuo gioco.
-
Prima si stila il game design e si fanno dei prototipi, senza investire su grafica e amenità varie, per testare il funzionamento delle dinamiche (ed eventualmente riconsiderarle), POI si pensa al resto.
Altrimenti, buona fortuna per il tuo gioco.
Sinceramente posso darti ragione al 50% ma anche darti torto nel restante 50% da esperienza personale!!!
Mi spiego, se io personalmente a muro non vedo concept, non leggo una sceneggiatura e magari non ho una linea di produzione visiva anche in maniera proprio stilizzata, personalmente non me ne frega assolutamente nulla di investire tempo nella programmazione di un gioco che non so come deve venire fuori. Un game design deve sapere bene, come dici tu, sia le dinamiche del gioco ma anche di come quel gioco deve venire fuori graficamente. L'altra settimana mi sono dovuto incontrare con un programmatore per lavoro e gli dico la mia idea, lui mi guarda e mi chiede di mostrargli sceneggiatura e concept di gioco. Io che ancora non ho in mano nulla gli dico che queste cose non c'erano. Lui mi guarda e mi dice che senza una sceneggiatura, difficilmente lui poteva andare a lavorare su un codice dato che per muovere un oggetto o programmare una IA, doveva sapere cosa avrebbe fatto quell'oggetto e come si comportà l'IA!!! Insomma, se le cose in programmazione si possono fare si fanno ma se manca una struttura (anche solo abbozzata), ci si trova in mano ad avere solo codice che serve a poco. Cosi allo stesso modo con un animatore 3D, se non vede come un soggetto si deve muovere o che animazione deve fare - e lo si vede da un concept - il lavoro parte ancora più complesso!!! Idem per il modellatore che deve avere sempre un model sheet per modellare un oggetto. Quindi no, per me non è tempo sprecato investire prima nella parte grafica.
Poi, gusti eh, io nelle mie produzioni attuali la prima cosa a cui sto pensando sono concept, soggetto del gioco e sceneggatura se necessita.
Con questo stadio già pronto in mano mia, parlare con un programmatore o un modellatore 3D per me è solo una strada in discesa, dato che non tutti hanno la fantasia di immaginarsi le cose e vedere dei disegni su carta, aiuta e anche tanto cosi come avere una sceneggiatura del progetto, serve tantissimo al programmatore che sa bene cosa deve succedere nel gioco dall'inizio alla fine.
-
collisioni per pixel...platform... qualcuno sta sbagliando qualcosa?
Ho detto "platform", potevo dire "shooter a scorrimento", non cambiava molto ai fini dell'esempio.
E comunque tecnologia e linguaggio di programmazione sono due robe un pò diverse.
Lo so, e per questo ho scritto 'correggo', e in ogni caso penso che nell'open post anche se si dice 'linguaggio di programmazione' la domanda reale riguardasse questo.
-
Prima si stila il game design e si fanno dei prototipi, senza investire su grafica e amenità varie, per testare il funzionamento delle dinamiche (ed eventualmente riconsiderarle), POI si pensa al resto.
Altrimenti, buona fortuna per il tuo gioco.
Sinceramente posso darti ragione al 50% ma anche darti torto nel restante 50% da esperienza personale!!!
Mi spiego, se io personalmente a muro non vedo concept, non leggo una sceneggiatura e magari non ho una linea di produzione visiva anche in maniera proprio stilizzata, personalmente non me ne frega assolutamente nulla di investire tempo nella programmazione di un gioco che non so come deve venire fuori. Un game design deve sapere bene, come dici tu, sia le dinamiche del gioco ma anche di come quel gioco deve venire fuori graficamente. L'altra settimana mi sono dovuto incontrare con un programmatore per lavoro e gli dico la mia idea, lui mi guarda e mi chiede di mostrargli sceneggiatura e concept di gioco. Io che ancora non ho in mano nulla gli dico che queste cose non c'erano. Lui mi guarda e mi dice che senza una sceneggiatura, difficilmente lui poteva andare a lavorare su un codice dato che per muovere un oggetto o programmare una IA, doveva sapere cosa avrebbe fatto quell'oggetto e come si comportà l'IA!!! Insomma, se le cose in programmazione si possono fare si fanno ma se manca una struttura (anche solo abbozzata), ci si trova in mano ad avere solo codice che serve a poco. Cosi allo stesso modo con un animatore 3D, se non vede come un soggetto si deve muovere o che animazione deve fare - e lo si vede da un concept - il lavoro parte ancora più complesso!!! Idem per il modellatore che deve avere sempre un model sheet per modellare un oggetto. Quindi no, per me non è tempo sprecato investire prima nella parte grafica.
Poi, gusti eh, io nelle mie produzioni attuali la prima cosa a cui sto pensando sono concept, soggetto del gioco e sceneggatura se necessita.
Con questo stadio già pronto in mano mia, parlare con un programmatore o un modellatore 3D per me è solo una strada in discesa, dato che non tutti hanno la fantasia di immaginarsi le cose e vedere dei disegni su carta, aiuta e anche tanto cosi come avere una sceneggiatura del progetto, serve tantissimo al programmatore che sa bene cosa deve succedere nel gioco dall'inizio alla fine.
Quella che tu chiami 'parte grafica' si chiama appunto fase di concept, che include anche bozze disegnate dagli artisti certo, ma che in realtà è roba che spesso e volentieri manco ci finisce nel gioco, perchè è appunto materiale di reference.
Perciò diamo a questa fase il giusto nome, se no ci si confonde.
E' sacrosanto partire da lì, si fa e si deve, sebbene prima di andare dall'illustratore a chiedergli di fare uno studio del personaggio principale, è buona norma che il game designer o lo sceneggiatore di turno lo abbia già definito in tutto e per tutto senza sprecare tempo e quindi danaro.
Ciò detto di solito la tecnologia non dovrebbe influenzare un concept, però è anche vero che in produzioni minori non c'è il budget per fare chissà che. Anche qua a volte comprendere il proprio limite tecnologico e farne la propria forza non è una mossa del tutto scema, anzi.
Ma occhio perchè con tecnologia intendo roba importante, non di certo pixel perfect collisions o meno(che fra parentesi non viene usata nemmeno nei picchiaduro, quindi deh, insomma..): cazzo ne so, engine di gioco di terze parti? che moduli mette a disposizione? quanto è customizzabile? Quante risorse ho? quanti programmatori? artisti? ecc ecc
Insomma ce n'è per farsene di domande.
Per Neo-Geo che magari è profano dell'ambiente: tecnologia e linguaggio di programmazione non sono la stessa roba. Quindi la tecnologia se manca ti può limitare(ma in alcuni casi anche ispirare), il linguaggio di programmazione non ti cambia di una virgola un concept che hai in mente.
-
collisioni per pixel...platform... qualcuno sta sbagliando qualcosa?
Ho detto "platform", potevo dire "shooter a scorrimento", non cambiava molto ai fini dell'esempio.
Puoi meterci tutti i generi che vuoi: se controbatti con un esempio fai almeno modo che sia valido :asd:
Però hai ragione non cambia molto ai fini dell'esempio. Rimane sbagliato :asd:
-
Quella che tu chiami 'parte grafica' si chiama appunto fase di concept, che include anche bozze disegnate dagli artisti certo, ma che in realtà è roba che spesso e volentieri manco ci finisce nel gioco, perchè è appunto materiale di reference.
No, in verità io dicevo concept e basta senza andare a toccare la grafica in-game vera e propria che viene davvero molto dopo mood, bozzetti e concept definitivi da passare poi a modellatori e animatori. Comunque per me l'ossatura base rimane sempre il soggetto anzi, ancora meglio, ci si deve concentrare su un bel game treatment complessivo di modo da avere bene in testa tutte le parti del gioco: conoscere cosa fa il personaggio controllato dal giocatore, cosa fanno i nemici, cosa si può fare nel gioco, il motore grafico da usare, lo stile creativo, la musica etc etc etc...questa per me è la base vera di ogni gioco che si vule andare a creare.
Personalmente non sono mai stato coinvolto nella realizzazione di un platform anche perchè non sarebbe proprio nelle mie corde ma con il gruppo con cui lavoro stiamo realizzando uno shooter isometrico e sto imparando che nulla deve essere lasciato al caso...tutto deve essere pianificato comunque alla base, anche se poi magari alcune cose si scartano e c'è capitato di dire: ok, questo è bello, sarebbe bello implementarlo ma non si può fare. Succede. Però è una cosa che era stata progettata e non messa li tanto per dire che c'era.
In ultimo, si è detto che "la tecnologia non dovrebbe influenzare un concept" ma purtroppo è proprio la tecnologia a mietere più vittime nei piccoli studi o in quelle persone che magari non hanno grandi mezzi per sviluppare giochi in proprio. Però a questo si possono trovare delle valide alternative strutturali...in giro ci sono molti indie game ridicoli come grafica ma che sono delle perle a livello ludico. Scegliere un buon motore grafico e sapere cosa "non può fare" è forse la cosa migliore che possa capitare alla fase creativa e alla risoluzione dei problemi dato che ci spinge sempre a trovare strade alternative per ovviare al problema :)
-
Però hai ragione non cambia molto ai fini dell'esempio. Rimane sbagliato :asd:
Perché scusa? L'esempio era al fine di dire che la tecnologia spesso influenza il design, perché a volte non c'è scelta e bisogna usare una certa tecnologia, e quindi il design ne viene influenzato.
E mi è venuto in mente l'esempio delle collisioni pixel-perfect perché è stato uno dei motivi per cui il famoso Wingers non è uscito, e una scelta sbagliata in fase di pianificazione, in cui si sarebbe dovuto fare i conti con la tecnologia da usare fin dall'inizio e modificare il design di conseguenza, e che alla fine s'è rivelato uno dei problemi più grossi del gioco (che io avevo previsto, del genere "L'avevo detto io!...") e che insieme ad altre piccole cose ha portato a non farlo uscire.
-
Stavo citando l'esempio di Wingers ieri ad un mio collega con cose del tipo "ecco come si fregano i soldi ai contribuenti: ti racconto una storia .."
Il motivo per cui wingers non è uscito è per via delle perfect pixel collisions?
Ciro ti prego. Un gioco non sparisce nel nulla perchè in fase di design qualcuno s'è inventato una feature inutile.
Ti prego non andare a dire certe cose allo IED o in qualsiasi luogo andrai a fare la case history del tuo gioco. :|
-
Wingers! :rotfl:
Wingers si esegue all'interno del Brawser internet. Ricordati di selezionare Explorer o Firefox come Brawser predefinitp.
Credo che il problema del famoso Wingers non siano le collisioni pixel-perfect.
:rotfl:
-
Brawser.
-
Il motivo per cui wingers non è uscito è per via delle perfect pixel collisions?
Ciro ti prego. Un gioco non sparisce nel nulla perchè in fase di design qualcuno s'è inventato una feature inutile.
Grazie per la lezione di superiorità, Cherno, peccato che a Wingers ci ho lavorato io, non tu.
Comunque non me la prendo perché ho scritto il primo post in questo thread sapendo già che scrivere una cosa qui avrebbe voluto dire generare un bashing incredibile a colpi di battutine e senza argomentazioni, ed ho avuto ragione :D
-
Bawshing.
-
(http://www.wingers.it/images/deco.jpg)
-
Il motivo per cui wingers non è uscito è per via delle perfect pixel collisions?
Ciro ti prego. Un gioco non sparisce nel nulla perchè in fase di design qualcuno s'è inventato una feature inutile.
Grazie per la lezione di superiorità, Cherno, peccato che a Wingers ci ho lavorato io, non tu.
Comunque non me la prendo perché ho scritto il primo post in questo thread sapendo già che scrivere una cosa qui avrebbe voluto dire generare un bashing incredibile a colpi di battutine e senza argomentazioni, ed ho avuto ragione :D
[OT]
Sì ci hai lavorato tu e tutta la cricca di gente che che ben conosciamo. E quindi? Siete stati così bravi, professionali e spinti da una passione e vena creativa, che il gioco non è uscito. Applausi, signori, applausi.
[/OT]
Tornando in topic. La mia non è questione di superiorità e ti prego di non saltare a conclusioni affrettate e di non prenderla neanche sul personale: però per la mia esperienza(e a vedere bene anche quella di altri) quello che hai scritto è una sciocchezza.
Dal canto mio sinceramente ho spiegato molto bene le mie opinioni sulle questioni sollevate, soprattutto sul fattore tecnologico, dicendo anche che la limitazione è essa stessa fonte di ispirazione.
Perciò visto che ci siamo e che hai tirato fuori tu il discorso, ora si vorrebbe capire da te in quale modo decidere di implementare le collisioni pixel perfect possa compromettere l'uscita di un prodotto.
A livello pratico, non di esempio: qua c'è gente che ha chiesto come si fa un platform. E' giusto che abbia risposte.
-
Sì ci hai lavorato tu e tutta la cricca di gente che che ben conosciamo. E quindi? Siete stati così bravi, professionali e spinti da una passione e vena creativa, che il gioco non è uscito. Applausi, signori, applausi.
Ripeto: a Wingers ci ho lavorato io e non tu, quindi ti posso assicurare che anche se avessi avuto una vena creativa come quelle che ha Schwarzenegger dei tempi d'oro sul collo, non cambiava molto.
Sui motivi per cui non è uscito, ce ne sono tanti. Mi preme solo dirti che a me, Wingers, ovvero quello che vedete voi esterni, fa cacare. Il lavoro che ci ho fatto non l'avete mai visto e mai lo vedrete, perché la parte che ho programmato (i menu) di fatto non è mai stata visibile, neanche nel video dell'IVDC 2008 (che ho editato io con il poco gameplay che avevamo).
Inoltre, tu parli di "cricca", ma non sai neanche chi ci ha lavorato. Io ti dico che noi della 'cricca', stipendiati per lavorarci, abbiamo fatto quello che potevamo con i mezzi che ci sono stati messi a disposizione e cercando di soddisfare le direttive che avevamo, anche se poi quando siamo andati via qualcuno ha detto il contrario a quelli che sono arrivati in sostituzione per giustificare il misero stato del gioco.
Comunque, per riavvicinarmi al topic ti racconto l'aneddoto che io trovo molto importante. Quando si trattava di decidere "come" fare il gioco, s'era scelto Flash come tecnologia. In una delle prime riunioni, loro avevano proposto di creare scenari giganti che fossero un'unica bitmap enorme, anzi più di una perché c'erano più livelli di parallasse.
Questo perché volevano che si smangiasse sulle esplosioni come in Worms.
Io avevo avvertito che sarebbe stato difficile se non impossibile farlo in Flash, e avevo proposto una gestione dello stage fatto con asset di dimensioni minori, componibili, per poter visualizzare solo quelli effettivamente a schermo, e di usare Box2D per la fisica - e a tal proposito avevo anche pensato ad una serie di scenari di gameplay molto carini.
Mi hanno detto che non si poteva fare, che bisognava fare un'unica grande bitmap perché "sennò veniva brutto", che usando elementi componibili veniva "poco artistico", ecc. Io ho insistito e per questo la riunione è finita quasi a mazzate, e ovviamente essendo un minion ho dovuto starmi zitto.
Ora, il programmatore del gioco fece anche un gran lavoro, ottenendo questa sorta di engine che caricava questi mostri da 8000 x 4000 pixel, con le collisioni pixel di cui dicevo, e i missili che smangiavano il terreno, e le granate con la fisica del rimbalzo.
Sfortunatamente - come previsto - non si arrivò mai ad un framerate decente.
Ora, non dico che questo è il motivo per cui il gioco non è uscito, ma è sicuramente il motivo per cui s'è perso tanto tempo e per cui il gioco all'IVDC 2008 era così inguardabile.
Ti va bene come risposta?
Poi non so, se non vuoi anche tu il mio CV (http://arsludica.org/forum/index.php?topic=5231.msg83658#msg83658) ma vuoi parlare di cose reali per criticarmi, critica questo: http://arsludica.org/forum/index.php?topic=5231.new#new (http://arsludica.org/forum/index.php?topic=5231.new#new) che è il mio lavoro e di cui rispondo (dico anche a Vazkor che è lanciatissimo sull'umorismo, vedo).
Se sparli di Wingers non stai offendendo me.
Detto questo, mi sono un po' rotto le palle di queste continue frecciate qui sul forum...
-
Ma infatti, per quanto tempo Ciro dovrà continuare a giustificarsi per aver lavorato a Wingers? Non ha mica deportato gente nei campi di concentramento :boh2: . La parte "poco chiara" dello sviluppo di quel gioco e la sua schifosità globale non è certo responsabilità dei "minion" che ci hanno messo il loro giovanile entusiasmo (e mancanza di alternative lavorative).
Proseguiamo nel topic :sisi:
-
ossignore non si può parlare qua dentro.
-
Sì ci hai lavorato tu e tutta la cricca di gente che che ben conosciamo. E quindi? Siete stati così bravi, professionali e spinti da una passione e vena creativa, che il gioco non è uscito. Applausi, signori, applausi.
Ripeto: a Wingers ci ho lavorato io e non tu, quindi ti posso assicurare che anche se avessi avuto una vena creativa come quelle che ha Schwarzenegger dei tempi d'oro sul collo, non cambiava molto.
Sui motivi per cui non è uscito, ce ne sono tanti. Mi preme solo dirti che a me, Wingers, ovvero quello che vedete voi esterni, fa cacare. Il lavoro che ci ho fatto non l'avete mai visto e mai lo vedrete, perché la parte che ho programmato (i menu) di fatto non è mai stata visibile, neanche nel video dell'IVDC 2008 (che ho editato io con il poco gameplay che avevamo).
Inoltre, tu parli di "cricca", ma non sai neanche chi ci ha lavorato. Io ti dico che noi della 'cricca', stipendiati per lavorarci, abbiamo fatto quello che potevamo con i mezzi che ci sono stati messi a disposizione e cercando di soddisfare le direttive che avevamo, anche se poi quando siamo andati via qualcuno ha detto il contrario a quelli che sono arrivati in sostituzione per giustificare il misero stato del gioco.
Comunque, per riavvicinarmi al topic ti racconto l'aneddoto che io trovo molto importante. Quando si trattava di decidere "come" fare il gioco, s'era scelto Flash come tecnologia. In una delle prime riunioni, loro avevano proposto di creare scenari giganti che fossero un'unica bitmap enorme, anzi più di una perché c'erano più livelli di parallasse.
Questo perché volevano che si smangiasse sulle esplosioni come in Worms.
Io avevo avvertito che sarebbe stato difficile se non impossibile farlo in Flash, e avevo proposto una gestione dello stage fatto con asset di dimensioni minori, componibili, per poter visualizzare solo quelli effettivamente a schermo, e di usare Box2D per la fisica - e a tal proposito avevo anche pensato ad una serie di scenari di gameplay molto carini.
Mi hanno detto che non si poteva fare, che bisognava fare un'unica grande bitmap perché "sennò veniva brutto", che usando elementi componibili veniva "poco artistico", ecc. Io ho insistito e per questo la riunione è finita quasi a mazzate, e ovviamente essendo un minion ho dovuto starmi zitto.
Ora, il programmatore del gioco fece anche un gran lavoro, ottenendo questa sorta di engine che caricava questi mostri da 8000 x 4000 pixel, con le collisioni pixel di cui dicevo, e i missili che smangiavano il terreno, e le granate con la fisica del rimbalzo.
Sfortunatamente - come previsto - non si arrivò mai ad un framerate decente.
Ora, non dico che questo è il motivo per cui il gioco non è uscito, ma è sicuramente il motivo per cui s'è perso tanto tempo e per cui il gioco all'IVDC 2008 era così inguardabile.
Ti va bene come risposta?
Poi non so, se non vuoi anche tu il mio CV (http://arsludica.org/forum/index.php?topic=5231.msg83658#msg83658) ma vuoi parlare di cose reali per criticarmi, critica questo: http://arsludica.org/forum/index.php?topic=5231.new#new (http://arsludica.org/forum/index.php?topic=5231.new#new) che è il mio lavoro e di cui rispondo (dico anche a Vazkor che è lanciatissimo sull'umorismo, vedo).
Se sparli di Wingers non stai offendendo me.
Detto questo, mi sono un po' rotto le palle di queste continue frecciate qui sul forum...
Sì mi va bene come risposta, ma ti ripeto lì il problema non è il metodo che si è scelto: proprio come hai detto il problema è stato che qualcuno molto incompetente ha imposto la sua visione al team, creando un grosso problema tecnico. Quel che dici invece è un ottimo spunto per parlare di quanto sia importante che le competenze siano distribuite in modo sensato nel team, onde evitare situazioni che hai vissuto.
-
il linguaggio di programmazione influenza il game design?
Assolutamente no.
Su questo non sono d'accordo... o meglio, correggo: la tecnologia che usi influenza il game design.
Esempio, uno su tutti: se non hai a disposizione collisioni per-pixel (perché magari il tuo gioco ha il gameplay in 2D ma gestisce i tile come poligoni in una scena 3D) ma solo poligonali, i tuoi asset dovranno avere delle forme squadrate o quantomeno componibili da forme di base.
Tornando in topic, mi e' stata fatta una domanda precisa, che e': "il linguaggio di programmazione influenza il game design?" ed io ho dato una risposta precisa: "assolutamente no". Che difendo.
Ciro, al di la' del bashing e/o trollame a vario titolo e/o antipatie personali, una cosa e' il linguaggio di programmazione (C/C++/C#/Flash) e una cosa e' la tecnologia, cioe', in concreto, COSA ci fai con il linguaggio.
Per capirci: io uso un linguaggio (che sia C o Flash) per costruire una tecnologia (per esempio le collisioni pixel-perfect o con gli AABB o a poligono).
Dopodiche', posso usare il C per costruire indifferentemente la tecnologia per le collisioni pixel-perfect o a poligono, oppure posso usare Flash per costruire collisioni pixel-perfect o a poligono.
Una volta che ci si e' chiariti sul significato di "tecnologia" e di "linguaggio di programmazione", la regola generale e' che puoi usare qualsiasi linguaggio di programmazione per costruire qualsiasi tecnologia. Per questo ho risposto che "no, il linguaggio di programmazione non influenza il game design".
Il discorso "con Wingers abbiamo usato Flash per fare una cosa ed e' andata storta perche' Flash" e' un buon esempio, ma di qualcos'altro, perche' li' il discorso e' diverso: avete sbagliato tecnologia, che e' quello che hai scritto anche tu (l'errore e' stato decidere di organizzare la scena in "mostri da 8000 x 4000 pixel" anziche' usare una mappa di tile), ma questo non vuol dire che avete sbagliato linguaggio di programmazione, vuole solo dire che l'avete usato male.
In questi termini non e' "la tecnologia che influenza il game design", e' al contrario: la tecnologia e' una cosa che va pensata come trait-d'union tra game design e piattaforma ("cosa vogliamo fare" + "cosa possiamo fisicamente fare dato l'hardware" = "come farlo"), e in quanto tale e' proprio il contrario: e' il game design che influenza la tecnologia.
Poi e' chiaro che esistono limiti tecnici - uno mica si sogna di fare, chesso', Halo 3 su iPhone paro paro a quello 360 perche', tipo, l'iPhone non e' potente come un 360 - e che magari alcune tecnologie sono fuori portata dato l'hardware, ma continua a non essere un problema di linguaggio.
-
Tornando in topic, mi e' stata fatta una domanda precisa, che e': "il linguaggio di programmazione influenza il game design?" ed io ho dato una risposta precisa: "assolutamente no". Che difendo.
E io ripeto, la tua risposta è corretta, ma la domanda fatta non mi sembra per niente 'precisa', perciò infatti ho detto:
Su questo non sono d'accordo... o meglio, correggo: la tecnologia che usi influenza il game design.
Dove 'correggo' vuol dire: "immagino che tu (NEO-GEO) con linguaggio di programmazione intendevi più genericamente la tecnologia, l'engine, la piattaforma su cui andare, e quindi SÍ, penso che il design venga influenzato da queste cose".
Certo se devo fare post chilometrici per spiegare questa sottigliezza, solo perché se dico che non sono d'accordo si scatena il putiferio e mi attaccano in tre...
Riguardo l'offtopic:
ossignore non si può parlare qua dentro.
Se tu non te ne uscissi con cose come queste
La mia non è questione di superiorità e ti prego di non saltare a conclusioni affrettate e di non prenderla neanche sul personale
Dopo aver detto questo
Ti prego non andare a dire certe cose allo IED o in qualsiasi luogo andrai a fare la case history del tuo gioco.
Sì ci hai lavorato tu e tutta la cricca di gente che che ben conosciamo. E quindi? Siete stati così bravi, professionali e spinti da una passione e vena creativa, che il gioco non è uscito. Applausi, signori, applausi.
Spalando merda sugli altri senza neanche sapere bene di cosa si sta parlando... uno che deve fare?
Direi che solo StM ha capito la questione.
Detto questo vorrei capire come ca** ci si cancella da sto forum una volta per tutte.
-
A me pare che ciro abbia subito specificato che si riferiva alla tecnologia e non al linguaggio.
Anche perché essendo i principlai linguaggi turing completi, non ci sono differenze. Quello che cambia é l'implementazione di tali linguaggi.
-
Tornando in topic, mi e' stata fatta una domanda precisa, che e': "il linguaggio di programmazione influenza il game design?" ed io ho dato una risposta precisa: "assolutamente no". Che difendo.
E io ripeto, la tua risposta è corretta, ma la domanda fatta non mi sembra per niente 'precisa', perciò infatti ho detto:
Su questo non sono d'accordo... o meglio, correggo: la tecnologia che usi influenza il game design.
Dove 'correggo' vuol dire: "immagino che tu (NEO-GEO) con linguaggio di programmazione intendevi più genericamente la tecnologia, l'engine, la piattaforma su cui andare, e quindi SÍ, penso che il design venga influenzato da queste cose".
Certo se devo fare post chilometrici per spiegare questa sottigliezza, solo perché se dico che non sono d'accordo si scatena il putiferio e mi attaccano in tre...
Premesso che non mi sembra di aver attaccato nessuno, ritorno a difendere la mia risposta (perche' tu hai diritto come tutti a dire la tua, ma anch'io).
Se anche la domanda volesse significare quello che dici (cosa che al limite ci dira' NEO-GEO), torno a ripetere che non e' la tecnologia che usi a decidere del game design ma il contrario perche':
- e' il game design a decidere la piattaforma (un platform per console e' molto diverso da uno per mobile, ad esempio, anche solo per l'input)
- e' il game design a decidere la tecnologia, di cui l'engine fa parte (se devo fare un platform, non ha senso usare un engine specializzato per gli fps e poi fargli fare i salti mortali)
Per questo ho editato il post precedente per aggiungere che:
In questi termini non e' "la tecnologia che influenza il game design", e' al contrario: la tecnologia e' una cosa che va pensata come trait-d'union tra game design e piattaforma ("cosa vogliamo fare" + "cosa possiamo fisicamente fare dato l'hardware" = "come farlo"), e in quanto tale e' proprio il contrario: e' il game design che influenza la tecnologia.
Il tuo esempio su Wingers, ripeto, non dice come la tecnologia influenza il game design. Dice che se sbagli tecnologia poi tutto va a rane.
Che e' vero ed e' giusto, sia chiaro; ma non c'entra con il discorso.
Ma che devo dire? Non sei l'unico che scrive post chilometrici e non viene capito. Anzi, in effetti HO capito quello che dici, e' solo che non sono d'accordo.
Tant'e' che ho risposto con la mia opinione, sia alla questione "linguaggio" sia alla questione "tecnologia". Per non sbagliare.
-
Il tuo esempio su Wingers, ripeto, non dice come la tecnologia influenza il game design. Dice che se sbagli tecnologia poi tutto va a rane.
Che e' vero ed e' giusto, sia chiaro; ma non c'entra con il discorso.
Il mio era un esempio in negativo, visto che abbiamo lavorato su un design fregandocene dei limiti della tecnologia che usavamo, e siamo stati puniti (li ripeto non tanto per te, che so che lo hai capito).
-
A me pare che ciro abbia subito specificato che si riferiva alla tecnologia e non al linguaggio.
Anche perché essendo i principlai linguaggi turing completi, non ci sono differenze. Quello che cambia é l'implementazione di tali linguaggi.
Sì ma il dubbio ce l'ha neo geo che ha aperto il topic, è a lui che bisogna dare risposte corrette utilizzando termini giusti e qualora ci siano delle imprecisioni di termini chiarirle subito. Onde evitare quello che è successo in questo topic. Cioè incomprensione.
Quindi per quanto interessante quello che dice Ciro, bisogna tenere conto che la domanda di neo geo era sul linguaggio di programmazione e non sulla tecnologia.
Non c'è bisogno di tirare in ballo Turing, davvero.
-
Appurato che con tutti i linguaggi si può fare tutto, banalizziamo: in alcuni linguaggi (ma sarebbe meglio dire piattaforme di sviluppo, giacché uno stesso linguaggio è spesso usato su piattaforme molto diverse - javascript ora è usato anche per grattarsi il sedere) ci sono tools, framework, librerie che rendono lo sviluppo di certe cose più facile. E magari una piattaforma che permette una prototipazione veloce può incoraggiare a fare più prove pratiche.
-
Appurato che con tutti i linguaggi si può fare tutto, banalizziamo: in alcuni linguaggi (ma sarebbe meglio dire piattaforme di sviluppo, giacché uno stesso linguaggio è spesso usato su piattaforme molto diverse - javascript ora è usato anche per grattarsi il sedere) ci sono tools, framework, librerie che rendono lo sviluppo di certe cose più facile. E magari una piattaforma che permette una prototipazione veloce può incoraggiare a fare più prove pratiche.
Esattamente: e' per questo che dico che e' la tecnologia che viene influenzata dal game design ("voglio fare un platform cosi', PERCIO' scelgo questo framework/tool/coso che ha il 90% di quel che mi serve"), e non il contrario.
-
Allora, siamo d'accordo che esistono entrambi i casi e che la tua risposta forse è più giusta.
Però perdonami Id, nell'ottica in cui l'utente che ha fatto la domanda sia alle prime armi (perché è quella l'impressione), tu pensi sia una buona idea dirgli "la tecnologia/il linguaggio vengono a seguito del design" e mandarlo a farsi il design del suo gioco senza freni, per poi scoprire magari che la strada di design che aveva intrapreso è infattibile per le sue capacità tecniche, disponibilità economiche del momento, ecc.?
Non pensi sia più formativo pensarla al contrario, partendo dai limiti e su quello adattare alcune (non tutte) le scelte di design? Capisco che è un po' andarci coi piedi di piombo, ma penso che in questa situazione è il consiglio migliore per lui.
Per quanto poi in generale quando ci sono i mezzi e le capacità dovrebbe essere come hai detto tu.
-
In generale però direi che è meglio avere un metodo per il quale si riesca a compilare una sorta di lista della spesa, piuttosto che andare allo sbaraglio.
Poi le valutazioni pratiche, incluso anche il non affidarsi a nessuna tecnologia già bella e che pronta, possano arrivare nel momento in cui una prima fase di ricerca e definizione di design sia terminata.
Il fatto è che pensarla al contrario come dici tu, richiede molta più esperienza o attitudine, o tutte e due. Vuol dire avere già metabolizzato alcuni tipi di ragionamenti ed avere piena padronanza di quello che si vuole andare a fare. Un neofita dovrebbe invece prima seguire un modello.
-
Però perdonami Id, nell'ottica in cui l'utente che ha fatto la domanda sia alle prime armi (perché è quella l'impressione), tu pensi sia una buona idea dirgli "la tecnologia/il linguaggio vengono a seguito del design" e mandarlo a farsi il design del suo gioco senza freni, per poi scoprire magari che la strada di design che aveva intrapreso è infattibile per le sue capacità tecniche, disponibilità economiche del momento, ecc.?
Non pensi sia più formativo pensarla al contrario, partendo dai limiti e su quello adattare alcune (non tutte) le scelte di design? Capisco che è un po' andarci coi piedi di piombo, ma penso che in questa situazione è il consiglio migliore per lui.
Per quanto poi in generale quando ci sono i mezzi e le capacità dovrebbe essere come hai detto tu.
"Nell'ottica in cui e' stata fatta la domanda". Sara' deformazione professionale, cercare sottotesti in quello che scrive qualcun altro?
E' stata fatta una domanda precisa, ho dato una risposta precisa; e se anche hai ragione sull'ottica, sinceramente penso sia una buona idea partire dal decidere dove andare prima di mettersi a correre (e perdersi).
Mi aspetto cmq di parlare con qualcuno che non e' idiota e non si propone niente di fuori di testa come primo esperimento.
Partire dalla tecnologia ha senso solo se non e' il primo titolo o cmq quando hai gia' della tecnologia e hai intenzione di sfruttarla il piu' possibile per minimizzare i costi ("ho fatto uno shoot'em up semplice, aggiungo feature e cambio asset grafici, cosi' ne faccio un altro o faccio il seguito").
-
A me pare che ciro abbia subito specificato che si riferiva alla tecnologia e non al linguaggio.
Anche perché essendo i principlai linguaggi turing completi, non ci sono differenze. Quello che cambia é l'implementazione di tali linguaggi.
Se vogliamo fare i fighi, anche Magic the Gathering è Turing-completo[1]. Un applauso al primo che mi fa il port di Doom giocabile.
Oh, magari c'è la carta che fa int 0x10 e ci manda in mode 13.
Tornando in topic, la risposta alla domanda è già stata data dal sensei francese.
Quello che ti serve è, in genere: disegnare sprite, disegnare tile, gestire l'input.
Se ci sono librerie/binding per fare queste cose nel tuo linguaggio preferito, allora vai.
Il resto non è un problema. Se hai un problema con l'implementazione di qualche feature, chiediti se serva davvero ai fini della realizzazione di un platform, perché li facevano già sul C64 giochi del genere.
1. http://www.toothycat.net/~hologram/Turing/HowItWorks.html (http://www.toothycat.net/~hologram/Turing/HowItWorks.html)
-
come si fa?
Non parlo di programmazzione ma solo di game design. C'è della letteratura in proposito?
bisogna saper disegnare? il linguaggio di programmazione influenza il game design?
Inviato dal mio GT-I9100 con Tapatalk 2
Piu' che letture sul design di un platform game, potresti cercare qualcosa sulla programmazione stessa.
Per quanto riguarda il design, quello dipende da te e dalla tua idea, basta che il punto di partenza sia un gioco in cui figura un personaggio che possa saltare e delle piattaforme su cui muoversi, il resto e' a tua completa discrezione.
-
Bum! Anni di cultura sul game design buttati nel cesso :asd:
-
Cultura e' una parola grossa... Ci sono scuole di pensiero e linee guida, a cui uno puo' ispirarsi o meno.
Un platform game alla Mario ha degli elementi molto diversi da uno alla Sonic, eppure sono platform game entrambi, nati semplicemente da un'idea del loro creatore e non da qualche "cultura" scritta chissa' dove.
Rifarsi alle idee degli altri come linee guida non penso si possa definire cultura, ma solo mancanza di innovazione e creativita'.
-
sei troppo forte.
-
sei troppo forte.
Vorrei poter dire la stessa cosa di te...
-
Un'idea di Miyamoto che è banale, evidente e abusata è: saltare in testa ai nemici per ucciderli. Riutilizzare quest'idea può essere che denoti mancanza di innovazione e creatività (ma poi Braid?).
Un'idea di Miyamoto che invece in molti si dimenticano è: rendi comprensibile e immediatamente evidente la funzione degli oggetti a schermo. Il giocatore non dovrà mai avere dubbi se incappare in un certo oggetto gli farà bene o male, o se un oggetto è interagibile o fa solo parte dello scenario. E qui puoi decidere se copiare gli stessi identici sprite di Super Mario per i tuoi power-up (niente innovazione, buuu), oppure stare a sentire cosa dice Miyamoto sui modi di ottenere risultati analoghi ma senza copiare qualcosa di esistente.
Ogni mestiere ha una sua storia, che ignorare è spesso una cattiva idea. Certo, potresti essere il Mozart dei videogiochi e non avere nessun bisogno di imparare da altri perché fai cose del tutto nuove e sconvolgenti; oppure no, e allora imparare qualcosa da chi ti ha preceduto è una buona idea.
-
Meno male che qualcuno mi capisce ogni tanto, grazie stm :D
-
Il giocatore non dovrà mai avere dubbi se incappare in un certo oggetto gli farà bene o male, o se un oggetto è interagibile o fa solo parte dello scenario.
In un'intervista per i 25 anni di Mario, Miyamoto ha parlato proprio di questi dubbi, l'esempio ricadde sul goomba, molto simile ad al power-up del fungo, tanto che quest'ultimo scatenava dubbi nei giocatori, sul raccoglierlo o meno.
Discorso a parte questo.
Quello che intendo e' che forse mi sono espresso male, esistono svariati tipi di platform game, ed il genere non e' rilegato al solo "salta e schiaccia i nemici", Abe Oddysee e' un platform game, nato da un'idea innovativa e fuori dagli schemi ad esempio, prima di lui non c'era nulla di simile o quasi.
Posso essere d'accordo che avere giocare a titoli del passato possa dare un'idea di cosa un platform sia, che in sostanza vuole un gioco in cui un personaggio possa saltare (come minimo), il resto e' a discapito del programmatore, se vuole movimenti fluidi alla Mario o qualcosa di piu' statico alla Flashback.
Ma parlare di cultura nel game design secondo me (e siete liberi di non condividere) e' un'esagerazione, semmai sarebbe piu' giusto parlare di buon senso, di cosa il giocatore dovrebbe trovare nel gioco e come il tutto debba essere messo per avere un'esperienza piacevole come minimo.
Il tutto puo' venire sia giocando giochi di altri, con la possibilita' di rimanere influenzati dalle loro scelte, oppure di farne di nostre e di innovative e vedere in prima persona se il tutto e' piacevole.
Comprendo il vostro punto di vista ma non lo condivido, questo e' quanto.
-
Ogni mestiere ha una sua storia, che ignorare è spesso una cattiva idea. Certo, potresti essere il Mozart dei videogiochi e non avere nessun bisogno di imparare da altri perché fai cose del tutto nuove e sconvolgenti; oppure no, e allora imparare qualcosa da chi ti ha preceduto è una buona idea.
Quoto.
Il tutto puo' venire sia giocando giochi di altri, con la possibilita' di rimanere influenzati dalle loro scelte, oppure di farne di nostre e di innovative e vedere in prima persona se il tutto e' piacevole.
Coprendo il vostro punto di vista ma non lo condivido, questo e' quanto.
Il discorso qui e' semplice e StM secondo me lo ha riassunto bene.
Il punto importante e' in quel "potresti essere il Mozart dei videogiochi", dopodiche' il resto e' statistica: quanti sono Mozart e possono fare a meno di studiare, e quanti no? Un genio e' un genio ed e' un discorso, ma la maggior parte di noi non lo e', nonostante quel che possa piacerci pensare.
Che poi uno si potrebbe pure domandare "e se Mozart avesse studiato, comunque, avrebbe potuto fare di meglio?", ma e' un altro capitolo, e niente affatto scontato.
-
Che poi uno si potrebbe pure domandare "e se Mozart avesse studiato, comunque, avrebbe potuto fare di meglio?", ma e' un altro capitolo, e niente affatto scontato.
Mozart ovviamente ha studiato pure lui, solo che è stato precocissimo e da un certo punto in poi non ha avuto più alcun bisogno di studiare: se riesci a ricordarti a memoria e a riscrivere intere opere di altri musicisti, sentendole una sola volta, cosa puoi mai avere da imparare ancora?
-
Il giocatore non dovrà mai avere dubbi se incappare in un certo oggetto gli farà bene o male, o se un oggetto è interagibile o fa solo parte dello scenario.
Posso essere d'accordo che avere giocare a titoli del passato possa dare un'idea di cosa un platform sia, che in sostanza vuole un gioco in cui un personaggio possa saltare (come minimo), il resto e' a discapito del programmatore, se vuole movimenti fluidi alla Mario o qualcosa di piu' statico alla Flashback.
Ma parlare di cultura nel game design secondo me (e siete liberi di non condividere) e' un'esagerazione, semmai sarebbe piu' giusto parlare di buon senso, di cosa il giocatore dovrebbe trovare nel gioco e come il tutto debba essere messo per avere un'esperienza piacevole come minimo.
Abe's Oddysee aggiunge delle meccaniche nuove a meccanismi ben rodati: ad esempio prende spunto da Flashback rendendo non fluido il movimento, bensì a tile. Oltre a questo implementa gli stilemi di quella corrente di videogames chiamata Cinematic Platformers dei quali fanno parte Prince of Persia, Another World, lo stesso Flashback e molti altri. Seguendo il tuo ragionamento dovremmo dire che sì sono stati bravi ad aggiungere il controllo degli antagonisti, però poco innovatori perchè usano le meccaniche di movimento di Flashback e di Prince of Persia. Pensarla così sarebbe veramente ingiusto e immagino tu ne convenga.
Come vedi è possibile analizzare un gioco, capire da dove arriva, da dove prende spunti e cosa vuole proporre. Si possono applicare le stesse analisi che si fanno per il cinema, per la letteratura, per la musica e via discorrendo. È proprio a fronte di queste analisi che si può e si deve parlare di cultura nel game design, anche perchè a fronte di questo non facendolo significa dimenticarsi che il game design in alcuni contesti è una professione e non un mero passatempo ed in quanto tale c'è del lavoro dietro che va al di là del buon senso.
Tutto questo senza neanche tirare in ballo la programmazione, la quale è il mezzo tecnologico per l'implementazione. In ogni caso se vuoi posso consigliarti delle letture e capirai che sull'argomento c'è tanto, ma tanto sul serio.
-
E' tutto giustissimo quello che dici, e anche quello che hanno detto anche gli altri amici del forum.
Non faccio discorsi di poca innovazione, specie nel caso di Abe Oddysee, il gioco ha preso questa piega (stando ad un'intervista al suo creatore) perche' fu influenzato tempo addietro da titoli come Another World e Flashback, eppure e' una cosa che prima non si era mai vista.
E dire che ha movimenti simili a Flashback o Prince of Persia, e' come dire che Mario e Sonic sono la stessa cosa perche' saltano e corrono entrambi.
Facendo un passo indietro, partiamo dal primo gioco di questo genere, ammettendo che prima non ci fosse nulla di simile.
Il creatore ha avuto un'idea e l'ha messa in pratica, non si e' rifatto a titoli gettonati e gia' presenti, ha partorito qualcosa di suo dal nulla ed ha creato uno stile.
Ci giochi, noti i meccanismi, i contenuti e il tutto ti risulta piacevole, ma basta giocarci per comprendere il perche' di tali scelte?
Giocando a svariati platform ti accorgi che uno scimmiotta l'altro (sperando di poterne cavalcare l'onda del successo), ti accorgi che ci sono contenuti simili tra uno e l'altro, power-up, piattaforme da raggiungere, nemici da schiacciare e cosi' via.
Vedo un po' difficile pero' semplicemente giocando, comprendere il perche' di tali scelte.
Un gioco come Tomb Raider e' un platform game, eppure non hai power-up e non schiacci nessuno (come in Abe), e' l'ennesima innovazione fuori dagli schemi del genere, la cui base e' avere un personaggio giocabile che possa saltare e raggiungere piattaforme.
Ora, arriva qualcuno e chiede, cosa mi consigliate per iniziare a realizzare un mio platform game?
Giocare a tutti i platform game che riesci e fartene un'idea?
Si finisce poi con il rimanere influenzati dalle scelte degli altri, come succede spesso.
La "cultura del game design" come dite voi, non e' il conoscere il gioco di questo e di quello e vedere cosa hanno fatto, e' avere buon senso nel fare le scelte giuste nel proprio gioco per cercare di non renderlo ne banale e ne frustrante, e cio' dipende da noi.
La cultura del game design e' invece conoscere le motivazioni che hanno spinto questo e quello a fare certe scelte nel proprio prodotto, e ripeto, questo non vuol dire che siano linee guida, ma solo il loro pensiero in quel momento.
-
Questo discorso lo condivido in pieno.
Basta guardarsi intorno e rendersi conto che anche con l'onda dell'entusiasmo per qualsiasi mediocrità indie non ci sono platform derivativi che abbiano avuto un successo molto ampio. Storicamente, poi, l'essere troppo derivativo è proprio quello che ha ucciso il genere: troppi giochi che si differenziavano solo per la mascotte e il design dei livelli.
Credo che, ad oggi, il platform sia il gioco tecnicamente più semplice da realizzare ma anche quello più difficile da "vendere".
E' facile farne uno decente e ben presentato, è difficile trovare quel quid che lo renda migliore delle altre migliaia di alternative già disponibili.
-
Sì ma stiamo cadendo nel classico "è nato prima l'uovo o la gallina?"
Quello di cui parli tu è poi l'applicazione del tutto, secondo il proprio stile e la propria ispirazione il che è fondamentale. Quello che semplicemente andavo dicendo è di stare attenti a non farsi prendere dalla sindrome del genio per poi ritrovarsi a produrre un gioco che banalmente non funziona, quando bastava farsi appunto una cultura sul game design per poter analizzare pregi e difetti di diversi prodotti e non cadere in errori per i quali già altri hanno dovuto pagare.
Infatti all'inizio Id diceva una roba sacrosanta ovvero: vuoi fare un platform? giocane a vagonate, studia le meccaniche, metabolizza il tutto e fai quello che più ti piace mettendoci del tuo.
Questo vuol dire farsi una cultura, anche perchè andare allo sbaraglio porta solo a non raggiungere il proprio obiettivo, ovvero fare un gioco.
Tu giustamente hai il dubbio che così facendo uno resta incagliato in cose già fatte, ma ti dirò anche che se una persona chiede come si progetta un platform vuol dire che non ha ancora il background adeguato per fare qualcosa di veramente suo. Pensaci un attimo: quando impari a scrivere copi dei disegni fin quando non metabolizzi il concetto che quel disegno è una lettera e che una sequenza di lettere formano un periodo, la quale utilità è esprimere dei pensieri che ci passano in testa. Se però uno salta la fase di riproduzione, non potrà mai scrivere cose sue. Vale lo stesso per la lettura: una persona che non legge non sà esprimersi, nè tantomeno scrivere in maniera adeguata e via così potremmo andare avanti all'infinito.
-
Questo discorso lo condivido in pieno.
Basta guardarsi intorno e rendersi conto che anche con l'onda dell'entusiasmo per qualsiasi mediocrità indie non ci sono platform derivativi che abbiano avuto un successo molto ampio. Storicamente, poi, l'essere troppo derivativo è proprio quello che ha ucciso il genere: troppi giochi che si differenziavano solo per la mascotte e il design dei livelli.
Credo che, ad oggi, il platform sia il gioco tecnicamente più semplice da realizzare ma anche quello più difficile da "vendere".
E' facile farne uno decente e ben presentato, è difficile trovare quel quid che lo renda migliore delle altre migliaia di alternative già disponibili.
In buona sostanza vuol dire che è difficile fare un prodotto valido. Ho paura che in questa discussione si vada troppo a mischiare il lato tecnico, con il lato di design.
-
come si fa?
Non parlo di programmazzione ma solo di game design. C'è della letteratura in proposito?
bisogna saper disegnare? il linguaggio di programmazione influenza il game design?
Inviato dal mio GT-I9100 con Tapatalk 2
Piu' che letture sul design di un platform game, potresti cercare qualcosa sulla programmazione stessa.
Per quanto riguarda il design, quello dipende da te e dalla tua idea, basta che il punto di partenza sia un gioco in cui figura un personaggio che possa saltare e delle piattaforme su cui muoversi, il resto e' a tua completa discrezione.
No ecco la programazione non è proprio il mio forte. A me interesseva proprio il puro e semplice design.
Inviato dal mio GT-I9100 con Tapatalk 2