MARTINUS!!! Che piacere!!! Mi mancano i tuoi nuke ingame!!!
Vado con ordine sperando che la vena polemica non si accenda piu' del dovuto.
Martinus ha scritto:Rispondo brevemente e generalmente, non riguardo all'argomento, ma al modo di fare.
Come hai gia' detto Mizar:
Fate vobis, come qualcuno piu' di una volta ha ricordato, il mud non e' una democrazia..
Ma questo non vuol dire che tutto quello che si propone passa direttamente nel cestino.
Potrebbe essere utile classificare le proposte in termini di "codificabilita'" e "impatto di bilanciamento": questo darebbe una misura a chi propone di quanto si e' "sulla strada giusta" per avere dei modelli di proposta che rendano le operazioni di screening e testing piu' veloci ed efficienti, poi ovvio che dipenda dalla disponibilita' degli implementor prendersi quelle 2 orette per scrivere le procedure.
Martinus ha scritto:Ti diro cosa puo succedere e ti daro anche un'esempio.
1) Non sempre gli implementor al momento della proposta hanno tempo e/o voglia di implementare quello che si propone. Magari hanno anche un'elenco lungo di bug da sistemare e/o altre cose nella coda delle implementazioni.
Non discuto sulle priorita' di debug rispetto a nuove implementazioni, ma la fase di instabilita' l'abbiamo superata da tanto mi pare..
Martinus ha scritto:2) Non e' che lo facciamo cosi tanto per dire, per quel motivo ho creato la sezione proposte interessanti, per ricordarci noi delle cose che ci sono piaciute, e per dare ai player che hanno proposto un feedback. Se vai a vedere quella sezione ci sono comunque cose non implementate ancora, ci sono cose che sono state riadattate e implementate etc etc.
Che dire.. i mob "freccer" del lab sono stati ideati a partire da una mia proposta quando esploravo altri OLG, in particolar modo la classe arciere e l'abilita' "scatter" (colpo fisico ad area). Quindi non metto indubbio la capacita' di adattare possibili migliorie al codice attuale di TS.
Martinus ha scritto:Ti faro anche un'esempio concreto, per una cosa che tu stesso hai proposto qualche tempo fa'.
Nel codice del tester e' presente la nuova versione del "charge" con cariche multiple e altre belle cosine.
Al tempo avevo detto pisc... stavo praticamente smettendo di codare, e cosi a occhio sembrava una modifica abbastanza consistente per il modo in cui era stato implementato il charge. Poi 1 mese fa' tipo l'ho rivisto con calma, ne ho discusso con nis e zaken, e alla fine si e' implementato, ed era meno complicato di quello che si credeva.
Ma e' proprio quello che dico io! Non capisco perche' a fronte di proposte "obbiettivamente" realizzabili sia in termini di tempo, che di difficolta', che di bilanciamento i tempi di attuazione si dilatino a dismisura (il rolling decap implica la modifica del valore lag_post_action da 3 a 0.2, non serve mica un anno di coding). Da sempre il mud e' ritrovo di programmatori di vario genere, e le "risorse umane" per buttare giu' bozze di codice sono l'unica cosa che e' sempre abbondata su TS. I player PWP sono gli stessi che hanno strutturato il loro gioco sulle procedure esistenti, ottimizzando la resa dei propri pg. Come sappiamo tutti, siamo arrivati ad un punto in cui alcuni PG sono stati trasformati in un contro-codice per le azioni ripetitive in cui il divertimento tende a 0. Non vedo perche' il rapporto tra player e admin debba essere necessariamente conflttuale piuttosto che collaborativo. Se gli implementor sono "occupati" e qualcosa di "carino" puo' essere implementato a breve termine, perche' non attingere dal potenziale dei PG stessi?
Martinus ha scritto:Quindi... pazienza. Non fatevi prendere dall'euforia della proposta nuova. Ogni cosa ha la sua importanza e avra il tempo che merita al momento oportuno.
Permettimi di precisare che il "tempo che merita" e "momento opportuno" sono 2 variabili dell'ottica admin. Per i player e' tutta un'altra cosa. Se le modifiche sul charge fossero state analizzate ai tempi, magari TS avrebbe il doppio della popolazione attuale. Questo non fa di voi dei cattivi implementor, ma sicuramente avete ampio margine di miglioramento sulle "tempistiche" di implementazione. Era chiaro sin da allora che la modifica non avrebbe richiesto 2 anni per l'implementazione, ma i PISC non hanno avuto certo un'effetto invogliante per gli utenti, o mi sbaglio? Le analisi fatte nel corso degli anni, anche in maniera tecnica con numeri alla mano, non sono state fatte per portare acqua al mulino di druidi, sorci o chierici in particolare, ma per evidenziare i buchi di gameplay.
Quando mi venne in mente la "frammentazione", la prima cosa che feci e' chiedere a qualcuno piu' esperto di me nel coding se e cosa fosse attuabile. Nello specifico esposi la cosa a Nis e Zaken, che mi risposero "Seeeeeeeeeeeeee". Non mi scandalizzai, mi rendevo gia' all'ideazione che a livello di codice avrebbe richiesto PARECCHIO sbattimento, ma il detto dice "chi comincia e' gia' a meta' dell'opera", per cui mi rivolsi qualche gradino piu' sotto a Venus. Esposi la mia idea e pur non essendo chiarissima, con parecchi buchi concettuali, e chiesi di buttar giu' una bozza di implementazione (che trovate sempre in sezione OT). Ora io ci capisco pochissimo di codice, ma non credo che quel papello sia completamente inattuabile o inadattabile. Se ci si pensa bene sono tutte sfumature di gameplay che gia' esistono nel gioco, si tratta solo di raggrupparle in maniera differente per tirare fuori skill o classi nuove. E di certo non avrei mai presteso che la cosa passasse in blocco, ho passato tempo sufficiente sul mud (cosi' come in RL) per capire da solo che gli aggiustamenti sono necessari SEMPRE. Quello che indispone e' il NO a prescindere, senza nemmeno dare la possibilita' di uno screening. Ai tempi chiedemmo una porzione del obj_DB in modo da sgravare un po' di lavoro dalle spalle degli implementor, fare qualche media, e fare delle correzioni base alle procedure in quesione. Quello che sto cercando di dire, e' che se in termini di tempo una cosa non e' fattibile ad 1 persona, si puo' "commissionare" parte del lavoro a chi di tempo ne avrebbe. L'ultima parola e le modifiche finali spetterebbero comunque ai gestori, e i "coder a progetto" tornerebbero volentieri a fare i player una volta conclusa la nuova implementazione, che in fondo e' la stessa cosa che avviene per gli AB ad un livello piu' basso.