Apro questa discussione per chiacchierare un po', anche perche' non ho nessuna intenzione di scrivere un nuovo mud (sto benissimo dove sto e ho abbastanza lavoro da riempire le mie giornate in allegria tutti i giorni)

Ma girando qui e li, anche e soprattutto in forum in inglese, ho notato che la proliferazione di mud continua (very well) e che molti si accingono a creare mud nuovi da zero (o da basi iniziali instabili, incomplete o comunque da riscrivere).
C'e' chi si appoggia al C/C++ chi intraprende la strada del Java, chi invece si affida al Python...

Ma qual e' il miglior linguaggio (tutto considerato) per scrivere un mud?
La domanda potrebbe sembrare superficiale, dato che la risposta chiaramente dipende da cosa ci si deve fare, le condizioni al contorno, ecc... Per cui andrebbe forse meglio interpretata come:
Quali sono i vantaggi e gli svantaggi nell'applicare i diversi linguaggi di programmazione al mondo muddico? Chiaramente parliamo solo del lato server.

Personalmente io ho avuto un approccio ai mud con il C, per derivazione da Smaug e affini, linguaggio al quale sono affezionato, dalle enormi potenzialita' sotto il punto di vista della velocita', performance, stabilita'. Cio' non toglie che il C non e' un linguaggio ad oggetti, nella sua struttura procedurale puo' avere delle limitazioni in confronto ad un linguaggio piu' recente.

Sono curioso di sentire le vostre opinioni, per integrarle con le mie

In verità mi verrebbe da rispondere pragmaticamente: "usa il linguaggio che conosci meglio e con cui ti trovi a tuo agio": inutile andare a pescare pesci in un lago che non conosci se la pozza che conosci te ne dà sempre in abbondanza. Ovviamente devi essere sicuro che quel linguaggio tu lo conosca molto bene, il che significa il più delle volte aver progettato un programma complesso e di grandi dimensioni, perché un mud questo è.

In seconda battuta posso risponderti più tecnicamente: ci sono sì delle caratteristiche che, nella mia esperienza nei mud (con il C e con il Python), possono giovare allo sviluppo e manutenibilità di un codice Mud:
- gestione automatica della memoria
- potenza sulla manipolazione sulle stringhe
- programmazione ad oggetti? (mh.. opzionale)

Riguardo al primo punto un linguaggio che abbia un garbage collector o altra implementazione della gestione automatica della memoria fa molto perché ti permette di lasciar perdere un problema meramente tecnico dalla soluzione che devi di volta in volta implementare per far funzionare i vari pezzi, semplificando il lavoro e diminuendo i tempi di sviluppo.

Riguardo il secondo punto beh, un mud è fatto sostanzialmente di stringhe, confronti tra stringhe di qua, print su video con codici telnet di là, buffer di qui.. insomma escono dalle pareti! Un linguaggio che abbia una buona base sulla gestione delle stringhe non è quindi una cosa da buttare, tuttaltro!

Il terzo punto: la programmazione ad oggetti è buona cosa, ma si possono fare cose adeguate anche con il buon vecchio paradigma strutturale oppure, perché no?, funzionale (se si utilizza un linguaggio funzionale puro non ci si deve più preoccupare dei memory leak).
E' anche vero che a creare un mud viene giustamente naturale pensare ad oggetti, soprattutto riguardo alle entità del gioco; tuttavia ultimamente preferisco un approcio misto anche orientato ai componenti:
http://it.wikipedia.org/wiki/Ereditarie ... riet.C3.A0




Io ho avuto esperienze sia con il C che con il Python, e mi sono trovato nettamente meglio con il secondo e sono convinto che mi troverò (quasi) altrettanto bene quando il mio mud avrà il doppio delle linee di codice, vedremo...
Ma cosa intendi per stabilità del C?

Comunque tornando con il mio lato pragmatico alla fin fine la questione si può riassumere così:
- il mud è un gioco, giocare significa divertirsi e se i giocatori si divertono: machissenefrega se il codice è scritto così e cosa e con questo linguaggio piuttosto che un altro...
- tuttavia quando programmi il tuo mud ogni tanto fatti la domanda: "il linguaggio con cui programmo mi rende la vita facile ad implementare ogni volta i vari pezzi?" Se sì tutto bene! Se no.. beh, dipende: poca conoscenza del linguaggio? Linguaggio scelto che si adatta male al proprio pensiero? Scelte di design sbagliate che rallentano lo sviluppo e la crescita del mud? etc etc..

Le due parole chiave sono quindi: "divertimento" e "agilità"

Vero, ma facciamo finta che il grado di conoscenza del linguaggio sia un aspetto secondario, dato che facciamo questo discorso in astratto



Hai ragione mi sono espresso male. Stavo pensando al fatto che il C e' stato usato e riusato miliardi di volte dalla sua nascita, molto piu' che non altri linguaggi piu' recenti... Ma la stabilita' di un codice dipende in effetti solo da chi lo scrive.

Riguardo al tuo approccio con il Python, mi sono sempre chiesto: ma il delegare certi meccanismi al garbage collector, o al gestore di stringhe, o ad altri complessi componenti strutturali "invisibili", non rischia di rallentare l'esecuzione del codice stesso?
Queste componenti sono state scritte ed ottimizzate per essere massimamente efficienti in condizioni "genericamente favorevoli". Di certo si possono trovare situazioni in cui scrivendo a mano la deallocazione di una certa parte di memoria (ad esempio) si rende quella parte di codice piu' efficente che non lasciando il tutto in mano al GC.
Probabilmente poi in un mud queste condizioni non si verificano mai, oppure troppo raramente per influire nella velocita' del gioco, ma il dubbio viene... cosi' come il dubbio che l'interpretazione del codice non compilato abbia un certo peso nella velocita' effettiva di ogni game_loop.

Sono assolutamente concorde con il beneficio della velocita' di scrittura. Ma se rallentare il coding del doppio (ad esempio) risulta nel velocizzare il gioco del 10%... chi non sceglierebbe questa alternativa?

Divertimento e agilita'. Assolutamnete daccordo!
Ed e' proprio per il fatto che il lavoro di un coder e' apprezzato dai giocatori che non sanno e non gli interesssa il linguaggio che sta dietro tutto cio', che si potrebbe parlare di linguaggio/i ideale/i a seconda del risultato visibile, indipendentemente dallo sforzo programmativo per tirarlo su

Vediamo anche gli altri cosa ne pensano

Sì, in effetti c'è una larga base di codice C per i Mud non da sottovalutare, anche se troppo spesso poco originali e ripetitivi. Io stesso scelsi lo Smaug anni fa come codice base perché c'era già pronta molta roba, però devo dire a posteriori che probabilmente il tempo di sviluppo che avre speso con lo smaug per implementare le cose che sto implementando e che implementerò con il Python, sarà maggiore nonostante abbia iniziato da zero con un mud in Python, e sono abbastanza convinto di ciò.



Vero, python è meno performante del C, dipende dai casi, ma così a naso direi di 10 volte nei miei utilizzi, tuttavia dipende quanto uno se la gioca con i colli di bottiglia che ha, prima scrivi il codice, poi lo profili e poi ne migliori le parti e solo quelle che fanno da collo di bottiglia con algoritmi intelligenti e meccanismi furbi.
Il python ha delle built-in che sono compilate in puro C, utilizzando solo quelle ed evitando chiamate a funzione (che oihmé sono la croce sulle performance dei programmi python in generale) arrivi a velocità comparabili a quelle del C, ovviamente il tutto ciò a discapito della leggibilità e manutenibilità del codice.
Per esempio ho dovuto evitare di utilizzare una funzione con del codice utilizzato più volte in varie parti per motivi di performance, pena: manutenibilità e leggibilità.
[Per completezza aggiungo che il python usa un garbage collector a reference counting, che è più veloce rispetto a soluzioni cicliche; che utilizza delle pool di memoria suddivise per tipologia di dato, queste zone di memoria sono già allocate, quindi se uno crea una nuova stringa essa va ad inseririsi in una di queste zone pronte all'uso, diminuendo il problema di performance di allocazione; infine il python non è interpretato ma semicompilato, proprio come il Java. Insomma ha le sue tecniche interne furbe per essere performante]

Tuttavia devo dire che il consumo di processore di Aarit, il mio mud in Python, non mi preoccupa troppo, invece il consumo della ram sta già raggiungendo livelli interessanti.
Sul server su cui gira la versione che ho rilasciato in open source il processore occupava il 15%, la versione attuale con tante aggiunte ora occupa slo il 9%, questo perché la versione rilasciata non l'avevo mai ottimizzata.
Ho sempre avuto un po' di paura che il mud risultasse lento e ho sempre fatto scelte di caching, di memorizzazione e di memoization per velocizzare il tutto.. e infatti ho esagerato.. avviando il mud da zero già occupa 50 mega, ed è tanto, il mud è appena agli inizi e deve fare un mucchio di cose, vedrò cosa potrò inventarmi, ma sono fiducioso, ho già il mente qualche trucchetto e refactoring.



Sì, ma secondo me il gioco non ne vale la candela, cioè è come studiare un manuale tecnico in lingua straniera, se sei bravo con quella lingua, te la cavi, ma se non sei bravo la comprensione del manuale ne risente, e magari non poco.
Cosa simile è l'utilizzo di un linguaggio di programmazione piuttosto di un altro, se vuoi utilizzarne uno di basso livello, cioè uno meno vicino all'astrazione umana, dovrai perdere tempo a pensare a tutte quelle cose tecniche in più (come l'allocazione della memoria e la relativa pulizia) e, a meno che tu non sia bravo bravo, ciò influenzerà sulla soluzione implementata.



In effetti una comunicazione tcp di solito ci mette di più di qualsiasi esecuzione di comando. Riguardo invece alla game loop la trovo una soluzione per certi versi obsoleta e concettualmente errata, tuttavia anche io la utilizzo, per semplicità implementativa, rispetto ad una sistema ad eventi (anche se mi sto spostando in quella direzione).
Difatti la game loop è uno dei miei colli di bottiglia: vi eseguo dei check sui reset, poiché ho i reset a tempo che scattano ad una certa ora rpg, ciclare su tutti i reset delle aree del mud ogni secondo rpg (due secondi reali) quando ben pochi di tali reset si attiverano.. è demoniaco..

Ma alla fin fine, come ho detto all'inizio, di meccanismi furbi se ne possono trovare, per esempio: se si crea una lista di mob, popolata man mano durante il ferimento degli stessi (e che quindi abbisognino di update per ripristinare la salute), il controllo ciclico di tale lista "probabilmente" ha un tempo di esecuzione minore rispetto al controllo cicliclo su tutti i mob del mud, il cui 90% sarà in perfetta salute. So che non è così semplice ed è solo un'ipotesi, però...



Ma assolutamente non la sceglierei! E' come chiedermi tra scegliere una macchina che va' a 100 all'ora ed una che va' a 110 all'ora che mi costa il doppio, magari anche più figa eh... Ma...
Cioè.. io personalmente codo 4 volte più velocemente in python che in C, non è sparata lì', ho fatto dei confronti con alcuni pezzi di codice di Mud che ho scritto in C e la translazione in python (verò è anche che ora ho tutta un'esperienza alle spalle.. ma è anche verò che sto implementando da zero alcune cose).
Ecco, ora cosa significa esattamente 4 volte? Significa che io in un anno scrivo un codice con le stesse feature che un coder in C con le mie stesse capacità scrive in 4 anni.
Facciamo che questo codice in C consumi metà risorse, sia processore che memoria.
Ora facciamo caso che io, che ho scritto il mud in python, upgradi il mio server per andare il doppio, quando spendo all'anno? Ok, facciamo 200 euro al posto di 100?
Ora direi che 200 euro * 4 anni < costo di 3 anni della propria vita spesi in coding per un Mud (supponiamo tante ore)
A meno che uno non scriva il mud perché gli piaccia scriverlo in C eh.. per soddisfazione personale, a quel punto ok, il costo dei tre anni si autoammortizza. Tuttavia in quel caso creare un mud non è l'unico, o non lo è affatto, obiettivo.


Considerazioni personali eh.. poi uno può essere due volte più veloce a scrivere in C rispetto a me con il Python e vabbe'.. il punto di vista cambia.
Quello che però ti vorrei far notare è che la tua frase "[...] Ma se rallentare il coding del doppio (ad esempio) risulta nel velocizzare il gioco del 10%... chi non sceglierebbe questa alternativa?" è squisitamente da C-ista, cioè del: performance a tutti i costi; ne riconosco il sapore perché anch'io la pensavo come te.

Concordo. Dovessi mai scrivere un mud nuovo ricomincerei sicuramente da zero. Il tempo di debug dura anni anche in corso di gioco, le nuove idee che entrano per dare un po' di originalita' smontano mano mano tutto il pregresso... con un buon progetto si riscrive tutto in brevissimo tempo unit-test compresi...


Buono, devo dire che non sono mai entrato in profondita' nell'esplorare il python. Ho letto come funziona, com'e' la sintassi, ma non ho mai fatto un "vero" programma in python.
Il fatto che sia semicompilato (come il java o come il c#) lo rende di certo piu' veloce di un interpretato normale ma e' comunque piu' lento di un compilato secco.
Le parti in C danno di sicuro quella miglioria di performance nei punti critici, quindi riesco a credere facilmente che le prestazioni sono ottimali in ogni caso.


Beh "tanto" e' sempre relativo. Su una macchina dedicata a fare da server per il mud, 50 mega sono una bazzecola
Poi cio' che influisce tanto sulla ram sono le aree, i mob, gli oggetti... non so come hai scelto di gestire (se da db o altro) i dati, ma immagino che "finche' si riesce a fare un caching di tutti i dati da utilizzare" sia la miglior risposta all'interrogativo "latenza di lettura su disco"
Ma non voglio "costringerti" a parlare della struttura interna del tuo mud (non sono qui a fare spionaggio ) quindi laciamo il discorso nelle sue linee generali.



Concordo, ormai e' risaputo che un evento occupa meno risorse che non fare un check continuo su tutti gli "oggetti" per vedere il loro cambiamento di stato...
E' interessante come in programmazione sia tanto cambiata la mentalita' negli ultimi 20 anni ma noi utilizziamo sempre gli stessi strumenti di allora



Rimanendo dell'idea che un evento sia meglio, creare liste su liste alla fine porta anche i suoi problemi... e' facile attraversare la linea che separa la lista inutile da quella necessaria.. con conseguente sovrabbondanza di informazioni e di memoria. Detto questo non trovo scorretto limitare i cicli ai soli mob che si sono segnalati come "da controllare" per qualsiasi motivo.


Beh , probabilmente hai ragione
Anche se nel mondo del lavoro io utilizzo il C#, la "forma mentis" da C-ista mi fa sempre buttare un occhio sulle prestazioni

Bhe non è che ci sia poi quel gran segreto visto che alcune versioni dl codice di Aarit sono in open source

Visto che tu ci lavori, quali potrebbero essere i pro e i contro di un mud fatto in C#?

Uhm...
Direi che molte delle cose che hai detto per il python si possono applicare anche al C#.

Di certo c'e' la facilita' di scrittura, compresa la complessa gestione delle stringhe;
c'e' la struttura ad oggetti che per un mud (come giustamente facevi notare) calza a pennello;
c'e' l'accesso ai dati nativo, sia verso un database che verso files xml, che aiuta moltissimo nel recupero delle informazioni senza dover programmare tutta l'interfaccia di formattazione;
c'e' il Garbage Collector che pulisce la memoria cercando di non appesantire gli altri processi;
c'e' la gestione dei Thread sincroni ed asincroni, e la gestione ad eventi di cui abbiamo accennato;
Il framework e' pieno di librerie di classi per ogni evenienza, lo scambio di informazioni sulla rete e' gestito da un paio di chiamate banali...
I lati positivi sono piu' o meno sempre gli stessi, in linea generale.
Le stesse cose che si potrebbero dire anche del Java.

La differenza del c# (rispetto al Java ad esempio) e' che permette anche la scrittura di codice a basso livello, dalla gestione dei puntatori alla scrittura di codice IL, liddove si vuole una gestione piu' "personalizzata" della memoria (a proprio rischio e pericolo), e chiaramente anche qui la possibilita' di inglobare elementi COM scritti in C/C++
Ulteriormente si possono chiamare esplicitamente i distruttori e forzare o inibire l'azione del GC.

Devo ammettere che il C# e' fin'ora il mio linguaggio preferito, ma non voglio fare discorsi soggettivi
I lati negativi che vedrei nell'utilizzo del C# per scrivere un mud sta proprio nelle stesse sua possibilita':
da una parte infatti abbiamo parato di multithreading, ma quindi dovremmo parlare anche di processi thread-safe... bisognerebbe evitare che piu' processi agiscano contemporaneamente sulle stesse variabili.
La gestione "manuale" della memoria e' rischiosa e non ci sono molti testi che spiegano come programmare il linguaggio intermedio.
Come si diceva in precedenza non mi fiderei molto del GC, il che mi potrerebbe via mooolto piu' tempo a programmare inibizioni dello stesso, piuttosto che godere delle sue facilitazioni.

Inoltre c'e' da dire che nonostante il C# sia virtualmente cross-platform, ad oggi l'unica societa'che ha puntato nello sviluppo e' stata la microsoft. Non c'e' da stupirsi quindi che C# e' diventato un po' una seconda veste di windows.... Certo, esiste il progetto MONO, ma di MONO mi fido poco
Non ho ancora visto girare dei progetti ad ampio respiro sul framework MONO, sincramente mi permetto ancora di dubitare della bonta' di quel framework riscritto (in termini di prestazioni si intende).
Di certo il framework MONO e' comodo per fare applicazioni semplici in C# si linnux o mac/os (ad esempio un buon client per mud, come quello che sto scrivendo dedicato ad ADdE), ma pe run server che "serva" un centinaio di utenti... hmmm e' rischioso.
Per cui un mud scritto in C# necessiterebbe di un server Windows... e quindi il costo comincia a salire... e se il mud e' fatto da persone come noi che lo fanno per hobby o comuqnue non a scopo di lucro, mantenere un windows server non e' proprio il massimo.... e non contemplo neppure l'utilizzo di macchine virtuali (magari pure crakkate)

Mi piacerebbe vedere come gira un mud scritto in C# anche se, riassumendo i lati negativi, forse come "effort" di programmazione siamo allo stesso livello di un C (se si vuole fare le cose perbenino) e come costi siamo ben sopra
Come risultato di questa spesa di energie, rispetto ad uno s.m.a.u.g. classico sarebbe forse paragonabile se non superiore (mettendoci in mezzo gli eventi e il multithreading), anche se c'e' sempre da considerare il lato della semicompilazione che seppure ottimizzata non puo' rivaleggiare con i cugini compilati

Ah volevo aggiungere... rispetto all'eventuale utilizzo di un database per il mud:
Io sarei decisamente favorevole.