Ponto V!

Home Arquitetura Programação Reinventando a roda do meu jeito (Magic3D Engine)
Thiago C. Moraes
Reinventando a roda do meu jeito (Magic3D Engine)Imprimir
Escrito por Thiago C. Moraes

Olá, meu nome é Thiago Chagas Moraes, tenho 32 anos, sou formado em processamento de dados e pós graduado em desenvolvimento de jogos, programo em C/C++ e Java há mais de 10 anos (me formei em 2001, mas já programava muito antes) e nos últimos 5 anos tenho trabalhado exclusivamente no desenvolvimento de jogos tanto em empresas quanto por lazer.

Nos últimos 3 anos estive tentando desenvolver jogos 3D (por lazer) para dispositivos móveis rodando tanto iOS como Android, mas tive vários problemas com as engines disponíveis para essas plataformas. Não problemas técnicos, mas problemas financeiros e de tempo (horas dormidas vs horas trabalhadas), pois as engines realmente boas custam caro ou contém cláusulas de licença restritivas, já as engines livres ou são incompletas e sem suporte ou quando se tornam estáveis começam a ser vendidas, inviabilizando dessa forma a continuidade dos meus projetos, pois para desenvolver para iOS é necessários ter um Mac, um iPhone e ou iPad e pagar uma licença anual de US$ 99,00 e para Android pelo menos um telefone ou tablet rodando o sistema e mais US$ 25,00 para se registrar como desenvolvedor, por isso se adicionado o valor de uma boa engine ou tempo para aprender e se necessário corrigir uma livre, é possível desenvolver uma própria que cumpra com o básico e ainda seja exatamente como se deseja.

Baseado nisso nasceu a Magic3D uma engine sem nenhuma pretenção de competir com as boas engines disponíveis no mercado, mas que poderá cumprir (ainda não fiz nenhum jogo nela, sua primeira versão estável ficou pronta em Janeiro de 2012) de forma simples e gratuita com a intenção de desenvolver jogos para dispositivos móveis e até mesmo para PC.

Nesse artigo quero apenas descrever o processo de criação da engine, algumas dificuldades e um pouco sobre as tecnologias escolhidas, sem entrar muito à fundo na parte técnica, pois não tenho todo o conhecimento necessário para abordar alguns temas.

A primeira coisa que eu tinha em mente era que uma boa engine precisaria de um bom editor, pois é difícil (não impossível) construir algumas cenas mais complexas apenas com linhas de código, mas deixei isso para um segundo momento, depois que já fosse possível ver algo funcionando, pois fiquei com medo de deixar o projeto de lado por não ver nada acontecendo, afinal não adianta ter um editor que não tem como editar, outro detalhe é que eu gostaria de um editor que fosse multiplataforma, pelo menos Windows e MacOS e esse é um outro problema que comentarei daqui alguns parágrafos.

Sem editor, era então necessário decidir a base tecnológica da engine, e após um pouco de pesquisa cheguei à seguinte lista que será comentada item a item até o final do artigo:

Gráficos 3D

  • OpenGL ES 1.1
  • OpenGL ES 2.0

Física

  • Bullet

Som

  • OpenAL
  • OpenSL ES 1.1
  • Vorbis
  • OGG

Vídeo

  • Theora

XML

  • TinyXML2

Compactação

  • Zlib

Outros Frameworks

  • VectorMath
  • vfpmathlibrary
  • Gerenciador de memória Fluid Studios
  • STL?

Imagens Suportadas

  • TGA
  • PNG

Modelos 3D Suportados

  • COLLADA

Gráficos 3D

Escolher entre OpenGL e DirectX é sempre um tema que gera muita discórdia entre programadores experientes, no entanto para desenvolver jogos para dispositivos com iOS ou Android não há outra opção a não ser OpenGL, por isso não vou irritar ninguém com esse artigo, porém a engine foi feita de forma a aceitar DirectX caso alguém venha a utiliza-la algum dia, para isso basta implementar uma única nova classe de render.

Como escolhi OpenGL, fui obrigado a escolher também a sua versão ES (embedded systems http://www.khronos.org/opengles/) pois os dispositivos móveis suportam apenas essa especificação, que na verdade não se diferencia muito da sua versão normal, no entanto o que realmente faz toda a diferença é a versão, pois na 1.1 temos o que chamamos de fixed function pipeline e na versão 2.0 temos o programmable pipeline (o poder dos Shaders), para a versão 0.5 da Magic3D que é a disponível no momento, implementei apenas a versão 1.1, por ser compatível com a maioria dos hardwares do mercado, principalmente com Android e por apresentar resultados rápidos no desenvolvimento, mas para a versão 1.0 da engine que deve ficar pronta após o primeiro jogo desenvolvido nela, a versão 2.0 estará com certeza implementada por conter muitos avanços principalmente visuais e de performance.

Física

A engine de física Bullet http://bulletphysics.org é muito conhecida pelos desenvolvedores de jogos e foi escolhida por ser extremamente fácil de se utilizar, portável para vários sistemas operacionais e ter excelente performance principalmente em dispositivos mobile.

Som

Especialmente para mim é uma parte crítica, não por ser complicado de se implementar, mas porque sou analfabeto em música, portanto não posso dizer que minha escolha foi a mais acertada em termos de qualidade, na verdade escolhi OpenAL http://connect.creativelabs.com/openal/ pela simplicidade na implementação, por isso atualmente os sons só funcionam no iOS, na versão 1.0 da Magic3D será implementado suporte a OpenSL ES que é a especificação suportada pelo Android.

Para a versão 1.0 da Magic3D pretendo colocar também suporte ao sistema de som nativo do iOS, por proporcionar melhorias significativas na performance dos jogos, pois utiliza o processador exclusivo para sons dos aparelhos como iPhone e iPad.

O formato OGG foi o escolhido por ser livre e não ser necessário pagar licença nem para ler e nem para gravar, por isso são necessárias as bibliotecas Vorbis e OGG http://www.xiph.org/downloads/.

Vídeo

Essa é uma característica que irei implementar na versão 1.0 da Magic3D junto com os shaders, pois em fixed function os vídeos tocam a menos de 20fps em alguns testes preliminares, mas a princípio a biblioteca Theora http://theora.org/ foi escolhida por ser livre e de fácil implementação.

XML

Um parser XML http://www.w3.org/XML/ pode ser facilmente substituído por um parser JSON http://www.json.org/, no entanto o formato escolhido para os modelos 3D da engine foi o COLLADA e sua especificação é em XML, portanto para aproveitar a biblioteca TinyXML2 https://github.com/leethomason/tinyxml2 que foi a escolhida para fazer a leitura dos modelos, o grafo de cena da Magic3D também utiliza o formato XML.

Compactação

Para armazenar os assets dos jogos na versão 1.0 da Magic3D será implementado um sistema de pacotes zip e para isso foi escolhida a biblioteca Zlib, que também é utlizada para descompactar as imagens PNG utilizadas nas texturas dos modelos.

Outros Frameworks

Para agilizar o desenvolvimento resolvi também utilizar outros frameworks que são importantes para a engine como por exemplo VectorMath http://bullet.svn.sourceforge.net/viewvc/bullet/trunk/Extras/vectormathlibrary/ e vfpmathlibrary http://code.google.com/p/vfpmathlibrary/ ambas para cálculos matemáticos de matrizes, vetores e quaternions, um gerenciador de memória da Fluid Studios http://www.paulnettle.com/ para detectar os memory leaks e a controversa biblioteca STL, controversa pois alguns amam e outros odeiam, no meu caso a escolha foi feita para encurtar o tempo de desenvolvimento, pois eu utilizo string, vector, list e map e se eu tivesse que implementa-las manualmente levaria muito tempo, mas eu não descarto a possibilidade de fazer isso caso seja necessário para evitar fragmentação de memória e número excessivo de alocações (características da STL, mas isso é assunto para um outro artigo) e até mesmo aumento de performance.

Assets

Para a versão 0.5 da Magic3D optei por utilizar os formatos PNG e TGA para as texturas, por serem formatos muito difundidos e altamente portáveis, no entanto para a versão 1.0 provavelmente será implementado o suporte ao formato PVRTC suportado pelos dispositivos com iOS para diminuir a quantidade de memória de vídeo utilizada.

Para os modelos 3D foi escolhido o formato COLLADA http://www.khronos.org/collada/ devido à sua flexibilidade e fácil utilização, no entanto essa escolha também pode causar discórdia, pois normalmente as engines implementam seus próprios formatos otimizados, mas uma boa justificativa para o uso do COLLADA é que por ser aberto e bastante difundido, vários softwares de modelagem como Max, Maya, XSI e Blender, exportam e importam seus modelos para esse formato sem a necessidade de plugins externos, enquanto que seu tivesse escolhido desenvolver um formato proprietário eu teria que implementar plugins para pelo menos os softwares mais famosos de modelagem e posteriormente dar manutenção e suporte aos mesmos em cada alteração no meu formato, o que demandaria muito tempo, tempo esse que pode ser utilizado em outras melhorias realmente importantes na engine.


Após a definição da base tecnológica era preciso juntar tudo isso e colocar para funcionar, e aí que aparecem as dificuldades, pois se eu apenas agrupasse tudo isso e dissesse que era uma engine com todas essas tecnologias eu estaria mentindo, pois não seria uma engine e sim um pacote de frameworks, que é o que muitas supostas engines fazem.

A principal idéia da Magic3D é que ela fosse simples e fácil de se utilizar, por isso ela foi desenvolvida de forma que a maior parte do trabalho seja feita pelo editor e que o programador realmente só precise programar a inteligência artificial do jogo sem se preocupar com os demais aspectos proporcionados pelos frameworks que a compõem.

Como eu disse anteriormente eu queria um editor que fosse multiplataforma e simples de utlizar, o primeiro problema eu resolvi utilizando QT http://qt.nokia.com/ que é um SDK completo inclusive com IDE que proporciona a possiblidade de desenvolver aplicações em e para Linux, Windows e Mac sem a necessidade de reescrever o código para cada um dos sistemas operacionais, na verdade o único trabalho é recompilar a aplicação. Quanto à simplicidade na utilização não sei se atingi o objetivo, pois ninguém o utilizou ainda, então só saberei e poderei melhorá-lo a partir dos comentários da comunidade.

Em relação ao tempo de desenvolvimento, comecei em Junho de 2011 e finalizei a primeira versão utilizável em Dezembro de 2011, mas em Janeiro de 2012 criei o template para utilizá-la no Xcode e desenvolver para iOS e o projeto para Android utilizando NDK que ainda não foi testado. Foram 2 meses para fazer a engine propriamente dita funcionar, 2 meses para aprender QT, implementar o editor e integrar com a engine e 2 meses de correção de bugs e melhorias no editor, sendo que durante todo o período de desenvolvimento eram gastas de 4 a 6 horas por dia (somente à noite após o trabalho).

A Magic3D encontra-se na versão 0.5 e deve chegar à versão 1.0 em Maio de 2012, seguem as características atuais e a previsão de melhorias para a próxima versão:

Versão 0.5 (Beta)

  • Render OpenGL ES 1.1
  • Física (Bullet)
  • Som (OpenaAL com suporte a arquivos OGG)
  • Cameras (Ortográfica e em Perspectiva)
  • Luzes
  • Multitextura (2 texturas)
  • Texturas em formato PNG e TGA
  • Sistema de Partículas
  • Modelos 3D com animação por bones (suporte a arquivos DAE)
  • Sprites 2D (baseado em atlas de textura)
  • Texto 2D (baseado em atlas de textura)
  • Sistema de GUI com listeners para interação com jogador.
  • Gerenciador de memória
  • Sistema de profile simples (FPS, triangulos, número de draw calls, etc.)
  • Biblioteca de matemática
  • Editor visual de cenas para Linux, Windows e Mac

Versão 1.0

  • Render OpenGL ES 2.0
  • Som (OpenaSL ES para dispositivos com Android)
  • Som (Sistema nativo do iOS com suporte a MP3)
  • Texturas em formato PVTRC para iOS
  • Shaders (incluindo alguns básicos como PHONG, TOON e HDR)
  • Vídeo (Theora)
  • Sombras (Shader e Stencil Buffer)
  • Octree para o grafo de cena.

Quem quiser pode fazer o download do editor (MGE) no site da minha empresa http://www.magictech.com.br/ e assim que terminar o primeiro jogo que estou fazendo com ela, disponiblizarei também os projetos template para iPhone, iPad e Android.

Nos próximos artigos vou escrever sobre o passo a passo do desenvolvimento da engine e mostrarei exemplos e tutoriais de como utilizá-la.


Comentários (37)
  • Jair Dubik  - Parabéns
    avatar

    Parabéns pela iniciativa.

    Ai pessoal, precisamos valorizar as coisas feitas em nosso pais.

  • Thiago C. Moraes
    avatar

    Obrigado Jair!

  • Rafael Prandi  - Parabéns!
    avatar

    Muito legal sua iniciativa!

    Espero que você continue a trabalhar para sempre melhorar a engine e continuarei acompanhando no Ponto V seus posts

  • Thiago C. Moraes
    avatar

    Obrigado Rafael!

    A ideia é continuar a melhorar a engine e sempre que possível postar artigos técnicos ou de tutorial.

  • Marcelo  - Sobre custos de desenvolvimento no android
    avatar

    Thiago, se não estou enganado, os US$ 25,00 que a google cobra para publicar aplicativos, é apenas para criar a sua conta de publicador, depois disso não se paga mais. Só se eles mudaram isso recentemente.

  • Thiago C. Moraes
    avatar

    Você tem razão, acho que me empolguei nas taxas, mas essa realmente é só para se registrar como desenvolvedor, já corrigi o texto, muito obrigado!

  • José F. Filho  - Nota dez !
    avatar

    Sou um grande fã do Thiago, desde os tempos de OGLE3D !

    Parabéns Thiagão !

  • Anônimo
    avatar

    ola!

    Gostei, mas porque não usas algumas bibliotecas como,
    Assimp (http://assimp.sourceforge.net/) - para carregar varios tipos de modelos
    DevIL(http://openil.sourceforge.net/) - para carregar vários tipos de formatos de imagens

    pessoalmente tb gosto do GLM (http://glm.g-truc.net/), é basicamente apenas alguns header files para permitir usar estruturas de dados e operações como em GLSL.

  • Bruno Crivelari Sanches
    avatar

    Na minha opinião, a Assimp não é muito boa para se integrar diretamente no engine, ela vem com um formato interno próprio e força um modelo de cena próprio, que não pode ser o que você quer para o seu motor, eu usaria no máximo no pipeline de ferramentas para fazer conversão.

    Uma das partes mais infernais de um motor 3d na minha opinião é de onde vem os modelos e isso você depende muito dos artistas, os artistas se restringem a uma ou duas ferramentas (leia 3d studio ou maya), as vezes usam alguma outra ferramenta, então um plugin para max ou suporte a FBX, já resolve 99% dos problemas.

    Depois da minha experiência com unity, vi como é prático para programadores e artistas o suporte a FBX, o artista exporta diretamente do FBX, pode editar diretamente o FBX se for preciso, aquilo é muito prático, eu se fosse fazer um novo motor, com certeza iria mais a fundo nisso e provavelmente de inicio só suportaria FBX.

    A DevIL acho muto problemática, é uma dor de cabeça para fazer builds com certos formatos e anda bem parado o projeto, eu prefiro usar SDL + SDLImage ou então a FreeImage: http://freeimage.sourceforge.net/

    Mas são opiniões e experiências :)

  • Thiago C. Moraes
    avatar

    Olá,

    Bem, como seu nome está Anônimo, não sei como te chamar hehehehe, mas é o seguinte, quando eu comecei a desenvolver a Magic3D, uma das premissas era que ela fosse pequena, simples e fácil de se entender e principalmente compilar, por isso só usei bibliotecas prontas para aquilo que eu não conseguiria ou levaria anos para programar, como por exemplo, Física, Som e Vídeo, o resto eu queria escrever do meu jeito inclusive para aprender definitivamente alguns conceitos que ainda me faltavam, então por isso que eu escrevi o código para ler TGA e PNG e não usei nenhuma biblioteca pronta e escrevi o código para carregar COLLADA, você não faz idéia do quão feliz fiquei ao ver o meu primeiro modelo 3D com animação por bones funcionar na Magic3D, utilizando os famosos Quaternions, sendo o código de leitura do COLLADA e renderização dos triângulos e animações todo escrito por mim ;).

    Bruno, faço minhas as suas palavras em todas as suas colocações, no entanto não usei o FBX por outra premissa básica da Magic3D, que é ter disponível o código fonte de tudo que ela faz, pois assim que eu disponibilizá-la (o que será nas próximas semanas) o meu intuito é que pessoas como eu que queiram saber como as coisas funcionam tenham pelo menos um lugar para procurar, pois como eu disse não vejo ela disputando com nenhuma engine do mercado, mas vejo talvez pessoas utilizando-a para de repente aprender como não se fazer algumas coisas hehehehehhe.

    Para ler e gravar arquivos FBX é necessário usar o SDK da Autodesk http://usa.autodesk.com/fbx/ que não vem com os códigos fontes, mas sem dúvida o formato FBX é excelente e como a Magic3D é free e com TODOS os fontes, se alguém quiser usá-la e implementar o suporte a FBX ou qualquer outro formato eu tenho certeza que conseguirá com muita facilidade.

    Inclusive para ler o COLLADA existe um projeto maravilhoso que é o OpenCOLLADA http://opencollada.org/ usado por muitas ferramentas, mas como eu disse eu queria aprender como o formato funcionava em sua essência e por isso escrevi o meu próprio.

    Outra coisa importante é que o COLLADA é suportado pelas principais ferramentas modernas de modelagem como MAX, MAYA, XSI e o Blender que foi a ferramenta escolhida por mim para fazer meu futuros jogos na Magic3D.

    Como disse no artigo, alguns pontos da Magic3D são controversos, pois são escolhas pessoais e talvez não sejam as melhores, mas fiz essas escolhas sempre pensando na simplicidade, possibilidade de distribuição gratuita e flexibilidade.

    Muito obrigado pelas opniões e será sempre um prazer conversar sobre essas tecnologias fantásticas que fazem parte do mundo dos GAMES.

  • Bruno Crivelari Sanches
    avatar

    Oi Thiago,

    sim, o FBX tem esse inconveniente que você fica amarrado na SDK da autodesk, como na maioria dos casos os estudios já são amarrados ao Max e outros produtos da Autodesk, isso geralmente não incomoda.

    Mas no seu caso, com os objetivos que você tem, o FBX passa a ser dor de cabeça mesmo.

    O COLLADA eu cheguei a estudar uma epoca, mas nunca fiz nada de concreto, já fiz projetos bons usando ele, o Penumbra por exemplo, no editor era só arrastar um arquivo dae para a tela que ele já carregava, que nem um Unity.

    Eu cheguei a ver essa APi do COLLADA, tão complexa quanto o próprio formato e acho que se fosse usar, faria o mesmo que você, faria um leitor no braço carregando então apenas as partes que fossem do meu interesse.

    Abraços

  • Daniel Monteiro
    avatar

    ADORO re-inventar a roda! :P
    Mas no meu caso, eu sou mais extremo. Eu gosto de escrever absolutamente tudo ( isso quando se trata dos meus projetos pessoais. Em ambiente profissional eu uso libs externas ).

    Mas uma questão que me deixou encucado: Se você esta no ambiente de C++ do Android, você ja não tem uma lib de XML no OS? Sei que no ambiente java ( no qual estou construindo minha própria engine de re-invenção de roda ) eu ja tenho isso cara. Lembro que quando fui fazer uma app de iOS que usava XML, tive que recorrer ao Google Data XML Framework, que resolvia lindamente meus problemas.

    Se você quiser ajuda para benchmarking, eu tenho uns Android por aqui =-D

    Boa sorte!

  • Thiago C. Moraes
    avatar

    Opa, então, não fui muito a fundo no android ainda, só compilei uma primeira versão do template para teste, vou deixar isso para quando o primeiro jogo ficar pronto, por enquanto estou focado no iOS para terminar logo o primeiro jogo que vou disponibilizar como tutorial da Magic3D, mas a escolha da TinyXML é pq ela é fácil, pequena e funciona em qualquer plataforma, justamente por não saber se no android tinha uma lib específica para isso resolvi escolher uma que eu sabia que funcionaria em qualquer plataforma.

    Quanto aos benchmarks assim que eu lançar alguma coisa nela será um prazer saber sobre a performance, pois poderei otimizá-la.

    Quanto a reescrever absolutamente tudo, dessa vez não foi possível, pois não vejo uma lib como a bullet, openal, zlib, libpng, ogg, theora e outras sendo escritas do zero e em menos de 6 meses que foi o tempo de desenvolvimento da engine, sem contar os anos de uso e testes que as transformaram em bibliotecas sólidas e robustas, por isso resolvi fazer do zero só algumas partes, para reduzir escopo e possíveis problemas, mas sem dúvida tudo do zero é muito mais legal huahauahuahauaha, só o editor por exemplo que comecei do zero inclusive sem saber Qt, já foi um aprendizado e tanto e extremamente prazeroso.

    Um abraço! Valew!

  • Nilton Constantino
    avatar

    Olá amigo, parabéns pela iniciativa! Estava com o mesmo problema que você, não encontrava alternativas que fossem boas e baratas. Então resolvi reinventar a roda. Apesar de que este termo é um pouco exagerado. Algumas técnicas só iremos conhecer se colocarmos a mão na massa realmente. Um projeto desse com objetivos de estudo (inicialmente) é muito válido para você e até mesmo para a comunidade, pois como você disse: "aprender a como não fazer as coisas" :) Quem sabe em um futuro a coisa deslancha.

    Tenho iniciado fazendo a engine física, e por enquanto só a física "basicona" de partículas está sendo projetada. Tenho desenvolvido em conjunto a engine gráfica tb, mas está muito fraquinha ainda. Mas, acredito que até o final do ano eu consiga fazer alguma coisa jogável nela (minha produção está um pouco lenta, mas logo logo melhora). Até havia pensado em usar a Bullet ou outra qualquer, mas como o objetivo é aprender e possivelmente ensinar, a coisa tem que ser na mão mesmo. Quem sabe futuramente troquemos figurinha! Grande abraço e bom trabalho.

  • Bruno Crivelari Sanches
    avatar

    Oi Nilton,

    como anda seu motor de física?

    Se quiser fazer artigos falando a respeito de como fazer um ou apenas discutir as técnicas, entre em contato :).

  • Nilton Constantino
    avatar

    Olá Bruno,

    Como disse outrora, o motor ainda está em fase de construção, planejamento e algumas coisas como física de partículas está implementada. Basicamente, é um motor de impulso. Por ser o meu primeiro motor de física (que faço com seriedade) achei melhor fazê-lo com base nesta vertente. Estou iniciando o pipeline de colisões e logo em seguida iniciarei a parte que trata da física de corpos rígidos. Essas divisões são as que estabeleci para mim mesmo. Mas, é isso. :)

    Sobre escrever os artigos, achei o convite interessante, pois é extremamente difícil encontrar material em português sobre o assunto, com relativa qualidade. Tentarei escrever algo com carinho e qualidade, mas estou realmente muito atarefado no momento e acredito que este artigo não sairá tão em breve assim. Ok?

  • Bruno Crivelari Sanches
    avatar

    Sem problemas, só entrar em contato quando tiver algo!

    Alias, quando tiver um demo publico me manda o link :).

    Obrigado!

  • Iberlucio  - Criando empresa
    avatar

    boa tarde Thiago,
    Vi seu poste e achei interessante, e fiz a leitura do mesmo, parabéns.

    Estamos criando uma empresa de desenvolvimento de jogos, e já definimos nossos objetivos, mas, preciso de uma equipe profissional,
    não queremos fazer nada amador, pois, não somos um grupo de estudantes ou amigos arriscando na vida, queremos duas informações tua:
    1 - Onde contrato o líder de equipe?
    2 - Onde entra tua engine, ela é realmente boa?
    3 - A maioria da equipe pode trabalhar em Home office ou é inviável?

    Atenciosamente
    Iberlucio santos

  • Iberlucio
    avatar


    Meu e-mail é: tiatiragames@hotmail.com

    No post não costa correto.

  • Thiago C. Moraes
    avatar

    Olá Iberlucio,

    Respondendo às suas perguntas:

    1 - Aqui no site tem uma área dedicada a anúncios de emprego, acredito que muita gente irá te procurar caso você anuncie a vaga aqui, no mais para esse tipo de vaga seria interessante conhecer bastante gente que trabalhe com jogos para pedir indicações, mas que fique claro que o salário de um bom profissional para esse cargo é alto, pois você precisará de alguém com bastante experiência para poder ter um bom produto, caso contrário poderá inclusive nem terminar o projeto, como muitas empresas que conheci.

    2 - Acredito que minha engine ficará boa em breve, pois como disse ainda estou terminando meu primeiro jogo nela e por isso não a recomendo, principalmente para uma empresa que está iniciando, acredito que a Unity seja a melhor escolha no seu caso, por ser barata, fácil, flexível e ter muita gente que trabalha atualmente com ela.

    3 - Minha opinião estritamente particular sobre Home Office é de que para jogos não funciona, pois jogos envolvem processos de criação e artísticos extremamente complicados de se unificar caso tenham sido desenvolvidos por equipes à distância, obviamente uma ou outra coisa pode ser feita (normalmente alguns assets secundários), mas acredito que para um bom jogo o ideal é uma equipe reunida em um mesmo ambiente.

    Obrigado!


    Acredito que os leitores do site podem ajudar ainda mais com opiniões e comentários a respeito.

  • José F. Filho
    avatar

    Sobre a questão do "Home Office", se não me engano, a Frictional Games trabalha assim. No próprio site deles está escrito que a equipe "tem a internet como escritório". Mas creio que o êxito trabalhando assim, vai depender das tuas exigências e é claro, da experiência da equipe e da complexidade do game.

  • Iberlucio  - Valor da equipe
    avatar

    Olá Thiago,
    na verdade eu trabalhava com Mainframe, e estou migrando para o mundo dos jogos, sendo assim, tô por fora dos valores a serem pagos para a equipe de jogos, por isso, fiz essa planilha baseado em algumas informações coletadas, tu pode dar uma ajudinha fazendo uma revisão nos valores e nas quantidades apresentadas para montar a equipe?


    Líder 1 R$ 3.000,00 R$ 3.000,00
    Recursos 1 R$ 2.000,00 R$ 2.000,00
    Eventos 1 R$ 2.000,00 R$ 2.000,00
    Scripts 1 R$ 2.000,00 R$ 2.000,00
    Roteirista 1 R$ 2.000,00 R$ 2.000,00
    Design 1 R$ 2.000,00 R$ 2.000,00
    Sonoplasta 1 R$ 2.000,00 R$ 2.000,00
    Mapeamento 1 R$ 2.000,00 R$ 2.000,00
    Pixel Art 1 R$ 2.000,00 R$ 2.000,00
    Multifunção 1 R$ 2.000,00 R$ 2.000,00

    Atenciosamente
    Iberlucio santos

  • Bruno Crivelari Sanches
    avatar

    A questão dos valores é um tanto delicada e depende muito do nível do profissional e da região onde você contrata ele.

    Sem falar que essas descrições sua não dizem muita coisa e algumas funções você nem precisa o tempo todo, pode terceirizar.

    Para os profissionais que tenho contato, esses valores estão bem abaixo do mercado...

  • Iberlucio
    avatar

    Ok Bruno,
    então qual o percentual que devo aplicar para ajustar esses valores ao de mercado que tu trabalha?

  • Bruno Crivelari Sanches
    avatar

    Depende muito, não tem como prever sem saber o tipo de projeto ou o jogo, varia muito...

    O valor de profissionais de jogos não é muito diferente de outros valores em desenvolvimento de sw, basta ver o tipo de profissional que você precisa... se você é da área da mainframe, tem contato com programadores e tem noção de valores na área, então vai conseguir chegar numa boa aproximação.

    Agora apenas valores assim ao alto, para uma capital, esses valores são ridículos, para uma cidade bem no interior afastada de grandes centros, em alguns casos são bons valores, mas em geral, apenas juniores e você não vai fazer muitos projetos apenas com juniores.

  • Iberlucio
    avatar

    Meu querido, eu sei que os valores estão baixos,
    como eu falei, não tenho noção dos valores para essa area, por isso, quero me familiarizar, na minha visão, os caras que ganhavam bem, sempre foram os de Grande porte.
    No caso de Mainframe eu sei, tenho 25 anos de praia, nessa plataforma.
    Mas essa papo está sendo muito proveitoso para fazer os ajustes que quero.

  • Anônimo
    avatar

    Interessante! Que tipo de projeto/jogo você está pensando em realizar? MMO?

  • Iberlucio
    avatar

    Jovem,
    infelizmente não posso responder a essa questão, pois, estamos fazendo todo o processo altamente profissional e sigiloso.
    Mas, não seria um(1) projeto, mas somos uma empresa que desenvolve vários projetos e todos direcionados para jogos.

    Caso seja do teu interesse se canditar, nos envie seu curriculo, já fizemos o anuncio aqui no site, ainda não foi publicado, mas creio que será.


  • Anônimo
    avatar

    Então a empresa já existe? Tem website?
    E se você já desenvolve projetos para jogos como você não sabe os cargos e custos relacionados? Não está me parecendo muito profissional, apenas mais um que não sabe com o que está lidando.

  • Anônimo
    avatar

    Certo Thiago,
    Analisei o site que tu passou acima, voce quer dizer que os valores pagos aqui noi Brasil, seguem esse padrão?

  • Anônimo
    avatar

    Então, que tipo de jogo você pensa em fazer?

  • Thiago C. Moraes
    avatar

    Na verdade como eu disse, essa era uma lista para você tirar os cargos necessários, mas os salários se convertidos diretamente para reais, ou seja sem a taxa de câmbio menos uns 20% podem sim ser tomados como base para as Capitais por exemplo.

  • Iberlucio
    avatar

    Obrigado Thiago,
    as informações colhidas aqui, foram úteis.

  • Ruby
    avatar

    Olá pessoal, estou com uma dúvida se é que pode-se dizer que é duvida. Mas vamos aos fatos: Estou tentando desenvolver um jogo que as ruas se movimentam e não as pessoas, essa podem andar de lá para cá, mas quando precisam se deslocar em grandes distancias estas usam as ruas que se movimentam, assim como se fossem esteiras rolantes, determinadas ruas são lentas outras rapidas e outras ainda ultra rapidas.

  • Anônimo
    avatar

    e? qual é a duvida? ...

  • Tania  - Contato Profissional
    avatar

    Thiago,

    Gostaria de seus contatos para falarmos de algo profissional. Você poderia passar seu e-mail ou telefone?

    (11) 4121-6684 ou tania.siqueira@semcon.com
    Obrigada.

Escrever um comentário
Your Contact Details:
Gravatar enabled
Comentário:
[b] [i] [u] [url] [quote] [code] [img]   
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch::(:shock:
:X:side::):P:unsure::woohoo::huh::whistle:;):S:!::?::idea::arrow:
Security
Por favor coloque o código anti-spam que você lê na imagem.
LAST_UPDATED2  

Busca

Linguagens

Twitter