Mais uma versao do JMud ja' esta' disponivel.

Pagina do JMud
http://www.dcc.unicamp.br/~evertonm/jmud/

Ultima Versao
http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.17.tar.gz

NOVIDADES
o Invisibilidade para personagens -- comando 'invisibilidade'.
o Portas ocultas.
o Politica de distincao entre: posto/nivel/titulo.
o Aperfeicoamento do comando 'comandos'.
o Criado um pequeno esboco de zona inicial.
o Comando 'privilegios'.
o Diversas correcoes e melhorias localizadas.

--
Everton da Silva Marques
mailto:evertonm@...
http://www.dcc.unicamp.br/~evertonm

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/jmud
Free Web-based e-mail groups by eGroups.com

Uma nova versao do JMud ja' esta' disponivel:

http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.16.tar.gz


NOVIDADES RELEVANTES

o Rascunho de um sistema de ganho e distribuicao de experiencia
   (inclusive para o grupo).
o Gatilhos para comandos sao anexados a criaturas via prototipo
   e/ou automacao.
o Introduzido um mecanismo rudimentar para regeneracao de
   ferimentos.
o Acrescentada automatizacao para manipulacao de portas.
o Corrigidas falhas em automatizacoes.
o Melhorado o parsing das automatizacoes em geral.
o Adicionado um esquema de calculo percentual de comportamento
   (vulgo alinhamento).
o Extendido o formato dos comandos para contemplar subparametros.
o Quebra da tabela de comandos em arquivos individuais para
   possibilitar o acesso a partir de outras classes.
o Conceito de 'clone' quase que totalmente convertido para o
   modelo de programacao generica. Com isso, o JMud esta'
   quase inteiramente adaptado ao novo modelo.
o Implementado o funcionamento de invisibilidade para itens.
o Criado o comando privilegiado 'onisciencia', utilizado sobretudo
   para teste de caracteristicas como invisibilidade.
o Criado o comando 'salve' para gravar o personagem sob
   demanda do usuario.


--
Everton da Silva Marques
mailto:evertonm@...
http://www.dcc.unicamp.br/~evertonm

------------------------------------------------------------------------
E-group home: http://www.eGroups.com/list/jmud
Free Web-based e-mail groups by eGroups.com

Para sanar alguns pequenos problemas com a versao 0.14 do JMud, ja'
existe a versao 0.15.

http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.15.tar.gz

Modificacoes relevantes:

o Correcao do comando 'siga'.
o Simplificacao do Sheet System.
o Consertado o problema de "dupla morte".
o Melhora na performance de substituicoes de strings.

--
Everton da Silva Marques
mailto:evertonm@...
http://www.dcc.unicamp.br/~evertonm
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

on Fri, 4 Dec 1998 17:15:59, Jose Alexandre Nalon wrote:
|
| Em outras palavras, voce me fez entender que voce queria que nao
| se entendesse muito bem o que estava escrito em um arquivo de mundo,
| e eu gostaria de saber por que.

Realmente houve um desentendimento aqui. Essa nunca foi a minha
intencao. Admira-me que voce tenha cogitado isso.

| Ok, voce fala em relacao custo/beneficio. Sera' que os beneficios
| de uma sintaxe mais racional sao assim tao poucos e a dificuldade
| em programar tao imensa que nao compensa nem pensar no assunto?

Eu ja' disse e repito que concordo, e ate' propus uma metodologia pra
fazer isso. Se voce nao se importa, vou cortar os varios paragrafos em
que voce tenta encaminhar o JMud numa direcao em que ele ja' esta'
indo.

| Voce diz que e' desnecessario pensar em uma maneira racional de
| implementar comandos, de tal forma que em futuras expansoes eles
| possam ser criados de uma maneira simples e coerente com o que
| ja' existe? E' porque foi isso que eu propus...

Eu fui contra ignorar sintaxe desconhecida.

| To comecando a achar que nem adianta muito...

A sua principal ideia que eu acho que entendi me pareceu muito
interessante: aprimorar a sintaxe dos arquivos do JMud. Esta' na lista
de coisas a se fazer. So' nao entendi porque voce ainda continua
querendo o que ja' conseguiu.

--
Everton
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> | Nao, a pergunta era: por que a nao completa legibilidade?
>
> "Completa legibilidade"? Acho que eu nao sei o que e' isso. Defina.

Voce falou - os arquivos de mundos nao deviam ser completamente
legiveis. O que nao contem completa legibilidade e' aquilo que
nao e' completamente legivel.

Em outras palavras, voce me fez entender que voce queria que nao
se entendesse muito bem o que estava escrito em um arquivo de mundo,
e eu gostaria de saber por que.

> custo/beneficio. Lembre-se de que um dia o JMud ja' foi um par de
> arquivos com algumas centenas de linhas.

Foi isso que eu quis dizer com simples. O JMud ja' foi pequeno e
simples, agora e' grande e complexo. Isso porque voce foi imple-
mentando pouco a pouco cada uma das caracteristicas.

Assim deve ser tambem com os arquivos de mundo - voce comeca com
pouca coisa, e vai implementando uma por uma. Dai', no final, voce
tem uma coisa maior, que funciona bem, que partiu de um principio
simples e que no final te da' um entendimento maior.

Ok, voce fala em relacao custo/beneficio. Sera' que os beneficios
de uma sintaxe mais racional sao assim tao poucos e a dificuldade
em programar tao imensa que nao compensa nem pensar no assunto?
Eu sinceramente nao consigo ver como.

Veja, eu nao estou querendo que os arquivos de mundo sejam definidos
em linguagem natural, entendendo ingles, portugues, esperanto, alemao
e japones. E' so' uma sintaxe do tipo:

Variavel = valor

Qual pode ser a dificuldade em se implementar isso? Em contraponto,
quanto beneficio nao pode trazer? Sinceramente, se voce acredita que
isso e' complexo, voce esta' subestimando a sua propria capaciadade
como programador.

Outros elementos, como aspas ou delimitadores de listas, sao tao
simples quanto. Nao e' necessario fazer um backtracking pra dizer
em que linha esta' havendo erro (pelo menos nao por enquanto - isso
sim eu considero dispensavel a priori). So' algo pra dar um pouco
mais de legibilidade ao arquivo de mundos.

> Uma GUI e' ideal para mundos pequenos. Ela cria registros prontos,
> default, e o construtor (builder) so' precisaria modificar alguns
> campos na propria interface.

Nao, falando serio - o que sera' mais complexo de se escrever - um
interpretador de sintaxe banal ou uma GUI para a criacao de mundos
(ainda que esta tambem seja banal)?

> codigo e realizar testes. Ou contar com uma grande ajuda minha ou do
> Matheus.

Adivinha o que vai acontecer? :)

> Compatibilidade para tras e' razoavel. Para frente,
> desnecessaria. Especialmente se considerarmos que ignorar sintaxe

Voce diz que e' desnecessario pensar em uma maneira racional de
implementar comandos, de tal forma que em futuras expansoes eles
possam ser criados de uma maneira simples e coerente com o que
ja' existe? E' porque foi isso que eu propus...

> | Vou estar pensando em novas sugestoes... :P
>
> Estarei aguardando, com curiosidade e temor. <:)

To comecando a achar que nem adianta muito...

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Devido a alguma falha com o EGroups, o servidor da nossa lista,
voces devem ter recebido 3 copias de um email (no. 22).
Aparentemente o problema jah foi resolvido.

Lamento pelo incomodo.
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

on Thu, 3 Dec 1998 17:28:32, Jose Alexandre Nalon wrote:
| > Para que fosse possivel ser modificado via editor de texto. Possivel,
|
| Nao, a pergunta era: por que a nao completa legibilidade?

"Completa legibilidade"? Acho que eu nao sei o que e' isso. Defina.

| O arquivo de configuracao era apenas um exemplo. A proposta se
| extende a todos os arquivos.
|
| > 3) definindo uma (ou mais) linguagem(ns) para descrever os arquivos
| >    e escrevendo um (ou mais) parser(s) com auxilio de alguma
| >    ferramenta
|
| Bom, se voce acha que essa e' a melhor coisa a ser feita, por que
| nao fazer? Se o problema for a complexidade, eu ja' dei minha
| opiniao varias vezes - o JMud em si e' complicado, so' que,
| implementando coisa por coisa, fica "simples".

Eu nao acho que seja. Voce cortou o texto onde eu disse que acho que
seria, se houvesse necessidade quando eu implementei.

Eu ja' disse que nao e' problema de complexidade. E' de
custo/beneficio. Lembre-se de que um dia o JMud ja' foi um par de
arquivos com algumas centenas de linhas. Se na epoca eu definisse
linguagens para descrever o mundo e os respectivos analisadores
sintaticos, eu teria dispendido muito mais esforco nisso do que em
melhorar o JMud.

| Mas voce esta' certo, o que eu estava propondo era o que voce
| colocou em (2) (inadvertidamente, apaguei). Na verdade, muito
| pouca coisa seria mudada, apenas nos arquivos teriam alguns
| nomes que facilitariam a vida de quem escreve o arquivo de
| mundo.

Pra fazer com cuidado, eu nao mudaria pouca coisa. E' uma modificacao
que pra valer a pena precisa ser bem feita. E estou disposto a
faze-la, mas gradualmente, como eu disse, ou o JMud ficaria muito
tempo "quebrado".

| Note que nao e' a mesma coisa que comentario - afinal, o cara
| sempre pode optar por nao escreve-los. E, sendo mais intuitivo,
| facilitaria a criacao de pequenos mundos teste, como voce
| sugeriu - afinal, o criador simplesmente nao precisaria partir
| para uma GUI ou consultar os manuais a cada minuto para imple-
| mentar uma zona, um objeto, etc...

Uma GUI e' ideal para mundos pequenos. Ela cria registros prontos,
default, e o construtor (builder) so' precisaria modificar alguns
campos na propria interface.

| > Eu pensei que voce estava escrevendo um manual de como "construir
| > mundos".
|
| Nao so' como tambem. Afinal, o JMud e' uma coisa so' e toda
| informacao e' bem vinda. Por exemplo, na parte de criacao de
| mundos, entram criaturas. Em criaturas, entram atributos. Bom,
| eu nao tenho a menor ideia do que faz cada um dos 20 atributos
| do Sheet System, nem como eles sao implementados no JMud. Talvez
| voce discorde de mim, mas acho que um implementor deveria saber
| como essas coisas funcionam sem ter que olhar no codigo...

Lembrar como a maioria das coisas funcionam e' plausivel durante um
certo periodo de tempo. Lembrar exatamente como foram implementadas e'
dificil mesmo em curto periodo de tempo.

Por exemplo, lembro-me como o Sheet System funciona. Mas nao me lembro
como foi a implementacao. E tenho certeza de que com o tempo vou
esquecer totalmente se nao ficar recordando.

| No meio do manual, tambem, muitas vezes vai ser necessario
| referenciar um ou outro comando... E cada um dos comandos
| referenciam varias caracteriscticas do JMud... Se eu nao
| sei como elas funcionam, a coisa fica meio prejudicada,
| nao? :)

Eu nao estava contando com que voce fosse escrever um manual dos
comandos. Pra fazer isso, voce vai precisar vasculhar intensivamente o
codigo e realizar testes. Ou contar com uma grande ajuda minha ou do
Matheus.

| > 2) tratar o formato atual como o que quer que signifique "primeira
| >    versao"
|
| Hm... hm... discordo, viu. Acho que desde o comeco ja' se deveria
| tentar utilizar algo mais... definitivo. Quero dizer, uma base
| fixa sobre a qual expansoes sejam possiveis. Essa base deve ser
| mantida, com seus erros e acertos, durante toda a vida do JMud.
| Dessa forma, ate' mesmo um JMud 1.0 poderia ler um arquivo do
| JMud 4.0 (ignorando a sintaxe que nao conhece, ou algo assim).

Compatibilidade para tras e' razoavel. Para frente,
desnecessaria. Especialmente se considerarmos que ignorar sintaxe
incorreta (desconhecida) e' danoso em termos de compilacao. UM exemplo
disso e' quando voce quer ter certeza que produziu um mundo
sintaticamente correto.

| > Dessa maneira, nao perdemos abruptamente o que ja' foi feito e a
| > transicao para um formato "human readable" fica mais suave.
|
| Nah... quanto a perder abruptamente, acho que tem uma solucao
| facil chamada conversor. E' so' montar um conversorzinho para
| os arquivos, nao e' nenhum bicho de sete cabecas (po, isso ate'
| eu sei fazer) :)

Uma solucao mais compativel e tao facil quanto e' "compatibilidade
para tras". Mas fique `a vontade para escrever o conversor. :)

| Vou estar pensando em novas sugestoes... :P

Estarei aguardando, com curiosidade e temor. <:)

--
Everton da Silva Marques
mailto:evertonm@...
http://www.dcc.unicamp.br/~evertonm
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> Para que fosse possivel ser modificado via editor de texto. Possivel,

Nao, a pergunta era: por que a nao completa legibilidade?

> Voce cortou o seu proprio paragrafo, no qual se nao me engano voce
> estava discutindo especificamente o arquivo de configuracao. Inclusive

O arquivo de configuracao era apenas um exemplo. A proposta se
extende a todos os arquivos.

> 3) definindo uma (ou mais) linguagem(ns) para descrever os arquivos
>    e escrevendo um (ou mais) parser(s) com auxilio de alguma
>    ferramenta

Bom, se voce acha que essa e' a melhor coisa a ser feita, por que
nao fazer? Se o problema for a complexidade, eu ja' dei minha
opiniao varias vezes - o JMud em si e' complicado, so' que,
implementando coisa por coisa, fica "simples".

Mas voce esta' certo, o que eu estava propondo era o que voce
colocou em (2) (inadvertidamente, apaguei). Na verdade, muito
pouca coisa seria mudada, apenas nos arquivos teriam alguns
nomes que facilitariam a vida de quem escreve o arquivo de
mundo.

Note que nao e' a mesma coisa que comentario - afinal, o cara
sempre pode optar por nao escreve-los. E, sendo mais intuitivo,
facilitaria a criacao de pequenos mundos teste, como voce
sugeriu - afinal, o criador simplesmente nao precisaria partir
para uma GUI ou consultar os manuais a cada minuto para imple-
mentar uma zona, um objeto, etc...

> Eu pensei que voce estava escrevendo um manual de como "construir
> mundos".

Nao so' como tambem. Afinal, o JMud e' uma coisa so' e toda
informacao e' bem vinda. Por exemplo, na parte de criacao de
mundos, entram criaturas. Em criaturas, entram atributos. Bom,
eu nao tenho a menor ideia do que faz cada um dos 20 atributos
do Sheet System, nem como eles sao implementados no JMud. Talvez
voce discorde de mim, mas acho que um implementor deveria saber
como essas coisas funcionam sem ter que olhar no codigo...

No meio do manual, tambem, muitas vezes vai ser necessario
referenciar um ou outro comando... E cada um dos comandos
referenciam varias caracteriscticas do JMud... Se eu nao
sei como elas funcionam, a coisa fica meio prejudicada,
nao? :)

> Mas nao posso prometer nada sobre o que for implementado pelo Matheus,
> pois acho que nada na face da Terra e' capaz de convence-lo a fazer
> esse tipo de coisa. ;)

O Matheus a gente convence na base da porrada! :P

> 2) tratar o formato atual como o que quer que signifique "primeira
>    versao"

Hm... hm... discordo, viu. Acho que desde o comeco ja' se deveria
tentar utilizar algo mais... definitivo. Quero dizer, uma base
fixa sobre a qual expansoes sejam possiveis. Essa base deve ser
mantida, com seus erros e acertos, durante toda a vida do JMud.
Dessa forma, ate' mesmo um JMud 1.0 poderia ler um arquivo do
JMud 4.0 (ignorando a sintaxe que nao conhece, ou algo assim).

> Dessa maneira, nao perdemos abruptamente o que ja' foi feito e a
> transicao para um formato "human readable" fica mais suave.

Nah... quanto a perder abruptamente, acho que tem uma solucao
facil chamada conversor. E' so' montar um conversorzinho para
os arquivos, nao e' nenhum bicho de sete cabecas (po, isso ate'
eu sei fazer) :)

Vou estar pensando em novas sugestoes... :P

Abracos:

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

on Thu, 3 Dec 1998 11:47:38, Jose Alexandre Nalon wrote:
| On Thu, 26 Nov 1998, Everton da Silva Marques wrote:
|
| > A intencao inicial nao era que fosse compreensivel diretamente, apenas
| > legivel.
|
| Entao, cabe uma pergunta interessante: por que?

Para que fosse possivel ser modificado via editor de texto. Possivel,
nao necessariamente recomendavel. Aplicando recorrencia: por que? Para
que fosse facil testar, simplesmente criando pequenos mundos com um
editor de texto.

| Com certeza, acrescentam alguma complexibilidade tambem. Mas, sera'
| que este nao seria um mal necessario?

E' a pergunta que estamos tentando responder. Mais detalhes adiante. E
talvez tambem no proximo capitulo. :)

| > Nalon, e' exatamente isso que JA' e' feito. A unica diferenca e' que nao
| > existe o sinal de igual. Ou seja, acho que nao entendi o problema. <:)
|
| Isso JA' e' feito... no arquivo de configuracao. Os outros arquivos
| estao uma zona total.

Voce cortou o seu proprio paragrafo, no qual se nao me engano voce
estava discutindo especificamente o arquivo de configuracao. Inclusive
os exemplos que citou foram tirados de la'. Se eu entendi mal, peco
perdao.

| > 2) facilitar o parsing
|
| O parsing fica muito pouca coisa mais dificil com essas inclusoes.
| Como eu disse, acho que o aumento de complexibilidade traria uma
| melhor compreensao dos formatos e tambem uma maior flexibilidade
| na estruturacao dos arquivos.

Discordo do "pouca coisa". Ate' onde eu posso enxergar, ha' tres
maneiras bem definidas e distintas de se fazer o parsing dos arquivos
do mundo:

1) utilizando um formato rigido para os arquivos, mas com a parsing
    extramamente facil via as facilidades de manipulacao de string de
    Java

2) utilizando um formato mais flexivel, mas com varios pequenos
    parsers escritos ad-hoc para cada palavra-chave (ou mnemonico) dos
    registros

3) definindo uma (ou mais) linguagem(ns) para descrever os arquivos
    e escrevendo um (ou mais) parser(s) com auxilio de alguma
    ferramenta

Como voce sabe, (1) e' o que existe, (2) e' o que eu acho que voce
esta' propondo e (3) e' o que eu consideraria o melhor a se fazer,
caso houvesse necessidade.

| Acredito tambem que o gasto com memoria nos discos nao e' uma
| coisa tao drastica assim. Afinal, memoria esta' cada dia mais
| barato, e um arquivo de mundo nao ia ficar tao grande assim.
| Caso seja esse o problema, que se utilize mnemonicos. Ao inves de
| ZonaInicialdoJavaMudQuandoEsteBootaLidoaPartirdoDiretorioedoArquivoaSeguir,
| utiliza-se apenas algo como InZona, ou ZIn, ou algo parecido.

Nao e' drastico mesmo. Mas nao faz mal economizar.

| Claro, eu sei que voce pretende um dia ter um GUI para gerar os
| arquivos. Eu mesmo me propus a escreve-lo. Mas voce nao pode
| contar com isso sempre. Ademais, se cada pessoa que for implementar
| o JMud precisar desse GUI, esse programa vai ocupar tambem algum
| espaco em disco em algum lugar. Talvez nem tanto quanto o ocupado
| pelo texto representando cada variavel. Mas, em compensacao, nao
| seria necessario um programa especial ou sequer muita compreensao
| do funcionamento do JMud. Com uma pequena lida nos manuais, seria
| possivel com muito mais facilidade colocar o JMud rodando.

Concordo. Exceto pelo fato de que nada melhor do que uma GUI para
poupar o usuario de compreender o funcionamento. :)

| Alem disso, como eu disse, tem a facilidade da escritura dos
| manuais, e eu acho que isso deveria ser levado em conta... Afinal,
| quanto antes a gente tiver os manuais do JMud, melhor. E, caso a
| mudanca seja feita depois, reescrever os manuais, hm...

Ponto pro Nalon.

| Relacao custo/beneficio, lembra? O custo e' perder alguns minutos de
| seu tempo leva ao beneficio de se facilitar a escritura dos manuais,
| e nao se perde tanto tempo assim anotando umas 5 linhas de documentacao...
|
| No momento, acredito que o melhor seria documentar o que ja' existe,
| pra que eu possa mexer com os manuais...

Hmmm...?

Eu pensei que voce estava escrevendo um manual de como "construir
mundos". Desse jeito voce me pega de calcas curtas. De que informacao
documentada exatamente voce precisa? Ha' MUITA coisa sem documentacao
-- se voce precisar de alguma coisa especifica, e' melhor avisar que
eu preparo sob demanda.

E depois desse puxao-de-orelha, documentarei cada componente que eu
implementar daqui por diante. :)

Mas nao posso prometer nada sobre o que for implementado pelo Matheus,
pois acho que nada na face da Terra e' capaz de convence-lo a fazer
esse tipo de coisa. ;)

				  ...

Ah, e sobre a discussao original, a respeito do formato dos arquivos,
acho que voce afetou minha visao errada do mundo. Veja a minha
proposta a seguir.

Proposta: Rumo a uma sintaxe mais intuitiva (tm)

1) introduzir o conceito de versao nos arquivos de mundo (e talvez nos
    demais arquivos de configuracao) -- possivelmente, com uma string
    como cabecalho dos arquivos

2) tratar o formato atual como o que quer que signifique "primeira
    versao"

3) acrescentar gradualmente novas versoes que conviverao com as
    antigas; ou seja, o JMud sempre sera' capaz de entender as versoes
    antigas, e comecara' a enteder as novas eventualmente (= tao cedo
    quanto possivel)

Dessa maneira, nao perdemos abruptamente o que ja' foi feito e a
transicao para um formato "human readable" fica mais suave.

Se voce tiver mais algum comentario, fique `a vontade. Em especial,
talvez voce queira sugerir especificacoes de formatos para alguns
arquivos. Atente apenas, para o obvio: os novos formatos devem pelo
menos conter as mesmas informacoes dos anteriores.


Um abraco,

--
Everton da Silva Marques
mailto:evertonm@...
http://www.dcc.unicamp.br/~evertonm
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Thu, 26 Nov 1998, Everton da Silva Marques wrote:

> A intencao inicial nao era que fosse compreensivel diretamente, apenas
> legivel.

Entao, cabe uma pergunta interessante: por que?

> Como voce vai ver, nao acrescentam apenas compreensibilidade.

Com certeza, acrescentam alguma complexibilidade tambem. Mas, sera'
que este nao seria um mal necessario?

> Nalon, e' exatamente isso que JA' e' feito. A unica diferenca e' que nao
> existe o sinal de igual. Ou seja, acho que nao entendi o problema. <:)

Isso JA' e' feito... no arquivo de configuracao. Os outros arquivos
estao uma zona total.

> 2) facilitar o parsing

O parsing fica muito pouca coisa mais dificil com essas inclusoes.
Como eu disse, acho que o aumento de complexibilidade traria uma
melhor compreensao dos formatos e tambem uma maior flexibilidade
na estruturacao dos arquivos.

Acredito tambem que o gasto com memoria nos discos nao e' uma
coisa tao drastica assim. Afinal, memoria esta' cada dia mais
barato, e um arquivo de mundo nao ia ficar tao grande assim.
Caso seja esse o problema, que se utilize mnemonicos. Ao inves de
ZonaInicialdoJavaMudQuandoEsteBootaLidoaPartirdoDiretorioedoArquivoaSeguir,
utiliza-se apenas algo como InZona, ou ZIn, ou algo parecido.

> Quanto a precisar ou nao ser um compilador, me parece que implementar um
> parser usando uma ferramenta como javacc ou javalex/cup e' a maneira mais
> pratica de se obter o resultado que voce propos.

Bom, como eu disse, e' simples. Nao existe a necessidade de implementar
um parser complexo, so' alguma coisa para ler os tokens apropriados e
o Java tem funcoes para isso. O aumento nao compreensibilidade compensa.
Voce falou em relacao custo/beneficio, e eu acho que esta e' uma situacao
em que o custo e' bem menor que o beneficio obtido.

Claro, eu sei que voce pretende um dia ter um GUI para gerar os
arquivos. Eu mesmo me propus a escreve-lo. Mas voce nao pode
contar com isso sempre. Ademais, se cada pessoa que for implementar
o JMud precisar desse GUI, esse programa vai ocupar tambem algum
espaco em disco em algum lugar. Talvez nem tanto quanto o ocupado
pelo texto representando cada variavel. Mas, em compensacao, nao
seria necessario um programa especial ou sequer muita compreensao
do funcionamento do JMud. Com uma pequena lida nos manuais, seria
possivel com muito mais facilidade colocar o JMud rodando.

Alem disso, como eu disse, tem a facilidade da escritura dos
manuais, e eu acho que isso deveria ser levado em conta... Afinal,
quanto antes a gente tiver os manuais do JMud, melhor. E, caso a
mudanca seja feita depois, reescrever os manuais, hm...

> Voce esta' mais do que certo de querer isso. Mas por enquanto ainda
> achamos que mais importante do que documentar e' fazer. Quando eu me
> pergunto: implemento mais uma feature ou documento a que acabei de fazer,
> a resposta e' imediata! :)

Relacao custo/beneficio, lembra? O custo e' perder alguns minutos de
seu tempo leva ao beneficio de se facilitar a escritura dos manuais,
e nao se perde tanto tempo assim anotando umas 5 linhas de documentacao...

No momento, acredito que o melhor seria documentar o que ja' existe,
pra que eu possa mexer com os manuais...

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."




------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

A versao 0.14 do JMud ja' esta' disponivel.

Pode ser obtida diretamente de:
http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.14.tar.gz

Ou navegando-se a partir da home page do JMud:
http://www.dcc.unicamp.br/~evertonm/jmud/

Principais Novidades
--------------------
. comando privilegiado 'onde'
. comando 'agrupe'
. comando 'siga'
. correcao completa (espero) da localizacao de quadros
. melhoria da aplicacao do JGP: MassiveAction (tm)
. acrescentada documentacao minima sobre execucao do servidor em
   ambiente DOS/Windows

Se o NFS da thor, o sistema de onibus de campinas, as provas e os
projetos finais colaborarem, o JMud podera' evoluir mais rapidamente
daqui por diante. :-)

Aguardamos comentarios, duvidas, sugestoes e criticas em geral.

Um abraco,

--
Everton da Silva Marques
mailto:evertonm@...
http://www.dcc.unicamp.br/~evertonm
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Wed, 25 Nov 1998, Jose Alexandre Nalon wrote:
> Esta lista esta' meio parada, entao deixem-me colocar um tema
> absurdamente controverso. Bom, pelo menos sei que o Udhos nao
> vai gostar... :)

Pelo contrario, acho bom poder pelo menos falar do JMud, ja' que a thor
nao permite implementar. <:)

> E' o seguinte: estou burilando com os formatos de arquivo de
> mundo, e a coisa que mais chama a atencao e' que e' praticamente
> impossivel entender o que significa cada coisa. Alem disso, os
> campos acabam ficando dispostos de uma maneira muito rigida, e
> e' dificil olhar para uma entrada em qualquer um dos arquivos
> e realmente entender o que se passa por la'...

A intencao inicial nao era que fosse compreensivel diretamente, apenas
legivel. Eu explico: realmente nao e' facil entender um registro dos
arquivos do mundo sem uma referencia. Mas, tendo a documentacao em maos,
deveria ser possivel faze-lo.

> Entao, vou dar algumas sugestoes para se alterar os arquivos de
> mundo que, ao meu ver, so' acrescentariam para a compreensibilidade
> da coisa:

Como voce vai ver, nao acrescentam apenas compreensibilidade.

> 1) Identificacao dos campos:
>
>    Ao inves de simplesmente deixar um campo solto ali, que tal
>    identifica'-lo por algum nome? Por exemplo, no arquivo de
>    configuracao, ao inves de simplesmente jogar um numero para
>    a zona inicial, que tal fazer uma variavel chamada ZonaInicial
>    e lhe atribuir um valor? Assim, o arquivo de configuracao
>    ficaria algo parecido com:
>
>    ZonaInicial = <numero da zona>
>    SalaInicial = <numero da sala>
>    DiretorioDeMundo = "<diretorio de mundo>"
>    etc...
>
>    Acho que, alem de ficar mais claro, proporciona alguma flexibi-
>    lidade, ja' que as variaveis poderiam ter a ordem trocada e
>    ficaria muito mais facil incluir, em futuras revisoes do JMud,
>    novos campos.

Nalon, e' exatamente isso que JA' e' feito. A unica diferenca e' que nao
existe o sinal de igual. Ou seja, acho que nao entendi o problema. <:)

> 2) Eliminacao de simbolos "estranhos":
>
>    Por simbolos estranhos, eu quero dizer coisas como "#", "$" e
>    "%". Eu sei que a sintaxe tradicional em arquivos de mundo de
>    MUDs e' essa, mas convem inovar um pouco.
>
>    Ao inves de utilizar esses simbolos, utilize-se tokens apropriados,
>    como "end", "id" e esse tipo de coisa. Assim, um arquivo de zona,
>    por exemplo ficaria algo como:
>
>    ZonaId = zzz
>      ZonaTitle = "Titulo da Zona"
>      Salas = ["salas1.sal", "salas2.sal"]
>      Items = ["itens1.ite", "itens2.ite"]
>      etc...
>    end

Voce tocou num ponto delicado.

Atualmente, os arquivos de mundo do JMud estao formatados de maneira a
atingir dois propositos:
1) minimizar o gasto de espaco
    (o motivo disso e' obvio, reduzir o espaco em disco gasto pelo mundo)
2) facilitar o parsing
    (eu nao queria ter que escrever um mini-compilador, pois achei que
     seria melhor gastar tempo com outras tarefas necessarias ao mud)

Por outro lado, a possibilidade que voce apontou e' muito interessante,
sobretudo se supusermos que seres humanos e' quem lidarao com os arquivos
diretamente. E isso e' verdade no estagio em que o JMud se encontra. Mas
eu tenho a esperanca de um dia ter uma GUI para edicao do mundo.

> 3) Unificacao das linhas de descricao:

Cabe o mesmo comentario que eu fiz acima. O que voce acha?

> Nao creio que coisas assim sejam dificeis de serem implementadas em
> Java, ja' que essa linguagem tem alguns recursos para trabalhar com
> strings, tokens, etc... E tambem nao precisa ser um compilador, e'
> so' reconhecer a variavel, o sinal de igual (que, na verdade vai ser
> ignorado, estando la' apenas para dar clareza) e o valor. Basicamente,
> e' a mesma coisa, so' que com um formato um pouco mais intuitivo.

Nao e' uma questao propriamente de dificuldade. Tem mais que ver com
decisoes de projeto: qual o custo/beneficio de se fazer assim ou assado e
para onde seria mais interessante direcionar os esforcos de implementacao.

Quanto a precisar ou nao ser um compilador, me parece que implementar um
parser usando uma ferramenta como javacc ou javalex/cup e' a maneira mais
pratica de se obter o resultado que voce propos.

> E, BTW, eu gostaria que os implementadores do JMud, a saber, Udhos e
> Matyah, escrevessem sempre o que estao fazendo e como as coisas fun-
> cionam (comandos, itens, etc...). Isso tambem facilitaria na hora de
> escrever os manuais. Nao e' dificil, e' so' manter um textedit aberto
> enquanto programa e anotar o que se esta' fazendo...

Voce esta' mais do que certo de querer isso. Mas por enquanto ainda
achamos que mais importante do que documentar e' fazer. Quando eu me
pergunto: implemento mais uma feature ou documento a que acabei de fazer,
a resposta e' imediata! :)

Hmmm, e tem cabimento abrir um textedit quando se utiliza facilmente o
Emacs pra editar um ou mais arquivos texto.

> Bom, acho que por hoje e' so', mas em breve eu vou estar pensando em
> alguma coisa a respeito dos atributos tambem. :)

Socorro! :)

Errr... mas ja' pense levando em consideracao os fatores que eu
comentei acima.

--
Everton


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Alo!

Esta lista esta' meio parada, entao deixem-me colocar um tema
absurdamente controverso. Bom, pelo menos sei que o Udhos nao
vai gostar... :)

E' o seguinte: estou burilando com os formatos de arquivo de
mundo, e a coisa que mais chama a atencao e' que e' praticamente
impossivel entender o que significa cada coisa. Alem disso, os
campos acabam ficando dispostos de uma maneira muito rigida, e
e' dificil olhar para uma entrada em qualquer um dos arquivos
e realmente entender o que se passa por la'...

Entao, vou dar algumas sugestoes para se alterar os arquivos de
mundo que, ao meu ver, so' acrescentariam para a compreensibilidade
da coisa:

1) Identificacao dos campos:

    Ao inves de simplesmente deixar um campo solto ali, que tal
    identifica'-lo por algum nome? Por exemplo, no arquivo de
    configuracao, ao inves de simplesmente jogar um numero para
    a zona inicial, que tal fazer uma variavel chamada ZonaInicial
    e lhe atribuir um valor? Assim, o arquivo de configuracao
    ficaria algo parecido com:

    ZonaInicial = <numero da zona>
    SalaInicial = <numero da sala>
    DiretorioDeMundo = "<diretorio de mundo>"
    etc...

    Acho que, alem de ficar mais claro, proporciona alguma flexibi-
    lidade, ja' que as variaveis poderiam ter a ordem trocada e
    ficaria muito mais facil incluir, em futuras revisoes do JMud,
    novos campos.

2) Eliminacao de simbolos "estranhos":

    Por simbolos estranhos, eu quero dizer coisas como "#", "$" e
    "%". Eu sei que a sintaxe tradicional em arquivos de mundo de
    MUDs e' essa, mas convem inovar um pouco.

    Ao inves de utilizar esses simbolos, utilize-se tokens apropriados,
    como "end", "id" e esse tipo de coisa. Assim, um arquivo de zona,
    por exemplo ficaria algo como:

    ZonaId = zzz
      ZonaTitle = "Titulo da Zona"
      Salas = ["salas1.sal", "salas2.sal"]
      Items = ["itens1.ite", "itens2.ite"]
      etc...
    end

    onde [<>, <>, ...] denota uma lista de objetos, podendo, logicamente,
    ocupar varias linhas.

    Detalhe: identacao permitida, e' logico.

3) Unificacao das linhas de descricao:

    Varias das descricoes ocupam varias linhas... Seria interessante
    se pudessemos unificar o texto da seguinte forma:

    Description = "<descricao ocupando varias linhas>"

    Assim, um arquivo de sala, por exemplo, teria o seguinte formato:

    SalaId = sss_1
      SalaTitle = "<titulo da sala>"
      Sinonimos = ["sin1", "sin2", ...]
      Description = "<descricao>"
      Properties = PROP1 + PROP2 + PROP3 + ...
      Link = [ <n|s|l|o|c|b> <sala>, <n|s|l|o|c|b> <sala>, ...]
    End

    SalaId = sss_2
      etc...

Nao creio que coisas assim sejam dificeis de serem implementadas em
Java, ja' que essa linguagem tem alguns recursos para trabalhar com
strings, tokens, etc... E tambem nao precisa ser um compilador, e'
so' reconhecer a variavel, o sinal de igual (que, na verdade vai ser
ignorado, estando la' apenas para dar clareza) e o valor. Basicamente,
e' a mesma coisa, so' que com um formato um pouco mais intuitivo.

Isso, alias, facilitaria em muito a compreensao dos manuais, e tambem
a sua escritura. Claro, estou puxando brasa para a minha sardinha... :)

E, BTW, eu gostaria que os implementadores do JMud, a saber, Udhos e
Matyah, escrevessem sempre o que estao fazendo e como as coisas fun-
cionam (comandos, itens, etc...). Isso tambem facilitaria na hora de
escrever os manuais. Nao e' dificil, e' so' manter um textedit aberto
enquanto programa e anotar o que se esta' fazendo...

Bom, acho que por hoje e' so', mas em breve eu vou estar pensando em
alguma coisa a respeito dos atributos tambem. :)

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Jah estah disponivel em:
http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.13.tar.gz

Novidades:

- Autenticacao de usuarios com senha de comprimento arbitrario via hash MD5;
- Comando 'fundos' para ajustar as financas de um personagem.

Mudancas:

- Limitado o numero de repeticoes do comando 'repita';
- Corrigida deteccao de de quadros nao operacionais;
- Melhoria expressiva do modelo de programacao generica;
- Melhoria de performance das buscas;
- Correcao de pequenos bugs.
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Estah vindo meio atrasado, mas eh Welcome Message, nao Mensage.


------------------------------------------------------------------------ZZZXXXZZ\
Z
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

on Tue, 13 Oct 1998 16:08:53, Jose Alexandre Nalon wrote:
| On Fri, 9 Oct 1998, Everton da Silva Marques wrote:
|
| > Nao e' suficiente. O caso mais geral seria um ciclo. Pra resolver,
| > apenas fazendo um percurso em grafo, talvez na carga do mundo.
|
| Que tal permitir um numero maximo de salas na queda? Dependendo,
| por exemplo, de algum atributo fisico do personagem. Por exemplo,
| se o cara tem Corpo ou Vigor 5, ele aguentaria cair (digamos) umas
| 20 salas, depois teria um colapso e morreria... Isso nao seria 100%
| legal, claro, e' uma brecha pro implementor fazer uma "Death Trap",
| mas seria uma solucao.
|

Isso fica um pouco como funcao da implementacao da queda.

|
| E', isso seria a melhor possibilidade mesmo. Um MUD com autodetect,
| hein? :) Existe alguma coisa parecida nos MUDs por ai'?
|

Nao que eu saiba. :)

--
Everton

------------------------------------------------------------------------ZZZXXXZZ\
Z
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Alo!

Primeira mensagem off-topic desta lista (espero que o administrador
nao me expulse por mandar spam...) :P

Bom, ha' algum tempo, nosso amigo Udhos, nao por acaso a pessoa que
implementa o JMUD, sugeriu que comecassemos a pensar em montar algumas
bibliotecazinhas para programacao de jogos simples. Eu, de cara, gostei
da ideia, mas, talvez por falta de iniciativa de nossa parte, nunca mais
se tocou na ideia e ela meio que morreu.

Nos ultimos tempos, tenho me divertido bastante com os jogos da linha
Final Fantasy, e fiquei pensando na possibilidade de programar alguns
CRPGs naquele estilo (mantendo as proporcoes, e' claro, isso seria um
hobby e os resultados seriam puramente para diversao).

Na semana passada, eu e o Fabricio Matheus, nao por acaso o administrador
desta lista, estivemos conversando sobre a possibilidade de montar um
sisteminha simples para visualizacao, que permitiria uma simulacao bem
acochambrada de terceira dimensao, mas que, acredito eu, seria bastante
eficiente para programar pequenas aventurinhas do estilo.

Eu me animei muito com a ideia, tenho o algoritmo completo na minha
cabeca (que permite, inclusive, uma ou outra variacao no ponto de
vista, na perspectiva utilizada, etc. Estou so' esperando uma
oportunidade para levar isso adiante.

A pergunta e': alguem mais desta lista estaria disposto a participar
nessa empreitada? Acredito que o desenvolvimento das rotinas basicas de
animacao, de desenho e outras nao deve ser muito complexo (talvez a
otimizacao para velocidade seja um pouco) e a partir dai' poderiamos
comecar a ter ideias para jogos. Alguem topa?

(Independente disso, eu vou estar trabalhando nessas rotinas. Quero levar
  a coisa adiante. Algumas solucoes basicas ja' podem ser encontradas pela
  Internet. Ontem mesmo encontrei alguns bons sites sobre programacao de
  jogos, com algumas referencias muito boas mesmo, nao so' sobre
  programacao de jogos, como tambem inteligencia artificial, programacao
  evolutiva, computacao grafica, orientacao a objetos, etc.).

E, alias, eu e o Fabricio tambem discutimos a possibilidade de utilizar
essas rotinas em um jogo on-line, e a ideia nao nos pareceu demasiadamente
absurda, desde que alguns pontos fossem mantidos. De repente, o JMUD
poderia evoluir para o primeiro MUD grafico em Java... :)

(Mudando um pouco de assunto, ontem eu finalmente consegui terminar
  o Final Fantasy I. O ultimo boss e' do alem - 2000 HPs, o que e'
  muito em FFI, e uma porcaria de um Heal Total a cada 4 rounds...
  Nao e' moleza).

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________
2X 2X 2X DOUBLE REWARDS POINTS! 2X 2X 2X
Open a new NextCard Internet Visa account with a
qualifying balance transfer and you'll earn DOUBLE
Rewards points. Earn free airline tickets in half the
time! Intro rates as low as 2.9% APR and NO annual fee!
Apply Online NOW!
http://www.nextcard.com/index.html?ref=eteegste06


Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

On Fri, 9 Oct 1998, Everton da Silva Marques wrote:

> Nao e' suficiente. O caso mais geral seria um ciclo. Pra resolver,
> apenas fazendo um percurso em grafo, talvez na carga do mundo.

Que tal permitir um numero maximo de salas na queda? Dependendo,
por exemplo, de algum atributo fisico do personagem. Por exemplo,
se o cara tem Corpo ou Vigor 5, ele aguentaria cair (digamos) umas
20 salas, depois teria um colapso e morreria... Isso nao seria 100%
legal, claro, e' uma brecha pro implementor fazer uma "Death Trap",
mas seria uma solucao.

> Eu acho que o mais razoavel e' aproveitar a saida para baixo mesmo. Se
> a queda for implementada corretamente, isso nao deve causar grandes
> problemas. E o jmud pode fazer um teste ao carregar o mundo e avisar a
> deteccao de ciclos para baixo em salas aereas.

E', isso seria a melhor possibilidade mesmo. Um MUD com autodetect,
hein? :) Existe alguma coisa parecida nos MUDs por ai'?

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________
2.9% 2.9% 2.9% 2.9% 2.9% 2.9% 2.9% 2.9% 2.9%
NextCard Internet VISA has a great introductory APR.
Customers with good credit are eligible for this special rate.
No tricks, no gimmicks - just a great rate for Internet customers!
http://www.nextcard.com/index.html?ref=eteegstr07

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

On Fri, 9 Oct 1998 15:23:13    Jose Alexandre Nalon wrote:
>
>Udhos, ou quem saiba, please, explique:

Vou tentar. :-)

>
>No arquivo de zonas:
>
>  <base><faixa><periodo de automacao>
>
>Isso seria, segundo eu consigo conceber, o numero minimo, o numero
>maximo para as salas daquela zona e o numero de minutos (de jogo)
>em que se reseta a zona?

<base> e <faixa> sao limites "internos" ao jmud. Existem para evitar a
sobreposicao de "coisas" de zonas diferentes. Esses valores permitem, por
exemplo, que itens de zonas distinas sejam criados com os mesmos identificadores
numericos e ainda assim nao colidam.

Na pratica, para cada zona e' alocada uma <base> e uma <faixa>. <base> e' o
valor somado aos IDs de todas as coisas daquela zona. <faixa> e' o numero maximo
de IDs que a zona pode alocar para cada tipo de coisa.

Um exemplo:

Voce esta' criando uma zona com <base> = 1000 e <faixa> = 100. Se voce criar um,
digamos, item com ID = 10,
internamente ele sera' reconhecido pelo JMud como o item 1010. E nessa zona
somente poderao haver os itens de IDs 0 ate' 99 (100 IDs distintos). Note que o
espaco de itens, salas, criaturas, etc e' separado. No caso, pode-se ter 100
itens, 100 criaturas, 100 salas, etc.

A ideia basica aqui e' que o autor de uma zona nao precisa se preocupar com IDs
de outras zonas ao criar a sua. Depois de pronto, a zona dele pode ser
"encaixada"
no mundo. Esse mecanismo tambem permite que o JMud automatize a tarefa de
detectar esse tipo de conflito,
embora isso nao esteja completamente implementado.

Obs.: Agradeca ao Matheus por esse mecanismo.


>
>Esses parametros precisam, por necessidade, estarem na mesma linha?

Sim, para simplificar o parsing.

>
>No arquivo de salas:
>
>  <propriedades>

No momento nao tenho acesso ao JMud para poder citar quais sao. Entretanto, se
nao me engano, esse campo
esta' reservado para expansao futura. Ainda nao deve
existir nenhuma propriedade. Como voce imagina, uma delas sera' algo do tipo
"AEREA".

>
>Please, quais sao as propriedades, quais seus signficados, etc...
>No mesmo arquivo, cada saida tambem tem um campo <propriedades>
>Explicai, please, esse campo tambem.

O mesmo eu digo para as propriedades das salas. Mas aqui eu me lembro que ja'
temos algumas interessantes,
como "fechavel" e "trancavel". Quando puder, envio os detalhes precisos.

>
>Por fim, no arquivo jmud.cfg, todos os nomes de diretorios, zonas,
>etc, sao convencionais, certo? Quero dizer, voce pode colocar o
>seu Diretorio de Mundo em rec/mun, mas se quiser colocar seu mundo
>em /usr/bin, era so' mudar no jmud.cfg, certo?

Exatamente. O proprio jmud.cfg pode ficar em qualquer lugar, desde que
especificado na linha de comando do JMud via flag -c:

java JMud -c /usr/bin/jmud.cfg :-)

>
>Ja' estou escrevendo o arquivo manual, mas ainda esta' muuuuuito no
>comeco. Quando tiver alguma coisa pronta, mando para a lista para
>apreciacao, right?

Excelente.

E lembre-se de que um manual no comeco e' muuuuuito mais do que existe hoje. :-)

Mas talvez fosse melhor colocarmos em uma home page e mandar so' o URL... Se for
o caso, voce envia e eu faco isso.

>
>Alem disso, estou comecando a pensar em um programinha para automatizar
>a criacao de zonas, salas, etc. Escrito em Java, logicamente, para manter
>a portabilidade e a coerencia com o resto do sistema... :)
>

E' uma boa ideia, embora eu ache que o ideal e' um dia implementarmos isso
dentro do JMud. Mas um sistema off-line tambem seria interessantissimo.


--
Everton



-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums
______________________________________________________________________
For the absolute lowest price on software visit:
http://www.bottomdollar.com/egroups/

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

on Thu, 8 Oct 1998 13:59:32, Jose Alexandre Nalon wrote:
| > | A cada sala, se contabilizaria um dano. Assim, a pessoa que estiver
| > | caindo vai receber algum dano pela queda. Algo coerente, e' claro...
| >
| > Ha' um problema aqui: se a saida para baixo levar para a mesma sala ou
| > gerar algum ciclo do tipo, o personagem caira' eternamente,
| > possivelmente travando o sistema. Se for bem feito, travara' apenas o
| > personagem, talvez temporariamente.
|
| Bom, eu tenho duas sugestoes.
|
| A primeira seria nao permitir que uma sala "voadora" tivesse link
| para ela mesma. Isso e' uma certa limitacao, eu reconheco, mas evitaria
| esse pequeno problema.

Nao e' suficiente. O caso mais geral seria um ciclo. Pra resolver,
apenas fazendo um percurso em grafo, talvez na carga do mundo.

|
| A outra seria um link "Caindo", exclusivo para salas voadoras, que
| indicaria onde o personagem cairia. Logico, isso tem alguns problemas.
| Dependendo de quem cria a zona, o camarada pode levantar voo no Brasil
| e cair no Japao, sem se mexer na horizontal.... :P
|

Esse "alguns problemas" e' inevitavel, mesmo que nao haja salas
voadoras. Um designer pode sempre colocar uma porta que conecte o
Brasil ao Japao. O caso de salas voadoras e' apenas um agravante.

Eu acho que o mais razoavel e' aproveitar a saida para baixo mesmo. Se
a queda for implementada corretamente, isso nao deve causar grandes
problemas. E o jmud pode fazer um teste ao carregar o mundo e avisar a
deteccao de ciclos para baixo em salas aereas.

E fica a possibilidade de criar uma "queda eterna" para zonas mais
exoticas. :)

--
Everton

______________________________________________________________________
The Weather Underground. We provide weather across the world.
Visit http://www.wunderground.com

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Udhos, ou quem saiba, please, explique:

No arquivo de zonas:

   <base><faixa><periodo de automacao>

Isso seria, segundo eu consigo conceber, o numero minimo, o numero
maximo para as salas daquela zona e o numero de minutos (de jogo)
em que se reseta a zona?

Esses parametros precisam, por necessidade, estarem na mesma linha?

No arquivo de salas:

   <propriedades>

Please, quais sao as propriedades, quais seus signficados, etc...
No mesmo arquivo, cada saida tambem tem um campo <propriedades>
Explicai, please, esse campo tambem.

Por fim, no arquivo jmud.cfg, todos os nomes de diretorios, zonas,
etc, sao convencionais, certo? Quero dizer, voce pode colocar o
seu Diretorio de Mundo em rec/mun, mas se quiser colocar seu mundo
em /usr/bin, era so' mudar no jmud.cfg, certo?

Ja' estou escrevendo o arquivo manual, mas ainda esta' muuuuuito no
comeco. Quando tiver alguma coisa pronta, mando para a lista para
apreciacao, right?

Alem disso, estou comecando a pensar em um programinha para automatizar
a criacao de zonas, salas, etc. Escrito em Java, logicamente, para manter
a portabilidade e a coerencia com o resto do sistema... :)

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________
The Weather Underground. We provide weather across the world.
Visit http://www.wunderground.com

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Alo, povo!

> Snapshot 0.12 dispon=EDvel em:
> http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.12.tar.gz
>
> O sistema de lojas operacional =E9 a principal novidade, acompanhada de=
>
> pequenas corre=E7=F5es localizadas.

Seguinte: que tal combinarmos um dia mais ou menos bom para todo mundo
para eu rodar o JMud toda semana na Berilio? Eu nao poderia garantir
muito tempo para rodar, eu ainda nao sei se os administradores podem
ver que tem algo "estranho" rodando por la' e se eles podem achar ruim,
mas... sempre tem uma desculpa boa para se dar.

(Como a gente nao esta' jogando, mas testando o programa, eu poderia
  falar que o Udhos nao tem como rodar o programa no DCC e eu achei
  que nao tinha problema rodar na Berilio... Como dizia o ex-sysad do
  DECOM, e' mais facil conseguir perdao que permissao). :)

O melhor dia pra mim e' na quinta-feira, a partir das 4 e meia da tarde,
ate' a hora de bandejar. Ou, talvez, durante algum tempo depois do
bandejao na quinta-feira tambem.

O que voces acham?

PS: Udhos, nao use acentos... :P

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________
For the absolute lowest price on Computer Hardware visit:
http://www.bottomdollar.com/egroups/


Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> | A cada sala, se contabilizaria um dano. Assim, a pessoa que estiver
> | caindo vai receber algum dano pela queda. Algo coerente, e' claro...
>
> Ha' um problema aqui: se a saida para baixo levar para a mesma sala ou
> gerar algum ciclo do tipo, o personagem caira' eternamente,
> possivelmente travando o sistema. Se for bem feito, travara' apenas o
> personagem, talvez temporariamente.

Bom, eu tenho duas sugestoes.

A primeira seria nao permitir que uma sala "voadora" tivesse link
para ela mesma. Isso e' uma certa limitacao, eu reconheco, mas evitaria
esse pequeno problema.

A outra seria um link "Caindo", exclusivo para salas voadoras, que
indicaria onde o personagem cairia. Logico, isso tem alguns problemas.
Dependendo de quem cria a zona, o camarada pode levantar voo no Brasil
e cair no Japao, sem se mexer na horizontal.... :P

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________
For the absolute lowest price on Computer Hardware visit:
http://www.bottomdollar.com/egroups/


Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Snapshot 0.12 dispon=EDvel em:
http://www.dcc.unicamp.br/~evertonm/jmud/files/jmud-0.12.tar.gz

O sistema de lojas operacional =E9 a principal novidade, acompanhada de=

pequenas corre=E7=F5es localizadas.

--=20
Everton

______________________________________________________________________
For the absolute lowest price on Computer Hardware visit:
http://www.bottomdollar.com/egroups/


Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Até que se prove o contrário, este é o primeiro servidor de Mud totalmente em
português e desenvolvido em Java. Ainda se encontra em estágio alfa, mas você
já pode pegá-lo para experimentar.
Essa lista visa manter os interessados e colaboradores a par do atual estágio
de desenvolvimento.  Mas também se destina a receber e discutir  sugestões  e
eventuais dúvidas que possam surgir sobre como utilizar o servidor.

A mais rescente versão oficial pode ser encontrada em:
http://www.dcc.unicamp.br/~evertonm/jmud/

Ele é distribuído sob a Licença Pública GNU:
http://www.gnu.org/copyleft/gpl.html

Java Multi-User Domain Group:
URL:         http://www.eGroups.com/list/jmud
E-MAIL:      jmud@egroups.com
Subscribe:   jmud-subscribe@egroups.com
Unsubscribe: jmud-unsubscribe@egroups.com
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

on Wed, 7 Oct 1998 16:29:44, Jose Alexandre Nalon wrote:
|
| Como o JMud vai trabalhar com voo? Digo, acredito que devem existir
| algumas salas que so' se pode atingir "voando", right? Bom, se nao,
| esta e' uma sugestao de implementacao... :)

Futuramente, com certeza, mas a dica esta' anotada.

|
| A sugestao que eu, em minha humilde posicao de nao conhecedor do
| codigo, posso dar e' que cada sala tenha um flag (do tipo VOANDO).
| Quando setado, a pessoa so' poderia acessar essa sala se pudesse
| voar.
|

Coincide com o que eu imaginava.

| O que me da' uma outra ideia: as salas deveriam sempre ter uma
| saida para "baixo". Assim, se o personagem perde a capacidade de
| voar, ele "cairia", ou seja, iria para a sala de baixo. Se a sala
| de baixo for tambem do tipo que so' se atinge voando, ele "cairia"
| de novo. O efeito, segundo eu consigo visualizar, seria ate' interes-
| sante... As descricoes das salas rolando pra cima iam ficar muito
| parecidas com o efeito de cair mesmo... :)
|
| A cada sala, se contabilizaria um dano. Assim, a pessoa que estiver
| caindo vai receber algum dano pela queda. Algo coerente, e' claro...
|

Ha' um problema aqui: se a saida para baixo levar para a mesma sala ou
gerar algum ciclo do tipo, o personagem caira' eternamente,
possivelmente travando o sistema. Se for bem feito, travara' apenas o
personagem, talvez temporariamente.

--
Everton
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Mais uma sugestao.

Seria uma boa se o administrador desta lista fizesse um "log" de todas
as mensagens que por acaso ocorressem de serem enviadas para a lista.
Assim, quando o JMud for um sucesso total, essas mensagens seriam
documentos historicos para a mitologia do programa. :)

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Alo!

Como minha primeira mensagem a esta movimentada lista, eu tenho
uma pequena perguntinha a fazer.

Como o JMud vai trabalhar com voo? Digo, acredito que devem existir
algumas salas que so' se pode atingir "voando", right? Bom, se nao,
esta e' uma sugestao de implementacao... :)

A sugestao que eu, em minha humilde posicao de nao conhecedor do
codigo, posso dar e' que cada sala tenha um flag (do tipo VOANDO).
Quando setado, a pessoa so' poderia acessar essa sala se pudesse
voar.

O que me da' uma outra ideia: as salas deveriam sempre ter uma
saida para "baixo". Assim, se o personagem perde a capacidade de
voar, ele "cairia", ou seja, iria para a sala de baixo. Se a sala
de baixo for tambem do tipo que so' se atinge voando, ele "cairia"
de novo. O efeito, segundo eu consigo visualizar, seria ate' interes-
sante... As descricoes das salas rolando pra cima iam ficar muito
parecidas com o efeito de cair mesmo... :)

A cada sala, se contabilizaria um dano. Assim, a pessoa que estiver
caindo vai receber algum dano pela queda. Algo coerente, e' claro...

---
Jose' Alexandre Nalon
nalon@...

"You raise the blade, you make the change,
  you rearrange me till I'm sane.
  You lock the door and throw away the key,
  There's someone in my head, but it's not me."


______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Outro teste. Culpa do moderador.

-----
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Isto e' um teste, quer voce acredite quer nao.

--
Everton da Silva Marques     | Universidade Estadual de Campinas
evertonm@...      | Instituto de Computacao
www.dcc.unicamp.br/~evertonm | Campinas (SP)
PGP public key is available  | Brasil

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.