Impostare un editor di mappe visuale

[Lenora]

Mi scuso intanto per la confusione fatta nel post di presentazione, ma in questi tempi mi sto affacciando a un mondo del tutto nuovo a cui, francamente, non avrei mai pensato di dover avere a che fare. Ora mi spiego in dettaglio, e vi prego di perdonare la lunghezza del post.

E' partito tutto da un'idea che ha proposto un collega poco tempo fa, quasi per ridere: "dato che tu sai programmare, e noi disegnare, perché non facciamo uno di quei giochini per iphone che vanno tanto in questi tempi?".
Ovviamente dall'uso che faccio io del Java al "saper programmare" c'è un abisso, ma ciononostante abbiamo deciso ugualmente di fare un tentativo. Scartato subito l'iphone, che richiede un Macintosh per lo sviluppo (troppi eurini per le mie povere tasche) abbiamo acquistato un piccolo telefonino con Android.
Appena visto l'SDK, già non lo potevo soffrire: emulatore a lumaca, classi incomprensibili e scombinate, documentazione pietosa. Dopo qualche settimana, inizio a capirci qualcosa, e mi scontro con un problema più grande. La tipologia di gioco convenuta è il cosiddetto "scroller", ovvero quel genere di giochino alla Super Mario che permette di muoversi solo in avanti.
Non ho mai fatto giochi in vita mia, e così affronto poco per volta le difficoltà che mi si presentano. Essendo assolutamente da delirio anche solo l'idea di programmare ogni singola composizione (per esempio gli alberelli, le collinette, le piattaforme eccetera) direttamente in java, ho pensato di fare un semplice programmino con interfaccia grafica che permettesse di comporre le suddette "mappe" dando al contempo la possibilità di impostare direttamente le coordinate per le collisioni.
Secondo la mia idea iniziale, questo piccolo editor dovrebbe generare un semplice file di testo contenente ciascun elemento statico presente nello schermo (che per comodità ho diviso a quadrettini identificati da due coordinate, che variano di dimensione a seconda dei valori di risoluzione schermo dell'hardware), caratterizzato a sua volta da una serie di attributi, come ad es. X, Y, il nome della bitmap, il livello (z) in cui posizionarlo, e ovviamente il riquadro della collisione (se la collisione è presente e non si tratta, per esempio, di un disegnino posto nel paesaggio).

All'atto del caricamento del "livello", il programma java dovrebbe leggere il file corrispondente e creare gli oggetti grafici a partire dal contenuto preimpostato, in maniera del tutto dinamica senza ricorrere ad enormi paesaggi bitmap interi, ma componendoli un pezzetto alla volta. Il punto dolente è che non sono io a dover disegnare i livelli, ma i due disegnatori (molto meno digiuni di me sull'argomento "videogames"): da qui, l'idea di creare un piccolo programmino per windows che svolgesse questo sporco lavoro in maniera chiara, possibilmente semplificata e soprattutto visuale.

Non ho intenzione di crearlo in java, perché trovo che per questi compiti (interfaccia grafica) sia enormemente scomodo e macchinoso, per non dire lentissimo (verificato personalmente) in fase di esecuzione, grazie alle inutilmente complicate e pesanti librerie integrate awt e swing (nonché all'imbarazzante gestione dei listeners degli eventi). Ciò che voglio dire è che preferirei concentrarmi sulle prove del giochino in sé e per sé, piuttosto che sulla stesura di un editor che alla fine sarebbe a momenti più complesso del gioco stesso (che già di suo mi sta facendo impazzire).

Passiamo quindi alle mie domande, da conoscitori dell'ambiente Delphi/Lazarus, credete che la mia scelta di utilizzare questo strumento per risolvere il problema possa essere efficace? Se sì, dove potrei documentarmi per poter utilizzare al meglio l'object pascal e le librerie integrate?

P.s.
Immagino che alcuni miei ragionamenti sullo sviluppo dello "scroller" possano apparire un po' ingenui, ma come comprenderete siamo dei completi principianti nello sviluppo di giochi per computer e cerco solo di fare del mio meglio! 

[xinyiman]

Allora per quanto rigurda la conoscenza del object pascal ho scritto le guide che ti dicevo nell'altro post.

Per quanto riguarda l'editor direi che è fattibile ma dovresti darci qualche informazione in più...

[Stilgar]

 Allora.
Il post è strutturato in vari punti.
Vediamo di dare una risposta omnicomprensiva.
Allora lo scoller che volete fare, vuoi usare le tecnica delle tiles. Nulla di nuovo sotto il sole, si usava già nel caro e vecchio DOS.
Per la tecnica in questione ti posso dire che la "mappa" sottostante non è impossibile da realizzare con un semplice file di testo, ma binario rende più veloce la lettura (OP permette di leggere blocchi in memoria, utilizzando i puntatori. Java rompe alquanto con i suoi stream, ma anche qui è fattbile). In più potresti avere anche la stessa tile ruotata o con altri attributi. Nel file di testo, la vedo duretta mettere troppe info.
Se vuoi passare l'object pascal, mi sembra compili direttamente codice per la JVM e Android, quindi potresti avere un unico ambiente di sviluppo per tutto. Game e Tool associati. (Per la configurazione per Android, passo la palla a quelli che ci stanno sbattendo la testa). Alla fine Lazarus e FreePascal si mettono come primo anello del tool chain del gcc.
Per la gestione delle collisioni, mi sembra tu non abbia le idee chiare.
Piccolo suggerimento. Lavora a layer.
In alcune prove fatte qui con il forum, abbiamo introdotto la quesione degli sfondi per il parallasse. Ne usavamo 2 o 3 ... non ricordo.
Poi c'era il piano di gioco vero e proprio.
E' con gli elementi di quest'ultimo che te la devi vedere nel controllo delle collisioni. Non con tutti gli elmenti dello schermo.
Nella nostra prova, le tile delle stelle potevanoessere ruotate e sfavillare con agolazioni e temporizzazioni diverse

Per arrivare alla tua domanda finale.
Sì e No.
Sì, è un compilatore general porpose, quindi ci compilano anche pezzi si sistemi operativi. Esiste il porting per Nintendo DS (grande Legolas ), quindi solo consolle per giochi.
No, non esiste una libreria standard per scrivere giochi sotto Android.

Per ovviare al "No" suggerirei di guardare ZenGL ... è un front end alle open gl.  Spulciando i sorgenti mi sembrava stesse passando alla compatibilità con Android, ma non so a che punto sia.
Di per sè non è una brutta libreria... solo che il codice è scritto mezzo con i piedi

Per le guide, ci sono quelle in questo forum, delle nel wiki di Lazarus, da dove cominciare è solo una questione di gusti.
Per Zen devi far riferimento al sito ...(ZenGL.org).

Per il resto c'è master card .... ops ... il forum
Stilgar

[Stilgar]

PS:
http://sourceforge.net/projects/lazarusiug/
Questo è il progetto su source forge

[Lenora]

Grazie mille per i chiarimenti.
Sulla questione delle collisioni, che a tutt'oggi trovo un po' difficile, sei stato chiarissimo. Infatti, piuttosto che a singoli livelli, avevo pensato a un indice numerico, che partendo da zero indicava gli elementi di liv. più basso, a salire, fino addirittura a quelli (che so, magari il tronco di un albero) che dovessero sovrapporsi alla figura dell'omino protagonista, omino che poi sarebbe una donnina (scelte di mercato, mi dicono). 
Quando chiedevo se la scelta del Lazarus per lo sviluppo potesse essere una soluzione vincente, in realtà mi riferivo solo all'editor, anche se apprendo con piacere che esistono delle librerie native in sviluppo, cosa che ignoravo. Tuttavia immagino, se ho capito bene, che il codice in questione non sarebbe poi portabile su sistemi dalle diverse architetture, in quanto per l'appunto nativo e compilato per uno specifico hardware (vabbé poi che il 99% dei telefonini sono arm...), correggimi se sbaglio.

L'obiettivo, infatti, è proprio quello di sviluppare un editor "a tutto tondo", di modo che i grafici possano disegnare i livelli (approvo in pieno la mozione sui files binari, anche se lo ammetto, preferirei sempre usare la praticità del C per quel tipo di cose, come per esempio i comodissimi fread e fwrite, ma senza java e la dalvik il tutto andrebbe compilato, temo) e io pensare semplicemente all'implementazione del programma che andrà effettivamente a creare la schermata di gioco.

Per intenderci, una vaga ispirazione mi venne da uno strumento su cui ho avuto il piacere di arrabattarmi per molto tempo, un vecchio programma di editing visuale che si chiamava rpg maker 2000 (se non erro, scritto con lo stesso delphi). Ovviamente la mia idea è assai meno complicata, ma il principio di base di funzionamento (scacchiera delle tiles, impostazione dei livelli di sovrapposizione, collisioni) mi sembrava molto pratico e interessante.

Ad ogni modo non volevo stressarvi col java, che di certo non è l'argomento di questo forum (e per fortuna, delle volte mi fa disperare). Da quel che ho visto seguendo le brevi guide di Xinyiman, object pascal sembra piuttosto semplice, di certo più schematico di java, ma mi richiederà comunque qualche giorno per uscirne fuori indenne! Nel frattempo, ancora ringraziamenti ad entrambi per le vostre gentilissime risposte. 

[Stilgar]

Di nulla.
A proposito. Java è tutto fuorchè portabile. Fuori dalla JVM i sistemi operativi non sanno che farsene Gira solo dentro la macchina virtuale.
Il codice "nativo" potabile si intende alla c++. Scrivi 1 volta e compili per 1000 piattaforme diverse. Dove piattaforma intendo combinazione processore+sistema operativo. La Sun mi ha sempre fatto incazzare con la storia della potrabilità. E sapessi le litigate con i commerciali su sta cosa (Ci bestemmio dalla versione 1.1.8 ... e ora è SPRING con la injection che mi fa diventare matto).
La portabilità  in questo caso è limitata da alcuni aspetti:
1) Ambiente di sviluppo e suo supporto per la piattaforma target (non intendo lazarus, bensì fpc)
2) Supporto nativo delle tue librerie su quella piattaforma.

Tieni conto che ZenGL ha 2 licenze, uno open source e l'altra commerciale.
Stilgar

[Lenora]

Beh, certamente java richiede la VM per funzionare, e infatti è uno dei motivi per cui lo vorrei escludere dalla scelta per l'editor (metti che poi i ragazzi ci vogliano lavorare dal portatile che hanno a casa, java non sanno nemmeno cosa sia, mentre un eseguibile compilato, clicchi e sei a posto!), e possibilmente pure dallo sviluppo del prodotto Android.
In confidenza, ho sempre usato java per brevissimi listati, e ancora mi chiedo come ha fatto un linguaggio dal garbage collector automatico (e tanto imprevedibile) a divenire de facto lo standard di sviluppo su mobile, prima con il CLDC (orrore inumano, provato e cancellato) e poi ora con la mostruosità di Google.
Per i test abbiamo comprato un LG Optimus hub. Il SO è alla versione 2.3.4, kernel linux alla 2.6.35, eppure a vuoto, senza applicazioni in esecuzione se non il sistema stesso, occupa trecento mb di ram! Non per dire, ma già non è che quel computerino sia un fulmine, con la dalvik l'uso diventa davvero poco confortevole.
Gradirei molto la possibilità di ottenere un software nativo, certamente supportato dal fatto che tutti gli android pari versione, parlando di alto livello, sono uguali, tuttavia il discorso del Native development kit mi sembra un po' deludente. Forse la mia è un'opinione condizionata dalla mia scarsa conoscenza dell'ambiente, ma mi pare davvero una complicazione inutile rispetto al semplice eseguibile "classico". Sinceramente, qualunque cosa andrebbe benone, purché avesse la possibilità di essere caricata sul marketplace senza richiedere accesso di root (parola che il cliente medio scambia regolarmente per una specie di insulto... gastrico).

Ah... Spring non lo conoscevo (come ti ho detto so programmare per modo di dire) e ho cercato un attimo in rete, tanto per capire di cosa stessi parlando... Mi gira la testa solo a pensarci!