Uma novidade bacana do Unity 2.6 é a sua integração com o Visual Studio. Quem usou a ferramenta até agora sabe que ela vem com o UniSciTE, um editor que até quebra o galho, mas tem alguns probleminhas irritantes a longo prazo.
Antes já era possível usar o Visual Studio para editar os scripts em C# do Unity, contando com auto-completar e tudo, graças aos recursos do .Net. Para tanto, era preciso somente criar um novo projeto e referenciar uma DLL do Unity que fica “escondida” em suas pastas internas. No entanto, ainda era preciso alguns cuidados e um trabalho extra pra usar o editor da Microsoft. Por exemplo, todo arquivo de script adicionado pela interface do Unity tinha de ser adicionado manualmente no projeto do VS depois.
Com o lançamento da versão 2.6, esse trabalho foi embora. Agora o Unity se integra oficialmente ao Visual Studio 2008, tanto na versão Express quanto na Profissional. A única diferença neste caso é que quando se usa a versão Profissional, é possível fazer com que o Visual Studio seja aberto quando damos dois cliques em um arquivo de código. Na versão Express isso não acontece e um duplo-clique resultará no arquivo sendo aberto no UniSciTE.
As vantagens de se usar o Visual Studio para desenvolver código no Unity são várias. O VS é um ótimo editor de código (certamente melhor que o UniSciTE) e o auto-completar funciona perfeitamente (novamente graças ao .Net), mostrando somente os atributos e métodos dentro do contexto (ao contrário do UniSciTE que simplesmente mostra uma lista com todas as opções possíveis). Além disso, é possível compilar o código ainda no Visual Studio para verificar possíveis erros antes de voltar para o Unity e realizar os testes.
A utilização deste recurso é bastante simples. Vou explicar somente como fazer no Visual Studio Express, que é gratuito. Com um projeto aberto, basta ir em Assets -> Sync VisualStudio Project (imagem acima) e pronto, a solução do Visual Studio já foi adicionada à pasta raíz do seu projeto (imagem abaixo). A partir daí, todo arquivo de código criado pela interface do Unity será adicionado ao projeto do Visual Studio. Arquivos criados dentro do Visual Studio também são adicionados automaticamente ao projeto do Unity, só não se esqueça de adicionar os arquivos dentro da pasta Assets, senão ele não aparecerá no jogo.
Depois do Unity, agora é a vez da Unreal ganhar uma versão gratuita. A ferramenta, chamada Unreal Development Kit (UDK) é a versão completa da Unreal Engine 3, porém só pode ser usada em projetos não-comerciais ou educacionais (ao contrário do Unity, que vem em uma versão mais limitada mas que permite uso comercial).
Para uso comercial, há dois tipos diferentes de licenciamento: projetos internos devem pagar $2,500 por cópia do UDK usada no desenvolvimento; e para produtos que são comercializados externamente há um pagamento de $99 pela licença mais 25% do lucro obtido com o produto (há uma isenção desta taxa sobre os primeiros $5,000 de lucro do produto). Pensando bem, apesar da alta taxa de royalties, ainda é uma boa pedida visto que não será preciso investir centenas de milhares de dólares na ferramenta.
Eu fico bastante feliz com a abertura destas ferramentas, pois fica cada vez mais fácil não só desenvolver um jogo indie mas também aprender as ferramentas que realmente são utilizadas nas grandes desenvolvedoras de jogos. Como disse o Bruno no Twitter, nessa briga das grandes engine a gente é que sai ganhando.
Inicialmente, esta versão gratuita suporta o desenvolvimento para PCs, mas parece que a Epic está considerando a possibilidade de abrir para consoles também.
O download do UDK (563 MB) está diponível em vários mirrors nesta página. Há ainda a documentação que parece ser boa e exemplos de jogos completos, para quem quiser estudar.
O portal Develop fez uma série de matérias sobre as dez engines mais importantes do momento. A cada semana, um post apresentou uma nova posição no Top 10, até chegar à conclusão que o Unreal Engine 3 é a melhor opção disponível no mercado.
A lista inclui, além de uma descrição sobre cada engine, detalhes como as plataformas compatíveis, jogos em que foi usada (já lançados e em desenvolvimento), preço (disponível só em alguns casos) e compatibilidade com outras ferramentas.
Para o desenvolvedor independente e pequenas empresas as opções ficam um pouco limitadas, mas engines como o Torque 3D ($1000) e o Unity ($199) são bons investimentos. Destaque para o Unity que ficou em quarto lugar na lista encarando os gigantes de frente. Segundo a matéria, o suporte ao Xbox 360 e PS3 será oferecido em breve (em adição às plataformas atuais PC, Mac, iPhone, Wii e Web).
Segue a lista completa (clique nos links para ver os detalhes da engine):
Para quem deseja desenvolver jogos 3D sem maiores complicações, o Unity 3D é uma boa escolha.
Ao contrário de ferramentas como o XNA, o Unity fornece um editor visual, o que facilita e muito a distribuição dos elementos dentro do jogo. Esse editor também possibilita configurar todos os objetos, inicializar valores de atributos e editar scripts. A ferramenta lembra outras engines de alto nível, como o 3D Game Studio, mas possui uma interface bem mais amigável e as linguagens de script oferecidas também são mais poderosas.
O Unity oferece componentes para trabalhar com física, partículas, audio, iluminação, redes, animações, terrenos, câmeras e muito mais. A lógica do jogo pode ser programada nas linguagens JavaScript, C# ou Boo (Python), e scripts escritos em uma linguagem interagem com scripts escritos em outra linguagem sem problemas.
Um grande diferencial ao meu ver é a importação de recursos para os jogos. O Unity é capaz de importar diretamente arquivos .blend, .max e .psd, por exemplo. Em alguns casos, pode ser necessário ter a ferramenta (como o 3D Studio Max) instalada, mas de qualquer forma há a possibilidade de importar formatos padrão, como .3ds ou .jpg.
Componentes criados no Unity também podem ser exportados e reutilizados em outros projetos, através do recurso de criação de prefabs, que cria um arquivo binário que passa a ser tratado pelo Unity como um outro recurso qualquer.
Até pouco tempo atrás o Unity estava disponível apenas para os sistema operacional MacOS, mas no mês passado uma versão do editor foi lançada para o Windows. O mais interessante é que, independente da plataforma usada para desenvolver, o Unity pode gerar executáveis tanto para Mac quanto para Windows. E ainda há a possibilidade de se criar jogos para a web, necessitando que o usuário instale um plugin no navegador para jogar. O Unity também permite desenvolver jogos para iPhone e Wii, mas nestes casos os custos de licenciamento são diferentes.
Falando em custos, a versão Indie da ferramenta custa US$ 199,00, o que, diante das facilidades oferecidas pelo editor é uma pechincha. A versão Pro sai por US$ 1499,00, que também não é nenhuma fortuna se comparado aos preços da CryEngine e da Unreal Engine. Os preços e maiores detalhes estão aqui.
Na página do Unity estão listados diversos jogos feitos com ele. Nada muito conhecido, mas vale a olhada. Interessante notar que o jogo T-Racer, mostrado dentro do último Big Brother Brasil, foi feito com o Unity.
Saiu ontem no Gamedev.net que foi lançada uma nova versão da engine 3D Irrlicht, com vários recursos, como suporte a COLLADA 1.4 e arquivos LWO, luzes volumétricas e renderizadores mais rápidos de terreno. Mais infos:
Pra quem está atrás de uma engine Opensource para projetos indie, a Irrlicht é uma ótima pedida, sendo que tem versões para C++ e Java (com a jirr). E com certeza, caso soubesse C++, usaria ou esta engine ou a Ogre3D.
Veja duas imagens do que a engine pode fazer (para mais imagens, vá a página oficial):
Half Life Lost Coast – Efeito de HDR (High Dynamic Range Rendering)
Nos últimos dias andei lendo e tentando entender os artigos traduzidos do Loading Time sobre a história do 3D. Na verdade o artigo é mais como um dicionário de termos técnicos comuns, mas focado em tecnologias que são hoje aplicadas em engines técnicas. Você vê explicações (algumas vezes bem difíceis de entender) sobre anti-aliasing, Z-Buffering, Normal Map e tecnologias que você pode nunca ter ouvido falar na vida, como Parallax Mapping, Post Processing e Ambient Occlusion (que eu só sabia que existia o nome). Eu fiquei maravilhado com isso, com esses termos difíceis, com as próprias tecnologias, mas eu estava no mundo da fantasia. Uma hora a ficha cai e você volta para o mundo real: meu, como eu faria um treco desses no meu jogo?
Pegamos o Realtime Shadows (Sombras em Tempo Real), usado em Splinter Cell. Pelo que eu entendi lendo o texto, é necessário ter um mapa de sombra, onde, caso um objeto se mova da fonte de luz, seria necessário atualizar todo o mapa de sombras do objeto e refazer todos os cálculos. Minha mente de programador está até agora sem nenhum tipo de idéia de como que eu poderia fazer um negócio desses.
OK, eu admito que não tenho conhecimento algum em engines. Não saberia, neste momento, criar algum tipo de efeito gráfico ou mesmo explicar, mas isso é algo a se pensar pra quem quer ser programador de games. E eu digo: programador de games. Aquele que vai mexer com códigos-fonte, com linguagens de programação, com engines, com inteligência artificial. Hoje muita gente acha que o termo programador de games se refere a alguém que cria o jogo. OK, ele pode acabar sendo o responsável por dar vida ao jogo, mas temos que dividir as áreas. Temos um modelador que faz os modelos 3D, temos os game designers que projetam as coisas, temos os ilustradores de conceitos para mostrar uma idéia usando um desenho, etc etc etc. Que tentemos colocar cada função e cada um em seu devido lugar.
Mas porquê um programador (ou alguém que queira entrar neste ramo) teria de pensar nisso? Porquê são eles que terão de se preocupar com os efeitos gráficos do jogo. São eles que vão botar a mão na massa e setar. São eles que terão, também, de escolher a engine certa para o projeto.
Hoje eu considero bem difícil escolher uma engine gráfica. Mais difícil seria projetar uma engine, já que o programador teria de estudar matemática em níveis bem avançados para criar cálculos que possam gerar efeitos gráficos. Vento, água, fumaça. Pode não parecer, mas são efeitos que quebram a mente de um programador avançado com uma facilidade tremenda. Mas pode ter alguma engine possa fazer isso. E aí entra os termos citados no começo deste texto.
Quando você joga um game, como jogador, você não pensa na dificuldade que os programadores podem ter tido ao desenvolver o mesmo. Chegar e pensar, por exemplo, em maneiras de poder economizar recursos de memória para o restante ser usado com outras coisas. Pensem numa multidão vista no vídeo abaixo, em Assassin’s Creed:
Impressionante? Então veja o Hydrophobia, game que mostrará uma simulação de água num nível que realmente impressiona:
OK, hoje os consoles atuais e os PCs conseguem facilitar a vida dos programadores, mas mesmo assim pense naqueles programadores que fazem as engines internas das produtoras. Ou mesmo pense naqueles programadores que desenvolvem engines gráficas de ponta, como a Unreal Engine 3. Pense nas pessoas que criaram parte do que você viu acima. Eu tenho um respeito enorme pelos caras, já que eles devem quebrar bem a mente pra poder criar cálculos efeitos gráficos. Um sistema comercial com banco de dados pode ser chato e monótono, mas é mais fácil do que você pensar em desenvolver cálculos complexos para criar efeitos de luzes e que pode ser fascinante ficar testando durante o seu horário de trabalho. Ou mesmo desenvolver uma boa rotina de inteligência artificial ou quebrar a cabeça com um monte de personagens na tela se interagindo de forma realista.
Hoje existem tantos efeitos técnicos numa engine que você acaba ficando maluco. São termos técnicos que até mesmo um modelador não entenderia logo de cara. Um game designer muito menos. Tenho certeza também que muito programador de games também podem não conhecer tudo. Não quer dizer que eles tem de conhecer, mas saber pelo menos o básico pode evitar muita dor de cabeça no futuro. Se uma equipe analisar bem que tipos de efeitos o jogo pode ter, a equipe pode escolher a engine que possa se adequar melhor aquele projeto. E não se preocupe por não saber tanto sobre Ambient Occlusion ou mesmo sobre HDR (High Dynamic Range Rendering). Talvez você nunca possa pensar em utilizar este tipo de tecnologia, dependendo do seu foco atual como desenvolvedor. De todos os termos, só conhecia o Normal Map, mapeamentos de textura e o Anti-Aliasing. Este último por ser algo bastante difundido em revistas de games. O mapeamento de textura por já ter feito algo parecido no Blender. E o Normal map por estar habituado a ver objetos 3D que possuem irregularidades numa superfície.
Continuando o post de ontem, decidi procurar mais referências sobre engines, mas neste post o foco são as engines freewares/opensource/gratuitas e artigos relacionados. Bom, muitas equipes tem dúvidas sobre qual a engine que eles podem utilizar em seus projetos. Cada linguagem possui engines próprias e é recomendado escolher uma engine de uma linguagem que os programadores já conhecem. Se eles conhecem C++ a fundo, obviamente podem usar uma engine desta linguagem, como o Ogre 3D. Ou, se sabem Java, podem tentar se aventurar pelos celulares ou mesmo usar o jMonkeyEngine, que está se tornando uma alternativa interessante sobre isso.
O primeiro lugar que a equipe deve procurar informações é no site Devmaster. Lá tem muita informação sobre engines/ferramentas e muitos detalhes de cada uma. Ou então acompanhar os fóruns de discussão e ver quais as engines mais usadas. Hoje, Ogre 3D, Irrlicht e Crystal Space são as mais usadas. Tem também o 3D Game Studio, que não é necessariamente uma engine (considero como uma ferramenta completa) e em Java tem-se a jMonkeyEngine, o Java 3D e o JME (Java Mobile, que também é conhecida como J2ME), por exemplo. Além dessas, tem também o Dark Basic e o Blitz Basic, que não posso afirmar muito sobre isso, em virtude do meu desconhecimento atual nestas ferramentas.
Continuando as minhas pesquisas, existem alguns artigos interessantes que os desenvolvedores tem de analisarem antes de escolher uma engine. A escolha de uma é crucial para o desenvolvimento e deve ser pensada com muito carinho. Afinal, se você ver depois que a engine que você está usando não tem aquele recurso que você planejou (se você planejou primeiro antes de sair desenvolvendo) e outra tem, trocar de engine no meio do projeto pode ser inviável, já que o jogo terá de ser refeito.
Bom, apesar de não falar muito sobre engines, mas sobre arquiteturas usando jogos multi-player. Recomendado pra quem quer fazer MMO (aliás, se você for tentar, leia isto antes de seguir num projeto desses!)
Aqui mostra um comparativo entre as ferramentas para games de celulares. Recomendo usar o Java, que parece ser a alternativa que mais está crescendo atualmente no mundo.
Por fim, se mais alguém quiser complementar este post com informações, fique a vontade!
Uma novidade bacana do Unity 2.6 é a sua integração com o Visual Studio. Quem usou a ferramenta até agora sabe que ela vem com o UniSciTE, um editor que até quebra o galho, mas tem alguns probleminhas irritantes a longo prazo.
Mais informações: aqui.
O portal 
