XMagazine

Tenho visto muitos servidores com mapas geométricos. Sim, mesmo com muita gente reclamando disso, os mapas continuam com as bordas “quadradas”! Todo mundo sabe que é feio, e mostra que o mapper é desqualificado ou precisa aprender muito antes de voltar a mexer com mapas. O que eu quero dizer é que vejo muitos mapas deste tipo: Mapa quadrado Definitivamente não fica legal, não é? Pois bem, muitos também acham que simplesmente fazendo uma diagonal ou aleatorizando um pouco os formatos resolve o problema da geometria. De fato não resolve: Mapa mal-feito Tsc, tsc, tenho pena de quem acha que assim fica bonito. Serve, se for um mapa enorme e você tiver pressa, mas se você quer mesmo fazer alguma coisa bonita, lembre-se que a Terra é completamente irregular! Mapa correto Não que esse esteja perfeito, mas é a base do que deve ser feito nesse quesito. Com certeza está muito melhor do que 90% dos que se encontra por aí, e é muito fácil de fazer com as novas facilidades dos editores modernos, como bordas automáticas, chão aleatório e doodad. Vale também dizer que é preguiça de dar uma chacoalhada no mouse para fazer umas pontas nas bordas, isso vai te levar no máximo 1 hora pra fazer num mapa de 20 MB. Abraços, Lordfire >>> Leia na XMagazine

Tenho visto muitos servidores com mapas geométricos. Sim, mesmo com muita gente reclamando disso, os mapas continuam com as bordas “quadradas”! Todo mundo sabe que é feio, e mostra que o mapper é desqualificado ou precisa aprender muito antes de voltar a mexer com mapas. O que eu quero dizer é que vejo muitos mapas deste tipo: Mapa quadrado Definitivamente não fica legal, não é? Pois bem, muitos também acham que simplesmente fazendo uma diagonal ou aleatorizando um pouco os formatos resolve o problema da geometria. De fato não resolve: Mapa mal-feito Tsc, tsc, tenho pena de quem acha que assim fica bonito. Serve, se for um mapa enorme e você tiver pressa, mas se você quer mesmo fazer alguma coisa bonita, lembre-se que a Terra é completamente irregular! Mapa correto Não que esse esteja perfeito, mas é a base do que deve ser feito nesse quesito. Com certeza está muito melhor do que 90% dos que se encontra por aí, e é muito fácil de fazer com as novas facilidades dos editores modernos, como bordas automáticas, chão aleatório e doodad. Vale também dizer que é preguiça de dar uma chacoalhada no mouse para fazer umas pontas nas bordas, isso vai te levar no máximo 1 hora pra fazer num mapa de 20 MB. Abraços, Lordfire >>> Leia na XMagazine

O OpenTibia ao contrário de vários projetos de servidores privados de diversos jogos está num estágio bastante avançado. Possuímos cerca de 90% ou mais dos sistemas que o Tibia oferece, uma quantidade considerável de colaboradores, diversas comunidades muito boas e uma flexibilidade para se criar novos sistemas incrível. Muitos conheceram meus dois famosos projetos denominados BlackOnix e Elementaria. Revolucionamos e quebramos vários dilemas do que pode ser feito com as ferramentas que o OTServ providencia. Apesar disso, o projeto nunca vingou devido as tantas promessas de novos códigos que fazíamos e que com um pouco de falta de organização, foram sendo perdidos ou mesmo descartados. Resultado disso, quando tivemos uma pré-estréia as funcionalidades normais de um servidor estavam comprometidas justamente por não terem sido planejadas. Hoje por experiência posso dizer que o sucesso de um projeto nem sempre estão nas promessas do diferencial de um servidor, as vezes esses detalhes servem apenas para mostrar o quão experiente é o servidor, mas que não necessariamente são indispensáveis para o sucesso deste. Foque no que o jogador quer, e não no que ele um dia gostaria de ver em um servidor. Ao criar um servidor ou mesmo manter um lembre-se que uma falha em algum sistema que o jogador já conheçe é mais grave do que uma ausência de um sistema “cool” nunca antes visto. Isso vale também para historinhas interessantes, mapas esdrúxulos e outras novidades sem muito nexo ao gameplay. Por mais que você crie um servidor custom este jamais irá fugir muito da jogabilidade do Tibia, e se mesmo assim acontecer, é arriscado os próprios jogadores não saberem o que fazer com tanta novidade. Nostradamus Desenvolvedor, OpenTibia Team. >>> Leia na XMagazine

Uma das coisas que mais me fascina em OpenTibia é a facilidade e o incentivo dado pelos desenvolvedores aos usuários de poderem modificar, adicionar ou mesmo remov Foi descoberto uma falha crítica no projeto OpenTibia, é necessário que todos atualizem seus servidores com o último release OpenTibia ou distros baseadas neste. >>> Leia na XMagazine

Tenho visto muitos servidores com mapas geométricos. Sim, mesmo com muita gente reclamando disso, os mapas continuam com as bordas “quadradas”! Todo mundo sabe que é feio, e mostra que o mapper é desqualificado ou precisa aprender muito antes de voltar a mexer com mapas. O que eu quero dizer é que vejo muitos mapas deste tipo: Mapa quadrado Definitivamente não fica legal, não é? Pois bem, muitos também acham que simplesmente fazendo uma diagonal ou aleatorizando um pouco os formatos resolve o problema da geometria. De fato não resolve: Mapa mal-feito Tsc, tsc, tenho pena de quem acha que assim fica bonito. Serve, se for um mapa enorme e você tiver pressa, mas se você quer mesmo fazer alguma coisa bonita, lembre-se que a Terra é completamente irregular! Mapa correto Não que esse esteja perfeito, mas é a base do que deve ser feito nesse quesito. Com certeza está muito melhor do que 90% dos que se encontra por aí, e é muito fácil de fazer com as novas facilidades dos editores modernos, como bordas automáticas, chão aleatório e doodad. Vale também dizer que é preguiça de dar uma chacoalhada no mouse para fazer umas pontas nas bordas, isso vai te levar no máximo 1 hora pra fazer num mapa de 20 MB. Abraços, Lordfire >>> Leia na XMagazine

Foi descoberto uma falha crítica no projeto OpenTibia, é necessário que todos atualizem seus servidores com o último release OpenTibia ou distros baseadas neste. >>> Leia na XMagazine

Nem sempre funcionalidade e inovação andam lado a lado. Veja porque é necessário certo balanceamento nesses fatores. >>> Leia na XMagazine

Descubra como a questão detalhamento deve ser compreendida pelo criador do mapa. >>> Leia na XMagazine

Detalhes, uma questão que gera bastante discussão. As pessoas dizem umas às outras suas opiniões sobre eles, nas não há conclusão. Há quem comente que, em excesso, deixam um mapa feio, e são até mesmo acusados de causar lentidão e travamentos no jogo. Existem dois pontos básicos para o detalhamento do seu mapa, mas esse é um ponto que deve ser avaliado e modificado pelo criador do mapa. O ponto 1 é a beleza: um mapa bem detalhado é um mapa que, sem atrapalhar jogadores, torna-se ao mesmo tempo bonito e informativo. Detalhes que não atrapalham não são o que falta: podem ser tufos de grama, pequenos pedaços de pedra ou terra, pedras que se pode caminhar por cima, enfim, uma grande variedade. O maior problema é a dificuldade de balancear estes itens, colocá-los de forma em que não sujem a imagem. Mapa feio: vegetação mal-feita, poucos detalhes Mapa bonito: vegetação trabalhada, muitos detalhes Como não dá de fazer um mapa apenas por beleza, aí entra o segundo ponto: a jogabilidade. O que é a jogabilidade? É a capacidade de um mapa de ser simples e fácil de compreender pelos jogadores, como placas e caminhos, e ao mesmo tempo ser amedrontante, como cavernas pegando fogo, ou caminhos sobre a lava. Também a variedade de combinações de itens e decoração influencia nesse ponto. Ninguém suporta ficar o dia inteiro caçando em uma caverna sempre com o mesmo estilo, numa montanha sempre igual caçando os mesmos monstros. Significa variar, fazer o jogo ser divertido pra quem joga e pra quem cria! Mapa sem jogabilidade: muita natureza, pouca informação, repetido Mapa com jogabilidade: árvores moderadas, boas trilhas, variado Fica aí a minha dica sobre detalhes: tente sempre se ver como se você estivesse jogando e se questione: vai ficar bom? Bonito? Dá pra caminhar pelo mapa sem esbarrar em árvores e arbustos? Boa sorte, Lordfire >>> Leia na XMagazine

O OpenTibia ao contrário de vários projetos de servidores privados de diversos jogos está num estágio bastante avançado. Possuímos cerca de 90% ou mais dos sistemas que o Tibia oferece, uma quantidade considerável de colaboradores, diversas comunidades muito boas e uma flexibilidade para se criar novos sistemas incrível. Muitos conheceram meus dois famosos projetos denominados BlackOnix e Elementaria. Revolucionamos e quebramos vários dilemas do que pode ser feito com as ferramentas que o OTServ providencia. Apesar disso, o projeto nunca vingou devido as tantas promessas de novos códigos que fazíamos e que com um pouco de falta de organização, foram sendo perdidos ou mesmo descartados. Resultado disso, quando tivemos uma pré-estréia as funcionalidades normais de um servidor estavam comprometidas justamente por não terem sido planejadas. Hoje por experiência posso dizer que o sucesso de um projeto nem sempre estão nas promessas do diferencial de um servidor, as vezes esses detalhes servem apenas para mostrar o quão experiente é o servidor, mas que não necessariamente são indispensáveis para o sucesso deste. Foque no que o jogador quer, e não no que ele um dia gostaria de ver em um servidor. Ao criar um servidor ou mesmo manter um lembre-se que uma falha em algum sistema que o jogador já conheçe é mais grave do que uma ausência de um sistema “cool” nunca antes visto. Isso vale também para historinhas interessantes, mapas esdrúxulos e outras novidades sem muito nexo ao gameplay. Por mais que você crie um servidor custom este jamais irá fugir muito da jogabilidade do Tibia, e se mesmo assim acontecer, é arriscado os próprios jogadores não saberem o que fazer com tanta novidade. Nostradamus Desenvolvedor, OpenTibia Team. >>> Leia na XMagazine

Aprenda como planejar um projeto e fazer com que este faça sucesso. >>> Leia na XMagazine

Não é desconhecido o fenômeno das grandes equipes que nunca conseguem terminar um projeto, todos nós já vimos inúmeros nomes ao longo da história dos OTServers que chamaram muita atenção, mas que, no entanto, nunca cumpriram o que prometeram. Não sei se sou especialista no assunto, mas já vivi mais de quatro anos no mundo dos OTServers e estou com a mesma equipe, com o mesmo servidor on-line, desde então. Durante esse período aprendi a melhor lição que poderia ter aprendido, a experiência me mostrou algo que hoje infelizmente poucas pessoas enxergam, com o tempo eu acabei descobrindo os segredos, ou melhor dizendo, os fatores, já que de segredos não tem nada, necessários para se manter uma equipe ativa por tanto tempo. Seria difícil trazer todos de uma vez, mas prometo que com o tempo irei compartilha-los um a um. O primeiro deles, e talvez o mais importante, me exigiu uma série de fracassos em outras equipes para ser entendido, comecei no mundo dos OTServers cedo, na época em que houses, skull system ou até um simples depot eram sonhos em nossas mentes, e já naquela época posso me lembrar de grandes projetos, com inúmeras promessas e dezenas de membros, todos, claro, famosos. Porém, conforme se mostrou depois, todos estes magníficos nomes caíam, um a um, exauridos pelo o que mais usavam para se vangloriar, os nomes, a reputação. Me perguntei por muito tempo como todos estes projetos não afloravam, e no entanto diversos outros, sem nome algum, eram erguidos e conquistavam boa posição. Grandes projetos recebem uma enorme expectativa, muita especulação e um tanto de divinização, se assim posso chamar, é o excesso de “puxa-sacos”, de seguidores sem cérebro que enaltecem tudo o que é feito no projeto, mas que, na verdade, envenenam os criadores com seus próprios egos, esta é a fórmula ideal para qualquer projeto falir, ter nome antes de um corpo para o receber, ter ideias inovadoras antes de conseguir sequer fazer o mais fácil. Por outro lado, vemos alguns projetos pequenos, com mapas ruins, pessoas desconhecidas e quase sem qualquer estrutura que crescem e acabam por conquistar muito além do que fora imaginado, isso parece um tanto injusto, não? Não. Não parece. Na verdade isso me parece extremamente justo, e eu agora vou dizer o porquê, vou lhes dar agora o primeiro fator que havia prometido, algo que poderia fazer em páginas e mais páginas de textos, mas que irei resumir na próxima frase: O segredo para um bom projeto e uma grande equipe é simples, não são grandes nomes que fazem grandes servidores, mas grandes servidores que fazem grandes nomes. É nisso que eu gostaria que vocês pensassem quando forem começar um projeto, eu devo primeiro fazer as coisas simples ou começar pensando nas ideias inovadoras? Devo contratar um colega pelo seu nome, ou pelo seu trabalho? Eu achei as minhas respostas, e espero que todos aqui também consigam fazê-lo. Kaupert, W. Administrador, PH3.tz >>> Leia na XMagazine

Saiba através do nosso colunista Baracs, administrador de um dos maiores OTServers, Darghos Server os problemas que ataques DdoS causam no mundo do OpenTibia. >>> Leia na XMagazine

No mundo do Open Tibia de hoje em dia, é dificil encontrar algum administrador de OTServ, que nunca teve, nunca enfrentou, ou nunca se deparou, com problemas enormes, que de início, deu impressão que não teria solução. Pessoalmente administro o servidor Darghos, antigo Ultrax Server, o mesmo se encontra a bastante tempo online, eu e meus companheiros de equipe, como muitos outros, já tivemos, e ainda temos, milhares de problemas a serem resolvidos. Fomos perto do fundo do poço, sim, o fundo do poço mesmo, graças ao mundo paralelo que existe dentro da internet. Com estes sites ignorantes, onde pessoas com alto conhecimento, fazem ferramentas hackers e distribuem gratuitamente elas, segundo eles, para ampliar o conhecimento dos usuários, acontece que amplia o conhecimento de apenas 10% de quem usa, os outros 90% geralmente se vingam, ou apenas decidem estragar com o trabalho digno de alguém. Essas ferramentas geralmente caem na mão de quem jamais deveria cair, existem pessoas que JAMAIS deveriam ter acesso a coisas poderosas, como o uso de links de máquinas dedicadas, para enviar floods a outras máquinas(DDoS). A enorme “Telefonica” que oferece serviços de telefonia, celular e internet, de São Paulo, a pouco tempo atrás, passou alguns dias sem fornecer seus serviços de internet, o motivo: ataques de negação de serviço, na sigla americana, DDoS. Dentro do mundo dos OTServers isso corre com mais de 50% dos servidores online, jogadores revoltados que não deveriam possuir b#####s(maquinas zoombies), mas possuem, acabam usando elas facilmente com o uso de algum tutorial encontrado por aí, contra o servidor, estragando a jogabilidade de todos outros jogadores que jogam humildimente. Fora o prejuízo que isso trás ao proprietario do servidor, que banca mensalmente uma máquina dedicada, para rodar o mesmo. Tem que ficar muito claro, que os denominados “Nukers“, não são realmente nada, pois na verdade quem desenvolve essas ferramentas que eles usam, são gringos com muita experiência, e falta do que fazer. Geralmente os nukers denominam-se, os “bolados” da situação, que eles são os perigosos da história etc, mais não são nada, são apenas pessoas que desfrutam de coisas desenvolvidas por outros. Você nunca irá ver hackers que desenvolvem scripts de shell, atacando um OTServer. Atualmente, técnicas de proteção existem, mais requer e exige bastante conhecimento da parte do usuário, no caso os administradores do servidor, tanto sistemas operacionais Windows ou compilações do Linux, possuem boas barreiras para isso. Mais você não irá fazer uma alta proteção com 5 cliques e um tutorial na internet, por isso é necessário muita dedicação e estudo sobre estes assuntos. Baracs Administrador, Darghos Server. >>> Leia na XMagazine

Melhore suas técnicas de desenvolvimento de algoritmos com dicas de como juntar performace e flexibilidade para tornar seu sistema o melhor possível. >>> Leia na XMagazine

Uma das coisas que mais me fascina em OpenTibia é a facilidade e o incentivo dado pelos desenvolvedores aos usuários de poderem modificar, adicionar ou mesmo remover alguma funcionalidade por meio de scripts. Com isso, é possível que muitas pessoas leigas no assunto possam fazer muitos códigos, que por mais que funcionem, podem pecar quando o assunto é desempenho. É necessário então uma otimização nos sistemas, e para isso, elaborei algumas formas de melhorar estes processos: 1. Veja se seu sistema realmente quer melhorias É normal ver programadores criticando outras pessoas por falarem que o algoritmo não está tão eficiente como poderia estar. Porém, não ache que ele é o dono da verdade, muitas vezes otimizar algum sistema é sinônimo de abdicar de alguns recursos que a forma que fora desenvolvido o proporciona. Algumas vezes você melhora a performace à custa de perder flexibilidade. Outras vezes, uma alteração para melhorar a performace agora poderá ter um custo adicional em manutenção do sistema no futuro. 2. Cuidado ao usar recursividade Recursividade é uma técnica bastante útil para definir-se algo parcialmente em termos de si mesmo. Podemos usar em programação para chamar funções dentro delas mesmas. Exemplos clássicos disso são algoritmos como o de fatorial ou mesmo da série Fibonacci. Apesar de facilitar a vida do programador, a recursão usa mais memória do sistema para acomodar variáveis a cada chamada. Além disso, o estado corrente da computação tem que ser armazenado para permitir a volta da chamada recursiva. É recomendado então, não usar algoritmos recursivos quando existe uma solução óbvia por interação, tais como uma razão de termos que seja comum. 3. Escolha entre temporaridade ou espaço Infelizmente quando queremos um sistema efetivo, é preciso escolher entre ter o menor tempo de execução possível ou uso de menos espaço. Tenha em mente que para avaliar a complexidade de seu algoritmo qual desses dois fatores deseja otimizar 4. Evite açúcares A maioria das linguagens usam diversos syntax suggars que nada mais são que “atalhos” para acesso de um recurso que não é muito elegante. Em gerenciamento de software o uso deste recurso é bem utilizado, porém, infelizmente se o objetivo é performace, deve-se evitar quando possível. 5. Tome cuidado em controles de fluxo A principal maneira de se otimizar um sistema é checando pelos controladores de fluxo deste. Condições Caso tenha uma série de condições, começe com as mais usuais e eficientes (interpretadas com facilidade). Caso seja mais normal de acontecer uma condição mesmo que esta seja menos eficiente, ignore o passo (1). Use nas condições ?atalhos? com os operadores ?or? e ?and? para evitar condições dentro de condições. Evite comparar strings, pois ao fazer isso você checa cada letra, e isso pode ser prejudicial. Sempre que possível, use os operadores lógicos ?or? e ?and? diretamente nas expressões ao invés de condições dentro de outras condições. Laços de repetição Em loops para vetores indexados por números dê preferência por: for _, v in ipairs(vetor) do -- código end O ?_? serve para pular o retorno e também para variáveis temporárias Se caso o loop for para vetores indexados por outros vetores usar: for k, v in pairs(vetor) do -- end Não declare variáveis em loops que não forem modificadas neste, isso serve para chamadas de funções: for i = 1, 10000 do local x = math.sin(I) end O processamento do exemplo acima é 30% mais lento do que: local sin = math.sin(I) for i = 1, 10000 do local x = sin end 6. Não confie no garbage collector Esteja atento à criação de objetos temporários quando se passa parâmetros do tipo class de/para funções. Seu programa pode perder muito tempo criando e destruindo objetos temporários, independentemente do compilador e da plataforma. Apesar de Lua, Java entre outras linguagens possuirem garbage collector (GC), pode ser que estes não hajam da forma mais adequada. Além disso, é uma boa prática caso você um dia migre para uma linguagem que não conte com esse recurso. >>> Leia na XMagazine

Mais uma revisão no OpenTibia está a caminho, e esta promete revolucionar o modo de se criar scripts. Veja mais detalhes sobre o revscriptsys clicando aqui. >>> Leia na XMagazine

Que a equipe de desenvolvimento do OpenTibia sempre revisa seus sistemas isso não é novidade. E agora, está prestes a ser terminado uma revisão no sistema de scripting que irá quebrar com todas as compatibilidades entre scripts Lua já desenvolvidos: trata-se da revscriptsys. Idealizada por Nostradamus e posta em prática por Remere, a revscriptsys tem como objetivo quebrar as barreiras que servem de limite para o scripter. Quando lançada, o OpenTibia estará na versão 0.7.0. Uma das maiores novidades é que todas as funções Lua e objetos serão tratados como classes ao invés de funções livres. A vantagem disso é que insere estruturas lógicas mais bem feitas, o que influencia principalmente na hora de se desenvolver sistemas maiores. Veremos abaixo as novidades que serão inseridas ao OpenTibia: XML Em todo tempo de existência do projeto OpenTibia os arquivos XML sempre estiveram presentes, sejam para armazenar dados (que por sinal não é usado como banco de dados mais, graças ao revdbsys), seja para registrar eventos. No revscriptsys, o uso do XML irá sumir na maior parte dos casos. Registros de magias, npcs e ações em geral não serão mais feitos por via desse formato e sim pelas dinâmicas tabelas da linguagem Lua. Apenas os monstros irão ser feitos em XML, pelo menos por agora. Mudanças na estrutura As já conhecidas pastas “actions”, “talkactions”, “movements”, “creaturevents” deixarão de existir e serão integradas de forma mais dinâmica. Essa divisão ao ponto de vista dos desenvolvedores mais avançados “limitavam o desenvolvimento de sistemas avançados”. Scripts não como widget, mas como necessidade A source do OpenTibia antigo era bastante instável e ilegível por haverem códigos que poderiam ser feitos com facilidade em scripting. Isso as vezes tornava difícil encontrar códigos de extrema importância que serviam de bases para os demais. No revscriptsys todos esses códigos agora passarão a ser por via de scripting, através dos novos eventos é possível fazer muito mais sistemas que não precisam alterar o código-fonte do servidor, o que ajuda e muito na estabilidade. Objetos Items, Players, Tile e etc são agora representados como objetos. E como um objeto, este pode ser manipulado em funções membras. item = createItem(2543) -- Cria um objeto de um item de ID 2543 (bolt) item:setCount(88) -- Configura a quantidade do ID 2543 para 88 (88 bolts) Objetos podem além de ser criados por scripts como acima também serem retornados por ambientes de trabalho ou funções de captura de dados. Por exemplo, para pegar o item do topo do tile da posição 1024, 1024, 7: tile = map:getTile(1024, 1024, 7) -- Pega o objeto referente a posição 1024, 1024, 7 item = tile:getTopItem() -- Retorna a partir daí, o item que está no topo do file (item mais acima) Objetos são sempre persistentes. Isso significa que se você linka uma referência a um objeto, você então poderá armazená-la ou modificá-la sempre (a não ser que este seja destruído por causas naturais), a única forma “não-natural” que destrói um objeto é: Itens contáveis: Quando dois itens contáveis separados são juntados em um só (por exemplo, adicionando uma pilha de 10 bolts com outra pilha de 20 bolts), um dos objetos são destruídos (qual deles não se sabe). Logout de players: Se um jogador sai do jogo e logo depois volta todos os itens que este carrega irão perder suas referências (como se tais itens fossem removidos e recriados novamente). Métodos são chamados em objetos usando o operador “:“. Chamar um método em objetos inválidos irá sempre causar uma excessão não caminhada. É possível verificar isso através de uma condição if simples: item = map:getTile(1024,1024,7):getTopItem() if item then -- Item válido! else -- Erro: Item inválido. end Eventos O revscriptsys é dotado de um poderoso sistema de manipulação de eventos que permitem que eventos sejam executados em runtime assim como modificações de parâmetros de eventos. Eventos são tratados usando register functions. Essas funções usam como referência parâmetros que especificam como este deve procedir e um callback que será executado quando a função ocorrer. Um exemplo é o evento onSpeak: function testCallback(event) -- Faz alguma coisa quando alguém diz "teste" end --[[ Os argumentos são, em ordem, tipo de equivalência, case sensitivy, a string a ser analizada, função callback ]] registerGenericOnSayListener("substring", false, "teste", testCallback) >>> Leia na XMagazine