Labs: Super Sparty Bros Extended

Super Sparty Bros – Extended foi um jogo desenvolvido dentro do curso “Game Development for Modern Platforms

O projeto pode ser acessado através do link no final do texto, é um sandbox, um level de teste para testar mecânicas e objetos dentro do jogo.

Para rodar o programa, é necessário um browser com suporte a WebGL.

O projeto teve nota 100% ao final do curso, preenchendo todos os elementos necessários propostos durante o curso.

Link: http://xuti.net/labs/sparty/


 

Sparty Super Bros – Extended was a game developed within the course Game Development for Modern Platforms

The project can be accessed via the link at the end of the text. It is a sandbox, a “level test” to test mechanical and objects within the game.

To run the program, a browser that supports WebGL is required.

The project took note 100% at the end of the course, completing all the necessary elements proposed during the course.

Link: http://xuti.net/labs/sparty/

Everything in WebGL / Tudo em WebGL (Update/Atualização)

(Inglês)

I updated the entire website (or, at least, the online games) and all games was updated to WebGL system. That allows some users, as Google Chrome users , for example, to use all games without using Unity Web Player. Have a good time! 😀


 

(Portuguese-Brazil)

Eu atualizei o site inteiro (ou, pelo menos, os jogos on-line) e todos os jogos foi atualizado para o sistema WebGL. Isso permite que alguns usuários, como usuários do Google Chrome, por exemplo, para usar todos os jogos sem o uso de Unity Web Player. Divirta-se! 😀

Some study on Coursera’s Course

This game (WIP) is developed in Game Development for Modern Platforms by Michigan State University on Coursera.

I’m really enjoying the course. And making some level up in GameDev 😉

This is a course of video to follow up the development. (Half of course). The complete set with level design developed by me (this is a prototype) I’ll put available online soon.

Solar System Simulator

O programa desenvolvido é um simulador (incompleto) de Sistema Solar.

Feito para rodar nos browsers com WebPlayer do Unity (Não funciona no Chrome), o programa mostra os planetas orbitando o Sol, com tamanhos e orbitas fora de escala.

A ideia do programa era desenvolver uma aplicaçao e criar um minimapa, que seja possível interagir.

Ao clicar em um planeta, a camera deve acompnhar esse objeto. Se utilizar o mini mapa o mesmo efeito pode ser conseguido.

Link: http://xuti.net/labs/solarsystem/

XUTI Labs

Resolvi alterar hoje o site para poder incluir alguns protótipos/tutoriais que estamos fazendo e deixar disponível o acesso desses produtos de alguma forma.

Além disso, com essa nova seção, “Labs”, posso mudar um pouco o foco do site para algo mais próximo de um blog, e assim fazer texto menores, mas ainda assim com conteúdo relevante.

Para acessar a nova seção, basta clicar em LABS na parte superior do site.

Alguns jogos foram movidos para dentro dessa aba, por não serem exatamente um produto, mas um teste de conceito.

Espero transformar essa seção em um blog em breve 😀

Nightmare

NIGHTMARE

v1.0

Foi desenvolvido como um jogo protótipo.

O objetivo dele foi desenvolver algumas técnicas de desenvolvimento, que resultaram em sucesso.

Os assets deste jogo (musica, gráficos, modelos, etc), bem como o GameDesign, foram desenvolvidos pela empresa Unity Tecnologies.

O desenvolvimento, mais próximo possível do projeto original, foi feito por nós.

COMO JOGAR:

ASDW / SETAS: para mover o personagem.

MOUSE: mira e atira

COMO JOGAR?

Opção 01:

Baixe a versão Standalone para Windows (32 bits – formato zip) –

Download “XuTi Game Development Website - 2006/2010” – Baixado uma vez –

Requisitos (recomendado): Windows Vista ou superior, 2Gb de RAM, 256Mb de VRAM.

Opção 02:

Utilize a versão WEB apontando para o seguinte endereço eletrônico:

http://xuti.net/labs/nightmare/

CURIOSIDADES: Para desenvolver esse jogo demoramos entre 20 horas, sendo 3 horas adaptando o nosso projeto ao projeto original da Unity e 3 horas num Bug indetectável até cair a ficha. 😀

 

SCREENSHOTS:

Protótipos: Estamos brincando com novas ferramentas

Não sumimos. Estamos brincando com novas ferramentas e trabalhando em novos jogos e oficinas. Quer ver o que estamos fazendo ?

Nossos testes que estão online são conceituais ainda, mas da para ver que a coisa está tomando forma…

Como curiosidade, estou colocando aqui os testes

CUBO: http://www.xuti.net/unity_test/unity001/unity001.html

Teste conceitual para aprender a usar fundos com skyboxes, e comando com mouse.

Captura de tela 2014-04-27 17.32.47
Teste com Cubo

 

CIDADE: http://www.xuti.net/unity_test/uni_street2/uni_street2.html

Outro teste conceitual, o negocio aqui foi aprender a trabalhar com cenários. Um efeito esperado é que, se você tentar sair do cenário pela única rua aberta, cairá num poço sem fundo tendo uma agradável visão da cidade debaixo….

Cidade Abandonada
Cidade Abandonada

 

A ILHA: http://www.xuti.net/unity_test/001_Island/001_Island.html

O objetivo aqui foi aprender a trabalhar com terrenos e som ambiente. Você poderá ver efeitos como água, percorrer a ilha, ver árvores e fará isso usando o mouse e SHIFT para correr.

A ilha
A ilha

 

LUNAR RUN: http://www.xuti.net/unity_test/lunar_run/lunar_run.html

Aqui é um esboço de jogo. Aprendendo a usar terrenos e raytracing, o jogo inteiro não usa efeitos de física na engine Unity. O tiro, dado coma  tecla CTRL, faz você destruir as esferas. Os cubos são destruídos quando você passa dentro deles com a nave. Os tiros não são objetos do jogo,mas efeitos com partículas.

Lunar Run - Quase um jogo....
Lunar Run – Quase um jogo….

Outros testes podem ser vistos AQUI. Aguardem que em breve teremos novas novidades….

É preciso desenvolver um engine para o seu jogo?

UMA ABORDAGEM PELA PROGRAMAÇÃO ORIENTADA A OBJETOS VERSUS PROGRAMAÇÃO ESTRUTURADA

Quando se tem em mente o desenvolvimento de um software, deve-se passar necessariamente pela fase de projeto, onde as idéias a respeito do que se quer fazer são confrontadas com as possibilidades técnicas do grupo de desenvolvimento e uma síntese entre intenção e realidade irá nortear o processo de construção do código. Em se tratando de jogos, a coisa pode se tornar ainda mais complicada, pois geralmente esperamos muito mais de nossos programas do que aquilo que somos realmente capazes de realizar em curto prazo.

Essa fase de projeto de software pode ser traduzida em um detalhamento mais fino das atividades, entradas e saídas que o sistema irá comportar. Isso passa necessariamente por uma escolha primordial: programação estruturada ou programação orientada a objetos. A programação estruturada é aquela que nos permite detalhar o funcionamento de um programa através das funções e procedimentos que o compõem. A programação orientada a objetos nos permite uma outra hierarquia, mais rica e mais complexa, de estruturação, com classes que comportam métodos que podem herdar características de outras classes e assim consecutivamente. A ênfase que se dá ao projeto em programação estrutura é em relação à ação que uma determinada função ou procedimento irá executar, já na programação orientada a objetos a ênfase na fase de projeto se dá ao tipo de dados que se deseja obter e a forma como esses dados serão tratados pelo programa. São dois enfoques bem diferentes e que têm implicações de projeto que resultam em conceitos diferentes para um mesmo software.

Bem, deixemos momentaneamente a questão da programação estruturada e da orientação a objeto de lado para colocar em questão o que se entende por engine e qual deve ser o seu papel.

A palavra engine pode ser traduzida como “motor” ou “máquina”. Um engine pode ser entendido, de tal forma, como uma coletânea de código orientada à ação (execução de ações por parte dos elementos do sistema) que visa ser genérica o suficiente para que possa ser reaproveitada na construção de outros sistemas, enfim, de outros jogos que executem ações semelhantes. Veja que quando falamos de ação, não estamos apenas nos referindo a jogos de ação, mas sim a como um programa toma decisões em tempo de execução com base numa interação por parte do usuário. Essa definição difere consideravelmente do que podemos considerar uma biblioteca de software propriamente dito: uma lib é orientada ao suporte de tarefas de mais baixo nível que dão muito trabalho se forem reescritas a cada novo sistema desenvolvido, ou seja, não tem essa preocupação se ser orientada à ação.

Tomemos como exemplo jogos de RPG e pensemos no papel que um engine pode ter. Essencialmente, a estrutura de programação desses jogos é a mesma, mudando apenas o conjunto de regras que irá nortear o comportamento dos usuários e a forma como os mesmos irão interagir com o sistema. Se tivermos um código genérico o suficiente para passarmos como parâmetro as regras do jogo e as formas de interação, teremos um construído um engine que, de forma geral, pode nos auxiliar em todo o desenvolvimento de jogos desse tipo.

Visto isso, voltemos agora aos conceitos de programação estruturada e orienta a objetos.

A orientação a objetos surgiu como um novo paradigma em programação visando justamente resolver o problema de reaproveitamento de código e da manutenção desse código por pessoas diferentes. Como dissemos acima, a própria ênfase da orientação a objetos se dá nos dados que uma classe deve tratar, ou seja, nos dados que devem ser recebidos como parâmetros e aqueles que devem retornar de um método encapsulado por uma classe, o que torna a tentativa de generalizar o código muito mais eficiente do que na orientação estruturada.

É evidente que tal forma de programação exige disciplina e experiência, já que sempre iniciamos nosso estudo em programação pela forma estruturada e levamos certo tempo até compreender a forma como as classes podem ser estruturadas e vantagem que isso traz ao código final. Também é evidente que para desenvolvermos pequenos jogos, a forma estruturada é mais simples e, diria mais, até mais útil. Mas, a questão que fica, é que se pretendermos desenvolver um trabalho a longo prazo, visando produtividade de construção de código, parâmetros de qualidade na fase de análise do projeto, teste e manutenção, devemos sim nos preocupar em construir engines que sejam orientados a objeto e possam ser constantemente revisados para trazer o nível de generalidade que pretendemos alcançar. Logo, a resposta ao título do texto é: depende do porte e do desenvolvimento a longo prazo do projeto que se pretende criar.