Post by Ivan Marcialis[...]
1) Dal poco che ho letto l'idea e' realizzare un Mud Engine in Java che
permetta la creazione di MUD molto flessibili
esattamente. I codici attuali sono scritti in C (quindi niente oggetti) e
sono monolitici.
Post by Ivan Marcialisbasati sulle skills invece che sui livelli.
EposOnline sarà basato sulle skills. Mythwaves è modulare quindi non ha
dipendenze da alcun sistema. Un sistema modulare permette:
a) Di gestire il codice in modo più pulito (se il modulo A non funziona,
cambi solo quello, difficilmente dovrai cambiare anche i moduli B, C e D
che dipendono da A. Difficilmente ovviamente sta a dire che può capitare)
b) Di implementare/modificare in modo più semplice le varie feature che un
mud vuole.
Post by Ivan MarcialisLa domanda e' perché avete deciso di farlo? Non
esistono Engine già pronti che facciano quello che voi volete e quindi
state coprendo un buco di "mercato"
Abbiamo fatto delle ricerche ma non abbiamo trovato nessuna engine modulare
eistente. Pensiamo quindi di essere i primi ad aver ragionato un approccio
simile (però sul sito sono stato attento a non citare da nessuna parte
"siamo i primi" perché non lo so se è vero), di certo è un'approccio
innovativo.
Tuttavia il "buco" mercato che cerchiamo di coprire è quello della lentezza
evolutiva dei mud. Trovo che, dal lato "tecnico" ci sia stata ben poca
evoluzione nell'ambito dei mud. Tanto per dirne una, Achaea è forse uno dei
migliori mud esistenti, eppure ha un client un poco più bruttino di quello
che aveva TheGate. L'MXP già citato in questo thread è un protocollo che
permette miglioramenti non strabilianti. Ti faccio notare che telnet è nato
come emulatore di un terminale VT100, ovvero nel periodo in cui i computer
costavano tanto, avevano i fosfori verdi etc. I tempi sono cambiati e quasi
nessuno usa più un modem 9,6K con un terminale vt100 :)
Post by Ivan Marcialisoppure vi state cimentando per il
gusto di molti informatici (anche il mio) di poter dire questo l'ho
fatto io
Guarda, se tornassi indietro non lo so se mi ci butterei di nuovo in questa
impresa :)
Resta il fatto che ormai metà lavoro è fatto (lo scheletro di leviathan) e
aspetto di essere ripagato di tutto il tempo che ho passato a ragionare
sulle varie meccaniche e sui vari possibili sistemi di comunicazione :)
Post by Ivan Marcialisoppure, ancora, è una via di mezzo nel senso che si sono cose
molto simili a quello che volevate ma modificare quello che non va era
più dispendioso che rifare tutto da capo?
2) Se la terza è buona cosa non potevate fare cogli engine esistenti che
invece volevate fare?
a) Non sappiamo lavorare in C, nè vogliamo saperlo fare
b) La potenza di un progetto sta nella modularità. Un programma modulare
richiederà un minimo di "competenza" in più, ma darà soddisfazioni
notevoli.
Post by Ivan Marcialis3) Il client sarà in Java/Swing immagino,
Java/SWT. Forniremo una versione in bytecode (.jar) e una nativa (ovvero che
funziona senza java) forse (sto discutendo in questi giorni con i ragazzi
di gcj per vedere se è possibile caricare .jar da un programma nativo).
Post by Ivan Marcialisma sarà una cosa simile a zMud
nel senso che andrà bene per tutti i MUD e bisogna configurare miliardi
di trigger/alias/buttons etc oppure sarà pesante configurato in
relazione al MUD che si utilizza, quando dico pesantemente intendo piu
di quanto si possa fare con un bel file di configurazione di zMud
Guarda, Hydra è una mia creatura posso dire e, sebbene dagli screenshot che
puoi notare sul forum non si veda, ha grosse potenzialità.
Funziona anche lui a moduli (plugins nel suo caso) che ci permettono quindi
di avere un client flessibile e che trova la sua unica limitazione nella
dipendenza dalla grammatica XML (Il sistema di comunicazione che usa è XML,
la sintassi del linguaggio è gestita dai plugin, ma la costruzione del
linguaggio deve essere fatta con l'XML).
Quindi direi che lo si può vedere come uno zMud dei mud che useranno
mythwaves.
Post by Ivan Marcialis4) Ci sarà grafica? se si dove?
Dipenderà dai plugin. Per i plugin di default ci sarà sicuramente molta più
grafica di quanta se ne vede solitamente, ma ogni inserimento grafico lo
consideriamo in relazione a quanto cattura l'attenzione del giocatore (lo
fa un grafico che lavora con noi) e siccome vogliamo che, di base,
Mythwaves sia una suite per MUD, stiamo stando ben attenti a ragionare la
grafica solo come contorno per il testo, e non viceversa :)
Comunque usando le SWT potenzialmente ci potrebbe essere qualsiasi tipo di
grafica, anche sviluppata usando le opengl.
Post by Ivan Marcialis5) Non ho trovato (pardon) nulla su MyCoS, sarà totalmente trasparente
per l'utente immagino e il client si occupa di parsare l'xml che arriva
dal server in modo che sia leggibile per l'utente e si occupa anche di
tradurre in xml quanto comanda l'utente? Faccio esempio per capire se
[...]
State facendo una cosa simile?
Ci siamo distaccati completamente da telnet, e usiamo l'xml solo perché è
più facile sviluppare una grammatica flessibile. Anche MyCoS andrà a
plugin, ovviamente. Essenzialmente direi che puoi immaginarti una cosa del
tipo:
MyCoS -> fornisce la grammatica base
Se si vuole l'oggetto lista, si installa sul server il modulo
"mycoslist" (che usa, per esempio, il tag <list>).
Alla connessione del client il server invierà qualcosa del tipo:
<requested tags="to,ping,list"/>
Il client controllerà se ha dei plugin appropriati, e se non li ha mostrerà
una finestra di dialogo che chiederà all'utente se desidera scaricarli dal
web.
Cose come il comando guarda saranno "futili" perché il server manterrà
costantemente aggiornate tutte le informazioni (lista dei pg nella stanza,
lista oggetti, etc.)
Post by Ivan MarcialisSe si, quali controlli lasciate al server
Per terra c'e' l'oggetto che ha id 1234, un baule, molto grande e
pesante. L'XML che spedite ha le info solo sul nome dell'oggetto e se
l'utente cerca di prenderlo fa una nuova richiesta al server che checka
se puo' sollevarlo o meno oppure lato clinet sono salvate (in uno dei
tanti modi conosciuti per renderle prottete ???) le info relative al PG
e al BAULE (le cui caratteristiche di peso e forma vengono spedite dal
server al client la prima volta che il pg vede l'oggetto) e il clinet
controlla se può sollevarlo o meno?
Avevamo pensato ad un approccio simile ma l'abbiamo abbandonato. Più il
client è intelligente, più ci saranno problemi di sicurezza sul server (un
plugin fatto male potrebbe mostrare all'utente informazioni che non vanno
mostrate). Stiamo tentando di mantenere il client il più stupido possibile.
Post by Ivan Marcialis6) Avete qualcosa di scaricabile e installabile? Mi basterebbe un
qualcosa con due stanze e 2 comandi per fare le prime prove con quelle
che sono le mie idee di clinet.
Per il 1° Marzo (forse non proprio il 1°, manca meno di una settimana e
siamo con l'acqua alla gola, quindi magari il 2 o il 3, comunque intorno ad
inizio marzo) abbiamo pianificato il primo test di gruppo per il progetto
EposOnline. Il test consisterà in un tour guidato all'interno di una villa
orientata su 3 piani, con tanto di oggetti.
Per allora sicuramente il client non avrà un bell'aspetto, ma penso
funzionerà.
Di nulla
--
Nicola 'GaWaiNe' Racco