Menu
▾
▴
mmospg-devs — Developers' mailing list
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(14) |
|---|
|
From: Giovanni C. <sca...@gm...> - 2009-12-30 21:33:26
|
Uno dei requisiti di sicurezza fondamentali del gioco è che gli script inseriti dagli utenti non possano prendersi vari livelli di libertà. Essenzialmente ci sono tre attacchi che uno script può fare: 1) attacchi al gioco: manipolare azioni e dati di altre entità (o del core stesso) senza passare attraverso il codice scritto da noi 2) attacchi al sistema: sfruttare le system call (open, fork, execve le più pericolose) per interagire con file, processi, reti o altro in modi comunque non prevedibili 3) attacchi alle risorse: un semplice loop infinito e il programma si blocca, oppure l'allocazione di una quantità atroce di memoria allo scopo di laggare il server Un modo per aggirare questi tre attacchi è l'esecuzione in una sandbox, ovvero in un piccolo processo separato che riceve tramite IPC i dati di cui ha bisogno e restituisce i risultati allo stesso modo. Questa è la soluzione più efficace al tipo di attacco 1: ogni informazione fornita allo script è accuratamente filtrata per verificare che sia autorizzato a conoscerla, e dall'altra parte ogni risposta dello script è adeguatamente controllata. D'altro canto il controllo non è istantaneo, in altre parole lo script non può sapere se un'operazione è andata o meno a buon fine fino al turno successivo, nè può agire di conseguenza; il rischio è la proliferazione di bug dovuti a dati errati nella zona privata, a causa della mancata azione sul server centrale. Questo sistema consente inoltre un buon controllo delle risorse usate dal programma (un SIGKILL non è intercettabile), ma non offre nessun particolare vantaggio per gli attacchi al sistema, necessitando dunque di un limite su __builtins__ e su __import__ per evitare spiacevoli sorprese (tranne forse la possibilità di usare chroot, ma probabilmente è da escludere richiedendo privilegi root sul processo server) A fronte di questo, l'implementazione tramite sandbox richiede la completa serializzabilità di tutte le risorse (o per lo meno quelle disponibili all'utente) più una generale riorganizzazione del programma per come è strutturato ora, introducendo una più decisa distinzione tra ciò che è scriptabile e ciò che non lo è. Inoltre servirebbe una buona dose di codice per rendere trasparente la serializzazione e mantenere una giocabilità adeguata. Completamente opposto a questo è il modello a capability, attualmente implementato in parte, che prevede che gli script siano in effetti incapaci di fare dei danni, poichè a loro vengono tolti tutti gli oggetti (trattati come capability appunto) che consetirebbero loro di portare a termine degli attacchi al gioco. In altre parole, ogni Entity, ogni Structure e ogni componente del gioco non ancora identificato prima di essere forniti allo script vengono sostituiti da oggetti proxy che mascherano gli attributi e i metodi disponibili, racchiudendoli con chiamate di controllo sul sistema stesso. L'effettiva implementabilità di questo sistema dipende da quante falle ha Python, che in effetti ha vari punti di attacco (__class__, __bases__, __dict__, object.__getattribute__() ecc), tuttavia esiste un modo di fornire dei dati al proxy senza che questi siano poi esposti dalla reflection (usando delle closures, che espongono solo dei tipi interni all'interprete, da cui non si può ritornare agli oggetti veri e propri). Inoltre anche gli attacchi basati su consumo di risorse sarebbero aggirabili, utilizzando signal.setitimer() per i tempi e forzando la garbage collection prima e dopo l'esecuzione degli script, mentre per gli attacchi sul sistema si dovrebbe agire sempre su __builtins__ e __import__, sperando dunque nell'assenza di falle nell'interprete Python. I vantaggi innegabili di questo sistema sono la maggiore libertà nella scrittura del codice (non c'è nessun vincolo di serializzabilità) e il fatto che si adatta maggiormente al linguaggio, dato che ad esempio le classi scritte dall'utente vengono convertite in oggetti corrispondenti memorizzati sul server. Inoltre il codice colla tra il lato script e il lato server è minimo e riesce ad essere estremamente generalizzato, tanto da esistere già in una versione di prova nel repository, modulo common.game.core.reference. Personalmente sarei più a favore dell'idea 2, quello che è da mettere in chiaro tuttavia è che prima di andare avanti a scrivere codice per l'integrazione tra i due campi del gioco è necessario definire quale soluzione adottare e quali interfacce o stratagemmi mettere in campo per attuarla nel modo più sicuro e trasparente possibile. Giovanni |
|
From: Massimo C. <cai...@gm...> - 2009-12-25 23:14:26
|
> 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! > |
|
From: Giovanni C. <sca...@gm...> - 2009-12-25 21:59:49
|
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! |
|
From: Massimo C. <cai...@gm...> - 2009-12-25 20:08:23
|
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. 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) 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). 6) Tutto il resto :-) Fatemi sapere cosa ne pensate! Ciao! Massimo |
|
From: Massimo C. <cai...@gm...> - 2009-12-20 21:42:15
|
IMO l'idea di "scriptare" gli scenari è da considerare più
sull'aspetto del gameplay che sull'aspetto implementativo. È più
divertente se il giocatore si trova ad affrontare situazioni diverse,
adottando quindi strategie diverse e più mirate, piuttosto che uno
scenario sempre uguale a sé stesso. Per fare ciò non è necessario
creare più scenari o più partite indipendenti: è anche possibile
creare ed estendere un unico scenario che al suo interno, in posti
(pianeti?) diversi, abbia caratteristiche diverse.
Come fare ciò dal punto di vista dell'implementazione...
In ogni caso, ci saranno degli script che risponderanno alle azioni
delle unità, ad esempio quando un'unità estrae delle risorse; se non
altro gli script scritti da noi. Possiamo quindi aggiungere nuove
funzionalità modificando questi script, ma il giocatore dovrà avere
sempre a disposizione un'interfaccia API che sia sufficientemente
semplice. È chiaro che introducendo nuove funzionalità e magari nuove
azioni possibili si deve aggiornare l'API.
Possiamo comunque fare una specie di framework molto generale, in cui
ogni unità ha una serie di dati espressi come chiave-valore, e
sfruttare un po' di magia nera del python per rendere semplice
l'introduzione di funzionalità mantenendo l'API semplice.
Faccio un esempio pratico.
Vogliamo creare un nuovo tipo di oggetto: un pulsante che può essere
premuto da un'unità e causa un'esplosione da un'altra zona della
mappa. (da ora in poi abbiamo definito anche la parola "oggetto",
provvederò ad aggiungerla al glossario.)
Una funzionalità di questo tipo può portare a strategie interessanti:
per esempio si potrebbero attirare le unità nemiche in quella zona per
farle saltare facilmente.
Per aggiungere questa funzionalità ci piacerebbe scrivere SOLO
qualcosa di questo tipo:
class BigButton(GameObject):
def pressTheBigButton(self):
for unity in unitiesInRect((10, 10), (30, 30)):
unity.life = 0 #kaboom!
Ci piacerebbe anche che nello script di una unità uno possa
semplicemente scrivere bigbutton.pressTheBigButton() per eseguire
l'azione relativa.
Vi garantisco che con metaclassi, decoratori e un po' di altre pozioni
magiche si può fare che quando viene eseguita la riga
bigbutton.pressTheBigButton()
nello script dell'unità, il codice della funzione non viene eseguito, bensì:
1) viene creato un dato che esprime questa azione che l'unità vuole compiere,
2) questo dato viene aggiunto alla lista delle azioni che l'unità
compirà in quel turno,
3) alla fine dell'esecuzione dello script questo dato verrà
serializzato insieme agli altri che esprimono le altre azioni,
4) solo quando il server avrà deserializzato le azioni di quella
unità, se l'unità potrà compiere quell'azione, il server eseguirà il
codice dentro la funzione.
5) la riga unity.life = 0 fa qualcosa di più che assegnare 0 a un
membro di un oggetto: nel framework assegna per quella unità un nuovo
valore alla chiave "life", modificando a tutti gli effetti lo stato di
quella unità.
Sim sala bim!
Ciao!
Massimo
Il 19 dicembre 2009 23.30, Giovanni Mascellani
<mas...@po...> ha scritto:
> Ciao Giovanni,
>
> Giovanni Campagna ha scritto:
>> Siccome sta cosa non riuscivo davvero a capirla (o comunque a capire
>> che effetti avrebbe all'atto pratico) ho provato a scrivere una pagina
>> wiki con un po' di codice. La trovate a
>> https://sourceforge.net/apps/trac/mmospg/wiki/GameObject
>> Fateci un salto e dateci un commento perchè io mi sto perdendo.
>
> Tutto quanto ho scritto nella mia ultima email sono soltanto opinioni e
> suggerimenti. Come ho già detto, non credo che avrò tempo per
> contribuire significativamente alla scrittura del codice, per cui sono
> il primo a ritenere le mie opinioni per nulla vincolanti.
>
> Nel merito della questione, è ovvio che rispetto a questi punti si va
> molto sul campo delle opinioni/idee, perché ognuno si fa una certa
> immagine del gioco. Sì, la mia idea è proprio quella di fare una cosa
> piuttosto generale.
>
> Dove va messo il limite alla generalità è una scelta di design: si può
> tranquillamente decidere che esistono tutta una serie di funzionalità
> (come il muoversi, lo sparare, eventualmente anche il raccogliere
> risorse) che sono basilari, e che quindi vanno implementate direttamente
> nel gioco. Ciò nonostante, io non disdegnerei l'ipotesi di lasciare un
> ampio spazio di scriptabilità al creatore dello scenario.
>
> Ad ogni modo, come dicevo, la scelta è vostra. Come ho già detto, per me
> la componente chiave di giocabilità è che il modello di gioco non
> imponga al giocatore di dover prendere tre lauree e quattro dottorati
> prima di poter scrivere degli script sufficientemente abili.
>
> Gio.
> --
> Giovanni Mascellani <mas...@po...>
> Pisa, Italy
>
> Web: http://poisson.phc.unipi.it/~mascellani
> Jabber: g.m...@ja... / gio...@el...
>
>
> ------------------------------------------------------------------------------
> 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
>
>
|
|
From: Giovanni M. <mas...@po...> - 2009-12-19 22:30:33
|
Ciao Giovanni, Giovanni Campagna ha scritto: > Siccome sta cosa non riuscivo davvero a capirla (o comunque a capire > che effetti avrebbe all'atto pratico) ho provato a scrivere una pagina > wiki con un po' di codice. La trovate a > https://sourceforge.net/apps/trac/mmospg/wiki/GameObject > Fateci un salto e dateci un commento perchè io mi sto perdendo. Tutto quanto ho scritto nella mia ultima email sono soltanto opinioni e suggerimenti. Come ho già detto, non credo che avrò tempo per contribuire significativamente alla scrittura del codice, per cui sono il primo a ritenere le mie opinioni per nulla vincolanti. Nel merito della questione, è ovvio che rispetto a questi punti si va molto sul campo delle opinioni/idee, perché ognuno si fa una certa immagine del gioco. Sì, la mia idea è proprio quella di fare una cosa piuttosto generale. Dove va messo il limite alla generalità è una scelta di design: si può tranquillamente decidere che esistono tutta una serie di funzionalità (come il muoversi, lo sparare, eventualmente anche il raccogliere risorse) che sono basilari, e che quindi vanno implementate direttamente nel gioco. Ciò nonostante, io non disdegnerei l'ipotesi di lasciare un ampio spazio di scriptabilità al creatore dello scenario. Ad ogni modo, come dicevo, la scelta è vostra. Come ho già detto, per me la componente chiave di giocabilità è che il modello di gioco non imponga al giocatore di dover prendere tre lauree e quattro dottorati prima di poter scrivere degli script sufficientemente abili. Gio. -- Giovanni Mascellani <mas...@po...> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.m...@ja... / gio...@el... |
|
From: Giovanni C. <sca...@gm...> - 2009-12-19 21:56:12
|
Siccome sta cosa non riuscivo davvero a capirla (o comunque a capire che effetti avrebbe all'atto pratico) ho provato a scrivere una pagina wiki con un po' di codice. La trovate a https://sourceforge.net/apps/trac/mmospg/wiki/GameObject Fateci un salto e dateci un commento perchè io mi sto perdendo. Giovanni 2009/12/18 Giovanni Campagna <sca...@gm...>: > Tutto ciò che segue è mia personale e umile opinione. La nomenclatura > tecnica (in particolare i livelli) cerca di seguire la wiki Glossario > e GameServer. > > 2009/12/17 Giovanni Mascellani <mas...@po...>: >> Salve a tutti, vi scrivo qualche idea che mi è venuta tra ieri sera e >> oggi a proposito di MMOSPG. >> >> Prima di tutto: condivido perfettamente quello che dice Maximilian: nel >> wiki c'è già chi sta scrivendo proposte molto tecniche (formato XML, >> implementazione), mentre secondo me manca ancora il grosso delle >> decisioni di struttura. > > Il problema è che, almeno secondo me, fino a che uno non scrive codice > nudo e crudo non ha la reale percezione delle varie problematiche di > design che possono sorgere. > >> Secondo me bisogna partire da questo presupposto: la parte interessante >> deve essere il programmare una strategia. Il giocatore (ossia colui che >> programma le unità) non deve rischiare di perdersi in tecnicismi per >> gestire il suo gioco, deve potersi concentrare sull'aspetto strategico >> ed organizzativo. Se bisogna stare mesi per mettere a punto gli >> strumenti per poter controllare le proprie unità, poi difficilmente si >> ha ancora voglia di pensare alla strategia. > > Ma, d'altro canto, il giocatore può voler perdersi in tecnicismi, > ovvero aggirare le funzioni di libreria e agire al livello più basso, > ritenendosi capace di una implementazione migliore di quella fornita > di base. Ovvero, se lui trova un'algoritmo di pathfinding che opera in > O(1) spazio è libero di usarlo, anche se la libreria fornisce quello > standard che calcola il path una volta e salva il risultato nella zona > dati (O(n) memoria persistente) > >> Altro presupposto: cercherei di fare un gioco che sia il più generale e >> flessibile possibile. >> >> La mia idea quindi è questa: lo schema di gioco è ridotto all'osso, >> ossia c'è una griglia quadrata e ci sono delle unità e festa finita. >> Ogni unità ha delle proprietà (espresse in forma chiave-valore), così >> come ogni casella della mappa. Il significato di tali proprietà non è >> intrinseco al gioco, ma dipende dalla definizione dello scenario con il >> quale si sta giocando. Questo vuol dire che lo scenario ha associati >> degli script (per esempio, le funzioni di una libreria; la forma tecnica >> di tali script può essere discussa), che possono essere (sotto >> determinate condizioni) invocati dai programmini che pilotano le varie >> unità. > > Ma... stiamo realizzando un gioco o un framework di sviluppo per giochi? > Perchè renderlo astratto significa sì renderlo più adattabile, ma > significa anche che molte ottimizzazioni ad hoc non sono possibili e > che è necessario un sistema generalmente più complesso per supportare > le maggiori modalità di gioco. > Ad esempio, che per muovermi in una casella io (io programmatore della > libreria di base, non io giocatore) debba fare > world.get(me.get("position").get("x"),me.get("position").get("y")+1).set("objid",me.get("objid")) > al posto di un semplice me.moveup(), solo per mantenere l'astrazione > nella remota ipotesi che qualcuno ne faccia un gioco diverso, diventa > un pochino irritante. > >> Per esempio: possiamo fare uno scenario in modo che ogni unità abbia >> associate delle proprietà che identificano il suo carico attuale, la sua >> vita e la sua potenza di fuoco e gli spari rimasti. Allora lo scenario >> può prevedere degli script "globali" che permettono di sparare >> (controlla se ha ancora spari rimasti: nel caso li decrementa e, se >> l'unità sulla quale sparare è abbastanza vicina, decrementa la sua >> vita). Un altro script "globale" permette di utilizzare le risorse che >> ha, per esempio, per costruire un'altra unità, o per trasferire tali >> risorse ad un'unità vicina. > > Di nuovo, o lo script "globale" è fornito dalla libreria (livello 3, > corrispondente all'"import gamehelper;" che quasi tutti i gli script > utente avranno) e dunque si aprono questioni di sicurezza e questioni > di semplicità (quanto vale la pena consentire all'utente di avere una > funzione diversa per implementare lo sparo, che tuttavia rispetti i > constraint del gioco?), oppure lo si può considerare semplicemente > parte del gioco al livello 2, senza introdurre astrazioni che > rischiano soltanto di perdere contatto con il gioco in questione. > >> Poi ci possono essere degli script associati a delle caselle: se >> un'unità è sufficientemente vicina ad una casella può invocare il suo >> script (o un suo script, se sono più di uno). Una miniera può essere un >> oggetto di questo tipo (quando un'unità invoca il suo script, tale >> script modifica le proprietà dell'unità in modo da aumentare il suo >> numero di risorse possedute). Una miniera ad esaurimento può essere >> implementata modificando contemporaneamente le proprietà dell'unità (in >> modo da aggiungergli risorse) e quelle della miniera (in modo da toglierle). > > Si ma quanto vale la pena consentire a qualcuno di avere una miniera > che non aumenta le risorse di chi raccoglie? O diversamente, quanto > questa astrazione rimane qualcosa che provoca in effetti del codice > reale e quanto invece diventa soltanto un modello su cui il grosso del > codice viene all'interno degli "script globali", rendendo l'astrazione > inutile? > >> Si possono poi mettere degli script time-triggered: ogni venti turni >> tutte le miniere ad esaurimento devono essere ricaricate di una certa >> quantità di risorse. >> >> In questo modo il gioco diventa molto più astratto, dunque il creatore >> dello scenario ha molta più libertà nel decidere con quali regole si >> gioca. In particolare, si potrebbero anche fare scenari "alla cieca", >> ossia nei quali i giocatori all'inizio non conoscono tutte le regole. >> Per esempio, potrebbero esserci delle caselle dal comportamento >> sconosciuto: quando un'unità trova una di queste caselle, riceve da essa >> una descrizione in linguaggio naturale di cosa può fare. L'unità deve >> fare arrivare al giocatore (tramite il comandante) tale messaggio, in >> modo che il giocatore possa decidere come sfruttare lo script presente >> nella casella scoperta. > > Si ma... chi è il creatore dello scenario? Possiamo aspettarci che > esista un solo scenario per server oppure consentiamo ai giocatori di > crearsi le proprie mappe private? > Nel primo caso, scaricarsi il codice da sf e modificarlo a mano è una > necessità, che siano script (e dunque funzioni esportate con una sorta > di polimorfismo) o semplicemente sia tutto scritto dentro nel > programma. Nel secondo caso, consentire più partite in contemporanea > nello stesso server può creare un sacco di problemi, che fino adesso > il server non è stato designato per contrastare. > >> In questo modo, inoltre, il giocatore (e le sue unità) interagiscono con >> lo scenario (e con gli altri giocatori e le altre unità) quasi puramente >> a livello di chiamate di particolari funzioni o script. Il >> giocatore-programmatore si può quindi concentrare sulla strategia, >> piuttosto che sullo scrivere complicate funzioni per fare muovere la sua >> unità, farla sparare nella direzione giusta, ecc... L'idea è che se gli >> elementi del gioco sono quanto più possibile schematici e semplici, i >> giocatori possono effettivamente dedicarsi alla parte interessante della >> programmazione. > > Le unità interagiscono comunque solo a livello di chiamate di > particolari funzioni. Solo che, vivendo in processi diversi (o > comunque, in ambiti in cui si suppone incomunicabilità) il livello 2 e > il livello 3, queste chiamate a funzioni devono essere trasformate in > uno stream di dati, che deve essere trasferito dall'uno all'altro, sia > che la funzione sia rappresentata da un nome pubblico, sia da un nome > privato, sia da un intero valido in una tabella hard coded nel server. > È comunque chiaro che la maggior parte del tempo i giocatori non si > occuperanno di questi dettagli di infimo livello e utilizzeranno il > codice fornito all'inizio del gioco, che includerà alcuni algoritmi e > alcune "chiamate di sistema" per le cose comuni del gioco. Ma se il > giocatore vuole aggirare questo codice (perchè ricordiamoci che i bug > esistono) è libero di farlo. > >> Ciaociao, Gio. >> -- >> Giovanni Mascellani <mas...@po...> >> Pisa, Italy >> >> Web: http://poisson.phc.unipi.it/~mascellani >> Jabber: g.m...@ja... / gio...@el... >> > > Giovanni > |
|
From: Giovanni C. <sca...@gm...> - 2009-12-18 18:00:39
|
Tutto ciò che segue è mia personale e umile opinione. La nomenclatura
tecnica (in particolare i livelli) cerca di seguire la wiki Glossario
e GameServer.
2009/12/17 Giovanni Mascellani <mas...@po...>:
> Salve a tutti, vi scrivo qualche idea che mi è venuta tra ieri sera e
> oggi a proposito di MMOSPG.
>
> Prima di tutto: condivido perfettamente quello che dice Maximilian: nel
> wiki c'è già chi sta scrivendo proposte molto tecniche (formato XML,
> implementazione), mentre secondo me manca ancora il grosso delle
> decisioni di struttura.
Il problema è che, almeno secondo me, fino a che uno non scrive codice
nudo e crudo non ha la reale percezione delle varie problematiche di
design che possono sorgere.
> Secondo me bisogna partire da questo presupposto: la parte interessante
> deve essere il programmare una strategia. Il giocatore (ossia colui che
> programma le unità) non deve rischiare di perdersi in tecnicismi per
> gestire il suo gioco, deve potersi concentrare sull'aspetto strategico
> ed organizzativo. Se bisogna stare mesi per mettere a punto gli
> strumenti per poter controllare le proprie unità, poi difficilmente si
> ha ancora voglia di pensare alla strategia.
Ma, d'altro canto, il giocatore può voler perdersi in tecnicismi,
ovvero aggirare le funzioni di libreria e agire al livello più basso,
ritenendosi capace di una implementazione migliore di quella fornita
di base. Ovvero, se lui trova un'algoritmo di pathfinding che opera in
O(1) spazio è libero di usarlo, anche se la libreria fornisce quello
standard che calcola il path una volta e salva il risultato nella zona
dati (O(n) memoria persistente)
> Altro presupposto: cercherei di fare un gioco che sia il più generale e
> flessibile possibile.
>
> La mia idea quindi è questa: lo schema di gioco è ridotto all'osso,
> ossia c'è una griglia quadrata e ci sono delle unità e festa finita.
> Ogni unità ha delle proprietà (espresse in forma chiave-valore), così
> come ogni casella della mappa. Il significato di tali proprietà non è
> intrinseco al gioco, ma dipende dalla definizione dello scenario con il
> quale si sta giocando. Questo vuol dire che lo scenario ha associati
> degli script (per esempio, le funzioni di una libreria; la forma tecnica
> di tali script può essere discussa), che possono essere (sotto
> determinate condizioni) invocati dai programmini che pilotano le varie
> unità.
Ma... stiamo realizzando un gioco o un framework di sviluppo per giochi?
Perchè renderlo astratto significa sì renderlo più adattabile, ma
significa anche che molte ottimizzazioni ad hoc non sono possibili e
che è necessario un sistema generalmente più complesso per supportare
le maggiori modalità di gioco.
Ad esempio, che per muovermi in una casella io (io programmatore della
libreria di base, non io giocatore) debba fare
world.get(me.get("position").get("x"),me.get("position").get("y")+1).set("objid",me.get("objid"))
al posto di un semplice me.moveup(), solo per mantenere l'astrazione
nella remota ipotesi che qualcuno ne faccia un gioco diverso, diventa
un pochino irritante.
> Per esempio: possiamo fare uno scenario in modo che ogni unità abbia
> associate delle proprietà che identificano il suo carico attuale, la sua
> vita e la sua potenza di fuoco e gli spari rimasti. Allora lo scenario
> può prevedere degli script "globali" che permettono di sparare
> (controlla se ha ancora spari rimasti: nel caso li decrementa e, se
> l'unità sulla quale sparare è abbastanza vicina, decrementa la sua
> vita). Un altro script "globale" permette di utilizzare le risorse che
> ha, per esempio, per costruire un'altra unità, o per trasferire tali
> risorse ad un'unità vicina.
Di nuovo, o lo script "globale" è fornito dalla libreria (livello 3,
corrispondente all'"import gamehelper;" che quasi tutti i gli script
utente avranno) e dunque si aprono questioni di sicurezza e questioni
di semplicità (quanto vale la pena consentire all'utente di avere una
funzione diversa per implementare lo sparo, che tuttavia rispetti i
constraint del gioco?), oppure lo si può considerare semplicemente
parte del gioco al livello 2, senza introdurre astrazioni che
rischiano soltanto di perdere contatto con il gioco in questione.
> Poi ci possono essere degli script associati a delle caselle: se
> un'unità è sufficientemente vicina ad una casella può invocare il suo
> script (o un suo script, se sono più di uno). Una miniera può essere un
> oggetto di questo tipo (quando un'unità invoca il suo script, tale
> script modifica le proprietà dell'unità in modo da aumentare il suo
> numero di risorse possedute). Una miniera ad esaurimento può essere
> implementata modificando contemporaneamente le proprietà dell'unità (in
> modo da aggiungergli risorse) e quelle della miniera (in modo da toglierle).
Si ma quanto vale la pena consentire a qualcuno di avere una miniera
che non aumenta le risorse di chi raccoglie? O diversamente, quanto
questa astrazione rimane qualcosa che provoca in effetti del codice
reale e quanto invece diventa soltanto un modello su cui il grosso del
codice viene all'interno degli "script globali", rendendo l'astrazione
inutile?
> Si possono poi mettere degli script time-triggered: ogni venti turni
> tutte le miniere ad esaurimento devono essere ricaricate di una certa
> quantità di risorse.
>
> In questo modo il gioco diventa molto più astratto, dunque il creatore
> dello scenario ha molta più libertà nel decidere con quali regole si
> gioca. In particolare, si potrebbero anche fare scenari "alla cieca",
> ossia nei quali i giocatori all'inizio non conoscono tutte le regole.
> Per esempio, potrebbero esserci delle caselle dal comportamento
> sconosciuto: quando un'unità trova una di queste caselle, riceve da essa
> una descrizione in linguaggio naturale di cosa può fare. L'unità deve
> fare arrivare al giocatore (tramite il comandante) tale messaggio, in
> modo che il giocatore possa decidere come sfruttare lo script presente
> nella casella scoperta.
Si ma... chi è il creatore dello scenario? Possiamo aspettarci che
esista un solo scenario per server oppure consentiamo ai giocatori di
crearsi le proprie mappe private?
Nel primo caso, scaricarsi il codice da sf e modificarlo a mano è una
necessità, che siano script (e dunque funzioni esportate con una sorta
di polimorfismo) o semplicemente sia tutto scritto dentro nel
programma. Nel secondo caso, consentire più partite in contemporanea
nello stesso server può creare un sacco di problemi, che fino adesso
il server non è stato designato per contrastare.
> In questo modo, inoltre, il giocatore (e le sue unità) interagiscono con
> lo scenario (e con gli altri giocatori e le altre unità) quasi puramente
> a livello di chiamate di particolari funzioni o script. Il
> giocatore-programmatore si può quindi concentrare sulla strategia,
> piuttosto che sullo scrivere complicate funzioni per fare muovere la sua
> unità, farla sparare nella direzione giusta, ecc... L'idea è che se gli
> elementi del gioco sono quanto più possibile schematici e semplici, i
> giocatori possono effettivamente dedicarsi alla parte interessante della
> programmazione.
Le unità interagiscono comunque solo a livello di chiamate di
particolari funzioni. Solo che, vivendo in processi diversi (o
comunque, in ambiti in cui si suppone incomunicabilità) il livello 2 e
il livello 3, queste chiamate a funzioni devono essere trasformate in
uno stream di dati, che deve essere trasferito dall'uno all'altro, sia
che la funzione sia rappresentata da un nome pubblico, sia da un nome
privato, sia da un intero valido in una tabella hard coded nel server.
È comunque chiaro che la maggior parte del tempo i giocatori non si
occuperanno di questi dettagli di infimo livello e utilizzeranno il
codice fornito all'inizio del gioco, che includerà alcuni algoritmi e
alcune "chiamate di sistema" per le cose comuni del gioco. Ma se il
giocatore vuole aggirare questo codice (perchè ricordiamoci che i bug
esistono) è libero di farlo.
> Ciaociao, Gio.
> --
> Giovanni Mascellani <mas...@po...>
> Pisa, Italy
>
> Web: http://poisson.phc.unipi.it/~mascellani
> Jabber: g.m...@ja... / gio...@el...
>
Giovanni
|
|
From: Massimo C. <cai...@gm...> - 2009-12-18 14:15:19
|
Ciao! Ve lo dicevo che Giovanni era uno bravo!!! A parte ciò... Mi piace un sacco l'idea di scriptare le caselle particolari della mappa, così come le varie azioni possibili delle unità! Primo perché rende più vari gli scenari e secondo perché all'inizio ci consente di lavorare ad un'infrastruttura del gioco più astratta. Colgo l'occasione per aggiornarvi su ciò che avevamo pensato, dato che sulla Wiki è tutto un po' confuso! Innanzitutto si pensava di sviluppare prima di tutto l'interfaccia utente, in modo che si possano vedere fin da subito i primi risultati. Consideriamo ciò che l'interfaccia deve mostrare all'utente: si tratta della conoscenza del gioco che ha il comandante, il quale però può anche aver ricevuto informazioni sullo stato del gioco da altre fonti. Ciò che il comandante sa, complessivamente, lo troviamo scritto nella sua zona dati, un po' perché lui si è salvato le informazioni viste nel tempo, un po' per le informazioni che gli sono giunte da altre fonti. Deve quindi esistere un formato particolare in cui il comandante, così come ogni altra unità, si salva le informazioni in zona dati. Dobbiamo preoccuparci di definire i vari tipi di dati, in modo che possano essere facilmente mostrati all'utente dall'interfaccia Web. Può esistere ad esempio un dato MapInfo, che non è altro che una griglia che associa ad ogni cella alcuni dati legati alla mappa. Se il comandante ha dei dati in questo formato, questi vengono mostrati all'utente effettivamente come una griglia tutta bella colorata in base a cosa c'è in ogni cella. In questo modo il giocatore può vedere la mappa senza violare i limiti della conoscenza del comandante. Avevamo pensato di dividere l'interfaccia web in due parti: un layer 1, più vicino al browser, e un layer 2 che invece si occupa di relazionarsi col server di gioco e che trasforma i dati ricevuti dal server in XML. L'XML viene trasformato in HTML tramite XSLT dal layer 1 oppure, se in futuro vorremo adottare Ajax, direttamente dal browser. Grazie a XSLT possiamo risparmiare un sacco di codice. Il formato XML è da decidere: deve poter rappresentare i dati del comandante che l'utente può vedere nell'interfaccia Web. Il dialetto XML che definiremo, però, deve essere più vicino alla visualizzazione dei dati, in modo che possa essere facilmente convertito in HTML. Quando avremo deciso i primi dati che un'unità può memorizzare e il formato XML per mostrarli all'utente, possiamo già buttarci a scrivere un po' di codice con dei risultati visibili... Per questo abbiamo deciso di cominciare già a scrivere qualcosa di tecnico. Questa cosa dei dati vale anche al contrario, cioè se io dall'interfaccia Web do un ordine a un'unità, l'ordine viene convertito in un dato che poi in Comandante interpreterà. Se ho tempo butto giù sulla wiki i tipi di dati che mi vengono in mente. Così se ci piacciono si può cominciare già a scrivere un po' di python. Ciao a tutti! Massimo Il 17 dicembre 2009 21.34, Giovanni Mascellani <mas...@po...> ha scritto: > Salve a tutti, vi scrivo qualche idea che mi è venuta tra ieri sera e > oggi a proposito di MMOSPG. > > Prima di tutto: condivido perfettamente quello che dice Maximilian: nel > wiki c'è già chi sta scrivendo proposte molto tecniche (formato XML, > implementazione), mentre secondo me manca ancora il grosso delle > decisioni di struttura. > > Secondo me bisogna partire da questo presupposto: la parte interessante > deve essere il programmare una strategia. Il giocatore (ossia colui che > programma le unità) non deve rischiare di perdersi in tecnicismi per > gestire il suo gioco, deve potersi concentrare sull'aspetto strategico > ed organizzativo. Se bisogna stare mesi per mettere a punto gli > strumenti per poter controllare le proprie unità, poi difficilmente si > ha ancora voglia di pensare alla strategia. > > Altro presupposto: cercherei di fare un gioco che sia il più generale e > flessibile possibile. > > La mia idea quindi è questa: lo schema di gioco è ridotto all'osso, > ossia c'è una griglia quadrata e ci sono delle unità e festa finita. > Ogni unità ha delle proprietà (espresse in forma chiave-valore), così > come ogni casella della mappa. Il significato di tali proprietà non è > intrinseco al gioco, ma dipende dalla definizione dello scenario con il > quale si sta giocando. Questo vuol dire che lo scenario ha associati > degli script (per esempio, le funzioni di una libreria; la forma tecnica > di tali script può essere discussa), che possono essere (sotto > determinate condizioni) invocati dai programmini che pilotano le varie > unità. > > Per esempio: possiamo fare uno scenario in modo che ogni unità abbia > associate delle proprietà che identificano il suo carico attuale, la sua > vita e la sua potenza di fuoco e gli spari rimasti. Allora lo scenario > può prevedere degli script "globali" che permettono di sparare > (controlla se ha ancora spari rimasti: nel caso li decrementa e, se > l'unità sulla quale sparare è abbastanza vicina, decrementa la sua > vita). Un altro script "globale" permette di utilizzare le risorse che > ha, per esempio, per costruire un'altra unità, o per trasferire tali > risorse ad un'unità vicina. > > Poi ci possono essere degli script associati a delle caselle: se > un'unità è sufficientemente vicina ad una casella può invocare il suo > script (o un suo script, se sono più di uno). Una miniera può essere un > oggetto di questo tipo (quando un'unità invoca il suo script, tale > script modifica le proprietà dell'unità in modo da aumentare il suo > numero di risorse possedute). Una miniera ad esaurimento può essere > implementata modificando contemporaneamente le proprietà dell'unità (in > modo da aggiungergli risorse) e quelle della miniera (in modo da toglierle). > > Si possono poi mettere degli script time-triggered: ogni venti turni > tutte le miniere ad esaurimento devono essere ricaricate di una certa > quantità di risorse. > > In questo modo il gioco diventa molto più astratto, dunque il creatore > dello scenario ha molta più libertà nel decidere con quali regole si > gioca. In particolare, si potrebbero anche fare scenari "alla cieca", > ossia nei quali i giocatori all'inizio non conoscono tutte le regole. > Per esempio, potrebbero esserci delle caselle dal comportamento > sconosciuto: quando un'unità trova una di queste caselle, riceve da essa > una descrizione in linguaggio naturale di cosa può fare. L'unità deve > fare arrivare al giocatore (tramite il comandante) tale messaggio, in > modo che il giocatore possa decidere come sfruttare lo script presente > nella casella scoperta. > > In questo modo, inoltre, il giocatore (e le sue unità) interagiscono con > lo scenario (e con gli altri giocatori e le altre unità) quasi puramente > a livello di chiamate di particolari funzioni o script. Il > giocatore-programmatore si può quindi concentrare sulla strategia, > piuttosto che sullo scrivere complicate funzioni per fare muovere la sua > unità, farla sparare nella direzione giusta, ecc... L'idea è che se gli > elementi del gioco sono quanto più possibile schematici e semplici, i > giocatori possono effettivamente dedicarsi alla parte interessante della > programmazione. > > Ciaociao, Gio. > -- > Giovanni Mascellani <mas...@po...> > Pisa, Italy > > Web: http://poisson.phc.unipi.it/~mascellani > Jabber: g.m...@ja... / gio...@el... > > > ------------------------------------------------------------------------------ > 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 > > |
|
From: Giovanni M. <mas...@po...> - 2009-12-17 21:48:10
|
Salve a tutti, vi scrivo qualche idea che mi è venuta tra ieri sera e oggi a proposito di MMOSPG. Prima di tutto: condivido perfettamente quello che dice Maximilian: nel wiki c'è già chi sta scrivendo proposte molto tecniche (formato XML, implementazione), mentre secondo me manca ancora il grosso delle decisioni di struttura. Secondo me bisogna partire da questo presupposto: la parte interessante deve essere il programmare una strategia. Il giocatore (ossia colui che programma le unità) non deve rischiare di perdersi in tecnicismi per gestire il suo gioco, deve potersi concentrare sull'aspetto strategico ed organizzativo. Se bisogna stare mesi per mettere a punto gli strumenti per poter controllare le proprie unità, poi difficilmente si ha ancora voglia di pensare alla strategia. Altro presupposto: cercherei di fare un gioco che sia il più generale e flessibile possibile. La mia idea quindi è questa: lo schema di gioco è ridotto all'osso, ossia c'è una griglia quadrata e ci sono delle unità e festa finita. Ogni unità ha delle proprietà (espresse in forma chiave-valore), così come ogni casella della mappa. Il significato di tali proprietà non è intrinseco al gioco, ma dipende dalla definizione dello scenario con il quale si sta giocando. Questo vuol dire che lo scenario ha associati degli script (per esempio, le funzioni di una libreria; la forma tecnica di tali script può essere discussa), che possono essere (sotto determinate condizioni) invocati dai programmini che pilotano le varie unità. Per esempio: possiamo fare uno scenario in modo che ogni unità abbia associate delle proprietà che identificano il suo carico attuale, la sua vita e la sua potenza di fuoco e gli spari rimasti. Allora lo scenario può prevedere degli script "globali" che permettono di sparare (controlla se ha ancora spari rimasti: nel caso li decrementa e, se l'unità sulla quale sparare è abbastanza vicina, decrementa la sua vita). Un altro script "globale" permette di utilizzare le risorse che ha, per esempio, per costruire un'altra unità, o per trasferire tali risorse ad un'unità vicina. Poi ci possono essere degli script associati a delle caselle: se un'unità è sufficientemente vicina ad una casella può invocare il suo script (o un suo script, se sono più di uno). Una miniera può essere un oggetto di questo tipo (quando un'unità invoca il suo script, tale script modifica le proprietà dell'unità in modo da aumentare il suo numero di risorse possedute). Una miniera ad esaurimento può essere implementata modificando contemporaneamente le proprietà dell'unità (in modo da aggiungergli risorse) e quelle della miniera (in modo da toglierle). Si possono poi mettere degli script time-triggered: ogni venti turni tutte le miniere ad esaurimento devono essere ricaricate di una certa quantità di risorse. In questo modo il gioco diventa molto più astratto, dunque il creatore dello scenario ha molta più libertà nel decidere con quali regole si gioca. In particolare, si potrebbero anche fare scenari "alla cieca", ossia nei quali i giocatori all'inizio non conoscono tutte le regole. Per esempio, potrebbero esserci delle caselle dal comportamento sconosciuto: quando un'unità trova una di queste caselle, riceve da essa una descrizione in linguaggio naturale di cosa può fare. L'unità deve fare arrivare al giocatore (tramite il comandante) tale messaggio, in modo che il giocatore possa decidere come sfruttare lo script presente nella casella scoperta. In questo modo, inoltre, il giocatore (e le sue unità) interagiscono con lo scenario (e con gli altri giocatori e le altre unità) quasi puramente a livello di chiamate di particolari funzioni o script. Il giocatore-programmatore si può quindi concentrare sulla strategia, piuttosto che sullo scrivere complicate funzioni per fare muovere la sua unità, farla sparare nella direzione giusta, ecc... L'idea è che se gli elementi del gioco sono quanto più possibile schematici e semplici, i giocatori possono effettivamente dedicarsi alla parte interessante della programmazione. Ciaociao, Gio. -- Giovanni Mascellani <mas...@po...> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.m...@ja... / gio...@el... |
|
From: Maximilian A. <alb...@gm...> - 2009-12-17 16:50:40
|
+1 agpl 2009/12/16 Massimo Cairo <cai...@gm...> > +1 per la AGPL > > Il 16 dicembre 2009 21.34, Giovanni Campagna > <sca...@gm...> ha scritto: > > L'hosting a Sourceforge è subordinato alla scelta di una licenza > > opensource, ma ancora non abbiamo pensato a questa cosa. Poichè ogni > > file ha bisogno di una notifica di licenza, prima di fare cambi che > > richiedono modifiche su tutto il repository, conviene decidere. > > > > Credo che la scelta fondamentale sia una: consentiamo a qualche > > azienda (casomai ne esistesse una interessata) di modificare il nostro > > programma e rivenderlo? > > Se sì, penso che una licenza BSD modificata ( > > http://opensource.org/licenses/bsd-license.php ) sia la soluzione più > > semplice, dato che offre grande libertà pur rimanendo all'interno dei > > vincoli di Sourceforge. > > Altrimenti, l'unica scelta percorribile è la AGPL ( > > http://www.fsf.org/licensing/licenses/agpl.html ) che è come la GPL ma > > ha il vincolo che ogni utente di un server mmospg privato ha accesso > > al codice sorgente. > > > > Personalmente sarei a favore della AGPL, ma qualcuno la potrebbe > > vedere come troppo restrittiva. > > > > Giovanni > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > ------------------------------------------------------------------------------ > 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 > -- Mit freundlichen Grüßen, Max! |
|
From: Massimo C. <cai...@gm...> - 2009-12-16 20:47:25
|
+1 per la AGPL Il 16 dicembre 2009 21.34, Giovanni Campagna <sca...@gm...> ha scritto: > L'hosting a Sourceforge è subordinato alla scelta di una licenza > opensource, ma ancora non abbiamo pensato a questa cosa. Poichè ogni > file ha bisogno di una notifica di licenza, prima di fare cambi che > richiedono modifiche su tutto il repository, conviene decidere. > > Credo che la scelta fondamentale sia una: consentiamo a qualche > azienda (casomai ne esistesse una interessata) di modificare il nostro > programma e rivenderlo? > Se sì, penso che una licenza BSD modificata ( > http://opensource.org/licenses/bsd-license.php ) sia la soluzione più > semplice, dato che offre grande libertà pur rimanendo all'interno dei > vincoli di Sourceforge. > Altrimenti, l'unica scelta percorribile è la AGPL ( > http://www.fsf.org/licensing/licenses/agpl.html ) che è come la GPL ma > ha il vincolo che ogni utente di un server mmospg privato ha accesso > al codice sorgente. > > Personalmente sarei a favore della AGPL, ma qualcuno la potrebbe > vedere come troppo restrittiva. > > Giovanni > > ------------------------------------------------------------------------------ > 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 > |
|
From: Giovanni C. <sca...@gm...> - 2009-12-16 20:34:42
|
L'hosting a Sourceforge è subordinato alla scelta di una licenza opensource, ma ancora non abbiamo pensato a questa cosa. Poichè ogni file ha bisogno di una notifica di licenza, prima di fare cambi che richiedono modifiche su tutto il repository, conviene decidere. Credo che la scelta fondamentale sia una: consentiamo a qualche azienda (casomai ne esistesse una interessata) di modificare il nostro programma e rivenderlo? Se sì, penso che una licenza BSD modificata ( http://opensource.org/licenses/bsd-license.php ) sia la soluzione più semplice, dato che offre grande libertà pur rimanendo all'interno dei vincoli di Sourceforge. Altrimenti, l'unica scelta percorribile è la AGPL ( http://www.fsf.org/licensing/licenses/agpl.html ) che è come la GPL ma ha il vincolo che ogni utente di un server mmospg privato ha accesso al codice sorgente. Personalmente sarei a favore della AGPL, ma qualcuno la potrebbe vedere come troppo restrittiva. Giovanni |
|
From: Giovanni C. <sca...@gm...> - 2009-12-16 13:20:14
|
Questo è il mio primo messaggio alla mailing list, l'inizio del meraviglioso progetto MMOSPG! Speriamo che si concluda felicemente Giovanni |
