[PROG] Codice base su cui poter iniziare

mattsteel ha scritto:

Jumping Jack ha scritto:In ogni caso se si vuole implementare un sistema multi mud, quindi con meccaniche diverse ma db in comune, coffee mud è assolutamente inadatto.

Sul punto del multi-mud: se l'idea è quella di avere un unico mega-engine in grado di far funzionare numerosi MUD contemporaneamente, allora la sconsiglio: se "cade" il processo del mega-engine si spengono tutti i MUD; forse conviene avere numerose copie (istanze) dello stesso engine (classe) le quali si differenziano per la loro configurazione iniziale (setup).
Inoltre, l'idea di avere un unico istanza di DB in esecuzione va ancora bene: normalmente un database dovrebbe essere più stabile di un MUD.
In ogni caso, sia con un mega-engine sia con delle istanze multiple dell'engine, ciascun MUD dovrebbe usare una connessione al DB dedicata per ciascun MUD.

Jumping Jack ha scritto:Ora bisogna decidere cosa fare, se partire con il progetto di fare un mud interessante e parzialmente versatile (the keeper mud) oppure un sistema totalmente nuovo completamente personalizzabile senza dover toccare il codice (the keeper core).
La strada che seguirei la cercherei in base a chi è interessato a questo sviluppo, sopratto all'interesse dei coder. E soprattutto valutando la difficoltà TKM è facile ma per nulla breve, TKC è estremamente difficile.

Vorrei tentare di estendere l'engine del MUD che ho scritto in Perl in modo da tentare di far funzionare tale engine in modalità mega-engine...

M.

No, non necessariamente il codice deve essere unico, anzi, il codice non deve essere unico, appunto per che non interferiscano eventuali problemi tra i vari server (NB se uno è un deficiente e fa boiate con il suo mudserver, non deve toccare gli altri mudserver) il codice può essere eseguito in più instance oppure utilizzare i thread o entrambi.
Il db server invece deve essere unico, in modo che le risorse siano comuni e interscambiabili facilmente. Ovviamente ognuno con la sua connessione e sui dati privati.
(NB: i codici mud attuali già possono funzionare in questo modo, con l'unica differenza che devono usare directory differenti per i file salvati, non dobbiamo progettare niente di che, semplicemente invece che lavorare su file, si lavora su db con l'aggiunta di comandi di interscambio e, questa è la vera differenza, per cambiare, anche radicalmente, una meccanica di gioco il codice non va toccato, deve essere uguale per tutti).

JJ

Appoggio l' idea di creare un core, da cui i keeper deriveranno i loro mud. Per cui esisteranno n istanze del core in n mud.
Noi forniamo gli alberi e le palline, i keeper li addobbano e si mettono le luci che vogliono, no?

macvart ha scritto:Appoggio l' idea di creare un core, da cui i keeper deriveranno i loro mud. Per cui esisteranno n istanze del core in n mud.
Noi forniamo gli alberi e le palline, i keeper li addobbano e si mettono le luci che vogliono, no?

Ecco il concetto base dovrebbe essere quello

Se poi riusciamo a inserire un sistema di scripting, per tutto quello che si può rendere "intelligente", il server definitivo è fatto

JJ