FANDOM


Come sta andando lo sviluppo? Bè come innumerevoli progetti anche questo è svolto nel tempo libero, quindi la parola classica adatta a descrivere la situazione è 'lentamente'.

Per il momento c'è un'interaccia semi-funzionante che permette di fare due o tre cose, ma è abbastanza per cominciare a discuterci.

Le prossime cose da sviluppare (con priorità abbastanza alta) sono: -salvataggio; -caricamento più completo; -salvataggio in un unico file; perché in questo modo è possibile avere una permanenza dei dati. Non solo, ma prevedo di cominciare a caricare gli script ed organizzarli in cartelle (che verranno caricate ricorsivamente). Il salvataggio in un unico file (un archivio zippato) sarà utile per evitare di portarsi dietro decine di cartelle e di file.

Anche di 'features' di interfaccia se ne potrebbero implementare a iosa, però considerando che sono da solo a programmare (almeno per ora) mi vedo costretto ad inserire solo le cose che servono a me -- e qualcos'altro se mi viene facile.

Altre cose da fare:

  • mettere nell'interfaccia delle listbox, ad esempio per l'inventario
  • implementare l'aggiornamento di tutti i dati del personaggio quando vengono modificati i dati
  • abbozzare una parte di rete di prova?
  • implementare TALENTI e TRATTI (razziali, di classe, quello che serve)

Come ho segnato nel sorgente, stavo anche pensando di:

  • concedere all'utenza di progettarsi in qualche modo una grafica personalizzata (tutto sommato potrebbe non essere giusta la grafica generata automaticamente)
  • mettere magari qualche attributo PG() per specificare i font da usare?
  • altro che non ricordo -- aggiungerò poi

Questioni più tecniche (potrebbe meritare una sezione a parte)

Dunque... Per realizzare un 'gioco' al momento viene caricato il file .c#.vrpg: com'è intuibile non è nient'altro che un sorgente c# che viene compilato a runtime.

La classe in esso contenuta viene estesa in jscript, e così poi esportando una funzione eval è possibile avere uno 'storage' dichiarato da usare.

Più in dettaglio: l'assembly generata dal CSharpCodeProvider è una dll managed che risiede nella cartella temporanea. Questa dll viene caricata come referenza di una nuova assembly jscript, la quale estende la classe contenuta nella prima assembly.

COSA SIGNIFICA

Significa che la dll generata viene copiata nel percorso del programma, e poi viene caricata dal clr. Di conseguenza non è più cancellabile (ma dalla cartella temp può essere cancellata, perché quella non è utilizzata).

Perché faccio questo? Sostanzialmente l'assembly jscript viene generata "in memoria" (notare i doppi apici... significa che il file più o meno c'è, ma in realtà l'impostazione GenerateInMemory è true), e quindi poi il clr può gestirsi tutto da sé e ripulire quello che ha creato. MA la dll c# viene generata fisicamente perché non ho trovato altro modo - nonostante possibilmente esista - per includere la referenza nel jscript. So che esiste Load(byte[]) per caricare le dll assembly come COFF in memoria, ma a me richiede comunque che ci sia il file fisico (cosa che credo avvenga per tutti o quasi).

Per quanto riguarda il funzionamento della cosa, POTREI fare a meno dell'assembly c#, il che significa usare solo jscript, MA... JScript non è il mio linguaggio primario (in realtà non lo è neanche c# :P), e in più jscript non ha LINQ :D che trovo abbastanza comodo (tranne quando si ha a che fare con enumerabili di lunghezza 0... che palle :( ). Perciò sostanzialmente uso c# perché così uno può più immediatamente crearsi anche dei form, può usare espressioni lambda (che in jscript io non riesco a fare, ora come ora), usare in generale gli oggetti .net, e in realtà perché le variabili sono strong typed (cast e jscript son due concetti che non vanno molto d'accordo).

IL FILE TEMPORANEO Mettiamola così: rinunciare a jscript, perlomeno secondo quando è il concetto attuale del gioco, è una cosa che non mi va assolutamente di fare, mentre rinunciare a c# sarebbe "solo" una grossa seccatura. In realtà poi jscript sarebbe sostituibile in parte da progetti come ncalc, ma non avrebbe comunque quella potenza (è ammissibile mettere in dubbio la necessità di tale potenza, ma risponderei che stando ad ora è possibile che siano da definire dei meta-template oltre ai template del gioco, e quindi che debbano essere creati degli oggetti e in generale interagire col sistema operativo dal file .c#.vrpg e da .js.vrpg).

Oh ecco altre una o due cose abbastanza importanti:

  • mettere magari un primo form di presentazione (tutto sommato sui computer non recenti potrebbe essere necessario qualche secondo di caricamento), adesso mi sfugge il nome di come si chiamano
  • mettere un file di configurazione, che potrebbe tornare utile
  • stavo riguardando rpgplayer, una cosa del genere sarebbe ovviamente necessaria anche qui, ma ancora non ho pensato a quella parte

Sta venendo scisso il programma e abbozzata la parte di rete.

Problema: dato che il funzionamento prevede che un partecipante alla partita possa inviare dati agli altri partecipanti, è necessario che i giocatori possano ricevere tali dati.

Questo significa che: o viene innestato un meccanismo di polling verso un server centrale, o si realizza una connessione permanente, o si entra con una connessione nel pc/dispositivo del partecipante.

L'ultima opzione è la prima da escludere, in quanto se l'utente è dietro un router o qualsiasi altra cosa o questi vengono configurati col port forwarding o bisogna ricorrere a delle hackerate tipo the core.

Il polling è la soluzione più immediata, ma a mio avviso parecchio brutta.

Rimane la connessione permanente: quali servizi la offrono? Si potrebbe fare anche http, ma poi sarebbe necessario un web server+linguaggio che fornisca la possibilità di usare a volontà le connessioni socket interne al webserver, e non credo che in genere vengano fornite queste risorse/permessi.

Ci sono altre possibilità come l'ftp, flussi audio e video, ma sarebbero tutte di nuovo delle hackerate.

L'unica possibilità che è solo una semi-hackerata sono le chat: si sfruttano i server di chat, diciamo che tutti i giocatori di una partita usano un privato col master (questo fatto internamente, gli utenti non sono al corrente del meccanismo), e questo rappresenterebbe una partita. I messaggi tra i programmi verrebbero mandati assolutamente in chiaro, e sarebbero facili da comprendere.


Altro problema: l'interfaccia.

Per ora son presenti, nel form "interazione" (4° form del programma...), la chat, due 'frame' dei comandi di master e utente, e degli altri comandi per la chat in alto come menustrip.

Potrebbe non essere sufficiente: tutto sommato sarebbe carino se, come in rpgplayer, venisse mostrato un elenco dei giocatori con le loro icone (e magari un popup sulla loro icona mostrerebbe delle azioni).

Il problema è che questo form comincia ad essere sovraffollato, e che bisogna determinare quali comandi sono in quale luogo. Chiaramente non è possibile fare tutto tramite click destro sull'icona dell'utente, sarebbe scomodo.

L'interfaccia di interazione sociale ora ha tutte le parti (chat, comandi, lista utenti) assieme.

Ho cominciato a realizzare la parte di rete via irc. C'è un problema: come comunicare i dati del personaggio e del gioco ai partecipanti? Anche comprimendoli comunque saranno svariati KB (secondo me), e trasmetterli per chat significa o metterci un tot di secondi (non una cosa snervante ma comunque seccante) o rischiare il ban per troppi messaggi.

L'alternativa sarebbe usare il dcc, ma devo ancora capire se sarebbe possibile in ogni situazione.

Tra l'altro, abbozzata parte di salvataggio dei dati del personaggio. È stata più difficile di quello che mi immaginavo. Devo ancora verificare se i dati salvati possono essere caricati... (non avevo tempo di farlo in quel momento)

È stato introdotto il form (non so quanto temporaneo o meno) per caricare/salvare i dati del personaggio riguardo la partita/gioco. PERCHÉ: perché i dati non vengono trasferiti, per ora, attraverso la rete, quindi non è pensabile che il master "tenga tutte le schede".

Verrà effettuato un tentativo di introdurre la comunicazione dei dati attraverso dcc, ma da quanto ne so potrebbe anche non funzionare, e quindi ipotizzo anche una comunicazione via email (sempre automatizzata), ma è proprio in extremis.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.