[PROG] Codice base su cui poter iniziare

Salve a tutti, volevo presentarvi un codice per Mud a mio avviso molto interessante e dal quale si potrebbe partire per arrivare allo scopo di questo progetto (ovvero un Mud personalizzabile).

Nome: CoffeeMud.

Vantaggi:
1) Scritto completamente in Java. Questo ci permette di legarlo a pagine Web dinamiche, Client,etc. (fino al Prolog).
2) Come scritto sopra, il sistema di base ha gia' un interfaccia grafica via browser web che permette di personalizzare il mud in ogni sua forma, dal db utenti alle aree/mob presenti, script, quest, uso della memoria... (tutto dinamicamente/run time).
3) Creato per essere un codice generico (quindi abbiamo una base anche x il mondo futuristico)
4) Per gli script uso di JavaScript (x chi lo conosce e' molto potente e non vincola il programmatore).
5) Gestione connessioni avanzata. Strumenti x rintracciare gli ip, account multipli etc. Possibilita' di scegliere tra creazione utente normale o tramite email.
6) Semplicita' nella programmazione. Ho esaminato il codice a fondo e modellato e vi posso dire che esiste finalmente un codice CHIARO.
7) Aggancio del mud in modo semplice a diversi tipi di DB (anche possibilita' di non usare DB, ma semplici files x chi non ne avesse la possibilita').
Uso dei piu' recenti protocolli x la trasmissione di informazioni e multimedia. ANSI colour, MSP sound support, MXP tag, MCCP compression).
9)SMTP server per email, mailing lists, annunci vari, e invio passwords.
10) Possibilita' di importare qualsiasi tipo di Area gia' costruita con altri editor x altri mud (ROM, Circle, Smaug, Icey, e altri).
11) Parsing del testo.
12) Quest automatiche (a tempo, random, personalizzate, stile Cluedo etc.)
13) Classi personalizzabili (si puo' scegliere se multiclasse attivi, oppure classi speciali, etc etc.)
14) Clan pienamente supportati (e altre cose simili come Fazioni etc). Gia' pronto anche il codice x i clan per edificare, governare territori, impostare tasse, e dichiarare guerra ad altri clan (con diversi modi ...anche giochi stile capture the flag).
15) Carrozze, Navi , Tank in cui entrare etc.
16) Supporto per l'intermud (non ricordo bene il nome ora...ma la possibilita' di aprire un canale tra mud con lo stesso codice -->ottimo x questo progetto)
17) Tanto altro....ma non ho piu' tempo x scriverlo!


Svantaggi:
1) Per ora attualmente disponibile solo in inglese.
2) Uso piu' pesante delle risorse HW (se si desidera caricare i web services+SMTP+mud)


Link: http://coffeemud.homeip.net/guides/Features.html

ottimo nick suggerirei a JJ, Hensky, Pra di darci un'occhiata cosi magari si inizia a fare qualche cosa di interessante

Ho analizzato un po' il codice, in modo inesperto perchè conosco poco java, e ho compreso che è strettamente legato al concetto di classe/skill/livello inoltre ha i soliti limiti come i maghi che possono usare solo vestiti di tela.
La configurabilità è prossima allo 0 se si vuole fare qualcosa di diverso, esempio un sistema skill-based. O anche class-based ma con skill non strettamente vincolate.
Altra cosa il ruling (ovvero la meccanica) non è modulare, il mud è studiato per funzionare in un certo modo, e cambiare il ruling implica cambiamenti che inducono per forza a problemi vari in giro per il codice. Cambiare per esempio il numero di uscite ha gli stessi problemi che si potrebbero avere con un codice circle.
La struttura base invece è modulare, db, connessioni, chat, intermud ecc... Quindi potrebbe essere un'ottima base su cui implementare un sistema di ruling più versatile e configurabile, basato su file (o db che sia) e non hardcoded. Che è proprio il nostro obiettivo.

JJ

Jumping Jack ha scritto:Ho analizzato un po' il codice, in modo inesperto perchè conosco poco java, e ho compreso che è strettamente legato al concetto di classe/skill/livello inoltre ha i soliti limiti come i maghi che possono usare solo vestiti di tela.
La configurabilità è prossima allo 0 se si vuole fare qualcosa di diverso, esempio un sistema skill-based. O anche class-based ma con skill non strettamente vincolate.
Altra cosa il ruling (ovvero la meccanica) non è modulare, il mud è studiato per funzionare in un certo modo, e cambiare il ruling implica cambiamenti che inducono per forza a problemi vari in giro per il codice. Cambiare per esempio il numero di uscite ha gli stessi problemi che si potrebbero avere con un codice circle.
La struttura base invece è modulare, db, connessioni, chat, intermud ecc... Quindi potrebbe essere un'ottima base su cui implementare un sistema di ruling più versatile e configurabile, basato su file (o db che sia) e non hardcoded. Che è proprio il nostro obiettivo.

JJ

io qui ragazzi non ci metto becco l'unica cosa importante credo sia però iniziare che sia da una base o da una cosa nuova biosgna iniziare a metter le basi

Jumping Jack ha scritto:
Ho analizzato un po' il codice, in modo inesperto perchè conosco poco java, e ho compreso che è strettamente legato al concetto di classe/skill/livello inoltre ha i soliti limiti come i maghi che possono usare solo vestiti di tela.

E' una linea di codice quella a cui ti riferisci. Immediatamente sostituibile o configurabile
Anzi, si puo' modificare l'intera classe (e crearne di nuove) in modo abbastanza intuitivo.

Jumping Jack ha scritto:
La configurabilità è prossima allo 0 se si vuole fare qualcosa di diverso, esempio un sistema skill-based. O anche class-based ma con skill non strettamente vincolate.

Manca l'1 davanti allo zero eheh. C'e' gia' tutto. Basta modificare in questo caso un file txt per avere sistemi senza classi, con classi, con multiclasse, con classi specializzate. Le skill stessa storia. Addirittura le skill possono essere insegnate anche da pg a pg .

Jumping Jack ha scritto:
Altra cosa il ruling (ovvero la meccanica) non è modulare, il mud è studiato per funzionare in un certo modo, e cambiare il ruling implica cambiamenti che inducono per forza a problemi vari in giro per il codice. Cambiare per esempio il numero di uscite ha gli stessi problemi che si potrebbero avere con un codice circle.

Sempre nel file txt a cui ti accennavo prima ti chiede di impostare il numero di uscite (6 o 10), la dimensione del "cielo"...etc.

Jumping Jack ha scritto:
La struttura base invece è modulare, db, connessioni, chat, intermud ecc... Quindi potrebbe essere un'ottima base su cui implementare un sistema di ruling più versatile e configurabile, basato su file (o db che sia) e non hardcoded. Che è proprio il nostro obiettivo.
JJ

Qui invece mi trovi d'accordo!


morale: Tranquillo si puo' fare tutto

Scusa eh ma se io leggo questa linea di codice

CMLib.ableMapper().addCharAbilityMapping(ID(),13,"Fighter_WeaponBreak",true);

seguita da una marea di altre con altri nomi di skill, capisco che assegna una skill ad un certo livello di una certa classe.
Quindi la definizioni delle classi è hardcoded. O no?

Quale è il file txt con la configurazione?

Le uscire appunto sono ristrette da 6 a 10...

E poi anche le weapons c'è un file java per ogni weapons... Questa non è configurabilità.

Il progetto a me sembra studiato in certo modo e espandibile in una certa direzione, certo se mi dimostri il contrario allora posso capire come si possa utilizzare per un core versatile, ma al momento lo vedo buono, e molto buono, solo per quello che è stato detto.

JJ

Jumping Jack ha scritto:Scusa eh ma se io leggo questa linea di codice

CMLib.ableMapper().addCharAbilityMapping(ID(),13,"Fighter_WeaponBreak",true);

seguita da una marea di altre con altri nomi di skill, capisco che assegna una skill ad un certo livello di una certa classe.
Quindi la definizioni delle classi è hardcoded. O no?

Come vedi l'associazione va reperita da una "libreria" che puo' essere facilmente modificata (ed eventualmente spostata su file txt x essere modificate dall'utente finale). Non capisco cosa c'e' che non puoi fare. Se vuoi puoi impostare una skill a qualunque classe (o a quella di default in caso di sistema senza classi). Naturalmente qualche piccola modifica se vuoi ottenere un prodotto COMPLETAMENTE configurabile va effettuata.

Jumping Jack ha scritto:
Quale è il file txt con la configurazione?

Subito nella cartella principale trovi un file .ini in cui vedi subito che ci sono tutte le opzioni modificabili. (scusa non ho il codice sottomano ora)

Jumping Jack ha scritto:
Le uscire appunto sono ristrette da 6 a 10...

Ehm...quante ne vorresti? Dopo che hai messo "n/s/w/e/u/d" + "nw/ne/sw/..." + tutte le eventuali uscite alternative (tipo "una buca", "portali magici" ...) non me ne vengono altre in mente!

Jumping Jack ha scritto:
E poi anche le weapons c'è un file java per ogni weapons... Questa non è configurabilità.

per ora e' stato impostato cosi' , ma si puo' trasformare anche in un DB. Il fatto di avere questo schema e' ottimo per l'eredita'. Si crea una spada base e poi ogni mud specifico la puo' modificare se non piace e in 2 secondi creare tutte le lame simili (spadini/spada 2 mani...).

Jumping Jack ha scritto:
Il progetto a me sembra studiato in certo modo e espandibile in una certa direzione, certo se mi dimostri il contrario allora posso capire come si possa utilizzare per un core versatile, ma al momento lo vedo buono, e molto buono, solo per quello che è stato detto.
JJ

Ok son sempre qui a rispondere alle domande, e sono curioso di sapere i commenti anche da parte degli altri, se hanno avuto domande simili o diverse.

Si può fare un sistema skill in questo modo: (ovviamente opzionale e senza scombussolare il codice, ma solo con piccole modifiche)
Le skill sono definite da un nome, un valore di difficoltà, xp base, xp attuali e livello.
Gli xp di una skill crescono in real time basandosi su una caratteristica del personaggio (esempio intelligenza).
Quando gli xp raggiungolo un certo valore determinato dagli xp base, dalla difficoltà e dal livello attuale, la skill sale di livello.
Per avere una skill è necessario studiare il libro (che fornisce la skill al livello 0), e avere i prerequisiti che sono altre skill ad un dato livello.
Ogni skill quando sale di livello, può dare un bonus ad un qualcosa.

Il file di configurazione l'ho trovato, è effettivamente molto versatile per certe cose, ma non ci sono praticamente opzioni sul sistema class/skill/level, quindi mi conferma la prima impressione in cui è fortemente legato a questo sistema. Per il resto direi che ci sono molte altre cose che invece sarebbero già fatte per il keeper core.

Le uscite devono essere variabili.
Se voglio fare una stanza con 4 uscite a nord, 4 a est, 4 a ovest e 4 a sud? Faccio un quadrato di 16 stanze? No...
Se voglio usare una base esagonale, tipo wargame?
Se voglio entrare in un mob? Oppure in un oggetto?

A proposito di questo...
E' possibile con il codice attuale mettere un mob dentro un oggetto?
Un pg dentro un mob?
Un mob dentro un pg?
Gestire in modo indifferente pg e mob?
Far combattere un oggetto?
Far combattere una stanza?
Mettere una stanza dentro un mob?
Se si il codice è versatile, se no è stretto...

JJ

Se vuoi pure il caffe', non lo fa

A tutto c'e' un limite...e' un codice, non IL codice definitivo per tutto. Quando ci saranno dei paletti, degli obiettivi da raggiungere, sara' anche piu' chiaro se il codice puo' essere adatto allo scopo. Sinceramente vedo ancora molte discussioni, ma pochi obiettivi da ottenere messi nero su bianco.

Per quanto riguarda l'ultimo messaggio, il codice allo stato attuale riesce a fare tutto tranne la stanza dentro il mob (almeno penso non si possa ancora fare). Pg dentro mob , viceversa, pg dentro oggetti...e' tutto plausibile.

Bene, allora vuole dire che ci sono anche altre parti molto interessanti nel codice.

Sul mettere nero su bianco cosa fare hai ragione, ci sono tante cose scritte ma niente di effettivamente utile per poter partire in modo concreto. Il discorso è che queste basi di partenza dovrebbero metterle proprio i programmatori, perchè anche se io o qualcun'altro dice che una cosa va fatta COSi', poi ai programmatori non piace, questa non viene fatta, questo perchè i programmatori non sono pagati :P:P

Chi è disposto a lavorare al keeper core, indipendentemente che si parta da 0 o da un core già fatto?

Cosa ne pensate di coffeemud?

Cosa è basilare e cosa importante in un codice mud?

JJ

Da quanto ho letto vi han brasato i post vecchi dal forum, quindi vado prendere il resto del post cum grano salis

Da quanto ho capito vorreste fare un motore generico per mud. Per quanto l'idea mi trovasse decisamente entusiasta anni fa, quando l'impegno mio e di Bardolfo porto' alla scrittura del PaGanMUD come progetto open source, al momento non lo trovo un progetto interessante, ne' utile.
Questo per vari motivi:
1: ci sono altri 3000 mud open source, ognuno con stle ed architettura diversa. Se volete paciugare senza toccare toppo codice, prendete uno smaug o un LP e rimuovete o togliete quel che vi serve. Se e' ancora troppo e sapete scrivere codice, partite da un messaging framework o da un game programming framework e aggiungete i pezzi che vi mancano. La vita e' troppo breve per reinventare la ruota ogni volta.
2: avete tutti idee diverse su cosa vi serve nel progetto. Programmi che fanno tutto o costano un sacco e sono complessi da mantenere, o lo fanno molto male. Piuttosto partite come da punto 1 sopra e, se il design e' fatto bene, quasi basta aggiungere le librerie opzionali che servono.
3: e' decisamente molto piu' complesso, dal punto di vista dello sviluppatore, scrivere sistemi flessibili e modificabili senza sapere per cosa verranno usati, che scrivere un sistema cui le specifiche son complete. scrivere un sistema generico inoltre e' rimosso all'obiettivo finale, cioe' scrivere un MOG: cio' causa problemi non solo a livello di che features implementare (ovvero in che direzione far andare il progetto), ma anche che features lasciare fuori e verificare che le features siano corrette (non dico senza bug, dico "conformi alle aspettative").
4: tornando sulle aspettative, ognuno di voi ha aspettative diverse, ed e' perfettamente normale. Mettersi daccordo non sarebbe male, ma lo vedo improbabile.



Se proprio volete un consiglio, e volete farlo, cominciate a decidere il minimo indispensabile che serve a tutti, poi fate un prototipo, e iterate. Documentate cosa fa ogni prototipo cosi' a ogni iterazione avete un deliverable che puo' essere usato.

Non ho riletto il messaggio prima di postare e vivo all'estero da anni, quindi e' pieno di errori

Non ti conosco, ma ti quoto in toto.

Razor ha scritto:Da quanto ho letto vi han brasato i post vecchi dal forum, quindi vado prendere il resto del post cum grano salis

Da quanto ho capito vorreste fare un motore generico per mud. Per quanto l'idea mi trovasse decisamente entusiasta anni fa, quando l'impegno mio e di Bardolfo porto' alla scrittura del PaGanMUD come progetto open source, al momento non lo trovo un progetto interessante, ne' utile.
Questo per vari motivi:
1: ci sono altri 3000 mud open source, ognuno con stle ed architettura diversa. Se volete paciugare senza toccare toppo codice, prendete uno smaug o un LP e rimuovete o togliete quel che vi serve. Se e' ancora troppo e sapete scrivere codice, partite da un messaging framework o da un game programming framework e aggiungete i pezzi che vi mancano. La vita e' troppo breve per reinventare la ruota ogni volta.
2: avete tutti idee diverse su cosa vi serve nel progetto. Programmi che fanno tutto o costano un sacco e sono complessi da mantenere, o lo fanno molto male. Piuttosto partite come da punto 1 sopra e, se il design e' fatto bene, quasi basta aggiungere le librerie opzionali che servono.
3: e' decisamente molto piu' complesso, dal punto di vista dello sviluppatore, scrivere sistemi flessibili e modificabili senza sapere per cosa verranno usati, che scrivere un sistema cui le specifiche son complete. scrivere un sistema generico inoltre e' rimosso all'obiettivo finale, cioe' scrivere un MOG: cio' causa problemi non solo a livello di che features implementare (ovvero in che direzione far andare il progetto), ma anche che features lasciare fuori e verificare che le features siano corrette (non dico senza bug, dico "conformi alle aspettative").
4: tornando sulle aspettative, ognuno di voi ha aspettative diverse, ed e' perfettamente normale. Mettersi daccordo non sarebbe male, ma lo vedo improbabile.



Se proprio volete un consiglio, e volete farlo, cominciate a decidere il minimo indispensabile che serve a tutti, poi fate un prototipo, e iterate. Documentate cosa fa ogni prototipo cosi' a ogni iterazione avete un deliverable che puo' essere usato.

ciao Razor felice di vederti sul nostro forum sono anche io in linea di principio daccordo con quanto dici partire da qualche cosa è sicuramente una buona idea, come dici tu reinventare la ruota ogni volta è una gran perdita di tempo specialmente quando si può partire da tanti validi progetti di base.

Razor ha scritto:Documentate cosa fa ogni prototipo cosi' a ogni iterazione avete un deliverable che puo' essere usato.

Di documentare nessuno ne ha ancora parlato, ma è molto importante, invece questa cosa viene di solito tralasciata nella scena muddistica (e non solo). In un progetto di questo tipo è assolutamente vitale.

JJ

Jumping Jack ha scritto:

Razor ha scritto:Documentate cosa fa ogni prototipo cosi' a ogni iterazione avete un deliverable che puo' essere usato.

Di documentare nessuno ne ha ancora parlato, ma è molto importante, invece questa cosa viene di solito tralasciata nella scena muddistica (e non solo). In un progetto di questo tipo è assolutamente vitale.

JJ

allora ragazzi il nuovo anno è iniziato chi c'e' ed ha tempo batta un colpo! bisogna iniziare a lavorare su questo progetto!

Io ci sono, con ancora meno tempo di prima; come priorità ho da ristabilizzare la situazione economica
Ma ci sono come leader e coordinatore, con piena libertà di scelta della base di sviluppo da parte di chi programmerà il codice, certo che chi vuole farlo deve essere più attivo di adesso, molto di più.

JJ

Toc!


A dicembre mi sono laureato, ora ho iniziato la specialistica. Sto facendo un piccolo progetto da consegnare per un esame di grafica, OpenGL e qualcosa delle DirectX. Fatto questo, avrò un po' di tempo libero.

Parpacak ha scritto:Toc!


A dicembre mi sono laureato, ora ho iniziato la specialistica. Sto facendo un piccolo progetto da consegnare per un esame di grafica, OpenGL e qualcosa delle DirectX. Fatto questo, avrò un po' di tempo libero.

Grats Parpack
ROTFL
...Scrivo anche in italiano

Complimenti per la laurea.

Mi fai poi vedere il progetto, sono sempre stato molto interessato alle OpenGL ma non ho mai approfondito solo diverse sessioni di studio e qualche programmazione.

JJ

Si ti farò vedere il progetto.
Sto cercando di fare un piccolo piano di gioco in 3D, formato da 15x15 caselle quadrate su cui verranno applicate delle texture. Le difficoltà le sto incontrando per la visualizzazione del personaggio, rappresentato da una immagine in 2D, che si muove nella scena. Non so come far rendere bene le sprite in un ambiente 3D, dovrebbero essere continuamente ortogonali alla "telecamera", anche in seguito a rotazioni della scena. Quando avrò qualche immagine vi farò vedere.
Buon weekend, alla prossima settimana.

Non sono pratico di queste cose, pero' per come hai accennato al problema mi verrebbe di consigliarti:

1) Il pg puo' essere espresso da 6 immagini 2D (una presa da ogni lato, una di fronte, una da dietro, una dal basso, una dall'alto)
2) Registrare, per il pg, lo stato di una direzione rispetto alla griglia del terreno (ovvero verso dove "guarda" il pg).

A quel punto, facendo un po' di combinazioni, potrai muovere la telecamera avendo il pg orientato nel modo corretto.


Ciao e mi aggiungo a JJ sul fatto che la tesi sia veramente interessante!

Nickewen/Nicolas

Questo progetto riguarda solo un esame di grafica, non la tesi di laurea, quella l'ho fatta su tutt'altra cosa.
Più o meno ci hai azzeccato, ma il problema non è quello, il personaggio sarà formato da delle sprite 2D che lo visualizzano da diverse angolazioni.
Il problema è che devo far visualizzare, in un terreno 3D, un rettangolo 2D sempre orientato verso la telecamera, ovvero che sia sempre perpendicolarmente al punto di vista, anche se quest'ultimo si muove e cambia angolo di visualizzazione.
Il risultato a cui punto è qualcosa di simile (non a questi livelli di grafica T__T , ma per lo meno riprodurne circa il funzionamento):


Mentre queste sono le sprite dei personaggi:
http://www.bghq.com/fft/Archer_M.PNG


PS.
Se non avete mai giocato a FFT (per ps1, non quelli per ds) ve lo consiglio.
Uno dei migliori giochi a cui abbia mai giocato. *___*

Parpacak ha scritto:Questo progetto riguarda solo un esame di grafica, non la tesi di laurea, quella l'ho fatta su tutt'altra cosa.
Più o meno ci hai azzeccato, ma il problema non è quello, il personaggio sarà formato da delle sprite 2D che lo visualizzano da diverse angolazioni.
Il problema è che devo far visualizzare, in un terreno 3D, un rettangolo 2D sempre orientato verso la telecamera, ovvero che sia sempre perpendicolarmente al punto di vista, anche se quest'ultimo si muove e cambia angolo di visualizzazione.
Il risultato a cui punto è qualcosa di simile (non a questi livelli di grafica T__T , ma per lo meno riprodurne circa il funzionamento):


Mentre queste sono le sprite dei personaggi:
http://www.bghq.com/fft/Archer_M.PNG


PS.
Se non avete mai giocato a FFT (per ps1, non quelli per ds) ve lo consiglio.
Uno dei migliori giochi a cui abbia mai giocato. *___*

scusa la mia ignoranza io non so programmare ma so fare grafica 3d... ora perche usi un disegno per ogni angolazione?!? non ha senso è uno sreco di tempo nella realizzazione.

in genere in 3dstudio si fa una sorta di mapping, dove si crea un modello 2d frontale e un modello 3d sul quale si applicana una sprite di base, poi è lo stesso 3dstudio a smemrarlo come meglio crede e a generare le ombre "statiche" che il modello avrà.

per intenderci una cosa cosi:
http://www.animationartist.com/2000/Tutorials/Alice/Alice.html

Alla fin fine, è una scelta.
Perchè il punto di vista ha delle posizioni fisse (4), non lo posso nè ruotare nè alzare/abbassare di quanto voglio, segue i punti cardinali dall'alto. Quindi creare un modello 3D sarebbe sprecato, verrebbe visualizzato da solo 4 punti di vista.
Dedicando un'immagine per angolazione dovrei disegnare solo 4 immagini del personaggio, considerando che a coppie risultano essere simmetriche: in totale disegno solo 2 immagini.



Ho fatto qualche prova, ho notato che ottengo un risultato migliore, senza dover "stretchare" l'immagine in altezza o larghezza.
Il tutto per il fatto che mi risulta più facile, a livello di programmazione, disegnare sullo schermo un rettangolo ed applicarci una sprite 2D (magari pure che cambia immagine nel tempo per simulare un'animazione), inoltre, nonostante sappia come creare oggetti 3D, non sono capace di creare un modello da zero di un personaggio.
Io praticamente non so disegnare.

Parpacak ha scritto:Alla fin fine, è una scelta.
Perchè il punto di vista ha delle posizioni fisse (4), non lo posso nè ruotare nè alzare/abbassare di quanto voglio, segue i punti cardinali dall'alto. Quindi creare un modello 3D sarebbe sprecato, verrebbe visualizzato da solo 4 punti di vista.
Dedicando un'immagine per angolazione dovrei disegnare solo 4 immagini del personaggio, considerando che a coppie risultano essere simmetriche: in totale disegno solo 2 immagini.



Ho fatto qualche prova, ho notato che ottengo un risultato migliore, senza dover "stretchare" l'immagine in altezza o larghezza.
Il tutto per il fatto che mi risulta più facile, a livello di programmazione, disegnare sullo schermo un rettangolo ed applicarci una sprite 2D (magari pure che cambia immagine nel tempo per simulare un'animazione), inoltre, nonostante sappia come creare oggetti 3D, non sono capace di creare un modello da zero di un personaggio.
Io praticamente non so disegnare.

La soluzione che si usa per quello che vuoi fare è proprio il rettangolo, quindi hai la soluzione giusta.
Per i modelli 3d ti consiglio di provare Poser (è eccezionale).

JJ