Podcasts
Tão logo veio e já vai partindo. A empresa que criou o jogo Earth Eternal, um MMO grátis com temática furry que roda dentro do browser, anunciou recentemente que faliu e está com seus papéis a venda no mercado.
Após angariar fundos que giram em torno de US$4.250.000,00 (quase 7 milhões e meio de reais) em 2008, a Sparkplay, dona do EE desenvolveu e lançou o jogo em outubro de 2009. Mas o jogo grátis não conseguiu emplacar e obviamente, os custos para manter o jogo e os funcionários continuaram corroendo os cofres da Sparkplay.
“Eu tive que demitir todos da nossa equipe na última sexta-feira [13 de agosto] exceto dois, e provavelmente na semana seguinte nenhum de nós estaremos mais empregados na Sparkplay”, disse Matt Mihaly, o quase ex-presidente da Sparkplay.
Mas de acordo com Matt, a empresa recebeu algumas ofertas de compra, e por conta de uma possível venda, ela decidiu dar o último suspiro e manter os servidores on-line até esgotar o contrato com a empresa de hosting. Após isso, os servidores serão desligados e todo o universo de Earth Eternal desaparecerá, não restando nem uma poeira cósmica para contar história.
Matt ainda completou que é incerto se a empresa que adquirir a Sparkplay continuará a arcar com os custos do EE e mante-lo vivo, ou se será descontinuado.
Eu tinha criado meu guaxinim no jogo, criei um leve carisma por ele, vai ser triste imaginar aquele universo entrando em colapso, engolindo todas as estrelas e planetas, levando consigo meu guaxinim. Mas é a pura realidade, na WEB se você não tem dinheiro, os jogos e sites que conhecemos e frequêntamos diariamente desaparecem da noite para o dia.
Para quem não lembra, o Furcadia foi (ainda é) um dos MMORPG Furries mais famosos do nosso meio, e agora para levar o vício no seu bolso para jogar enquanto espera o ônibus ou até mesmo na faculdade *ahem*, o App oficial está disponível no iTunes Store para iPhone e iTouch caso tenha WiFi por US$4,99.
Desenvolvido por Ayluro com a colaboração do DEP (Dragon Eye’s Production), ao comprar você recebe 5 “Golden Dragonscales” (uma espécie de moeda, item, etc).
clica que amplia, espero
De acordo com o Flayrah, algumas pessoas reclamaram que o jogo é um voraz consumidor de bateria mesmo em estado de espera (IDLE), um bug que pode ser corrigido, mas as reviews estão sendo ótimas por enquanto!
Não há nem especulações sobre versões para iPad, mas é bom primeiro providenciarmos nossos iPhones e iTouch primeiro :)
Via Flayrah
Está complicado manter em dia, mas… Vamos que vamos!
Essa aula foi uma dobradinha de UML, um dia inteiro de Projeto de Jogos.
Depois de dois mokaccinos, eu estava preparado para a aula da manhã que tinha como tópicos os Diagramas de Objetos e Transição o os de Estados.
É a forma de representar de maneira concreta os possíveis comportamentos de um objeto instanciados de uma abstração(Classe). Uma instanciado um objeto de uma certa classe, normalmente ele não irá trocar para outra classe em seu tempo de vida. Cada ocorrência de um objeto é distinta de todas as outras ocorrências.
É deselegante desenhar uma coleção de objetos mais as suas instâncias. Em vez disso, represente um “multiobject” que representa uma coleção de objetos anônimos.
Desenhar um mesmo objeto não significa que se está fazendo duplicatas do mesmo! Isso significa que cada ocorrência daquele objeto representa um estado diferente.
É possível diferenciar instâncias de classes ativa fazendo uma borda mais “grossa”. Geralmente, objetos ativos são usados para modelar múltiplos fluxos de controle onde cada objeto ativo representa a raiz de um fluxo de controle e pode ser usado para nomear outros fluxos.
Uma associsção também pode ter instâncias. O desenho de uma ligação é igual ao de uma associação, porém conecta objetos.
Um atributo ou operação com escopo de classe (class-scoped) é um objeto compartilhado por todas as instâncias da classe.
O estereótipo e os tagged values de um objeto derivam da abstração associada.
Um exemplo interessante é: Um objeto do tipo Inimigo(especializado da classe Personagem) poder virar um objeto do tipo Amigo(também especializado da classe Personagem) em dado momento do jogo e vice-versa.
Objetos protótipos são “substitutos” para objetos concretos, ou seja, são papéis aos quais instâncias concretas espalham-se.
Uma instância bem estruturada está associada explicitamente a uma abstração(Classe) específica.
Um diagrama de objetos bem estruturado equivale a um frame do storyboard dinâmico representado pelo diagrama de interação.
Uma máquina de estado representa a sequência de estados de um objeto durante o seu tempo de vida em decorrência de enventos, assim como as respostas a esses eventos.
Geralmente, são especificadas instâncias de classes, casos de uso e ou do sistema inteiro. Essas instâncias podem responder a eventos como sinais, operações ou passagem do tempo.
Ao ocorrer um evento, dependendo do estado atual do objeto, realizará uma atividade diferente. O estado de um objeto é uma uma situação em que o objeto passa dirante seu tempo de vida, onde ele satisfaz alguma condição, realiza alguma atividade e/ou espera por algum outro evento.
Pode-se visualizar as máquinas de estado de duas maneiras:
Um evento é uma ocorrência significativa que tem lugar no tempo e no espaço, onde pode disparar uma transição de estados.
Partes de um Estado:
Após um almoço demorado, tendo em vista que eu segurei o professor na sala para sanar minhas dúvidas à respeito de um dos diagramas de meu projeto e o fato dele nos ter pedido para prolongar um pouquinho o almoço para poder ir almoçar em casa com a família, todos voltamos com o ânimo revigorado para a aula, mas não antes de mais 2 mokacinnos, claro. O tópico agora seria os Diagramas de Interação.
Uma interação é um comportamento que compreende um conjunto de mensagens trocadas entre um conjunto de objetos dentro de um contexto a fim de atingir um propósito. Os diagramas de seqüência e colaboração são isomorfos.
Pode-se modelar cada interação de duas maneiras
Podem ser encontradas na colaboração de objetos que existem no contexto do sistema como um todo ou de um subsistema, assim como no contexto de uma operação ou de uma classe, na representação de um componente, um nó ou um caso de uso(Nesse contexto, uma interação representa um cenário), que sejam do tipo classifier.
Assim como no diagrama de objetos, os objetos que participam de uma interação são ou coisas concretas ou protótipos. Apesar das classes abstratas e das interfaces, por definição, não terem instâncias diretas pode-se encontrar instâncias dessas coisas em uma interação onde podem representar, respectivamente:
Sempre que houver uma associação entre duas classes, poderá haver uma ligação entre suas instâncias assim como, sempre que houver ligação entre dois objetos, um poderá enviar mensagens ao outro. Caso exista a necessidade, esteriotipar um relacionamento com os seguintes acessórios: association, self, global, local ou parameter. O único acessório que não pode ser usado é o de multiplicidade.
Uma mensagem é a troca de informação realizada entre os objetos na qual pode ser considerada um evento, que por sua vez, pode resultar em uma mudança de estado. Caso o objeto retorne uma resposta, o valor do retorno pode ser modelado.
Pode-se enumerar a ordem das mensagens, mas normalmente a seqüência é especificada por um fluxo de controle procedural ou aninhado (seta preenchida), porém ela também pode ser especificada por um fluxo de controle plano (flat) (seta não preenchida).
Prefixando o número sequencial da mensagem com o nome do processo ou thread situado na raiz da seqüência, dá para representar múltiplos fluxos de controle. Exemplo:
É possível mostrar parâmetros reais transportados invocados por uma operação ou por um sinal, assim como mostrar os valores de retorno de uma função, como em 1.3.2 : p := find (“Enemy”), onde “p” é o valor retornado pela operação “find” e “Enemy” é o parâmetro real enviado à operação.
Geralmente, os objetos que participam de uma interação existem durante todo o tempo que ela dura. Entretanto, em algumas interações objetos podem ser criados ou destruídos assim como acontece com as ligações (links). Para especificar características do ciclo de vida de um objeto ou link utiliza-se as seguintes restrições ao elemento: new, destroyed ou transient (nasce e morre durante a interação).
Assim como no Diagrama de Objetos, a replicação de um objeto representa a sua modificação que passa em seu tempo de vida. As variações do objeto podem se dar de duas maneiras:
Se foca mais na sequência do fluxo dos dados entre os objetos. Nesses diagramas, aparecem os retornos das mensagens. Possuem duas características que os diferenciam dos diagramas de colaboração:
Nos diagramas de sequência, geralmente se mostra apenas um fluxo de controle. Geralmente, se faz vários diagramas, nos quais representam fluxos principais, alternativos ou condições de exceções. Apesar disso, é possível, em um mesmo diagrama, se utilizar de recursos como iteração e ramificações para fazer simples variações.
Se foca mais na relação em os objetos tem entre si, como estão ligados. São mais adequados para a visualisação de iterações e ramificações mais complexas. Possuem duas características que os diferenciam dos diagramas de seqüência:
Para se representar uma iteração, se faz uso do simbolo *, já para uma condição, sua cláusula condicional deve estar entre colchetes. Ex.: [x < 0] A UML nãodefine um “padrão” para a representação nas condicionais, portanto pode ser representado tanto por pseudocódigo, como por código mesmo. Podem ser feitas ramificações utilizando as condições, mas estas deve ser claras e uma não deve sobrepor a outra.
Um diagrama de interação bem estruturado, representa as interações do contexto do sistema como todo, de uma operação ou de uma classe.
Procure mostrar apenas as propriedades de cada mensagem (parâmetros, valor de retorno, etc.) que sejam relevantes para a compreensão do mesmo.
Evite usar ramificações, pois elas aumentam a complexidade de seu diagrama. Caso suas ramificações fiquem muito complexas, use diagramas de atividade para especificar melhor elas.
Prometo que tentarei reduzir o atrazo nos posts, mas de fato o tempo se tornou algo escasso por aqui. Mas chega de lero lero e vamos para o que interessa.
Procrastinei um pouco antes de me levantar, o que resultou em meu atrazo para a aula e o “descontentamento” de Tácio, pois era para estar 7:30(Bem… Era, mas 7:30 foi quando estava saindo) no ponto de ônibus e quase o fiz se atrazar. Mas enfim, eu e a Flam(sim, ela me acompanhou para assistir uma aula) chegamos na sala, onde já estava sendo feita uma das apesentações. Eu estava meio nervoso, pois sabia que o meu jogo piscava mais do que em uma festa rave, por conta da taxa de atualização do mesmo, então tentei concertar às pressas.
Antes de minha apresentação, assistimos as dos meus demais colegas que, diga-se de passagem, ficaram muito bem feitas e algumas deveras engraçadas. Enfim, chegou a minha vez, na qual comentei sobre:
Logo em seguida iniciei a demonstração de meu jogo, porém Murphy e Bill Gates tinham me abençoado e surgiram 2 bugs BEM visíveis do nada. Um deles foi o fato do herói colidir no nada e perder uma vida. Ok, isso foi aceitável até, porém o segundo foi o fato do Power chegar a zero e o jogo não ter encerrado(mais tarde, em casa, descobri que foi a minha última atualização, quando o power chegava em zero, ele não reduzia mais e havia me esquecido de atualizar a parte onde checava se o Power havia chegado a zero para encerrar o jogo, estava chechando se era menor do que zero. Falha boba, eu sei, mas acontece.), fora isso, foi como o planejado.
Estou disponibilizando o código fonte para download aqui, quem quiser dar uma analisada, sinta-se à vontade. E para quem quiser conferir o jogo em si, pode fazer o download aqui.
Após as apresentações, continuamos com a aula sobre a Chien2D2, onde nos aprofundamos a respeito das Classe Ator e Mapa, onde o Ator trata geralmente dos personagens e o Mapa trata do mapa em um jogo em tiles.
As Animações se resumem a: uma sequência de quadros da animação em um vetor, o número total de quadros, o intervalo de tempo entre cada quadro(FPS) e um efeito sonoro.
O Espaço do Ator pode ser definido por uma bounding box(“caixas” que delimitam os limites, onde iniciará a colisão com o seu ator). Um ator pode ter várias bounding boxes, uma para cada necessidade, assim como as animações.
Um Estado é uma ação contínua que o personagem faz. Ex.: Andando, Parado, Morto, etc.
Um Evento é uma ação que dispara um Estado. Ela pode ocorrer dentro do jogo, ou por comando do jogador através de um controle. Ex.: Jogador aperta a tecla para a direita e o personagem anda para a direita, o personagem recebe um tiro e morre, etc.
Para montá-los, utilizamos o Mappy, que é uma ferramenta gratuita e excelente. Para fazer o mapa, precisamos dos tiles(são fragmentos de um mapa. Ex.: Um pedaço de chão, um pedaço de parede, etc) para poder preencher o nosso cenário. Tendo os tiles prontos e carregados, basta “pintar” o seu canvas, montando o seu cenário. O Mappy tem capacidade de até 7 layers(camadas) de profundidade.
Existem tiles especiais que servem como rótulos, nos quais disparam um evento(Ex.: Início, Fim, Parede, Morte, etc), nos quais tu pode colocar em seu mapa, facilitando muito o trabalho de criar estágios. Geralmente se coloca os rótulos na camada acima da layer com os tiles com que você deseja rotular. Para facilitar o trabalho e você não ter de ficar trocando de layer o tempo todo, você pode ativar o recurso Onion Skin(Pele de Cebola) para poder ver a layer anterior “através” da layer ativa.
Mais uma vez nos atrazamos e o pessoal foi indo na frente almoçar. Eu, a Flam e mais dois colegas, todos famintos, com sono, pressa e pouco dinheiro no bolso, fomos no chinês na frente da facul. Sobrevivemos a ele e discutimos bastante a respeito de Final Fantasy XIII com seus “Summons Transformers”, The Shadow of Colossus e seus vastos campos intermináveis, entre outros.
Chegando na aula, começamos vendo o diagrama de casos de uso do jogo de tabuleiro já citado nos meus outros dois diários, o Himalaya.
Logo em seguida começou com o tópico do dia: Diagrama de Classes.
Resumidamente, é um conjunto de objetos que compartilham mesmos atributos, operações, semânticas e relacionamentos. Neles se podem ser representado coisas de software, hardware ou até mesmo coisas puramente conceituais. Ele pode ser uma abstração do jogo ou da implementação.
Uma classe pode não ter atributos, assim como pode não ter métodos.
Uma responsabilidade é um contrato de uma obrigação da Classe.
Use um relacionamento de dependência(uma seta com a linha pontilhada), somente quando precisar que uma classe use uma outra. Uma dependência pode ter um nome, mas isso é raro. É mais comum utilizar-se esteriótipos para diferenciar vários tipos de dependências.
A generalização(uma seta com a linha cheia) é comum para se representar heranças.
Use uma associação(uma linha cheia) para mostrar relacionamentos estruturais e especificar um caminho estrutural.
A associação tem dois tipos especiais fora a simples: A Agregação e a Composição.
Agregação
Quando uma classe A tem uma agregação com outra classe B, quer dizer que você tem a estrutura de B dentro da estrutura de A. Caso venha a deletar A, B também é deletado.
Composição
Quando uma classe A tem uma composição com outra classe B, quer dizer que você tem uma referência de B dentro da estrutura de A. Caso venha a deletar A, B continua como está, afinal somente a sua referência foi perdida, mas não ele em si.
Em relacionamentos N para N(muitos para muitos), usa-se listas de ponteiros que aponta de uma classe para a outra e vice-versa. Esses relacionamentos só terão uma tabela associativa, caso agreguem algum valor a mais na relação e/ou executem algum método durante a relação.
Bem, apesar de estar com uma semana de atrazo, trago-lhes mais um Diário de Aula.
A chegada à faculdade dessa vez foi menos “desastrosa” do que a de meu 1º dia, com direito à todo conforto que um Ford Ka pode dar(carona RLZ!).
A aula foi total e completamente dedicada à biblioteca para o desenvolvimento de jogos 2D, a Chien2D2(que a propósito, foi desenvoldida pelo Paulo Vinícius Radtke para a Tutoria de Jogos.), onde as suas características principais são:
E para trabalhar junto com a Chien2D2, são usadas 3 bibliotecas da SDL:
No início da aula, a galera ficou boquiaberta com a apresentação da biblioteca e vibrava muito, até o momento que um professor que dava aula para outra turma pediu para baixarmos o volume da música.
Bem… Ainda não tenho certeza se posso postar detalhes maiores sobre a ferramenta, pois creio que seja propriedade da instituição, mas caso eu tenha permição, darei uma breve explicação das funcionalidades.
Depois do delicioso e caro almoço no restaurante próximo à faculdade(minha carteira gritava, porém o meu estomago não), retornamos para a aula da tarde em meio de muitas piadas, memes e comentários interessantes sobre jogos e ferramentas de desenvolvimento.
Nessa aula, vimos sobre 2 diagramas da UML, o Diagrama de Atividade e o Diagrama de Casos de Uso.
Em poucas palavras, é um fluxograma, onde nele se mostra o fluxo de uma atividade para a outra. Também podem-se representar atividades concorrentes(trabalhando ao mesmo tempo, em paralelo).
Podem ter um escopo(limite) macro ou micro, como por exemplo:
Elas são triggerless(sem gatilho), ou seja, não necessitam que ocorra algum evento para que elas acontessam, assim que a atividade anterior encerrar, a próxima se inicia e assim sucessivamente até o término de tudo.
Podem-se ter ramificações para caminhos alternativos, assim como um ELSE(então) para uma saída padrão, caso nenhuma das condições tenham sido supridas e também pode-se fazer iterações. As Guard Expressions(Condições de saída) não podem ser sobrescritas.
Para representar as atividades concorrentes, usa-se as barras de sincronização Fork(Bifurcar) para representar o início dos processos paralelos e o Join(Unir) para representar o fim deles. O número de processos que deixam um fork, deve ser igual aos que entram em um join.(Ex.: Caso um fork se divida em 3 processos paralelos, devem chegar 3 processos no Join, nem mais, nem menos.)
Swimlanes representam entidades que podem ser representadas em uma ou mais classes. Elas ajudam na organização do diagrama, assim como na compreensão sobre qual processo será representado por quem.
Basicamente, o diagrama de Casos de Uso servem para definir e representar O QUE será usado para depois se definir o COMO será feito.
Podem ter uma nomenclatura símples, ou possuir um prefixo do pacote(um escopo menor do escopo completo do projeto,uma pequena visão. Exemplo: Animação é um dos pacotes de Jogo onde representa todos os casos de uso que envolvem as animações do personagem, monstros, UI, etc.) onde está incluso. Um caso de uso SEMPRE atenderá alguém.
Podem ser pessoas, hardwares(máquinas), outros sistemas, etc, que estão fora do sistema, porém, interagem com o mesmo, seja com entrada ou com saída e são conectados aos Casos de Uso com uma linha cheia, assim indicando reciprocidade. Pode ser especializado usando-se um relacionamento de especialização(herança).
Pode-se especificar o comportamento de um caso de uso, descrevendo o seu fluxo de eventos de uma forma que seja facilmente assimilada por qualquer pessoa. Ela pode ser escrita de diversas maneiras, com um texto estruturado informal, onde se mostram as pré-condições e as pós-condições para um evento ocorra, por pseudocódigo, entre outros.
Nele pode conter:
É desejável separar o caso de uso de seus fluxos alternativos.
São conjuntos de classes para a execução de um caso de uso(Por exemplo: Um jogo que será aplicado em 3 diferentes plataformas: Desktop, Mobile e Web.).
Well… Como eu prometi, esse é o meu primeiro “Diário de Aula” onde procurarei passar para vocês como é e o que se vê em uma Especialização em Jogos Digitais.
Seguinte, antes de tudo, gostaria de pedir sugestões/críticas para que eu possa melhorar o conteúdo nos próximos artigos, pois não sei o quanto eu posso e se devo me aprofundar muito na área “nerd” da coisa, ou se passo uma visão mais superficial. Enfim, conto com vocês!
Bem… Vamos lá.
A única parte chata foi chegar ensopado por conta de uma chuva que me pegou de surpresa no caminho. A aula foi bem descontraída.
A aula é ministrada pelo professor Fábio Vinícius Binder, coordenador do primeito curso de especialização em Jogos no Brasil com 16 anos de experiência na área(Trabalhou no Erinia, Supermercado, A Casa Maluca, etc), teve um artigo premiado no SBGames 2004, entre outros.
Após a introdução, ele nos apresentou jogos feitos pela turma do ano passado(Roda de Capoeira, Metal Skull, Matt Sniper 2D, etc), desde os jogos em modo texto, até os 3D. Muito bons, diga-se de passagem.
Teve uma breve explicação de como seriam feitos e avaliados os trabalhos e o projeto final. Em seguida, começou a explicar os componentes principais de um jogo.
O jogo, ele é uma aplicação em tempo real e de loop(repetição) contínuo, ou seja, ela nunca irá parar a não ser que o jogador feche o jogo. Para que um jogo pareça um jogo, o processador “pinta” a sua tela com uma determinada frequência(assim como em desenhos animados). Quanto mais quadros e mais rapidamente os exibirmos, mais suave a animação será. O tempo é um fator importante nos jogos, pois se um processessador for muito veloz, o jogo ficaria absurdamente rápido, por conta de seu poder de processamento, já por outro lado, se o processador for mais lento, rodará o jogo de forma mais lenta, tornando assim, impraticável a jogabilidade. Para resolver isso, devemos controlar o tempo, para que a tela seja “pintada” na mesma frequência, seja em computadores mais potentes, ou em computadores mais antigos.
Explicando:
Inicia-se o jogo, carrega todas as bibliotecas e os recursos necessários para que o jogo funcione e inicia o loop principal.
A lógica do jogo é atualizada(movimento do personagem, movimento dos inimigos, processamento de AI(Inteligência Artificial, etc), seguido pelo desenho da tela. Verifica se o jogador encerrou o jogo, caso ele não tenha, volta para o início do loop principal.
Mas caso ele tenha encerrado, descarrega os recursos e encerra as bibliotecas que não serão mais utilizadas, liberando para outros aplicativos e encerra o jogo.
Depois disso e de uma breve explicação sobre uma biblioteca para utilizarmos na atividade, começamos a desenvolver um simulador em modo texto, no qual ele exibia uma ação aleatória dentre as 6 que o nosso herói tinha.
Curiosidade: O padrão do DOS são 25 linhas por 80 colunas, mas isso é configurável.
Terminada a atividade e as risadas, o professor começou a falar sobre OO(Orientação a Objetos), usando como exemplo, o Yahok(Yet Anhother Horrible Object Killer), um jogo de naves simples.
Nele, é claro ver que:
E além deles, existem 3 Classes que não são visíveis, mas que são essenciais importância em jogos grandes:
Com base nisso, temos os seguintes atributos:
E os seguintes métodos:
Também foi falado sobre encapsulamento, mensagens(forma como o método de um objeto é chamado), herança, polimorfismo e como se organizar tudo isso em um Diagrama de Classes.
Uma dica dada foi para não fazer muito uso de Heranças, pois podem comprometer o desempenho do jogo. Sempre que possível, deve-se optar por uma Agregação(quando uma classe, de classes que são independentes, agrega valores à uma outra) ou uma Composição(quando uma classe agrega valores à outra, porém uma depende da outra).
Bem… Depois do delicioso lanche no qual o preço era exatamente inverso ao seu tamanho, fui para a segunda aula.
A aula é ministrada pelo professor Vidal Martins.
Após a apresentação, iniciou-se a aula sobre UML(que no meu caso, soou mais como uma revisão, foi muito boa).
Uma coisa muito interessante e importante citada foi, que em uma empresa de jogos, cada área entende o jogo de uma forma, ou seja, o Game Designer deve criar visões do projeto do jogo no qual se adequa para cada área, assim facilitando o trabalho de todos e aumentando a qualidade do produto final.
As visões são 5:
Ao término da explicação, fizemos uma dinâmica. Jogamos um jogo de tabuleiro chamado Himalaya, onde o seu objetivo é conseguir a maior influência religiosa, política e econômica dos vilarejos, no qual pode ser obtido dando a eles os recursos que eles necessitam. O nosso objetivo agora é fazer uma engenharia reversa e colocar nos diagramas todo o funcionamento do jogo.
Enfim… É isso. Foi um dia bem interessante, divertido e cansativo, mas valeu a pena! Espero que tenham gostado e fico na espera de seu feedback! ;3
Recebemos uma sugestão do leitor Gui Wolf sobre jogos rpg e furry, seria difícil comentar sobre todos os jogos que possuam personagens com cauda e orelha, alias em parte foi desse tipo de iniciativas que nasceu o universo furry, desenhos animados, RPG e game. A maioria dos jogos que possuem personagens antropomórficos não são jogos furries como muitos acham ser, pelo menos na minha opinião, no caso citado do Digimon está claro, e um jogo simplesmente convertido do anime Digimon, e o game Ragnaturn e um mod do Ragnarok Online, com alteração dos sprites (gráficos de personagens) levemente para que aparentem ter cauda.
Para serem furries os jogos nao precisam ter personagens que tenham a aparência furry, mas sim a mentalidade, por exemplo no game Perfect World International, você pode ter um personagem bárbaro com cabeça de lobo, tigre ou uma mulher com orelha e cauda de raposa, entre outras coisas, ate os skills de personagens acompanham, porém os jogadores não. Nestes casos, o game propicia uma certa interação, mas ele so vai se tornar em parte furry a partir do momento que vários furries interajam entre si, o game continua não sendo furry, mas o entorno desses jogadores, sim.
Voltando ao assunto dos games com personagens animais, temos hoje, inclusive o Pet system, que são animais de estimação, tanto dos personagens como do usuário, em Ragnarok, você tem pets que são bichinhos de estimação que você cuida, trata, e as vezes ele até ajuda, em PerfectWorld você pode ter vários pets e dependendo da classe você pode pedir que eles façam tarefas, assim como em Lineage. Mas também há os pets de Neopets, onde online você participa de jogos, trata do seu bichinho e vê ele evoluindo.
Os jogos mais orientados a furries são ainda o Furrymuck, Furcadia e o próprio SecondLife, novamente é bom lembrar que quem faz a comunidade furry são os próprios, as pessoas que frequentam e contribuem. E para quem pensa que a arte é crucial, a arte furry é consequência, e, falando em arte, para quem ainda não conhece vai a dica do Furry Music Foundation.
Banner da Campanha Imposto Justo para Videogames
A indústria global de videogames já ultrapassou a indústria do cinema e da música, mas o Brasil representa apenas 0,5% da indústria de videogames.
Até o México, muito menor que o Brasil, já chegou aos 2%. Por quê?
Por causa dos altos impostos que fazem consoles e jogos custarem até o triplo do que custam nos Estados Unidos. Essa situação é absurda.
Os impostos altos:
O Brasil tem hoje 195 milhões de habitantes, dos quais mais da metade são jovens. É o mercado com maior potencial para crescimento, neste momento, no universo dos games e para isso, precisamos fazer nossa parte. Cobrando a diminuição dos impostos sobre games.
Muitas ações podem e devem ser tomadas neste sentido. De todas, uma é a mais urgente: o projeto de lei 300/07, apresentado em 2007 pelo então deputado Carlito Merrs (PT-SC), estende para os videogames os benefícios que desoneram produtos de informática. Se for aprovado, os videogames vão ficar mais baratos instantaneamente. O problema é que desde 2008 ele está parado na Comissão de Finanças do Senado. O relator é o deputado Antonio Palocci (PT-SP).
Não é possível um projeto de lei de tamanho impacto econômico ficar paralisado dois anos. A campanha CAMPANHA IMPOSTO JUSTO PARA VIDEOGAMES tem o objetivo de forçar a aprovação desta lei, através da pressão organizada dos brasileiros, através de um abaixo assinado e de uma campanha online, faremos chegar a Brasília a voz de milhões de gamers e do mercado organizado de videogames.
Faça sua parte! Entre nesta corrente já e divulgue para seus amigos. Todo mundo precisa dizer:
CAMPANHA IMPOSTO JUSTO PARA VIDEOGAMES
À Câmara dos Deputados, Brasília
Eu, abaixo assinado, peço a aprovação do projeto de lei 300/07, que desonera os videogames, no mais curto prazo possível.
Ao Deputado Antonio Palocci, Câmara dos Deputados, Brasília
Deputado Palocci, aguardamos parecer favorável ao projeto de lei citado, no mais curto prazo possível, assim como empenho do Congresso para sua aprovação.
Esta campanha é apolítica e apartidária. tudo o que aqui estiver escrito pode ser reproduzido em qualquer outro site.
.
Este texto foi removido página oficial da campanha (http://www.impostojustoparavideogames.com.br).
Para contribuir basta acessar o link acima, no qual levará à página da campanha e preencher o formulário.
Colaboradores do #FurryGameDev
Olá leitores do Fauna Urbana! Aqui quem vos escreve(desesperadamente para essa coluna para ir ao ar no tempo certo, apesar de estar indo com atraso mesmo) é Koga SilverDragon, um dos colaboradores do #FurryGameDev.
A idéia surgiu após notar o constante crescimento e interesse dos furries na mística e mágica área da criação de games, visto que muitos ficam indecisos por conta de não conhecer toda a gama de possibilidades de atuação dentro da área e as vezes acabam fazendo escolhas precipitadas. O objetivo com essa coluna é de lhes trazer informações para todos aqueles que pretendem e/ou queiram ingressar nessa área, assim como trazer, comentar novidades e dar nossos pitacos no que há de novo e velho nessa área.
Atualmente temos sete(7) colaboradores onde cada um terá o seu foco em determinada(o) área/tema(o que não quer dizer que o colaborador se restringirá apenas para aquele conteúdo), e eles são:
Formado em Análise de Sistemas pela Uniandrade, recentemente me inscrevi para especialização em Game Design(Jogos digitais) na PUCPR. Procurarei passar uma visão “intermediária” de alguém que já tem alguma experiência na área de desenvolvimento assim como o conhecimento que eu adquirir.
Bacharel em Ciência da Computação, com iniciação científica em interfaces semióticas para Inteligência Artificial, sempre tive uma paixão por UX (user experience) e interfaces gráficas ao que se diz na facilidade e compreensão de menus, telas, e toda a parte que exige interação do usuário com a máquina, e é isto que estarei compartilhando com vocês aqui nesta coluna.
Estudante de engenharia de computação na Universidade Tecnológica Federal do Paraná, há muito tempo almejo trabalhar com desenvolvimento de jogos. Já desenvolvi alguns pequenos jogos em Java, mas meus trabalhos mais notáveis na área até o momento foram no desenvolvimento de mapas (Cenários, missões) para jogos existentes. Sempre acompanho o lançamento de novos jogos, novas tecnologias e a indústria em geral e espero trazer aqui um pouco das novidades da área!
G’day, mates! Cursando Ciência da Computação, término previsto para 2011, Atuo na área de Web mas não é a primeira vez que eu trabalho com jogos eletrônicos, tanto criando para diversão pessoal quanto dentro do trabalho, já estudo desenvolvimento de games por conta própria.
Já atuo com desenvolvimento de jogos para navegador de forma freelance. Meu negócio é o núcleo da coisa toda, aquelas continhas malditas que fazem a coisa andar. É disso que eu vou falar aqui.
Graduando em Artes Visuais na UFRGS, e tecnólogo em Jogos pela UNISINOS, atuo a mais de 7 anos no mercado de trabalho no Brasil, com passagem pela Southlogic Studios e Ubisoft/Brazil, de onde saí recentemente para começar meu próprio estúdio. Quero passar uma visão objetiva sobre o funcionamento das empresas, e principalmente a entrada do pessoal no mercado de trabalho.
Saudações a todos! Sempre gostei muito de jogos eletrônicos e sonhei em um dia poder fazer os meus próprios jogos. Estou atualmente cursando Design de Games pela Universidade Anhembi Morumbi, e aqui pretendo falar um pouco do ponto de vista de quem já entrou na faculdade direto nessa área, quais eram minhas expectativas e o que encontrei pelo caminho até agora.
Esperamos que o #FurryGameDev se torne uma ferramenta informativa, no qual auxilie você em sua decisão de seguir na carreira de Desenvolvedor de Jogos.
Sabe aqueles jogos que você passeia por um cenário matando todos os inimigos, os famosos beat-them-up? Agora imagine um jogo assim, mas com coelhos. Bem, adicione coelhos lutadores e você tem Overgrowth, o jogo que a empresa Wolfire Games está criando há pelo menos dois anos.
Tudo começou em 2005, quando o então aluno de ginásio David Rosen criou um jogo elaborado para o Macintosh chamado Lugaru. David não estava muito confiante que seu jogo de “coelhos ninja” fosse fazer sucesso, mas, para sua surpresa, fez. Tanto é que a Crytek (criadora dos jogos Far Cry e Crysis) queria contratar o rapaz após lançar Lugaru mas este negou o convite pois ele queria terminar os estudos. Além de ganhar prêmios no circuito de desenvolvimento de jogos independentes para Macintosh, David fez versões de Lugaru para Linux e Windows, juntou outros jogos que ele havia elaborado durante o ginásio e fundou a Wolfire Games em que atualmente além de ter 12 membros agora, esta trabalhando arduamente no projeto Overgrowth, a sequência espiritual de Lugaru.
Demonstração de Lugaru
Lugaru é um jogo de ação em terceira pessoa com ênfase em combate corpo-a-corpo e um ou outro movimento de parkour. O jogo, que continua tendo vendas após 5 anos sendo distribuído como shareware, foi aclamado pela sua jogabilidade rápida e intensa e que chama atenção justamente pelo fato de que o jogador não controla um viking ou um space mariner ou um ninja e sim um coelho que, contrariando o estereótipo da natureza pacífica do animal, não parece sentir nem um pouco de remorso em cortar a garganta de outros coelhos (TRACHEOTOMY!!) e ainda por cima enfrenta de cara uma alcatéia de lobos que seriam seus predadores naturais para poder salvar sua raça da escravidão. Uma ironia sombria que David Rosen afirmou gostar muito.
Em uma entrevista ao site TAKEitGAME, David afirmou que ao criar Lugaru, não queria fazer apenas mais um jogo cheio de clichês: “Se eu fosse fazer um jogo sobre ninjas, space mariners ou soldados da segunda guerra, Lugaru seria apenas mais um jogo do gênero e se perderia entre os demais“. David também disse que ele se inspirou em jogos como Rune e Oni para elaborar o sistema de combate de Lugaru.
Coelho de armadura
Voltando ao projeto Overgrowth, a Wolfire criou uma engine a partir do zero chamada de Phoenix Engine. Ela seria muito mais avançada do que a engine usada em Lugaru e, ainda, extremamente “modável” pelos jogadores, não apenas criando novas texturas e cenários mas também criando personagens e vários tipos de animação também. É sabido que Overgrowth terá muito mais modos de jogo e missões, quesitos esses que eram o ponto fraco de Lugaru. Além do habitual “mate todos para passar de fase”, Overgrowth contará com missões de stealth, corrida contra o tempo, chegar a um determinado local e assassinato. Um modo multiplayer co-op também será incluso embora não como elemento principal do jogo. Rosen afirma que haverá modos de jogo multiplayer especiais como, por exemplo, um em que dois jogadores disputam quantos inimigos eles conseguirão derrotar antes de serem mortos (alguém aí lembra de Legolas e Gim?). É possível um modo death match também embora isso não tenha sido oficialmente comentado.
Paisagem local
Outro elemento que foi aperfeicoado em relação a Lugaru é a criação de mais 3 raças antropomórficas. Além dos coelhos e lobos presentes em Lugaru, haverão também ratos que primam pela habilidade de ‘stealth’, felinos que terão mais preferência em intimidação ao invés de lutas diretas e cães que além de poderem usar armas mais pesadas, poderão engajar em um combate direto com seus inimigos.
Não há muitas informações sobre o enredo do jogo. Sabe-se porém que o nome do jogo Overgrowth terá quatro significados que serão aplicados ao enredo. Para quem já jogou Lugaru e terminou o jogo, fica bastante óbvio o que será um desses significados. E o compositor Miko Tarmia, responsável pela trilha sonora da série de Survival Horror para PC Penumbra, criado pela Fricitonal Games, também está envolvido no projeto.
Atualmente, Overgrowth está em estágio Alpha. David afirma que não quer que Overgrowth tenha uma data de lançamento definida por que ele quer que todos da Wolfire tenham o tempo necessário para fazer as coisas bem. Desde que não demorem tanto quanto o anime Steamboy; ou pior: vire uma novela chamada Duke Nukem Forever. Por enquanto, interessados podem fazer um pre-order e experimentar a Phoenix Engine e receber atualizações semanais do software Alpha, com novidades dos editores para criar mods.
Demonstração do jogo e do editor
Para mais informações e vídeos do andamento do projeto Overgrowth, acesse estes sites:
Por Giles F. Ahrun
Há observações e complementos dessa licença que devem ser lidos em: Compartilhamento.
English