Diamond Crush sul Cellulare

[Rubberick]

Che ne pensate? e' un'idea fattibile o una cavolata assurda? ovviamente sarebbe un qualcosa tipo single player a punti... ne girano di cosi' schifosi di giochi sui cell sarebbe la volta buona che passa qualcosa di figo ^^

[cionci]

Fek aveva già fatto una prova... Comunque credo che siano necessarie molte modifiche... Il numero di classi, interfacce e packages di Diamonds sarebbe troppo elevato...

[fek]

Originariamente inviato da cionci

Fek aveva già fatto una prova... Comunque credo che siano necessarie molte modifiche... Il numero di classi, interfacce e packages di Diamonds sarebbe troppo elevato...

Dipende dal modello di cellulare che vogliamo supportare. MIDP2 non grandi limitazioni rispetto a Diamonds, ci girerebbe quasi nella sua interezza (ovviamente un solo schermo). Avevo inizato il porting, ho una gemma di Diamonds sul mio cellulare

Mi sono bloccato perche':

- Mi e' piombato addosso il GDC 2006
- Non avevo un'idea chiara su come condividere codice fra due progetti diversi in Eclipse
- Non riuscivo a far funzionare Antenna, l'Ant task per fare il build di MIDP
- Java mobile supporta solo 1.4

Il primo problema e' risolto
Se qualcuno puo' aiutarmi sul secondo problema ne sarei grato. Il terzo problema richiede solo un po' di sbattimento. Il quarto problema richiede la riscrittura di un po' di codice ma nenmmeno troppo.

Non escludo che alla fine del progetto si possa fare un porting per cellulari, non dovremmo impiegare troppo, uno o due mesi secondo me.

[thebol]

Originariamente inviato da fek

Dipende dal modello di cellulare che vogliamo supportare. MIDP2 non grandi limitazioni rispetto a Diamonds, ci girerebbe quasi nella sua interezza (ovviamente un solo schermo). Avevo inizato il porting, ho una gemma di Diamonds sul mio cellulare

Mi sono bloccato perche':

- Mi e' piombato addosso il GDC 2006
- Non avevo un'idea chiara su come condividere codice fra due progetti diversi in Eclipse
- Non riuscivo a far funzionare Antenna, l'Ant task per fare il build di MIDP
- Java mobile supporta solo 1.4

Il primo problema e' risolto
Se qualcuno puo' aiutarmi sul secondo problema ne sarei grato. Il terzo problema richiede solo un po' di sbattimento. Il quarto problema richiede la riscrittura di un po' di codice ma nenmmeno troppo.

Non escludo che alla fine del progetto si possa fare un porting per cellulari, non dovremmo impiegare troppo, uno o due mesi secondo me.

quale parte di codice vorresti dividere?

potrei pensarci io.

[fek]

Originariamente inviato da thebol

quale parte di codice vorresti dividere?

potrei pensarci io.

Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.

[thebol]

Originariamente inviato da fek

Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.

basta creare 2 progetti(game e engine).

Poi game si linkera a engine(o al futuro engine_cell). I riferimenti non possono essere incrociati(il progetto game puo usare il progetto engine, ma non viceversa).

Stasera provo a individuare la parte di engine, ne discutiamo e poi provo a dividerle.

Risultato ci troveremo 2 progetti da dover sincronizzare(che può portare parecchi vantaggi)

[Rubberick]

a questo punto dopo aver fatto tutte le revisioni del caso per la prox release di diamonds vi converrebbe riordinare la struttura delle directory nell'svn

appro fek ti ricordo che i backup sono ancora li e hanno raggiunto la bella cifra di 900mb :P quando ti logghi e fai un po' di pulizia?

[fek]

Originariamente inviato da thebol

basta creare 2 progetti(game e engine).

Poi game si linkera a engine(o al futuro engine_cell). I riferimenti non possono essere incrociati(il progetto game puo usare il progetto engine, ma non viceversa).

Stasera provo a individuare la parte di engine, ne discutiamo e poi provo a dividerle.

Risultato ci troveremo 2 progetti da dover sincronizzare(che può portare parecchi vantaggi)

thebol, ne parliamo un po' piu' in la'? Ora il refactoring che stai facendo e' molto piu' importante.

Rubbe, lo so, sono colpevole, lo devo fare

[^TiGeRShArK^]

immagno che potrei dare una mano qui..
diciamo che una certa esperienza in questo campo ce l'ho
..anke se ho sempre usato ant anzikè antenna
devo imparare ad usare quello perkè immagino ke sia molto + facile

[cdimauro]

Col refactoring di Engine, Audio, Keyboard, ecc. a cui sto lavorando dovrebbe essere molto più semplice effettuare il porting per qualunque piattaforma.

[jappilas]

un mio amico mi ha messo la pulce nell' orecchio ieri sull' utilizzo di cellulari Bluetooth...

perchè non usarli non come piattaforma di gioco ma come dispositivo di input (a mo' di gamepad wireless ) per il multiplayer?

utilità e fattibilità di una cosa simile secondo voi, ?

[71104]

hum, come cavolo facciamo a stabilire la connessione via Blue Tooth... io non so niente di Blue Tooth, comunque l'idea del tuo amico è carina; però la lascerei come opzione, nel senso che la possibilità di giocare solo sul cellulare secondo me deve esserci

[cdimauro]

Quando sarà terminata l'ultima grande rifattorizzazione, che riguarda Keyboard & Event, sarà molto semplice realizzare quanto chiesto.

[fek]

Originariamente inviato da cdimauro

Quando sarà terminata l'ultima grande rifattorizzazione, che riguarda Keyboard & Event, sarà molto semplice realizzare quanto chiesto.

E sara' anche molto YAGNI

[cdimauro]

La rifattorizzazione o il porting per i cellulari?

[jappilas]

Originariamente inviato da cdimauro

La rifattorizzazione o il porting per i cellulari?

credo il fatto di usare i cell come gamepad

[thebol]

Originariamente inviato da fek

Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.

Ho fatto l'esperimento di togliere dal progetto le librerie ogl e audio, e le classi che danno errore(cioè che si potrebbero spostare) sono 6(quelle che incominciano con OpenAl e LWJGL, ottima nomenclatura =D ).

Poi falliscono anche game e gameLoop perche utilizzano l'oggetto Sys di lwjgl per scrivere il msg box di errore e di info in caso di no audio, e per ottenere le info dell adapter e la versione del display.

Incorporando queste 2 funzioni in displayInterface, penso si possa dividere il gioco dall'implementazione che ci gira sotto =D

[cionci]

Però non hai considerato che per J2ME sei obbligato a compilare per Java 1.4...

[thebol]

Originariamente inviato da cionci

Però non hai considerato che per J2ME sei obbligato a compilare per Java 1.4...

pensavo piu al fatto di dividere il gioco dal motore video e audio.

Il fatto della 1.4, sarà il problema piu grosso...
Si potrebbe fare del refactoring(in eclipse cè un framework per realizzare funzioni di refactoring), oppure fare un parser, che trasformi i template e i for each in costrutti java 1.4 compatibili(non è banale, ma neanche impossibile).

[thebol]

Compatibility compilation (Use Java 1.5 language features with Java 1.4 VMs)

Depending on the VM compatibility setting in the Build | Internal build section of the Project Settings dialog CodeGuide can generate .class files compatible with a specific VM version. With this feature applications using Java 1.5 language features can be run on Java 1.4 VMs. In contrast to Sun's protoype modification of the bootclasspath or including any custom JAR files is not necessary.

appena scoperto =D

ora mi informo meglio