[FEATURES] Il Sistema Locazioni Wild e Unità di riferimento e Descrizioni

Dipende da che gioco vuoi sul mud, JJ.

Se si basa sulla "competizione", che sia contro altri pg o contro il server (ammazzare mob o risolvere quest a "enigmi" che sia), allora hai ragione.

Ma se sviluppi più un gioco di interazione, più stile da chat gdr, dove contano le "storie" che si intrecciano tra i pg, allora servono giocatori che stiano insieme.

Non a caso, negli rpimud i "mondi" rappresentati sul server sono zone relativamente piccole, a volte addirittura solo una singola città con varie etnie di pg, e un po' di campagna e "interland" intorno.

Non solo, il nuovo giocatore impara anche guardando gli altri.

Ciononostante, concordo che uno debba poter giocare pure da solo, se gli va e/o se non c'è nessuno online.

Maan ha scritto:Dipende da che gioco vuoi sul mud, JJ.

Se si basa sulla "competizione", che sia contro altri pg o contro il server (ammazzare mob o risolvere quest a "enigmi" che sia), allora hai ragione.

Ma se sviluppi più un gioco di interazione, più stile da chat gdr, dove contano le "storie" che si intrecciano tra i pg, allora servono giocatori che stiano insieme.

Non a caso, negli rpimud i "mondi" rappresentati sul server sono zone relativamente piccole, a volte addirittura solo una singola città con varie etnie di pg, e un po' di campagna e "interland" intorno.

Non solo, il nuovo giocatore impara anche guardando gli altri.

Ciononostante, concordo che uno debba poter giocare pure da solo, se gli va e/o se non c'è nessuno online.

si analisi corretta diciamo che di base il mondo deve essere giocabile anche da soli (ci sono realtà dove ad es gli oggetti si possono solo fabbricare e se c'e' mancanza di pg la cosa è drammatica) ecco specialmente nelle fasi iniziali di un mud sono situazioni controproducenti in quanto allontanano i player ancor più di un mud con 10000 città.

Maan ha scritto:Dipende da che gioco vuoi sul mud, JJ.

Se si basa sulla "competizione", che sia contro altri pg o contro il server (ammazzare mob o risolvere quest a "enigmi" che sia), allora hai ragione.

Ma se sviluppi più un gioco di interazione, più stile da chat gdr, dove contano le "storie" che si intrecciano tra i pg, allora servono giocatori che stiano insieme.

Non a caso, negli rpimud i "mondi" rappresentati sul server sono zone relativamente piccole, a volte addirittura solo una singola città con varie etnie di pg, e un po' di campagna e "interland" intorno.

Non solo, il nuovo giocatore impara anche guardando gli altri.

Ciononostante, concordo che uno debba poter giocare pure da solo, se gli va e/o se non c'è nessuno online.

Un mud rpi comunque è un'altra tipologia di gioco, e comunque ristretto a pochi appassionati. Non dico che il discorso vada escluso, ma è senzaltro da tenere in considerazione in modo limitato, non è di certo l'obiettivo. Questo ovviamente a mio parere. Io sono dell'idea di fare un sistema che permetta di giocare a tante persone. E soprattutto di fare un sistema che stia su da solo senza l'obbligo di uno staff che stia dietro. Poi oguno può essere libero di adattarlo a cosa crede.
Comunque la strada giusta è permettere di fare 100 città poi se uno vuole farne una sola è sua scelta. Di certo sviluppare per una sola città impedisce di fatto la possibilità di crearne 100...

JJ

Jumping Jack ha scritto:

Maan ha scritto:Dipende da che gioco vuoi sul mud, JJ.

Se si basa sulla "competizione", che sia contro altri pg o contro il server (ammazzare mob o risolvere quest a "enigmi" che sia), allora hai ragione.

Ma se sviluppi più un gioco di interazione, più stile da chat gdr, dove contano le "storie" che si intrecciano tra i pg, allora servono giocatori che stiano insieme.

Non a caso, negli rpimud i "mondi" rappresentati sul server sono zone relativamente piccole, a volte addirittura solo una singola città con varie etnie di pg, e un po' di campagna e "interland" intorno.

Non solo, il nuovo giocatore impara anche guardando gli altri.

Ciononostante, concordo che uno debba poter giocare pure da solo, se gli va e/o se non c'è nessuno online.

Un mud rpi comunque è un'altra tipologia di gioco, e comunque ristretto a pochi appassionati. Non dico che il discorso vada escluso, ma è senzaltro da tenere in considerazione in modo limitato, non è di certo l'obiettivo. Questo ovviamente a mio parere. Io sono dell'idea di fare un sistema che permetta di giocare a tante persone. E soprattutto di fare un sistema che stia su da solo senza l'obbligo di uno staff che stia dietro. Poi oguno può essere libero di adattarlo a cosa crede.
Comunque la strada giusta è permettere di fare 100 città poi se uno vuole farne una sola è sua scelta. Di certo sviluppare per una sola città impedisce di fatto la possibilità di crearne 100...

JJ

si si infatti diciamo che il discorso è sempre una di quelle features on/off che dovremo prevedere (o meglio questa è proprio una scelta di creazione del mondo e del bg del mondo).

Gadda ha scritto:
si si infatti diciamo che il discorso è sempre una di quelle features on/off che dovremo prevedere (o meglio questa è proprio una scelta di creazione del mondo e del bg del mondo).

Appunto è strettamente legato al master, non alla programmazione, essendo cose che necessitano solitamente di poca programmazione, eccetto alcune funzioni che comunque si vuole implementare.
Dobbiamo puntare sulla versatilità della wild. E' in fondo l'elemento più caratterizzante, perchè una wild mal fatta è una palla al piede per qualunque mud vi si sviluppi sopra.

JJ

Ho visto sugli rpimud hanno un concetto di "zone" all'interno della classica room.

Ad esempio, all'interno della room ci sono zone tipo "centro room" "verso est" "verso ovest" "verso nord" "verso sud" "verso il basso" "verso l'alto", per usare le classiche sei direzioni.
Con questo sistema, se io arrivo da ovest mi trovo nella sotto-zona "verso ovest": posso ascoltare chiaramente solo chi sta lì, se uno digita al volo "attacca" (usando armi da corpo a corpo) da un'altra sotto-zona perde un round per avvicinarsi, ecc.
Se dalla sotto-zona "verso ovest" mi spostassi a ovest, uscirei subito dalla room.
Qualunque altra direzione mi porta, invece, alla sotto-zona "centro room"; da qui, un'ulteriore comando di direzione mi porta nella sotto-zona relativa (ad es., un comando "nord" mi porta alla sotto-zona "verso nord"; da qui, dando di nuovo "nord" uscirei dalla room, diretto a nord).

Altro sistema è mettere invece dei "punti di riferimento" all'interno della room.
Ad esempio, un oggetto "La montagna PincoPallo" oppure "una macchia di alberi" o "una radura nella foresta".
In questo caso esiste una sotto-zona "generica" e una serie di sotto-zone per ogni punto di riferimento presente. Per cui un pg entra nella "zona generica" e poi può avvicinarsi alla "zona radura", "zona montagna", ecc. Anche gli oggetti lasciati vengono messi nelle giuste sotto-zone, e il movimento, il combattimento, gli esprimi/parlato sono influenzati dalla sotto-zona.
Utile per la wild, il sistema vale anche per le stanze cittadine che rappresentano grandi dimensioni: una locanda potrebbe avere punti di riferimento come "tra i tavoli", "al bancone", "sotto al palco", ecc.

Il problema diventa probabilmente la "raffigurazione" sul client. Magari si vede chiaramente solo ciò che c'è nella propria sotto-zona (mob, pg, oggetti) e nelle altre si nota solo "c'è qualcuno vicino al bancone" oppure "senti rumori di conversazione sotto al palco".

Altro problema, più serio, è la possibile poca intuitività di questo sistema per chi entra la prima volta. Nessun mud italiano ha mai usato queste "sotto-zone", che io sappia. Potrebbe confondere un po'.

Saltando di palo in frasca, altra cosa a cui pensavo, invece, è se sia utile un sistema "realistico" di rappresentazione dello spazio, o se non possa tornare più utile e flessibile un sistema più astratto.
Ad esempio, nei vecchi mud tipo i diku puoi collegare le uscite di due caselle teoricamente lontanissime, oppure creare mappe illogiche (a est vai da A a B, ma se torni a ovest invece che tornare in A finisci in R).

Questo modo "libero" di poter organizzare le cose potrebbe avere più senso rispetto al solito "casellario" alla TG e simili.
Ad esempio, permette di infilare un "passaggio segreto" in una casa senza che il metagamer possa guardare da fuori di quante caselle è fatta la casa e quindi farsi i conti di quante room ci siano all'interno (a quel punto, se manca qualche casella è ovvio che debba esserci qualche passaggio nascosto ).

Altra possibile idea, quella di mettere link ipertestuali al posto delle direzioni.
Non più est, nord, basso, ecc., ma nomi convenzionali. Dopotutto, quando cammino per una città non è che abbia ben presente se sto andando verso una certa direzione cardinale!
Quindi che so, una room rappresentante una strada cittadina mi darebbe come uscite possibili:

La Via dei Mercanti prosegue verso una grande piazza Un imponente portone da accesso ad una casa signorile [chiuso] Una scala in pietra conduce a una piccola porta [chiuso] Un bel colonnato sostiene un portico Una via laterale si diparte da qui La Via dei Mercanti termina davanti alla Porta Maggiore

...questo sistema darebbe totale libertà nel costruire il mondo, e per di più permetterebbe di aggiungere nuovi "collegamenti" perchè non si sarebbe limitati dalle direzioni cardinali previste.
Se voglio aggiungere una nuova casa su una certa via, mi basta mettere un nuovo accesso ("Una porta di legno conduce a un'abitazione bla bla bla") che porterà all'ingresso della nuova casa.
Permette anche di prevedere accessi da finestre, comignoli o quant'altro.

Idee sparse, come al solito...

Maan ha scritto:Ho visto sugli rpimud hanno un concetto di "zone" all'interno della classica room.

Ad esempio, all'interno della room ci sono zone tipo "centro room" "verso est" "verso ovest" "verso nord" "verso sud" "verso il basso" "verso l'alto", per usare le classiche sei direzioni.
Con questo sistema, se io arrivo da ovest mi trovo nella sotto-zona "verso ovest": posso ascoltare chiaramente solo chi sta lì, se uno digita al volo "attacca" (usando armi da corpo a corpo) da un'altra sotto-zona perde un round per avvicinarsi, ecc.
Se dalla sotto-zona "verso ovest" mi spostassi a ovest, uscirei subito dalla room.
Qualunque altra direzione mi porta, invece, alla sotto-zona "centro room"; da qui, un'ulteriore comando di direzione mi porta nella sotto-zona relativa (ad es., un comando "nord" mi porta alla sotto-zona "verso nord"; da qui, dando di nuovo "nord" uscirei dalla room, diretto a nord).

Altro sistema è mettere invece dei "punti di riferimento" all'interno della room.
Ad esempio, un oggetto "La montagna PincoPallo" oppure "una macchia di alberi" o "una radura nella foresta".
In questo caso esiste una sotto-zona "generica" e una serie di sotto-zone per ogni punto di riferimento presente. Per cui un pg entra nella "zona generica" e poi può avvicinarsi alla "zona radura", "zona montagna", ecc. Anche gli oggetti lasciati vengono messi nelle giuste sotto-zone, e il movimento, il combattimento, gli esprimi/parlato sono influenzati dalla sotto-zona.
Utile per la wild, il sistema vale anche per le stanze cittadine che rappresentano grandi dimensioni: una locanda potrebbe avere punti di riferimento come "tra i tavoli", "al bancone", "sotto al palco", ecc.

Il problema diventa probabilmente la "raffigurazione" sul client. Magari si vede chiaramente solo ciò che c'è nella propria sotto-zona (mob, pg, oggetti) e nelle altre si nota solo "c'è qualcuno vicino al bancone" oppure "senti rumori di conversazione sotto al palco".

Altro problema, più serio, è la possibile poca intuitività di questo sistema per chi entra la prima volta. Nessun mud italiano ha mai usato queste "sotto-zone", che io sappia. Potrebbe confondere un po'.

Saltando di palo in frasca, altra cosa a cui pensavo, invece, è se sia utile un sistema "realistico" di rappresentazione dello spazio, o se non possa tornare più utile e flessibile un sistema più astratto.
Ad esempio, nei vecchi mud tipo i diku puoi collegare le uscite di due caselle teoricamente lontanissime, oppure creare mappe illogiche (a est vai da A a B, ma se torni a ovest invece che tornare in A finisci in R).

Questo modo "libero" di poter organizzare le cose potrebbe avere più senso rispetto al solito "casellario" alla TG e simili.
Ad esempio, permette di infilare un "passaggio segreto" in una casa senza che il metagamer possa guardare da fuori di quante caselle è fatta la casa e quindi farsi i conti di quante room ci siano all'interno (a quel punto, se manca qualche casella è ovvio che debba esserci qualche passaggio nascosto ).

Altra possibile idea, quella di mettere link ipertestuali al posto delle direzioni.
Non più est, nord, basso, ecc., ma nomi convenzionali. Dopotutto, quando cammino per una città non è che abbia ben presente se sto andando verso una certa direzione cardinale!
Quindi che so, una room rappresentante una strada cittadina mi darebbe come uscite possibili:

La Via dei Mercanti prosegue verso una grande piazza Un imponente portone da accesso ad una casa signorile [chiuso] Una scala in pietra conduce a una piccola porta [chiuso] Un bel colonnato sostiene un portico Una via laterale si diparte da qui La Via dei Mercanti termina davanti alla Porta Maggiore

...questo sistema darebbe totale libertà nel costruire il mondo, e per di più permetterebbe di aggiungere nuovi "collegamenti" perchè non si sarebbe limitati dalle direzioni cardinali previste.
Se voglio aggiungere una nuova casa su una certa via, mi basta mettere un nuovo accesso ("Una porta di legno conduce a un'abitazione bla bla bla") che porterà all'ingresso della nuova casa.
Permette anche di prevedere accessi da finestre, comignoli o quant'altro.

Idee sparse, come al solito...

ma guarda è una cosa su cui ho ragionato parecchio anche io, secondo me una delle poche versioni percorribili è quella di scavalcare il concetto di "casella" per gli spostamenti del player ma di utilizzare il concetto di area.

Ossia determinare un'area di caselle che rispondono a determinate caratteristiche (es descrizione, clima, tempo, fisicità) all'interno delle quali si è cmq liberi di muoversi ed interagire.

ma il problema grosso secondo me non è tanto la "stanza" a se ma l'interazione/distanza tra le componenti della stessa e di chi la abita e il suo livello di astrazione.

dobbiamo a mio avviso valutare la possibilità che in una cella non stia più di un pg/mob ma che in un'area ci possano invece essere più pg/mob
in questo modo avremo:
visualizzazione stringhe di testo normali da stanza anche se i pg sono racchiusi nell'area.
visualizzazione di testi speciali a seconda della distanza (es urla o sussurra)
visualizzazione di azioni normali come in una stanza
visualizzazione azioni speciali (es azioni in modalità furtiva) filtrate dalla distanza
interazione con i pg/mob/oggetti solo a contatto [caselle limitrofe] o a distanza ove possibile (es lanciare oggetti).

Nel sistema di wild a più livelli (dimensioni della casella) che avevo descritto consideravo implicito la possibilità di muoversi su di un certo livello. Come muoversi all'interno di una stanza, oppure in una piazza, o girozolare per il prato invece di attraversarlo.
I link al posto delle direzioni sono impliciti in tutti i mud con i portali rinominabili. Per esempio in DDD puoi creare un'uscita verso una qualunque altra room con un nome qualunque (esempio buco nel muro, tronco cavo, pozzo, baule, mettere 8 porte nella stessa parete ecc...) e questa uscita speciale è materialmente un semplice portale.
Un buon sistema è quello di creare una lista di uscite per ogni stanza, questa lista di uscite è comprensiva sia delle uscite classiche che le uscite speciali, in questo modo i trigger e altri parametri di movimento valgono per tutte le uscite senza dover gestire casi particolari.
Altra cosa il movimento tra zone wide (esempio in campo aperto) non necessariamente deve essere un salto tra room distanti, per esepio se io do nord e mi muovo di 1km con un solo comando il server mi fa passare attraverso tutte le 2000 room di 50cm che ci sono, e si ferma solo se è necessario, altrimenti non vedo niente. Fatto così non bisogna preoccuparsi di fare cose strane per "intercettare un pg" con un mob che difende un campo per esempio, ma la cosa avverrà in modo automatico. Come il classico "run" che ti fa skippare i mob, questo non è corretto che avvenga, non del tutto almeno.

Riguardo al discorso dei link astratti è un po' una scelta... Ovvero se metti la wild per forza ti tagli le gambe da quel punto di vista, hai ancora piccole possibilità ma perdi tantissimo nel concetto di disorientamento e "illogica".
Personalmente preferisco un mud senza wild, ma con aree fatte bene (che purtroppo è cosa rara). Immaginarsi lo spazio, invece che vederlo è più "realistico".

JJ

Jumping Jack ha scritto:Riguardo al discorso dei link astratti è un po' una scelta... Ovvero se metti la wild per forza ti tagli le gambe da quel punto di vista, hai ancora piccole possibilità ma perdi tantissimo nel concetto di disorientamento e "illogica".
Personalmente preferisco un mud senza wild, ma con aree fatte bene (che purtroppo è cosa rara). Immaginarsi lo spazio, invece che vederlo è più "realistico".

JJ

Si, è quello che intendevo...
Preferisco una "rappresentazione" plausibile, giocabile, bella da vedere, ecc... a una molto "realistica" ma che si dimostra poco pratica.
Paradossalmente, vedo che per esperienza l'esasperare la componente di "realismo" di fatto rende le cose meno immersive, oltre che meno divertenti.

E sono d'accordo anche sul fatto che la maggior parte delle pecche di molti mud siano nel building più che nel codice.
Esempio, a che pro una wild enorme di caselle tutte simili e clonate?

Quello che non riesco ancora a "visualizzare" bene è il modo in cui il tutto verrà visto dal giocatore, però...
Insomma, cosa gli appare sul client.

Maan ha scritto:

Jumping Jack ha scritto:Riguardo al discorso dei link astratti è un po' una scelta... Ovvero se metti la wild per forza ti tagli le gambe da quel punto di vista, hai ancora piccole possibilità ma perdi tantissimo nel concetto di disorientamento e "illogica".
Personalmente preferisco un mud senza wild, ma con aree fatte bene (che purtroppo è cosa rara). Immaginarsi lo spazio, invece che vederlo è più "realistico".

JJ

Si, è quello che intendevo...
Preferisco una "rappresentazione" plausibile, giocabile, bella da vedere, ecc... a una molto "realistica" ma che si dimostra poco pratica.
Paradossalmente, vedo che per esperienza l'esasperare la componente di "realismo" di fatto rende le cose meno immersive, oltre che meno divertenti.

E sono d'accordo anche sul fatto che la maggior parte delle pecche di molti mud siano nel building più che nel codice.
Esempio, a che pro una wild enorme di caselle tutte simili e clonate?

Quello che non riesco ancora a "visualizzare" bene è il modo in cui il tutto verrà visto dal giocatore, però...
Insomma, cosa gli appare sul client.

posso esprimere dissenso sulla "nonwild"? trovo che cmq la wild per quanto vuota e ripettiva serva, il lato esplorativo di un mud è sempre un lato importante e anche solo geograficamente è "bello" trovare posti anche vuoti da riempire :)l.....

Gadda ha scritto:
posso esprimere dissenso sulla "nonwild"? trovo che cmq la wild per quanto vuota e ripettiva serva, il lato esplorativo di un mud è sempre un lato importante e anche solo geograficamente è "bello" trovare posti anche vuoti da riempire :)l.....

Si è geograficamente più appagante, ma tra un mud con una wild semivuota e un mud ben fatto senza, il secondo stravince sulla giocabilità alla grande. Certo che se si fa una wild veramente completa, e esiste la possibilità di non usarla, esempio per le gallerie o il movimento in zone "coperte" (campo di grano, foresta nera, acqua ecc.).

JJ

Jumping Jack ha scritto:

Gadda ha scritto:
posso esprimere dissenso sulla "nonwild"? trovo che cmq la wild per quanto vuota e ripettiva serva, il lato esplorativo di un mud è sempre un lato importante e anche solo geograficamente è "bello" trovare posti anche vuoti da riempire :)l.....

Si è geograficamente più appagante, ma tra un mud con una wild semivuota e un mud ben fatto senza, il secondo stravince sulla giocabilità alla grande. Certo che se si fa una wild veramente completa, e esiste la possibilità di non usarla, esempio per le gallerie o il movimento in zone "coperte" (campo di grano, foresta nera, acqua ecc.).

JJ

si jj ma sai cosa infondo noi parliamo di wild e di zone ma quello che dobbiamo riusicre a fare è guardare oltre e pensare ad un sistema unico! dove tutto è wild e tutto può essere zona... non so se mi spiego ma se io ho possibilità in una casella di pianura tra le altre 10 mila che ci sono di scavare un buco piantarci un albero e costruirci una casetta... be le cose si fanno più interessanti... vuol dire che quella casetta la vado a fare in un punto che mi sembra comdo ecc...

Si certo, infatti parlavo di cose che la wild limita, perchè si tratta di una mappa 2d. Purtroppo sono cose che si perdono, cosa che invece non succede tra un mud senza wild, e un mmorpg con grafica 3d. La naturale evoluzione di un mud è il mmorpg, ma la nuova evoluzione è un mud con wild complesso, ricco, profondo, versatile, che è quello a cui dovrebbe pensare questo progetto, tanto che conieremo una nuova definizione.

JJ

Jumping Jack ha scritto:Si certo, infatti parlavo di cose che la wild limita, perchè si tratta di una mappa 2d. Purtroppo sono cose che si perdono, cosa che invece non succede tra un mud senza wild, e un mmorpg con grafica 3d. La naturale evoluzione di un mud è il mmorpg, ma la nuova evoluzione è un mud con wild complesso, ricco, profondo, versatile, che è quello a cui dovrebbe pensare questo progetto, tanto che conieremo una nuova definizione.

JJ

si penso che il punto sia effettivamente quello riuscire a rendere qualche cosa che vada al di la del MMORPG, ossia qualche cosa che non sia solo grafica ma che sia "utilizzabile", "giocabile".