COME DIVENTARE SVILUPPATORI Opzioni

[faustigno]

Ma come si fa a diventare sviluppatore di programmi o giochi per ds?? E' difficile?? Scusatemi ma in questo campo sono un analfabeta

P.S. ESISTE PER CASO QUALCHE GUIDA??

[batblaster]

Mi inserisco in questa discussione perchè mi interessa molto essedo uno sviluppatore ufficiale Nintendo.

Per prima cosa è del tutto vero che imparare un linguaggio di programmazione non è tutto ma avere delle buone basi ed essere furbi nello sviluppare le routine è fondamentale... Per furbi intendo usare piccoli trucchetti che , nella totalità del gioco, ti fanno guadagnare tempo macchina sufficiente per permetterti di inserire un effetto in più o una cosa in più che casomai non potevi fare...
Una buona analisi del software è fondamentale , se vi vedete le parti extra di molti dvd d/pixar vedrete come tutti cominciano da un'idea di base che si sviluppa nel tempo , con i primi disegni in bianco e nero per poi passare ad una prima stesura, con singoli disegni, della storia intera.
Non è vero che solo la EA lavora in questo modo , ci lavorano tutti anche noi che siamo un tem piccolo...
Abbiamo appena finito un gioco il cui gamedesign non era ns, ci era stato dato quando ci hanno commissionato il lavoro e devo dire che essendo scritto male e con i piedi ci ha creato enormi difficoltà.
Il gamedesgin e l'idea del gioco vanno ovviamente creati prima di mettere mano a qualsiasi pezzo di codice anche se una base di routine, a tipo libreria, sono sempre utili... Pensate solo che Capcom ha sviluppato tutti gli episodi di street fighter sulla base del primo , ovviamente evolvendo le routine ma , di base , erano quelle. La routine di collisione , quella di creazione dinamica degli sprite e tante altre cosette sono state nel tempo affinate e migliorate ma erano di base sempre le stesse.
Per quello che riguarda il pascal non è affatto vecchio ma vi posso garantire che non fa parte del pacchetto in dotazione da nintendo agli sviluppatori, non ne parlano in nessuna pagina del manuale e da quel punto di vista sono anche abbastanza rigidi. Mi dispiace non poter entrare nel merito ma mi è praticamente impossibile parlare del devkit ufficiale, vi posso dire che nelle varie presentazioni ce ne sta una di un famoso membro giapponese di Nintendo che scrive , (non metto il nome) con le ns librerie creerai un gioco in 5 minuti. Posso dire che non ci vogliono proprio 5 minuti ma appena capito il funzionamento delle stesse è stato veramente fantastico.
Il ns team ha 3 programmatori e 4 grafici, il musicista è esterno perchè ,tranne alcune grosse case , molti commissionano musiche da musicisti esterni , costa meno. Non abbiamo ancora un gruppo di modellatori 3D perchè con il DS basta poco , non servono cose molto complesse e se dovessero servire abbiamo chi , esternamente , ce le farebbe.
Per qualsiasi domanda che non sia sul devkit nintendo posso rispondere senza problemi.
Passare da un homebrew ad un prodotto commerciale è molto difficile perchè vi garantisco che c'è una differenza enorme , è anche vero che ci sono degli ottimi prodotti homebrew che a mio avviso potevano essere dei discreti prodotti commerciali.

Edit:
in riferimento a quello che dice Lucatarik su R-Type non ti credere che sia così facile , ci sono tante cose in uno sparattutto di quel tipo che nemmeno immagini... Esempio devi avere una velocissima routine di management dinamica degli sprite in quanto te li deve cancellare e ricreare, devi pensare che in un gioco dove si cambia arma hai bisogno di un buon management interno per non rallentare il tutto , armi complesse devono essere gestite bene altrimenti sono inutili, la routine di collisione di un gioco come Ikaruga fa spavento se pensi che ci sono centinaia di proiettili sullo schermo.
Nessun gioco è facile da fare , credimi.
Per quanto riguarda un platform la gravità la si gestisce in una maniera abbastanza semplice , ci sono molti esempi in giro.. Quello più facile che ho visto è quello che danno insieme alle PAlib... Non è assolutamente la migliore soluzione visiva ma te la descivo..
Premo A e ho 2 soluzioni:
1 faccio saltare l'omino di (esempio) 64 pixels, che ovviamente vanno sottratti/sommati (solitamente sottratti) a poco alla volta altrimenti si vedrebbe uno scatto a video, e poi decremento appena sono arrivato in cima.
2 come in alcuni giochi più premi il tato più salti, decido di avere una quantità da sottrarre , esempio 8 , la routine comincia a sottrarre 8 fino al raggiungimento del limite massimo di salto ma appena lasci si blocca la possibilità di premere nuovamente e un'altra routine inizia a sommare una quantità che è la gravità , nel momento in cui si tocca terra la routine di jump viene riattivata.

Ci sono ovviamente metodi più evoluti per il calcolo della gravità ma quello che ti ho descritto è quello rudimentale per poter iniziare.

In risposta ad Artù ti dico che esistono delle versioni speciali delle routine base come la print che reindirizzano il testo sul video del ds , non si usano molto perchè sono lente ma ci sono.

[siriokds]

Mi inserisco in questa discussione perchè mi interessa molto essedo uno sviluppatore ufficiale Nintendo.

Per prima cosa è del tutto vero che imparare un linguaggio di programmazione non è tutto ma avere delle buone basi ed essere furbi nello sviluppare le routine è fondamentale... Per furbi intendo usare piccoli trucchetti che , nella totalità del gioco, ti fanno guadagnare tempo macchina sufficiente per permetterti di inserire un effetto in più o una cosa in più che casomai non potevi fare...
Una buona analisi del software è fondamentale , se vi vedete le parti extra di molti dvd d/pixar vedrete come tutti cominciano da un'idea di base che si sviluppa nel tempo , con i primi disegni in bianco e nero per poi passare ad una prima stesura, con singoli disegni, della storia intera.
Non è vero che solo la EA lavora in questo modo , ci lavorano tutti anche noi che siamo un tem piccolo...
Abbiamo appena finito un gioco il cui gamedesign non era ns, ci era stato dato quando ci hanno commissionato il lavoro e devo dire che essendo scritto male e con i piedi ci ha creato enormi difficoltà.
Il gamedesgin e l'idea del gioco vanno ovviamente creati prima di mettere mano a qualsiasi pezzo di codice anche se una base di routine, a tipo libreria, sono sempre utili... Pensate solo che Capcom ha sviluppato tutti gli episodi di street fighter sulla base del primo , ovviamente evolvendo le routine ma , di base , erano quelle. La routine di collisione , quella di creazione dinamica degli sprite e tante altre cosette sono state nel tempo affinate e migliorate ma erano di base sempre le stesse.
Per quello che riguarda il pascal non è affatto vecchio ma vi posso garantire che non fa parte del pacchetto in dotazione da nintendo agli sviluppatori, non ne parlano in nessuna pagina del manuale e da quel punto di vista sono anche abbastanza rigidi. Mi dispiace non poter entrare nel merito ma mi è praticamente impossibile parlare del devkit ufficiale, vi posso dire che nelle varie presentazioni ce ne sta una di un famoso membro giapponese di Nintendo che scrive , (non metto il nome) con le ns librerie creerai un gioco in 5 minuti. Posso dire che non ci vogliono proprio 5 minuti ma appena capito il funzionamento delle stesse è stato veramente fantastico.
Il ns team ha 3 programmatori e 4 grafici, il musicista è esterno perchè ,tranne alcune grosse case , molti commissionano musiche da musicisti esterni , costa meno. Non abbiamo ancora un gruppo di modellatori 3D perchè con il DS basta poco , non servono cose molto complesse e se dovessero servire abbiamo chi , esternamente , ce le farebbe.
Per qualsiasi domanda che non sia sul devkit nintendo posso rispondere senza problemi.
Passare da un homebrew ad un prodotto commerciale è molto difficile perchè vi garantisco che c'è una differenza enorme , è anche vero che ci sono degli ottimi prodotti homebrew che a mio avviso potevano essere dei discreti prodotti commerciali.

Edit:
in riferimento a quello che dice Lucatarik su R-Type non ti credere che sia così facile , ci sono tante cose in uno sparattutto di quel tipo che nemmeno immagini... Esempio devi avere una velocissima routine di management dinamica degli sprite in quanto te li deve cancellare e ricreare, devi pensare che in un gioco dove si cambia arma hai bisogno di un buon management interno per non rallentare il tutto , armi complesse devono essere gestite bene altrimenti sono inutili, la routine di collisione di un gioco come Ikaruga fa spavento se pensi che ci sono centinaia di proiettili sullo schermo.
Nessun gioco è facile da fare , credimi.
Per quanto riguarda un platform la gravità la si gestisce in una maniera abbastanza semplice , ci sono molti esempi in giro.. Quello più facile che ho visto è quello che danno insieme alle PAlib... Non è assolutamente la migliore soluzione visiva ma te la descivo..
Premo A e ho 2 soluzioni:
1 faccio saltare l'omino di (esempio) 64 pixels, che ovviamente vanno sottratti/sommati (solitamente sottratti) a poco alla volta altrimenti si vedrebbe uno scatto a video, e poi decremento appena sono arrivato in cima.
2 come in alcuni giochi più premi il tato più salti, decido di avere una quantità da sottrarre , esempio 8 , la routine comincia a sottrarre 8 fino al raggiungimento del limite massimo di salto ma appena lasci si blocca la possibilità di premere nuovamente e un'altra routine inizia a sommare una quantità che è la gravità , nel momento in cui si tocca terra la routine di jump viene riattivata.

Ci sono ovviamente metodi più evoluti per il calcolo della gravità ma quello che ti ho descritto è quello rudimentale per poter iniziare.

In risposta ad Artù ti dico che esistono delle versioni speciali delle routine base come la print che reindirizzano il testo sul video del ds , non si usano molto perchè sono lente ma ci sono.

Ma tu guarda chi c'è... sei proprio tu il BatBlaster che ho incontrato allo SMAU '93 (Amiga)? Quello di NA?

Ah... vecchie glorie...

QUOTO tutto quello che dici.


SiRioKD (Koga Design)