Suggerimenti sulla struttura di un bs laterale

[Fire-Dragon-DoL]

Allora...la prima volta che ho fatto un battle system laterale ero su rpgmaker 4.0 (il 2k insomma)....è stata follia pura ma ci sono riuscito (il lavoro è circa 10 volte di quello che potrei fare scriptando, visto che non c'è praticamente nulla di parametrizzabile)...comunque, avendo visto le possibilità di rpg xp lo voglio fare scriptandolo da 0 (quindi mi creo la mia apposita mappetta e faccio tutto li)... durante l'organizzazione della struttura però (si, su carta e penna per organizzare classi,metodi,proprietà...) stavo stilando la classe "combattente" (che verrà ereditata da MOSTRI e PG) e volendo tenere separata la parte che gestisce la grafica da quella tecnica (ciò che gestisce gli attacchi, i turni etc) mi è sorto un dubbio su quale approccio fosse il piu interessante ai fini della separazione di queste due parti, vi illustro qui sotto le mie idee:

 

A) La classe Combattente conterrà tutte le informazioni tecniche (stats etc) in un file, in un altro invece tutte quelle grafiche, di conseguenza a livello teorico non sono separate ma a livello pratico si

qualcosa di questo tipo

#file 1class Combattente  attr_accessor :str  attr_accessor :dex  attr_accessor :atb  #e cosi viaend #file 2class Combattente  attr_accessor :grafica_eroe  attr_accessor :pos_pixelX  #e cosi viaend

 

B) Ereditare una classe "Combattente_Grafica" da "Combattente" ottenendo un risultato pressochè identico al precedente (al limite risulterà un pò scomodo usare il costruttore)

 

C) Mettere un parametro "graphic" dentro a "Combattente" che sarà un oggetto atto a contenere tutte le informazioni grafiche e relativi metodi

class Combattente  attr_reader :graphic  def initialize	@graphic=GraphicInfos.new  end  #solite coseend

 

di conseguenza potrei accedere alle informazioni grafiche scrivendo:

 

lol=Combattente.newlol.graphic.muovifigura #per esempio

 

E attualmente è quella a cui sono piu propenso (e forse dovrei "richiudere" le stats in un unica classe perchè sta diventando immensa sta class combattente)

 

Detto questo, lascio qui delle domande tecniche di cui mi sono sorti dubbi durante la progettazione:

1) Quante immagini posso mostrare, non usando picture (quindi memorizzando tutto $qui o @qui o dovemipare) in contemporanea?Un centinaio o "illimitate" (fino a che non va in crash il game.exe perchè in sovraccarico, in caso a quanto ammonta circa questo valore?) (in poche parole, quanti sprites posso mostrare contemporaneamente?)

2) (questa immagino di si)Posso generare un immagine dinamicamente mettendone piu di una insieme (se per esempio devo scrivere un messaggio su uno sfondo e metterci un icona, posso "fonderli" in un unica bitmap in modo da risparmiare spazio per altre sprites (quindi invece di 3 sprite è solo 1))=

3) Il wait è in frame, ora i frame in teoria variano in base a come si sta eseguendo il gioco (se ti scatta cambiano gli fps), questo valore è legato in qualche modo a ciò oppure 20 frame sono sempre "1 secondo" all'interno del gioco?(se poi ti sta esplodendo il pc ovviamente no ma è un'altra storia XD) il wait() del ruby equivale al wait degli eventi a livello di funzionalità?

4) Ho provato a memorizzare una classe in una variabile globale (intendo $global_variables) affinchè venisse salvata (esiste un altro modo per salvare una variabile oltre questo?) e ho notato che con F9, sembrerebbe proprio che la classe venga serializzata. Se trascrivo quel valore paro paro come stringa in un file, poi lo leggo e lo riscrivo nella variabile (anche dopo aver chiuso e riaperto il gioco), è come se rendessi quella variabile quell'istanza di oggetto (pari pari, quindi posso riutilizzarla?))

 

Grazie mille e perdonate il tema :P

Edited April 6, 2009 by Fire-Dragon-DoL

[Sleeping Leonhart]

Sei fortunato in quanto ho appena finito un bs laterale e quindi ti posso dare qualche suggerimento, ti anticipo però che l'ho fatto modificando il bs standard e non ricreando le classi da 0 così da mantenere una buona compatibilità con gli script standard e con quelli creati da terzi.

Allora io ho fatto così:

In Game_Battler ho messo la gestione dei parametri quali coordinate del battler, calcolo del frame da mostrare, nome della grafica e altro, in Sprite_Battler invece ho messo la gestione del movimento del battler, la visualizzazione del frame, il movimento del battler verso il nemico e altra robaccia.

Il Game_Battler viene passato allo Sprite_Battler come parametro @battler (in poche parole come fa rpg maker) e dal battler si prende tutte le informazioni che gli servono.

Per quanto riguarda le domande ti rispondo in ordine:

1) Puoi mostrare quante immagini vuoi, almeno finchè Rpg Maker riesce a tenerle, poi dipende anche dal PC su cui gire Rpg Maker credo.

2) Si, puoi usare la funzione blt e stretch_blt della classe bitmap, ti consiglio di guardartele sulla guida di Rpg Maker perchè io spiego da cane.

3) Io non conosco la funzione wait, conosco la funzione sleep che ti stoppa l'esecuzione per n secondi, il wait degli eventi invece è un aggiornamento "a vuoto" dell'evento, nel senso che aggiorna l'evento senza fargli eseguire le operazioni listate al suo interno.

4) Cosa intendi per salvare la variabile? Cioè se vuoi salvare un oggetto su file usa il metodo

Marhsal.dump(oggetto, file)

e poi per caricarlo usa il metodo

ogetto = Marshal.load(file)

La pressione di F9 mostra semplicemente i valori delle switch e delle variabili facendo riferimento a

$game_switches e $game_variables, non serializza nulla.

[Fire-Dragon-DoL]

Eccomi, purtroppo io non so nulla di come sono strutturati gli script di rpg maker (e tanto ricreandolo da 0 non mi serve a niente xD giusto 2 funzioni per mostrare testo, figure e per mostrare animazioni...il resto è tutto custom visto che script da terzi non ne vorrei :P) comunque grazie da quel che hai detto ho capito che l'idea era la C (graphic è un oggetto..insomma quella che preferivo)

 

1) Ok come supponevo

2) Grazie guarderò nella documentazione (i nomi funzioni mi servono da morire cosi nn cerco a vuoto per intuizione per un paio d'anni)

3) ah non sapevo ci fosse la funzione sleep, ok userò quella...il wait a vuoto potrebbe servirmi però...ma ci darò un'occhiata successivamente

4) No intendevo una variabile salvata quando creo un file di salvataggio (nel senso che salvo proprio dal menu "salva" del gioco) chiedevo come fare a salvare una variabile insieme ai file di salvataggio in modo che non andasse persa... ma per l'appunto trovo che memorizzarla in $game_variables va piu che bene

5) Fai cosi:

class Prova  attr_accessor :forza  attr_accessor :destrezza  attr_accessor :nome  def initialize	@forza=45	@destrezza=12	@nome="boh"  endend....poi da qualche parte....lolprova=Prova.new$global_variables[1]=lolprova

 

A questo punto in gioco, premi F9 e guarda la variabile 1 nella lista: ti accorgerai che ha un valore molto strano (tipo una serie di lettere e numeri senza senso) questo sembra un hash, tipico di una classe serializzata...

 

se trascrivo questo valore in un file come stringa e poi lo rileggo e lo metto nella stringa, torna come prima?

(comunque marshal.dump va bene lo stesso per l'idea...a sto punto la domanda è piu per curiosità)

 

grazie di tutto :O

[Sleeping Leonhart]

Ah ok ho capito, ti esce un inseime di lettere e numeri poichè un ogetto è sostanzialmente una struct in C, se la assegni a una variabile e poi la rileggi dovrebbe ridarti l'ogetto come lo hai trascritto.

[Fire-Dragon-DoL]

Ah ok ho capito, ti esce un inseime di lettere e numeri poichè un ogetto è sostanzialmente una struct in C, se la assegni a una variabile e poi la rileggi dovrebbe ridarti l'ogetto come lo hai trascritto.

Ah è una struct in C! allora è chiarissimo! grazie mille