Re: [Mmospg-devs] Prime fasi di sviluppo

[Massimo C. <cai...@gm...>]

> In realtà qui si deve fare una scelta fondamentale di stile per
> cominciare a scriverle: le classe devono essere orientate al back-end,
> ovvero all'astrazione, al framework di gioco, con molto codice per
> trasformarle nel formato XML (che invece è soltanto front-end) e vari
> strati di magia Python per renderle giocabili intuitivamente, oppure
> devono essere modellate sull'interfaccia e sullo specifico scenario di
> gioco?

Il problema si pone soprattutto per descrivere le azioni compiute da
un'unità. Io direi che queste classi debbano essere orientate allo
script dell'unità più che al server di gioco, dato che lo script non è
a conoscenza degli internals del server. Nello script dell'unità ogni
entità non è altro che un ID (o una posizione sulla mappa dove lo
script suppone che sia questa unità), wrappata da una classe che gli
dà un'interfaccia più intuitiva, con un po' di magia Python.
Comunque ci sono altri dati più semplici per cui non si pone il
problema, per esempio la descrizione del territorio circostante ecc.
Proverò quando ho tempo e voglia a scrivere sulla wiki qualcosa di
dettagliato, così ci discutiamo su direttamente, oppure scrivete
qualcosa voi se vi va.

> All'atto pratico, un'interfaccia modellata sul framework astratto
> prevederebbe soltanto dati chiave-valore, analogamente alla Entity ma
> con la condizione di serializzabilità, poichè in effetti lo script può
> memorizzare qualunque cosa e in qualunque modo all'interno di
> quest'oggetto; verrebbero introdotte funzioni "di convenienza" per la
> gestione di questa zona dati in un formato pseudo-standard e
> dall'altra parte funzioni il cui scopo sia la conversione verso il
> modello a oggetti di livello 1.

Direi che non c'è alcun bisogno di modellare questi dati sul
framework: sono per la seconda opzione. Uno script di un'unità
potrebbe anche derivare una classe da quelle che abbiamo definito noi
(sempre con un po' di magia magari), l'importante è mantenere la
serializzabilità, ovvero la possibilità di convertire tutto in un
formato standard. Poi sicuramente ci sarà anche una classe che
memorizzerà dati nella forma chiave-valore, con un bel po' di codice
condiviso col server che già fa questo nel framework.

Ciao a tutti!
Buon S.Stefano! (quando ho iniziato a scrivere era ancora Natale...)

Il 25 dicembre 2009 22.59, Giovanni Campagna
<sca...@gm...> ha scritto:
> 2009/12/25 Massimo Cairo <cai...@gm...>:
>> Ciao!
>> Forse abbiamo abbastanza elementi per cominciare a fare un design
>> dettagliato, per poi cominciare a scrivere le prime righe di codice.
>> In questi giorni se ho tempo comincio a definire le varie classi, con
>> metodi, attributi ecc., e li metto sulla wiki, così ne discutiamo e se
>> qualcuno vuole contribuire può farlo. Finito ciò, chiunque sappia un
>> po' di python può implementare qualcosa.
>>
>> Le cose da fare sono, più o meno in ordine di importanza:
>>
>> 1) Classi per i dati che le unità ricevono in input e che memorizzano
>> in zona dati, dato che sono quelli che l'interfaccia web deve mostrare
>> all'utente.
>
>
> In realtà qui si deve fare una scelta fondamentale di stile per
> cominciare a scriverle: le classe devono essere orientate al back-end,
> ovvero all'astrazione, al framework di gioco, con molto codice per
> trasformarle nel formato XML (che invece è soltanto front-end) e vari
> strati di magia Python per renderle giocabili intuitivamente, oppure
> devono essere modellate sull'interfaccia e sullo specifico scenario di
> gioco?
>
> All'atto pratico, un'interfaccia modellata sul framework astratto
> prevederebbe soltanto dati chiave-valore, analogamente alla Entity ma
> con la condizione di serializzabilità, poichè in effetti lo script può
> memorizzare qualunque cosa e in qualunque modo all'interno di
> quest'oggetto; verrebbero introdotte funzioni "di convenienza" per la
> gestione di questa zona dati in un formato pseudo-standard e
> dall'altra parte funzioni il cui scopo sia la conversione verso il
> modello a oggetti di livello 1. Il vantaggio evidente è l'enorme
> libertà data allo script, che può memorizzare qualunque cosa e nel
> modo che più gli risulta congeniale; inoltre le funzioni esposte da
> altre Entity e le chiamate "di libreria" smettono di fare assunzioni
> particolari sul formato della zona dati, rendendole più generiche.
> Dall'altra parte, un formato più orientato all'interfaccia e allo
> scenario di gioco prevederebbe specifiche classi Map, Path,
> MessageQueue, ActionQueue, EntityStore, ecc. più eventualmente un
> Object generico il cui contenuto però rimane vuoto a meno che non sia
> usato esplicitamente. Il vantaggio è la maggiore intuitività per il
> giocatore, dato che il formato riflette effettivamente
> l'organizzazione del gioco, e la maggior adattabilità all'interfaccia
> utente, rendendolo formattabile e analizzabile direttamente dal
> browser senza funzioni di conversione; d'altro canto questo formato
> rende molto più difficile sostituire le funzioni previste dalla
> libreria "di convenienza" perchè è necessario mantenere il model di
> quest'ultima. Inoltre la formattazione degli oggetti rimane fissa e di
> conseguenza l'utente ha comunque un punto di vista limitato sulla zona
> dati, quello filtrato dalla conversione standard.
>
>> 2) Un abbozzo di interfaccia web, anche temporanea, per cominciare a
>> vedere i primi risultati del lavoro.
>> 3) Il core del gioco: un framework che gestisce varie "entità", cioè
>> cose a cui sono associati dei dati nella forma chiave-valore e che
>> rispondono a degli eventi con degli script (scritti da noi). Questo
>> framework deve anche eseguire il codice scritto dal giocatore.
>> (All'inizio non farà altro che chiamare la funzione principale dello
>> script del giocatore, ma dopo bisognerà implementare una comunicazione
>> in streaming sicura)
>
> Qualcosa dei punti 2 e 3 è stato fatto ed è presente nel repository,
> se qualcuno vuol commentare ben venga.
>
>> 4) I primi script che controllano scenario e unità. (questi ultimi non
>> dovranno fare altro che mettere in pratica, ove possibile, cioè che
>> ricevono dagli script scritti dal giocatore)
>> 5) Il codice template per le unità, visibile e modificabile dal
>> giocatore, più la libreria che esso usa (anche immutabile dal
>> giocatore, principalmente si occuperà di serializzare i dati e gestire
>> la comunicazione col server di gioco).
>
> In realtà prima di scrivere questi dovremmo avere un GamePlay decente,
> e non mi riferisco solo al concetto generico di unità / strutture /
> punti di raccolta risorse, ma nello specifico nomi, valori, abilità
> speciali, azioni possibili, ecc.
>
>> 6) Tutto il resto :-)
>
> C'è anche un resto?
>
>> Fatemi sapere cosa ne pensate!
>>
>> Ciao!
>> Massimo
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Mmospg-devs mailing list
>> Mmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/mmospg-devs
>>
>
> Giovanni
>
> PS:  buon natale a tutti!
>