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??

Si, ma al novatanove percento ti passerà la voglia dopo la seconda pagine di un qualsiasi manuale del C

Impari un linguaggio tra c, c++ e pascal(*), ti scarichi il devkitPro, ti scarichi un emulatore e hai tutto quello che ti serve
Gli esempi del devkitpro sono la miglior guida in circolazione.

(*)In questo caso ti serve anche il compilatore free pascal per nds e la conversione delle libnds per pascal

ah è così difficile??

No, i giochi li paghiamo 70 euro giusto per farci mangiare tutti i distributori sopra che credi.

bellissima!

si è difficile. e a livello amatoriale non si raggiungono grandi risultati.

inizia a mangiare pane e C, C++ e pascal a colazione pranzo e cena e poi ne riparliamo....

...cmq niente è difficile...basta solo la volontà

oddio il pascal è un tantino antiquato anche per l'hardware cesso del DS XD

Boh ragazzi, io non capisco perché sono tutti convinti che per sviluppare un gioco basta solo imparare a programmare, è come affermare che per scrivere un libro basti soltanto imparare a leggere e scrivere. In realtà non è assolutamente così perché prima di tutto ci vuole l'idea di gioco e non è banale perché è necessario trovare un concept innovativo e che possa destare interesse (si suppone che una volta finito il gioco vogliamo che ci sia qualcuno che abbia voglia di giocarci!) poi è necessario un processo di progettazione di questo software che stiamo per produrre: come vengono gestiti i dati, come vengono definite le classi, gli algoritmi da utilizzare, ecc e questo si fa tutto intorno ad un tavolino con carta e penna, discutendo con tutto il team di sviluppo. Poi si inizia a implementare il codice e si iniziano a fare i primi bozzetti di grafica e musica da inserire nel primo prototipo (e quindi è necessario avere a disposizione anche artisti grafici e musicisti!) poi si fa testing del motore, si ricontrollano tutti i parametri (ad esempio velocità del salto, dello sparo, ecc) e si fa una lista di tutte le cose da modificare. Alla fine deve essere fatto il level design con relativo test e al contrario di quello che si può pensare, è un processo lunghissimo e noiosissimo, soprattutto a causa della difficoltà di utilizzo dei tool appositi!
Infine si raccolgono tutti gli elementi multimediali definitivi e i livelli e si impacchettano insieme al codice, si fa alpha test, si raccolgono i feedback e i difetti e si fanno le dovute modifiche e si procede per la beta test.

Questa è la sintesi estrema della procedura che in genere si segue (ovviamente nel caso è anche necessario ripetere l'una o l'altra fase) Come potete vedere, imparare il linguaggio C è proprio il male minore, ovviamente se volete fare un gioco di qualità che vale la pena di essere giocato!

Parli per sentito dire, suppongo. Non mi riferisco mica al turbo pascal, ma al Free Pascal che è, allo stato attuale, il compilatore che produce il codice ASM maggiormente ottimizzato per i processori ARM, anche rispetto al GCC del devkitpro.

più che antiquato, dubito sia ancora usato da qualcuno in ambito professionale, quindi se è quello il punto a cui si vuole arrivare, conviene partire direttamente col c...

Tutto giusto, se lavori per la Electronic Arts però, il processo di cui parli è quello per le grandi produzioni, per le cose amatoriali o hai il colpo di genio o ti appoggio alla programmazione che è il primo scoglio che incontri.

Ma quello non è uno scoglio, è solo la punta di un iceberg. Io ho partecipato a numerosi progetti amatoriali e non ne ho terminato neppure uno perché mancava appunto un valido game design e valido materiale artistico; andando avanti con il progetto inizi a chiederti se, con la mancanza di questi elementi, riesci a tirare fuori un prodotto valido per quanto non si voglia realizzare qualcosa di commerciale. Se hai l'idea geniale e riesci a concludere il progetto (ad esempio il concept di un puzzle game o un'idea di una semplice utility a cui nessuno ha pensato prima, che è molto semplice da realizzare, ma necessita di idee rivoluzionarie affinché sia interessante) bene, altrimenti escono fuori dei pallidi tentativi di imitazione di giochi esistenti e altri giochi a cui mediamente un utente ci dedica al massimo 10 minuti e poi lo elimina.

Per il resto è sempre e cmq interessante per sé stessi imparare un nuovo linguaggio o ancora di più se si vuole programmare su piattaforme diverse dal PC quali console portatili e non.

già. ho fatto tanti meeting con me stesso per sfornare quei 2-3 giochi per il ds. per non parlare di quanti schizzi ho fatto.

il processo che hai descritto è il processo che usano le software house con un team di persone. non è il caso del singolo utente.

ovviamente ci vuole l'idea, la grafica, la progettazione per fare un gioco. per fare un gioco.

mentre la domanda era diventare "sviluppatore" di applicazioni/giochi per ds.

e fidati, la programmazione è lo scoglio più grande, perchè la fantasia ce l'abbiamo più o meno tutti e uno bravino con la grafica lo si trova sempre. se però non hai le conoscienze, tradurre la fantasia in codice è molto difficile, a volte impossibile.

E' banale dire che se non hai una MINIMA idea è inutile che cominci, ma molte volte amatorialmente parlando anche solo realizzare uno shooter non chiede tanto game design quanto il saper veramente mettere in atto le idee.

E' inutile crearsi una sceneggiatura da gioco da 20000 pagine e non sapere manco come si apre il C++, casomai è un pò piu utile avere una vaga idea di come muovere un astronave ma avere tutti i mezzi per saperla realizzare.

il game desing, i grafici e i musicisti servono solo per le grandi produzioni. alla fine la storia o la prendi "in prestito" da qualche gioco che già esiste o fai una storia di *****; la grafica e la musica quasi sempre si scaricano da internet; la vera difficoltà e la scrittura del codice stesso. alla fine praticamente tutti nella scena sono solo programmatori(e usano solo il c++, che potessi programmare in pascal il ds l'ho scoperto ora), i grafici & co sono in secondo piano. comunque la più grande difficoltà che ho incontrato è la voglia: la prima settimana almeno 2 ore al giorno a programmare, poi incontri le prime difficoltà e cominci a romperti il cavolo, dato che non c'è uno straccio di documentazione, e smetti(questo per ds).

In ambito DS te la appoggio, anche perché il devkit ufficiale è solo c/c++ (contattammo la Nintendo of America per sapere se c'era la possibilità di supportare direttamente l'Object Pascal tramite il Free Pascal, ma ci risposero che al momento non rientrava nei loro piani ).
In ambito professionale "allargato" (applicativi, gestionali, ecc.) ti posso assicurare che l'object pascal è più vivo che mai

si, intendveo in ambito professionale dal punto di vista videogiochi

D'accordo che ho scritto due papiri, ma prima che rispondiate vorrei almeno che leggeste cosa ho scritto...
Prima di tutto lo scopo era di sfatare il mito: so programmare -> sviluppo un videogioco.

Alla domanda: posso sviluppare un gioco in solitario? La risposta è: sì, ma affinché vuoi che gli altri giochino con il tuo lavoro, l'idea deve essere molto interessante, altrimenti esce fuori solo un software mediocre che potrete usare al massimo come esercizio di programmazione o divertimento personale, e anche questo è uno scopo più che valido perché è un'occasione per vedere cosa significa "sviluppare".
Se volete un esempio pratico: Meteos è stato sviluppato da 2 persone, ma c'era una più che valida idea alla base.

non è semplice sviluppare software valido...io ho delle buone basi di c e c++ ma non mi sono mai voluto cimentare nello sviluppo di un gioco per console(neanche con architettura non proprio eccelsa come il ds) perchè so che ci vuole molto temp(che non ho) per avere soddisfazioni...

manca praticamente tutta la punteggiatura nel discorso(lo preciso perchè se non sbaglio c'è un tale in giro cha non fa altro che notare errori nella scrittura)

stavolta non puo dirti nulla, avevi già precisato che non avevi tempo
cmq il problema non è il saper programmare, ma è capire come programmarlo...
ad esempio un gioco in stile rtype te lo programmo in 2 secondi (background scorrevole, collisioni, ecc ecc) ma un platform invece non saprei nemmeno come creare la gravità...

Si può programmare in pascal??? Figo...Ma se dovessi fare un qualsiasi readln come inserisco gli ipotetici dati??

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.

beh per la programmazione o sei particolarmente portato oppure devi stare anni a studiarti i manuali di c/c++ iniziando dai rudimenti. molti di noi hanno iniziato grazie alle scuole che comunque forniscono un lento procedimento di apprendimento che però ti da il tempo di memorizzare le basi e poi magari ampliartele per conto tuo. certo che se pretendi di partire da 0 e diventare sviluppatore in un mese allora o sei un folle o un genio

e questo vale se devi solo programmare, presupponendo che qualcuno ti abbia commissionato il lavoro e che ci siano altri che si occupano delle altri fasi del lavoro, altrimenti amen.
non per niente i team di sviluppo, per quanto grandi e professionali, impiegano anche più di anno per mettere su dei signori giochi.

senti visto che ci sei, anche se è un po' OT rispetto al topic, mi potresti spiegare in poche parole come vi regolate per realizzare le ombre dinamiche. soprattutto per i giochi 3D.

Grazie batblaster per aver apportato la tua esperienza di programmatore professionista a questa discussione Permettimi di farti una domanda, necessaria per alcune mie pubblicazioni e per il fatto che le stesse mi stanno costringendo ad imparare come usarle: le PAlib, nell'ottica dell'apprendimento (cioè per diventare sviluppatori in piena regola), quanto sono utili? Costituiscono valido appoggio o sono conoscenze che vengono scartate in ambito professionale?
Evrain

Secondo me decisamente molto poco, alla fine non vedi nulla di quello che fanno, e di come lavora il ds a basso livello, quindi addio ottimizzazione...
Poi, partendo da zero e iniziando direttamente con le PAlib, salti anche molte di quelle basi del C che servono sempre e comunque, vedi matrici, puntatori, strutture, liste, ecc...
Per me le PAlib sono utili per 2 cose: come trampolino di lancio, si inizia con quelle, ma poi si passa a qualcosa di un po più serio, compreso un bel corso di C
La seconda è come le uso io, debug veloce... Le funzioni che gestiscono il testo nelle PAlib sono ovviamente più facili da usare che le libnds normali, e hanno qualche feature in più, quindi le uso per vedere in fretta cosa sta succedendo nel mio codice (in effetti, fino adesso l'unica funzione delle PAlib che ho usato è PA_OutputText, tutto il resto è codice mio )

Invece secondo me servono.Perchè, essendo i comandi facili, impari facilmente la struttura del C(naturalmente con l'aiuto di qualche buon libro).Invece con le libnds ti complichi la vita

le palib sono delle librerie. sono utili quanto sono utili le altre librerie (wxwidgtes, sdl, etc etc).
e se non sbaglio anche il devkit della nintendo sarà strutturato così (cioè una libreria).

Quanto sono valide a livello professionale le palib? un cavolo. è comunque un esperienza.

cmq sia che tu le usi o no, devi conoscere la macchina e i suoi limiti e questa è una buona cosa.

batblater.. non è che ci puoi dire almeno la tua software house così che possiamo dire: "questo l'ha fatto lui" e leccarti un po' il culo?

Io ti parlo per esperienza, visto che un gioco come R-Type l'ho programmato e non mi è risultato difficile...
Certo non era ai livelli di Ikaruga, pero era venuto carino... era fatto in pixel art visto che altrimenti su ds sarebbero venute astronavi giganti, e non mi sembra difficile gestire una routine di creazione dinamica degli sprites quando tutti i metodi (sparo, collisione avvenuta) restituiscono i parametri appropriati...
L'unica cosa che non ho saputo fare è creare uno script esterno per l'inserimento dei nemici, e ho optato in una soluzione di background ripetuuto/perpetuo dove venivano spawnati massimo 5 tipi di nemici diversi alla volta sullo schermo, scelti in modo casuale, e prima di accedere al boss bisognava sconfiggerne 100. per il livello successivo si moltiplicavano queste variabili per 1,5

faccelo vedè faccelo toccà!

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)

Grande batblaster (7 Raven Studios, per chi l'aveva chiesto)!
Ci siamo sentiti via email/msn qualche tempo fa e devo dire che è una persona competente e estremamente disponibile



Tutte le funzioni di I/O video-tastiera non sono implementate, perché sul DS non avrebbe senso (a meno di non avere un sistema operativo che gestisca una tastiera virtuale sul touch). In compenso è possibile usare le funzioni di output a video di libnds (printf, iprintf, ecc...), che però dovrebbero essere usate soltanto per mettere rapidamente qualcosa a video durante il debug. Se trovo un po' di tempo (e se riesco a far funzionare in maniera decente il nuovo memory manager ) vedrò di attivare write e writeln

Le PAlib servono se si vuole avere subito qualcosa di funzionante, infischiandosene di capire cosa ci sia dietro le quinte. Se invece si vogliono cercare di capire anche il funzionamento e i limiti dell'hardware, forse è preferibile utilizzare libnds

Rispondo un po' a tutti...

Per lo SMAU del '93 saluto chiunque scriva, non ho partecipato a molti eventi ma quelli a cui sono stato li ricordo volentieri.

Allora, per quello che riguarda le PALib non è vero che utilizzando quelle si perda la funzionalità del c e di quello che si deve creare come array , puntatori , matrici e cose del genere. Nel kit ufficiale ci sono una marea di librerie , una libreria non è altro che un'insieme di funzioni scritte mediamente in c/c++ che posso servire a vari scopi.. Esempio srs_ObjSetXY(objno,x,y) non è altro che una delle funzioni ella ns libreria che serve per dare allo sprite specificato le corrdinate da assumere a video..
Pensate che nintendo fornisce il pacchetto base del kit di sviluppo e poi tutta una serie di librerie per fare tutto quello che vedete sul DS. Ovviamente se non le sai usare e non sai a cosa servono non ci cavi un ragno dal buco.Le PAlib per un lavoro amatoriale sono un ottima cosa se però pensiamo poi di utilizzare lo stesso codice sul devkit ufficiale , diventando sviluppatori, bhe allora è inutile.. Dico inutile perchè tutti i setting del video , della VRAM (chi è pratico sa di cosa parlo), del pad e dello stylus non hano nulla a che vedere con la PAlib come non lo hanno con le libnds. C'è da dire che se però mi scrivo un motore 3D anche semplice su base opengl usando le libnds il porting viene facile. Faccio un semplice esempio e spiego i rudimenti su come si posso scrivere un pezzo di codice portabile su tutte le macchine..
Le libreirie sono fondamentali , qualsiasi esse siano e spiego il perchè...

Per evitare problemi di porting parte del ns codice è scritto così.

Se nintendo chiama la sua funziona per il tracciamenteto vertici di un poligono nin_vertex(x,y,z) (NON è assolutamente il nome vero) noi creiamo una ns libreria chiamata srslib che fa questo

srs_vertex(x,y,z)
{
nin_vertex(x,y,z);
}

in questo modo se dovessimo portare il gioco su un'altra macchina a noi basterà cambiare solo le chiamate all'interno della ns libreria con quelle della macchina nuova...

Vi siete mai chiesti come mai tutti i giochi per le nuove macchine come ps3 x360 e pc sono uguali ? per questo motivo , sono scritti una sola volta e compilati su 3 macchine usando librerie di porting, ecco perchè molti giochi non li si vedranno mai su Wii.

Ritornando al discorspo PA , per Evrain , se hai esigenze particolari mandami un pm e poi ci sentiamo in privato.

Per le ombre dinamiche NO COMMENT. Ci sono molte cose che fanno parte di un motore 3D tra cui anche quelle, se hai voglia di capire , se hai un po' di esperienza ed anche una PSP ti consiglio un porting di irrlicht (motore3d) per PSP degli ltestudios (Italiani) completamente gratuito.Se ti interessano dei tutorial sulle opengl ti consiglio questo sito OpenGL Tutorial.

Per quello che riguarda lo shooter in stile r-type non discuto sul fatto che sia facile ma come vedi anche la creazione di script per il management dei nemici è una delle difficoltà. Nulla è semplice a volte è difficile anche scrivere un semplice tool in commandline di conversione di un file da testo a binario... Dipende sempre dal proprio skill e dalla conoscenza del campo.. Esempio io non sono un grafico e non sono un musicista ma su SNES scrissi sia playroutine che converter da mod a SPC700 in assembler perchè non si poteva fare altrimenti. Io non conoscevo e non conosco cosa sia la musica ma sapendo programmare e sapendo cosa dovevo fare lo feci. Non sono un grafico ma il tool di sviluppo grafico che usiamo qui lo ho fatto io, il ns tool permette di creare e gestire tutti i bg del GBA (DS è uguale) di gestire animazioni dei tileset, creare e vedere le preview su come si vedrebbero i BG sul vero GBA , stripping delle tiles duplicate ed inutilizzate. Gestione delle multipalette , gestione degli sprite in tutti i formati del GBA/DS e in modalità custom stripping dei frame uguali negli sprite e creazione delle file table in modo da risparmiare spazio, compressione dei file in uscita e tanto altro ancora. Non sapevo neanche cosa fosse un bitmap o meglio non ne conoscevo il formato ma sapendo programmare mi è stato semplice.

A me purtroppo la scuola non ha insegnato nulla e devo dire che oggi l'insegnamento è molto cresciuto , se guardate indietro vedrete che l'informatica che facciamo e facevamo noi è anni luce arretrata rispetto a quella di altri paesi, in america si danno esami di programmazione anche su videogame. In italia un professore di informatica non ha idea da dove si cominci a scrivere un videogame. Devo dire che conosco tantissimi programmatori ma sono veramente pochi quelli che riuscirebbero a scrivere codice veloce su una macchina piccola come il GBA o il DS.Ci sono una marea di trucchetti che impari con il tempo e guardando cose di altri. Io ho cominciato con il vic20 e devo dire che adoro ancora oggi programmare in assembler qualcosa quando si può... Alcune cose su GBA le ho anche scritte in asm giusto per avere un po' di velocità e devo ringraziare tanti amici che mi hanno aiutato anche per questo quando posso aiuto. Come vi può confermare chi mi ha precedentemente ringraziato.

Spero di aver risposto a qualcuna delle vs domande e resto a disposizione per qualsiasi ulteriore informazione servisse.

Ciao...

allora il mio fresco fresco 29 in architettura dei calcolatori (in cui c'è anche assembly) non è proprio da buttare

Che bestia cattiva e' l' assembler, eppure e' cosi' facile: una manciata di istruzioni e lo hai gia' appreso tutto

Scusa la domanda stupida ma facendo cosi' non hai un doppio salto e un doppio accesso allo stack?
non e' meglio usare #define?
#define srs_vertex(x,y,z) nin_vertex(x,y,z)
oppure un bel search e replace all, whole word, case sensitive?
ciao
brets

io ho scritto l'esempio senza mettere quello che ci potrebbe essere all'interno di quella funzione... Esempio... Su DS non hai la FPU (FloatingPointUnit) mentre sulla psp ci sta quindi le tue routine si dovrebbero cambiare del tutto , invece no , richiamando librerie di porting tu fai solo dei piccoli cambiamenti. A dirlo poi è facile a farlo non del tutto ma si fa. Nell'esempio io ho scritto e basta ma per driti se stai su PSP i valori saranno float mentre su DS meglio non usarli perchè rallentano quindi prima di
nin_vertex ci potrebbe essere un qualcosa che ci dice

#ifdef DS_BUILD
converti in fixedpoint
chiama la funzione nin_vertex
#endif
#ifdef PSP_BUILD
chiama la funzione sony_vertex
#endif

la conversione su PSP non serve perchè ha la FPU...

In questo modo il tuo sorgente chiamerà sempre la srs_vertex e poi la libreria vedrà cosa fare.

Il mio è solo un esempio non sto cercando di insegnare nulla a nessuno ho troppo da imparare io da permettermi di insegnare... L'esempio del post precedente era poco dettagliato cercavo solo di rendere l'idea di come un gioco possa uscire su PC PS3 XB360 perfettamente identico e nello stesso giorno... Perchè internamente sono praticamente uguali.

ok, anzi adesso penso che potevo arrivarci anche da solo
per il discorso che c'e' sempre da imparare sono pienamente daccordo, io sono 17 anni che programmo quasi esclusivamente a basso livello e in ogni nuovo progetto trovo sempre qualche sfida(ga) in piu'
E' proprio per questo che chiedevo, micca per fare il saputello

EDIT: Io sono abituato a lavorare anche su macchine molto piccole, dove lavoravo prima alcune montavano un motorola 6809 a 4MHz, quindi per me certi problemi di porting non si pongono, routines dedicate per ciascuna macchina e via... (al massimo uso lo stesso nome per la stessa funzione)

Che fantastica discussione. Io sono programmatore presso una società di Napoli e mi interesserebbe davvero tanto, divertirmi per conto mio sul DS.

Una for, lol.

beh come la capcom penso anke la namco con i tekken abbia fatto così...
i movimenti dei personaggi onnipresenti non mi sembra si discostino tanto dai primi episodi(se non per fluidità,ma questo dipende da tutt'altro)
penso che il problema sia proprio quello di sviluppare un motore grafico e uno fisico la prima volta, e se è valido continuare a usarlo nel tempo apportando solo delle migliorie...

Il beneamato PES che la Konami ci presenta ogni anno con piccole migliorie è un esempio lampante di come si fanno soldi x 6 volte con 1 solo gioco... PES usa un motore 3D commerciale non fatto da Konami , sono centinaia le aziende che compano motori 3D e non li sviluppano costa meno, e con piccole migliorie al codice per farlo girare più veloce e con upgrade del motore stesso riescono ad inserire ogni volta qualcosa in più e fanno soldi... Come vorrei farlo anche io hehehe