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

WILD:
Unica wild per rappresentazione sia di interni che di esterni con possibilità di zommare (+/-). Lo zoom offre la possibilità di muovere il pg velocemente all'interno di un numero di caselle proporzionale al livello di zoom (es. in una pianura con zoom -1 il pg si muoverà attraverso 3 caselle in tre caselle con un solo click ovviamente rappresentando cmq le 3 caselle, le loro descrizioni e il loro contenuto).

Unità di Riferimento:
L’unità a mio avviso che svolge meglio questa funzione è quella del modulo umano schematizzato ossia immaginiamoci un cubetto 60x60x60cm o 50x50x50 che in altezza viene moltiplicato per 3.

Queste misure rappresentano indicativamente le dimensioni umane alle quali possiamo abbastanza facilmente riferire ogni altro oggetto/pg/png sul mud.

Ovviamente la problematica maggiore che incontriamo con un sistema di questo genere è la presenza di oggetti ma ancora più problematico di png di dimensioni maggiori ad 1 unità.

Ad esempio un cavallo occuperebbe magari 60x(60+60+60)x(60+60+60), ovviamente questo tipo di oggetto deve essere trattato a sua volta in maniera particolare.

Descrizioni Locazioni
non per tutto ma per il particolare (ossia inutile ripetere informazioni base e ripetitive [vedi terreni, muri ecc...] mentre utile indicare nelle descrizioni le particolarità dei luoghi. Quindi nelle creare delle macroaree o dei macrotipi autodescritti o dagli oggetti inseriti tramite il sistema SDS.
Le Macroaree sono dei raggruppamenti di caselle che sono accumunate da caratteristiche simili (es. temperatura,descrizione,tipologia ecc...) i macrotipi possono essere delle caselle pregenerate (es pianura temperata) oppure creati tramite l'utilizzo di oggetti (sds).

Gadda ha scritto:WILD:
Unica wild per rappresentazione sia di interni che di esterni

Favorevolissimo, appunto perchè volevo applicarlo anche io.

con possibilità di zommare (+/-). Lo zoom offre la possibilità di muovere il pg velocemente all'interno di un numero di caselle proporzionale al livello di zoom (es. in una pianura con zoom -1 il pg si muoverà attraverso 3 caselle in tre caselle con un solo click ovviamente rappresentando cmq le 3 caselle, le loro descrizioni e il loro contenuto).

Unico problema è il movimento.
Per semplicità avevo eliminato lo spostamento di più caselle contemporaneamente. Perchè altrimenti il sistema è un po' confusionario.
Come dovrebbe essere gestito?
Cosa dovrebbero vedere i giocatori durante gli spostamenti, in entrambi gli zoom?

Parpacak ha scritto:
Unico problema è il movimento.
Per semplicità avevo eliminato lo spostamento di più caselle contemporaneamente. Perchè altrimenti il sistema è un po' confusionario.
Come dovrebbe essere gestito?
Cosa dovrebbero vedere i giocatori durante gli spostamenti, in entrambi gli zoom?

questo si forse risulta problematica ma in realtà non è un vero spostamento di più caselle ma solo un dire 3 nord invece che nord nord nord, poi non so bene se potrebbe funzionare o è una vaccata, credo possano essere molto utili i comandi per seguire sentieri, confini e strade o elementi geografici.

ma cmq va pensato qualche cosa perche ovviamente se abbiamo caselle di 50 cm x 50 cm... be vuol dire che se ho una città distante 10 km se non sbaglio i conti sono 20000 caselle!!!!! mi si consuma la tastiera

mi ricordo tg quando si faceva temperia aral che erano un 200 caselle sembrava un'eternità e si parla di ben 2 zero in meno!!!

forse potrebbe essere presa in considerazione l'ipotesi del tenere schiacciato un tasto (es N) continua a muovere il pg verso quella direzione in tempo reale senza lag.

Gadda ha scritto:

Parpacak ha scritto:
Unico problema è il movimento.
Per semplicità avevo eliminato lo spostamento di più caselle contemporaneamente. Perchè altrimenti il sistema è un po' confusionario.
Come dovrebbe essere gestito?
Cosa dovrebbero vedere i giocatori durante gli spostamenti, in entrambi gli zoom?

questo si forse risulta problematica ma in realtà non è un vero spostamento di più caselle ma solo un dire 3 nord invece che nord nord nord, poi non so bene se potrebbe funzionare o è una vaccata, credo possano essere molto utili i comandi per seguire sentieri, confini e strade o elementi geografici.

ma cmq va pensato qualche cosa perche ovviamente se abbiamo caselle di 50 cm x 50 cm... be vuol dire che se ho una città distante 10 km se non sbaglio i conti sono 20000 caselle!!!!! mi si consuma la tastiera

mi ricordo tg quando si faceva temperia aral che erano un 200 caselle sembrava un'eternità e si parla di ben 2 zero in meno!!!

forse potrebbe essere presa in considerazione l'ipotesi del tenere schiacciato un tasto (es N) continua a muovere il pg verso quella direzione in tempo reale senza lag.

Il tenere il tasto premuto è subordinato alla velocità di ripetizione della tastiera, quindi abbastanza orripilante e poi dipendente dal valore che uno ha impostato (cosa che quasi nessuno modifica), ovviare a questo si può, ma bisogna creare un "filtro" per i tasti e non è semplice. (Può sembrare banale, ma premere un tasto genera trigger nei vari form e in windows, se non si evita che questi vengano generati, un tasto tenuto premuto genera lag in tutto il sistema)
E' molto meglio fare comandi per seguire una strada o una certa direzione in modo intelligente, fino a che non si arriva ad una condizione, esempio "segui prato nord" oppure "segui strada sud", il primo caso si ferma quando finisce il prato, il secondo quando incontra un incrocio. Oppure "vai a nord per 10km" o "vai nord fino alle montagne". Comandi così non sono difficili da interpretare, un po' di più da implementare ma non troppo.

JJ

Jumping Jack ha scritto:

Il tenere il tasto premuto è subordinato alla velocità di ripetizione della tastiera, quindi abbastanza orripilante e poi dipendente dal valore che uno ha impostato (cosa che quasi nessuno modifica), ovviare a questo si può, ma bisogna creare un "filtro" per i tasti e non è semplice. (Può sembrare banale, ma premere un tasto genera trigger nei vari form e in windows, se non si evita che questi vengano generati, un tasto tenuto premuto genera lag in tutto il sistema)
E' molto meglio fare comandi per seguire una strada o una certa direzione in modo intelligente, fino a che non si arriva ad una condizione, esempio "segui prato nord" oppure "segui strada sud", il primo caso si ferma quando finisce il prato, il secondo quando incontra un incrocio. Oppure "vai a nord per 10km" o "vai nord fino alle montagne". Comandi così non sono difficili da interpretare, un po' di più da implementare ma non troppo.

JJ

qui secondo me sono strade un po da provare anche io sono per il vai direzione o il vai 10km o il segui fiume ecc... piuttosto che l'usare il tastierino direzionale, un'altra strada interessante potrebbe essere quella del cliccare con il mouse sulla mappa (tra l'altro le caselle visualizzate sulla mappa con una wild cosi sarà decisamente ampia il che non è un problema da poco per chi ha un monitor a bassa risoluzione)

Quello dei viaggi è un problema di scegliere tra due opposti... parlo per discussioni già avute, quindi riassumendo quello che era saltato fuori.

Sostanzialmente, i problemi sono:
- i tempi di viaggio sono forzatamente lunghi, se si vuole fare un mondo anche relativamente piccolo (basta solo una regione italiana, come dimensioni, ed ecco che un viaggio a piedi da una città all'altra diventa forzatamente questione di mezz'ora reale, pure contando che il tempo del mud scorra più veloce);
- se si vuole avere un po' di plausibilità i tempi di spostamento devono essere per forza di cose piuttosto onerosi: sarebbe ridicolo poter spostarsi in cinque secondi da un punto all'altro del mondo di gioco;
- una wild ampia da esplorare è interessante, ma quando si viaggia diventa un problema. Un viaggio non è un'esplorazione, è solo una corveè, una rottura di scatole in cui si butta tot tempo per spostarsi da un punto A a un punto B: questo è il problema essenziale, i viaggi sono obbiettivamente noiosi. Quando ti stai spostando lungo la carovaniera, anche se con altri pg, è difficile anche solo seguire un discorso.

La soluzione più gettonata a questi problemi, dall'alba dei tempi, sono i sistemi di "fast travel" (viaggio veloce).
Alcuni sono resi nel mondo di gioco con trasporti vari: carrozze, navi, carovane, zeppelin, ecc.

Questi sistemi hanno però un problema, che comunque dovrebbero impiegare del tempo; quindi se pure una carrozza impiegasse un quarto del tempo che impiega il pg a piedi per raggiungere una certa città... questo significherebbe comunque che il pg dovrebbe stare tot tempo "fuori gioco" (e manco avrebbe quel blando divertimento che deriva dall'incontro imprevisto durante il viaggio a piedi).

Allora un altro metodo è il fast travel "mistico": cose come il teletrasporto, i portali magici e cose simili.
Questi sistemi, in quanto "portentosi", eliminano del tutto i limiti logici e rendono possibile collegare 2 luoghi di interesse permettendo ai pg di spostarsi istantaneamente.

Il problema qui diventa soprattutto di ambientazione: cose del genere sono molto "high magic", quindi non troppo adatte per ambientazioni che vogliono tenere basso il ricorso al magico e allo straordinario.
Inoltre possono creare vari problemi di coerenza nell'ambientazione: per dire, non esisterebbero più le carovane, se è possibile passare per un'arco che ti porta direttamente a destinazione. E anche le guerre, come sarebbero gestite? Eccetera.

Certo, si possono pensare tanti modi per limitare il ricorso a questi "collegamenti istantanei"... ma anche qui, se vengono limitati troppo poi diventano inutili e si ritorna al punto di partenza.

L'idea di comandi tipo "segui strada" non mi sembra risolva... evita solo di consumare la tastiera, ma i tempi rimangono sostanzialmente simili. E poi si rischia di creare un mondo pieno di "uccelli Bip!Bip!" che sfrecciano lungo le strade...

Altrove si era giunti alla conclusione che i sistemi di fast travel siano l'unico modo per risolvere questo problemi di collegare i punti di "aggregazione di pg" (città, di solito) senza costringere i giocatori a pallosissimi viaggi.

Il problema è tutto nel come giustificare questi sistemi di viaggio veloce nella logica dell'ambientazione. Ma questo diventa un problema inerente al mud creato, secondo me.
In un mud in cui l'intero mondo di gioco riproduca solo una città e i suoi sobborghi, anche un sistema di fast travel rappresentato da carrozze sarebbe sufficientemente plausibile.
Per mondi più ampi diventano necessarie spiegazioni mistiche... starà ai creatori decidere come giustificarle. O se non usarle affatto, e soffrire in nome del realismo

Maan ha scritto:Quello dei viaggi è un problema di scegliere tra due opposti... parlo per discussioni già avute, quindi riassumendo quello che era saltato fuori.

Sostanzialmente, i problemi sono:
- i tempi di viaggio sono forzatamente lunghi, se si vuole fare un mondo anche relativamente piccolo (basta solo una regione italiana, come dimensioni, ed ecco che un viaggio a piedi da una città all'altra diventa forzatamente questione di mezz'ora reale, pure contando che il tempo del mud scorra più veloce);
- se si vuole avere un po' di plausibilità i tempi di spostamento devono essere per forza di cose piuttosto onerosi: sarebbe ridicolo poter spostarsi in cinque secondi da un punto all'altro del mondo di gioco;
- una wild ampia da esplorare è interessante, ma quando si viaggia diventa un problema. Un viaggio non è un'esplorazione, è solo una corveè, una rottura di scatole in cui si butta tot tempo per spostarsi da un punto A a un punto B: questo è il problema essenziale, i viaggi sono obbiettivamente noiosi. Quando ti stai spostando lungo la carovaniera, anche se con altri pg, è difficile anche solo seguire un discorso.

La soluzione più gettonata a questi problemi, dall'alba dei tempi, sono i sistemi di "fast travel" (viaggio veloce).
Alcuni sono resi nel mondo di gioco con trasporti vari: carrozze, navi, carovane, zeppelin, ecc.

Questi sistemi hanno però un problema, che comunque dovrebbero impiegare del tempo; quindi se pure una carrozza impiegasse un quarto del tempo che impiega il pg a piedi per raggiungere una certa città... questo significherebbe comunque che il pg dovrebbe stare tot tempo "fuori gioco" (e manco avrebbe quel blando divertimento che deriva dall'incontro imprevisto durante il viaggio a piedi).

Allora un altro metodo è il fast travel "mistico": cose come il teletrasporto, i portali magici e cose simili.
Questi sistemi, in quanto "portentosi", eliminano del tutto i limiti logici e rendono possibile collegare 2 luoghi di interesse permettendo ai pg di spostarsi istantaneamente.

Il problema qui diventa soprattutto di ambientazione: cose del genere sono molto "high magic", quindi non troppo adatte per ambientazioni che vogliono tenere basso il ricorso al magico e allo straordinario.
Inoltre possono creare vari problemi di coerenza nell'ambientazione: per dire, non esisterebbero più le carovane, se è possibile passare per un'arco che ti porta direttamente a destinazione. E anche le guerre, come sarebbero gestite? Eccetera.

Certo, si possono pensare tanti modi per limitare il ricorso a questi "collegamenti istantanei"... ma anche qui, se vengono limitati troppo poi diventano inutili e si ritorna al punto di partenza.

L'idea di comandi tipo "segui strada" non mi sembra risolva... evita solo di consumare la tastiera, ma i tempi rimangono sostanzialmente simili. E poi si rischia di creare un mondo pieno di "uccelli Bip!Bip!" che sfrecciano lungo le strade...

Altrove si era giunti alla conclusione che i sistemi di fast travel siano l'unico modo per risolvere questo problemi di collegare i punti di "aggregazione di pg" (città, di solito) senza costringere i giocatori a pallosissimi viaggi.

Il problema è tutto nel come giustificare questi sistemi di viaggio veloce nella logica dell'ambientazione. Ma questo diventa un problema inerente al mud creato, secondo me.
In un mud in cui l'intero mondo di gioco riproduca solo una città e i suoi sobborghi, anche un sistema di fast travel rappresentato da carrozze sarebbe sufficientemente plausibile.
Per mondi più ampi diventano necessarie spiegazioni mistiche... starà ai creatori decidere come giustificarle. O se non usarle affatto, e soffrire in nome del realismo

disocrso interessante che condivido sostanzialmente in toto solo un paio di appunti:

1) sicuramente il fast travel sarà un'opzione ON/OFF tra le possibilità dei mud
2) il fast travel è giustificabilissimo laddove come dici tu l'ambientazione lo permette, al di la dei portali (che ovviamente non sono alla portata di tutti e debbono cmq essere "onerosi" dal punto di vista magico e di $ ) dei sistemi interessanti sono quelli rappresentati come ad esempio in WOW dai mezzi di trasporto "veloci" che percorrono realmente il percorso semplicemente non interagendo con esso.

Ad esempio in wow esistono gli zeppelin o i grifoni che volano e ti trasportano in un tempo decisamente inferiore rispetto che camminare da un luogo all'altro, su un mud potrebbe essere fatto anche per mezzi a terra quali appunto carrozze e simili (diciamo che magari potrebbero dimezzare il tempo di marcia normale con un cavallo), sarebbe però bello rendere cmq questi mezzi "intercettabili" ossia se passa una carrozza un gruppo di player potrebbe magari assaltarla o bloccarla.

Gadda ha scritto:
disocrso interessante che condivido sostanzialmente in toto solo un paio di appunti:

1) sicuramente il fast travel sarà un'opzione ON/OFF tra le possibilità dei mud
2) il fast travel è giustificabilissimo laddove come dici tu l'ambientazione lo permette, al di la dei portali (che ovviamente non sono alla portata di tutti e debbono cmq essere "onerosi" dal punto di vista magico e di $ ) dei sistemi interessanti sono quelli rappresentati come ad esempio in WOW dai mezzi di trasporto "veloci" che percorrono realmente il percorso semplicemente non interagendo con esso.

Ad esempio in wow esistono gli zeppelin o i grifoni che volano e ti trasportano in un tempo decisamente inferiore rispetto che camminare da un luogo all'altro, su un mud potrebbe essere fatto anche per mezzi a terra quali appunto carrozze e simili (diciamo che magari potrebbero dimezzare il tempo di marcia normale con un cavallo), sarebbe però bello rendere cmq questi mezzi "intercettabili" ossia se passa una carrozza un gruppo di player potrebbe magari assaltarla o bloccarla.

Beh su wow stai a guardare il culo dell'uccellone anche 10 o 20 minuti ogni volta che ti sposti, soprattutto per tratte lunghe. Infatti hanno impostato dei fast travel (le pietre) per cui scegli un posto dove puoi fare un recall rapido ovunque tu sia.
La maggior parte dei mmorpg utilizzare questi sistemi per inchiodare i giocatori per un po' di tempo, non esiste il gioco di soli 5 minuti (entri picchi il mob che ti interessa ed esci). Io sono solo in parte d'accordo con questa politica. Sicuramente non sono d'accordo sul permettere un funzionale di soli 5 minuti (eccetto il gestire negozi o lavori in genere).
Anche in EVE i viaggi possono essere molto lunghi, quando si vuole andare da un posto all'altro della propria zona ci vogliono alcuni minuti, a volte uno solo. Mentre per andare da un posto all'altro ci può volere tanto tempo, se è molto lontano anche diverse ore (soprattutto con navi lente, ma questo non è il nostro problema).
Il gioco a mio avviso deve svolgersi a zone, non in tutto il mondo, è per questo che comunque bisogna puntare ad avere almeno un centinaio di giocatori in un mud. Se poi arrivassimo ai 300-400 dei mud in inglese (russi, polacchi, statunitensi) sarebbe un ottimo traguardo (ovviamente è la grafica in questo caso che creerebbe l'interesse). Ovviamente più giocatori si hanno aumentando l'interese e aumentando l'obbligo a restare.
L'obbligo a muoversi per un tot di tempo, è un elemento positivo, le mappe grandi sono un elemento positivo, ma tutto subordinato all'utilità e al non annoiarsi.
Percorrere 1000 locazioni di wild, in cui sai che non troverai mai nulla se non qualche mob errante scassa palle, non è una buona cosa. Ma se, come in wow, puoi metterti a cercare miniere o erbe allora in viaggio diventa anche utile.

JJ

allora penso che tutti questi discorsi in liena di massima siano corretti quello che mi chiedo è in linea di decisionale cosa pensate sarebbe il caso di fare ossia va bene la wild con caselle "uomo" ossia ammettiamo 1 metro di lato o bisogna trovare dei compromessi?

credo che le strade che avete illustrato per rendere i viaggi più agevoli vadano inserite tutte come opzioni a scelta dei Keeper però rimane il fatto che la wild debba necessariamente essere univoca per tutti.

Non so, dipende tutto dalla "raffigurazione".
Troppe caselle possono diventare letali, anche perchè tante caselle disperdono i pg. Ecco perchè sono nate le città nei mud, per fare da punto di aggregazione.
Ma se anche solo il bar di una locanda è composto di 20 caselle...

Maan ha scritto:Non so, dipende tutto dalla "raffigurazione".
Troppe caselle possono diventare letali, anche perchè tante caselle disperdono i pg. Ecco perchè sono nate le città nei mud, per fare da punto di aggregazione.
Ma se anche solo il bar di una locanda è composto di 20 caselle...

Difatti ci vuole un buon supporto grafico e testuale, anche perchè se tu sei in un bar e senti i discorsi di 10 persone contemporaneamente non capisci niente, ed è quello che succede se in un gruppo su un mud si mettono a parlare tutti assieme.
Per cui un bar a caselle in cui vai dalla persona con cui vuoi parlare usi comandi adeguati è un sistema che funziona, certo deve essere chiaro di dove sono tutti.
I comandi disponibili potrebbero essere sussurra, parla piano, parla chiaro, parla forte. Una serie di toni di voce che tutti usiamo. Se parli piano ti sente solo la persona che ti sta vicino, se parli chiaro ti sentono quelli che ti stanno intorno, se parlo forte ti sentono tutti quelli del bar. Poi ci sarebbe il concetto di rumore di fondo, ma quello può essere uno stato successivo.

JJ

Jumping Jack ha scritto:

Maan ha scritto:Non so, dipende tutto dalla "raffigurazione".
Troppe caselle possono diventare letali, anche perchè tante caselle disperdono i pg. Ecco perchè sono nate le città nei mud, per fare da punto di aggregazione.
Ma se anche solo il bar di una locanda è composto di 20 caselle...

Difatti ci vuole un buon supporto grafico e testuale, anche perchè se tu sei in un bar e senti i discorsi di 10 persone contemporaneamente non capisci niente, ed è quello che succede se in un gruppo su un mud si mettono a parlare tutti assieme.
Per cui un bar a caselle in cui vai dalla persona con cui vuoi parlare usi comandi adeguati è un sistema che funziona, certo deve essere chiaro di dove sono tutti.
I comandi disponibili potrebbero essere sussurra, parla piano, parla chiaro, parla forte. Una serie di toni di voce che tutti usiamo. Se parli piano ti sente solo la persona che ti sta vicino, se parli chiaro ti sentono quelli che ti stanno intorno, se parlo forte ti sentono tutti quelli del bar. Poi ci sarebbe il concetto di rumore di fondo, ma quello può essere uno stato successivo.

JJ

sul sentire chi e cosa il discoro fila e puntualizzarerei che chi vuole puo avere una finestra nel client per i discorsi una per gli emote una per la mappa ecc... insomma se la configura a piacimento l'utente.

un'altra cosa che di questi tempi è molto in voga... secondo voi una cosa tipo Team Speack integrata nel gioco sarebbe follia o antigdr?

Gadda ha scritto:

Jumping Jack ha scritto:

Maan ha scritto:Non so, dipende tutto dalla "raffigurazione".
Troppe caselle possono diventare letali, anche perchè tante caselle disperdono i pg. Ecco perchè sono nate le città nei mud, per fare da punto di aggregazione.
Ma se anche solo il bar di una locanda è composto di 20 caselle...

Difatti ci vuole un buon supporto grafico e testuale, anche perchè se tu sei in un bar e senti i discorsi di 10 persone contemporaneamente non capisci niente, ed è quello che succede se in un gruppo su un mud si mettono a parlare tutti assieme.
Per cui un bar a caselle in cui vai dalla persona con cui vuoi parlare usi comandi adeguati è un sistema che funziona, certo deve essere chiaro di dove sono tutti.
I comandi disponibili potrebbero essere sussurra, parla piano, parla chiaro, parla forte. Una serie di toni di voce che tutti usiamo. Se parli piano ti sente solo la persona che ti sta vicino, se parli chiaro ti sentono quelli che ti stanno intorno, se parlo forte ti sentono tutti quelli del bar. Poi ci sarebbe il concetto di rumore di fondo, ma quello può essere uno stato successivo.

JJ

sul sentire chi e cosa il discoro fila e puntualizzarerei che chi vuole puo avere una finestra nel client per i discorsi una per gli emote una per la mappa ecc... insomma se la configura a piacimento l'utente.

un'altra cosa che di questi tempi è molto in voga... secondo voi una cosa tipo Team Speack integrata nel gioco sarebbe follia o antigdr?

Ne follia ne anti gdr. Anzi un mud potrebbe anche essere configurato come piattaforma per giocare al tavolo... ma distanti.
Riguardo all'utilità è l'unico dubbio, in fondo basta che i giocatori usino team speak o ventrillo (che sono fatti apposta).
Unico dubbio ce l'ho sul fatto che EVE abbia il suo supporto voice e non so perchè.
Comunque sui mmorpg il voip è d'obbliogo, anzi molte top alleaze/gilde obbligato ad avere un supporto voip.
Diciamo che se la voce non ha interazione diretta con il gioco lascerei a chi lo sa fare meglio il compito di gestire il voip.


JJ

Il gioco a mio avviso deve svolgersi a zone, non in tutto il mondo

Questo è un aspetto molto importante.
Se i giocatori sono forzati a giocare in certe zone, non sparsi per il mondo, sono incentivati a giocare tra loro.
Credo sia uno dei punti (più) importanti da tenere conto.

Parpacak ha scritto:

Il gioco a mio avviso deve svolgersi a zone, non in tutto il mondo

Questo è un aspetto molto importante.
Se i giocatori sono forzati a giocare in certe zone, non sparsi per il mondo, sono incentivati a giocare tra loro.
Credo sia uno dei punti (più) importanti da tenere conto.

si quoto al 300% questa affermazione sono sempre stato un fervente sostenitore dell'annullare le città megagalattiche abitate da 5 pg.... e del rendere nel mud classico l'astrazione dello spazio (ossia una taverna è 1-2 stanze non 5 stanze, una torre è una stanza con la scala! ecc..).

Forse una mezza soluzione ci sarebbe... ossia che la casella piccona non rappresenta veramente la casella ma è ad esempio 1/9 di casella e in realtà ci si muove di casella in casella.

- Io sono favorevole a canali di comunicazione off: o li metti nel mud o comunque vengono usati i vari programmi di istant messaging, quindi tanto vale incorporare la comunicazione off nel gioco. E' utile per organizzarsi, inutile negarlo: meglio allora prevederla e regolamentarla.

- D'accordo sulla gestione della comunicazione on, finchè rimane giocabile (ovvero, se i comandi non sono troppi: pure solo ricordare tutti i modi di parlare che hai a disposizione diventa uno stress, altrimenti).
Meno d'accordo sul dividere gli emote dal parlato, è comunicazione pure quella... anzi, forse potrebbero avere pure gli emote diversi "gradi" (più o meno visibili).

- Le "stanze"... dipende. Un bar con 5 caselle può tornare utile se significa che puoi spostarti con i tuoi 3 amici per parlare senza sentire e vedere altri 10 pg di cui ti importa poco.
Ho visto in un mud rpi avevano la locanda con un sistema "a tavoli": seduto al tavolo 1 sentivi solo gli altri sentiti al tavolo 1, poi alcuni comandi e pregi permettevano magari di origliare altrove...
Non dico di fare lo stesso, ma è un'idea come "concept".

Maan ha scritto:-
- Le "stanze"... dipende. Un bar con 5 caselle può tornare utile se significa che puoi spostarti con i tuoi 3 amici per parlare senza sentire e vedere altri 10 pg di cui ti importa poco.
Ho visto in un mud rpi avevano la locanda con un sistema "a tavoli": seduto al tavolo 1 sentivi solo gli altri sentiti al tavolo 1, poi alcuni comandi e pregi permettevano magari di origliare altrove...
Non dico di fare lo stesso, ma è un'idea come "concept".

be l'idea non è male si potrebbe ad esmpio creare un sistema di "aggregazione" ossia si parla "tra alcune persone" una sorta di chat nella quale non si subiscono ad esempio emote esterni (priorità 3 4 5) a parte gli emote principali (priorità 1 e 2) e si sentono solo tipologie di voce alte (ad esempio se facciamo 4 o 5 livelli di comunicazione si sentono solo 1 e 2). questo sistema di aggregazione funziona ad inviti un po come i gruppi dei vecchi mud.

Magari vado OT, però colgo anche qui l'occasione per suggerire di evitare il non-senso dei mud a "wild ampia" in cui il teorema di Pitagora non avrebbe mai potuto essere formulato. Sarebbe opportuno considerare le "direzioni diagonali" (es. nord-est), di modo che seguire una strada verso nord-est per andare da un punto A ad un punto C, consenta di risparmiare tempo rispetto a seguire una strada ad est dal punto A ad un punto B, a sud del punto C, e di nuovo un'altra strada da B a C. Insomma l'ipotenusa del triangolo rettangolo dovrebbe essere più corta della somma dei cateti.

Sì va bene torno nella mia caverna.

Valeder ha scritto:Magari vado OT, però colgo anche qui l'occasione per suggerire di evitare il non-senso dei mud a "wild ampia" in cui il teorema di Pitagora non avrebbe mai potuto essere formulato. Sarebbe opportuno considerare le "direzioni diagonali" (es. nord-est), di modo che seguire una strada verso nord-est per andare da un punto A ad un punto C, consenta di risparmiare tempo rispetto a seguire una strada ad est dal punto A ad un punto B, a sud del punto C, e di nuovo un'altra strada da B a C. Insomma l'ipotenusa del triangolo rettangolo dovrebbe essere più corta della somma dei cateti.

Sì va bene torno nella mia caverna.

ma sai cosa i movimenti in diagonale sono abb semplici da inserire ma a sono ovviamente un sistema che non funziona in una schematizzazione a griglia in quanto accorciano i tempi sproporzionatamente rispetto a chi si muove nei punti cardinali.
Li avevamo utilizzati su Anacronia mi ricordo e sinceramente non si sentiva sto gran vantaggio alla fine ci si muoveva cmq con le frecette e tornava più comodo e veloce.
Cosa invece che trovo possa davvero essere utile è il movimento point&clilck magari su una visualizzazione wild ad ampio raggio, magari con traccia del movimento fatto, (per chi ha giocato a civilization una cosa tipo il goto)

Valeder ha scritto:Magari vado OT, però colgo anche qui l'occasione per suggerire di evitare il non-senso dei mud a "wild ampia" in cui il teorema di Pitagora non avrebbe mai potuto essere formulato. Sarebbe opportuno considerare le "direzioni diagonali" (es. nord-est), di modo che seguire una strada verso nord-est per andare da un punto A ad un punto C, consenta di risparmiare tempo rispetto a seguire una strada ad est dal punto A ad un punto B, a sud del punto C, e di nuovo un'altra strada da B a C. Insomma l'ipotenusa del triangolo rettangolo dovrebbe essere più corta della somma dei cateti.

Sì va bene torno nella mia caverna.

A me le diagonali personalmente piacciono, il problema è solo appunto il valutare il tempo e il consumo di energia in un movimento diagonale.
Il problema principale in una mappa a quadretti è il confine diagonale che di fatto non esiste, per questo motivo è inapplicabile perchè obbligherebbe ad eliminare tutte le meccaniche basate su un passaggio da una casella ad una vicina.
Se tu pensi i giochi da tavolo con le caselle di solito non permettono il movimento laterale con le mappe quadrate, quando invece si tratta di movimenti su "terreno" solitamente la mappa è esagonale. Purtroppo credo che non si esca da questi due concetti (quadrato o esagonale).
La mappa andrebbe esagonale perchè la strada percorsa da un punto ad un'altro si avvicina molto a quella reale qualunque sia la direzione presa. E' solo ingiocabile con i cursori, perfettamente giocabile invece con il point&click.

Se dovessi fare un mud senza wild sicuramente lo farei con le diagonali (o beh l'ho già fatto ) ma con le wild invece è un discorso diverso, o si passa ad una grafica "senza caselle" oppure non sono applicabili.
Diciamo che il lato server lo farei indipendende dalla rappresentazione in modo che se in futuro si potesse fare un client con una grafica tipo NWN si potrebbe fare senza problemi.

JJ

Jumping Jack ha scritto:

Valeder ha scritto:Magari vado OT, però colgo anche qui l'occasione per suggerire di evitare il non-senso dei mud a "wild ampia" in cui il teorema di Pitagora non avrebbe mai potuto essere formulato. Sarebbe opportuno considerare le "direzioni diagonali" (es. nord-est), di modo che seguire una strada verso nord-est per andare da un punto A ad un punto C, consenta di risparmiare tempo rispetto a seguire una strada ad est dal punto A ad un punto B, a sud del punto C, e di nuovo un'altra strada da B a C. Insomma l'ipotenusa del triangolo rettangolo dovrebbe essere più corta della somma dei cateti.

Sì va bene torno nella mia caverna.

A me le diagonali personalmente piacciono, il problema è solo appunto il valutare il tempo e il consumo di energia in un movimento diagonale.
Il problema principale in una mappa a quadretti è il confine diagonale che di fatto non esiste, per questo motivo è inapplicabile perchè obbligherebbe ad eliminare tutte le meccaniche basate su un passaggio da una casella ad una vicina.
Se tu pensi i giochi da tavolo con le caselle di solito non permettono il movimento laterale con le mappe quadrate, quando invece si tratta di movimenti su "terreno" solitamente la mappa è esagonale. Purtroppo credo che non si esca da questi due concetti (quadrato o esagonale).
La mappa andrebbe esagonale perchè la strada percorsa da un punto ad un'altro si avvicina molto a quella reale qualunque sia la direzione presa. E' solo ingiocabile con i cursori, perfettamente giocabile invece con il point&click.

Se dovessi fare un mud senza wild sicuramente lo farei con le diagonali (o beh l'ho già fatto ) ma con le wild invece è un discorso diverso, o si passa ad una grafica "senza caselle" oppure non sono applicabili.
Diciamo che il lato server lo farei indipendende dalla rappresentazione in modo che se in futuro si potesse fare un client con una grafica tipo NWN si potrebbe fare senza problemi.

JJ

si credo che l'unica altra soluzione sarebbe quella di non fare caselle ma a quel punto bisognerebbe davvero pensare a qualche cosa di molto diverso dove le descrizioni vengono date ad aree definite sulla mappa e cose del genere e la grafica e i movimenti sono del tutto liberi e slegati .

Gadda ha scritto:

Parpacak ha scritto:

Il gioco a mio avviso deve svolgersi a zone, non in tutto il mondo

Questo è un aspetto molto importante.
Se i giocatori sono forzati a giocare in certe zone, non sparsi per il mondo, sono incentivati a giocare tra loro.
Credo sia uno dei punti (più) importanti da tenere conto.

si quoto al 300% questa affermazione sono sempre stato un fervente sostenitore dell'annullare le città megagalattiche abitate da 5 pg.... e del rendere nel mud classico l'astrazione dello spazio (ossia una taverna è 1-2 stanze non 5 stanze, una torre è una stanza con la scala! ecc..).

Forse una mezza soluzione ci sarebbe... ossia che la casella piccona non rappresenta veramente la casella ma è ad esempio 1/9 di casella e in realtà ci si muove di casella in casella.

Io avrei una domanda... Perchè bisogna forzare i giocatori a giocare tra loro? Se vogliono giocare tra di loro di aggregano se non voglio stanno da soli...
Un punto di forza dei giochi tipo Ogame è che puoi giocare sia da solo che di gruppo e nessuno ti obbliga a fare niente.

Se il problema è che i giocatori si disperdono troppo, allora sono necessari i "fast travel" (portal, teleport ecc...) ma obbligare a giocare in aree limitate, secondo me, è proprio sbagliato.

Riguardo al fare le cose piccole e bene sono d'accordo. Esempio una città con poche locazioni, in buona parte utili (e non 100 coreografiche e 5 utili come succede di solito).
Personalmente credo che un mud con una wild di 400x400 (16000 locazioni) che abbia 300-400 luoghi utili sarebbe un bellissimo mud. Invece di solito i luoghi utili sono pochi e spesso di 100 sub locazioni (delle quali 80 inutili). Se faccio 20 dungeon di 1-5 locazioni, faccio un lavoro molto più utile che un solo dungeon di 100 locazioni.

JJ

Jumping Jack ha scritto:

Io avrei una domanda... Perchè bisogna forzare i giocatori a giocare tra loro? Se vogliono giocare tra di loro di aggregano se non voglio stanno da soli...
Un punto di forza dei giochi tipo Ogame è che puoi giocare sia da solo che di gruppo e nessuno ti obbliga a fare niente.

Se il problema è che i giocatori si disperdono troppo, allora sono necessari i "fast travel" (portal, teleport ecc...) ma obbligare a giocare in aree limitate, secondo me, è proprio sbagliato.

Riguardo al fare le cose piccole e bene sono d'accordo. Esempio una città con poche locazioni, in buona parte utili (e non 100 coreografiche e 5 utili come succede di solito).
Personalmente credo che un mud con una wild di 400x400 (16000 locazioni) che abbia 300-400 luoghi utili sarebbe un bellissimo mud. Invece di solito i luoghi utili sono pochi e spesso di 100 sub locazioni (delle quali 80 inutili). Se faccio 20 dungeon di 1-5 locazioni, faccio un lavoro molto più utile che un solo dungeon di 100 locazioni.

JJ

ma guarda parlo solo per esperienza diretta di gioco: un mud per definizione è un gioco in cui l'interazione dei player è fondamentale (se no tanto vale giocare a morrowind). Interazione ovviamente non vuol dire necessariamente giocare con gli altri ma almeno fare in modo che il gioco collettivo sia incentivato (non dico di penalizzare il gioco single player ma ovviamente certe cose si possono fare solo in tanti).

per quel che riguarda invece le dimensioni faccio 2 esempi: 1 revenge, wild enorme 10 città e 10 razze con città niubba di partenza... 50ina di giocatori... risultato = 5 player per città in totale che in genere su 24 ore vuol dire circa 1 player per città contemporaneamente...

ecco questo è una delle peggiori situazioni che si possono creare in un mud, vuol dire uccidere il mud ancor prima di crearlo, in quanto i player non hanno aiuti, supporto, interazioni e non incontrano mai nessuno di nuovo (per spostarsi da una città all'altra ci volevano anche delle mezz'ore e i viaggi erano diffili con molti mostri) e alla lunga i player desistono. Ma non è colpa della vastità del gioco ma delle possibilità di "incontro" che il mud offre.

Se nella sterminata wild tutti partivano ad esempio da 2 città stereotipate (la calssica buona e cattiva) non troppo distanti ma nemmeno troppo poco e poi si dava la possibilità pian piano con difficoltà di creare altre realtà ai player allora la cosa funziona diversamente. Si vengono a creare i presupposti per l'interazione dei player.

Che in un certo senso è quello che è successo in TG (esempio 2) dove si partiva da 1 città e un luogo di riferimento per i "cattivi" e successivamente si sono create tante altre realtà.

Gadda ha scritto:

Jumping Jack ha scritto:

Valeder ha scritto:Magari vado OT, però colgo anche qui l'occasione per suggerire di evitare il non-senso dei mud a "wild ampia" in cui il teorema di Pitagora non avrebbe mai potuto essere formulato. Sarebbe opportuno considerare le "direzioni diagonali" (es. nord-est), di modo che seguire una strada verso nord-est per andare da un punto A ad un punto C, consenta di risparmiare tempo rispetto a seguire una strada ad est dal punto A ad un punto B, a sud del punto C, e di nuovo un'altra strada da B a C. Insomma l'ipotenusa del triangolo rettangolo dovrebbe essere più corta della somma dei cateti.

Sì va bene torno nella mia caverna.

A me le diagonali personalmente piacciono, il problema è solo appunto il valutare il tempo e il consumo di energia in un movimento diagonale.
Il problema principale in una mappa a quadretti è il confine diagonale che di fatto non esiste, per questo motivo è inapplicabile perchè obbligherebbe ad eliminare tutte le meccaniche basate su un passaggio da una casella ad una vicina.
Se tu pensi i giochi da tavolo con le caselle di solito non permettono il movimento laterale con le mappe quadrate, quando invece si tratta di movimenti su "terreno" solitamente la mappa è esagonale. Purtroppo credo che non si esca da questi due concetti (quadrato o esagonale).
La mappa andrebbe esagonale perchè la strada percorsa da un punto ad un'altro si avvicina molto a quella reale qualunque sia la direzione presa. E' solo ingiocabile con i cursori, perfettamente giocabile invece con il point&click.

Se dovessi fare un mud senza wild sicuramente lo farei con le diagonali (o beh l'ho già fatto ) ma con le wild invece è un discorso diverso, o si passa ad una grafica "senza caselle" oppure non sono applicabili.
Diciamo che il lato server lo farei indipendende dalla rappresentazione in modo che se in futuro si potesse fare un client con una grafica tipo NWN si potrebbe fare senza problemi.

JJ

si credo che l'unica altra soluzione sarebbe quella di non fare caselle ma a quel punto bisognerebbe davvero pensare a qualche cosa di molto diverso dove le descrizioni vengono date ad aree definite sulla mappa e cose del genere e la grafica e i movimenti sono del tutto liberi e slegati .

Beh il client non ha le caselle, ma dal lato server ci sono. Ho citato NWN per questo, se fai un area per NWN ci vuole davvero poco, si disegna a caselle, poi si piazzano gli elementi fissi, si piazzano degli hotspot per i mob (dove poppano) e finito. In gioco invece il movimento è libero dalle caselle. A quel punto la descrizione cambia quando c'è il passaggio tra una casella e l'altra. E' solo un modo di rappresentare.

JJ

Gadda ha scritto:

Jumping Jack ha scritto:

Io avrei una domanda... Perchè bisogna forzare i giocatori a giocare tra loro? Se vogliono giocare tra di loro di aggregano se non voglio stanno da soli...
Un punto di forza dei giochi tipo Ogame è che puoi giocare sia da solo che di gruppo e nessuno ti obbliga a fare niente.

Se il problema è che i giocatori si disperdono troppo, allora sono necessari i "fast travel" (portal, teleport ecc...) ma obbligare a giocare in aree limitate, secondo me, è proprio sbagliato.

Riguardo al fare le cose piccole e bene sono d'accordo. Esempio una città con poche locazioni, in buona parte utili (e non 100 coreografiche e 5 utili come succede di solito).
Personalmente credo che un mud con una wild di 400x400 (16000 locazioni) che abbia 300-400 luoghi utili sarebbe un bellissimo mud. Invece di solito i luoghi utili sono pochi e spesso di 100 sub locazioni (delle quali 80 inutili). Se faccio 20 dungeon di 1-5 locazioni, faccio un lavoro molto più utile che un solo dungeon di 100 locazioni.

JJ

ma guarda parlo solo per esperienza diretta di gioco: un mud per definizione è un gioco in cui l'interazione dei player è fondamentale (se no tanto vale giocare a morrowind). Interazione ovviamente non vuol dire necessariamente giocare con gli altri ma almeno fare in modo che il gioco collettivo sia incentivato (non dico di penalizzare il gioco single player ma ovviamente certe cose si possono fare solo in tanti).

per quel che riguarda invece le dimensioni faccio 2 esempi: 1 revenge, wild enorme 10 città e 10 razze con città niubba di partenza... 50ina di giocatori... risultato = 5 player per città in totale che in genere su 24 ore vuol dire circa 1 player per città contemporaneamente...

ecco questo è una delle peggiori situazioni che si possono creare in un mud, vuol dire uccidere il mud ancor prima di crearlo, in quanto i player non hanno aiuti, supporto, interazioni e non incontrano mai nessuno di nuovo (per spostarsi da una città all'altra ci volevano anche delle mezz'ore e i viaggi erano diffili con molti mostri) e alla lunga i player desistono. Ma non è colpa della vastità del gioco ma delle possibilità di "incontro" che il mud offre.

Se nella sterminata wild tutti partivano ad esempio da 2 città stereotipate (la calssica buona e cattiva) non troppo distanti ma nemmeno troppo poco e poi si dava la possibilità pian piano con difficoltà di creare altre realtà ai player allora la cosa funziona diversamente. Si vengono a creare i presupposti per l'interazione dei player.

Che in un certo senso è quello che è successo in TG (esempio 2) dove si partiva da 1 città e un luogo di riferimento per i "cattivi" e successivamente si sono create tante altre realtà.

Sono d'accordo solo in parte. Anche se è vero che se non si disperdono i giocatori, è più facile il gioco di squadra, non è vero che si incentiva il gioco di squadra il mud funzioni. Anzi soprattutto i nuovi giocatori devono giocare da soli, devono imparare a giocare, è questo il vero problema. Obbligarli ad appoggiarsi ad altri giocatori più capaci, che magari gli regalano dell'eq, fa si che non capiscano un piffero di come si gioca, e siano sempre dipendenti dagli altri, perchè da soli non sanno dove andare e schiattano sempre.
Ora mi viene in mente WOW: inizialmente il gioco è in solitaria, non è vietato il gioco di gruppo, ma non da benefici eccetto il "traino", quando invece i livelli salgono è sempre più obbligatorio il gioco di gruppo per fare eq, ma c'è sempre l'opzione del gioco in solitaria per sviluppare le skill e fare xp.
L'importante è che i giocatori imparino a giocare, e non con le solite aree delle balle che ti spiegano tutto e poi uno non si ricorda niente. Partendo direttamente con il gioco, del tipo vai la e prendi questo, oppure uccidi quel mob o qualcosa di mirato e comprensibile a tutti, fornendo solo i comandi strettamente necessari per quel compito. Se poi uno vuole sapere come si trascina un divano, o di addrestra un cavallo, o si guarda attraverso un foro sulla porta, lo scoprirà poi, tanto all'inizio non serve a niente.

JJ