Semana passada eu descobri que a SDL foi portada para o Nintendo DS, então eu pensei que seria legal portar o Rockbot para ele - eu adoraria recriar o Rockman 0 e 10 para jogar no meu DS já que a Capcom decidiu não portá-lo. Na verdade, a primeira razão para eu decidir criar todo o projeto Rockbot foi por estar brabo com a Capcom que decidiu não portar um jogo que parece de NES para plataformas antigas como o Playstation, e eu não tenho dinheiro ou desejo de comprar um console de nova geração.
Mas bem, uma vez assentada a idéia, eu tinha que construir todo o SDK do DS e as bibliotecas SDL, o que se mostrou um desafio, porque a SDL foi baseada em uma evrsão antiga do kit de desenvolvimento e tive que corrigir alguns bugs antes de ter um ambiente funcional para compilar alguns testes. Uma vez terminado, eu teria que diminuir o uso de memória de 46MB para menos de 4MB, que é o limite do Nintedno DS.
Aí vem a parte divertida, a maioria dos programadores de hoje são simplesmente preguiçosos de otimizar o código e usam o quanto de memória conseguirem, e frequentemente as pessoas acham que os jogos mais legais são os que as obrigam a comprar um computador inteiro novo, então podem ter um PC super modificado com luzes de laser interno e resfriamento a água e outras tolices frescas. Felizmente, os videogames não estão infestados por essa moda de atualizações frequentes. Então, a primeira coisa a fazer é usar variáveis menores, já que estou lidando com valores abaixo de 64 mil, todos os inteiros foram convertidos para short. O próximo passo foi limitar o uso de cores a 256, usando paleta web-safe, o que no fim das contas é legal, por parecer mais com os jogos antigos de NES. Finalmente, não dá para carregar toda uma fase na memória de uma vez, pois é isso o que mais usa memória, já que o núcleo em sí é bem pequeno. Então, eu reduzi o tamanho do mapa, e agora o jogo usa cerca de 5.1MB de RAM!
Mas nós precisamos de mais, por isso eu planjeo usar os mesmos truques que jogos de NES antigos usavam: quebranco a fase em partes. Lembram-se como era lenta a transição de tela quando você estava em uma escadaria, ou alguns jogos tinham uma sala de chefe no meio? A razão é que, neste momento, vocês está liberando um mapa e carregando outro. Assim, acredito que será possível reduzir o uso de memória para 3MB.
O passo seguinte é aprender a editor os makefiles dos exemplos de SDL para DS para recompilar o Rockbot para o Nintendo DS e testar. Mas como o fim de ano está próximo, por enquanto planejo trabalhar em gráficos.
Outras notícias:
- você pode sair da introdução pressionanto start
- começado trabalho em um teileset para montar um cenário
- feito um build teste para PS2, funciona bem, mas ainda tem problemas com delay/waiters.
- O PS2 precisa de ajustes para carregar os drivers necessários de acordo com a unidade de onde o programa está rodando, e também setar o FILEPATH com ela
- precisa ser refeito o sistema de tempo para frame de animação- por alguma razão eu perdi parte do código
- devemos implementar escadarias e "teleporte" de um mapa para outro
- implementar som usando SDL_mixer e doomsdl_mixer (PS2)
segunda-feira, 14 de dezembro de 2009
loading...
Last week I found that SDL was ported to Nintendo DS, so I tought that it would be a great thing to port Rockbot to it - I would love to recreate Rockman 9 and 10 to play on my DS once Capcom do not port it. Actually, the first reason I decided to create the whole Rockbot project was because I was angry Capcom did not wanted to port a game that is NES like to old platforms such as Playstation 2 and I do not have money, nor desire, to buy a new generation console.
But well, once settled the idea, I had to build all the DS SDK and SDL libraries, that showed to be a chalenge, because the SDL port was to an old version of the devkit and I had to fix some bugs before having an working dev enviroenment to build some tests. Once it was done, phase two started, I have to diminish memory usage from 46 MB to less than 4MB, that is Nintendo DS limit.
Now comes the fun part, most programmers today are just lazy to optimize code and take as much memory as he can get, and often people find that the good games are the ones that need a complete upgrade on your system, so you can have and ultra modded PC with internal lazer lights, water cooling and other pimp foolishes. Gladly videogames are not plagued by this upgrade-often fashionism. So, first thing is to use smaller variables, as I'm dealing with values under 64k, all integers were converted to short. Next step is to limit color usage to 256 colors, using web-safe palette, that is nice because looks more like old NES 8 bits style. Finally, we can't load the whole stage in memory, because it is the thing that uses more space, as the program core footset by itself is very small. So, I've lowered the size of the map, and now the game uses only just around 5.1 MB in RAM!
But we need more, so I plan to use the same tricks old NES games used: breacking the stage in parts. Remember how slow was the scrolling when you changed screens on a starircase? Always wondered why some games had a middle-boss room? This is why, in that moment, you just freed one map, and loaded a new one. So, I believe soon, we'll be able to reduce the memory usage to 3MB.
Next step is learn how to edit the makefiles from SDL+DS examples to compile Rockbot to Nintendo DS and test. But as holidays are near, for now I've work on intro and graphics.
In other news:
- you can skip intro by pressing enter
- started to work on a tileset to build a scenary
- made a build to test PS2, works OK but still have bugs with delay/waiters
- PS2 needs adjustments to load necessary drivers according to the unity is is running from, also, set the FILEPATH with it.
- needs to re-work the animation frame delay - for some reason I've lost part of code
- must implement staircase and map "teleport" to another map
- implement sound using SDL_mixer and doomsdl_mixer (PS2)
But well, once settled the idea, I had to build all the DS SDK and SDL libraries, that showed to be a chalenge, because the SDL port was to an old version of the devkit and I had to fix some bugs before having an working dev enviroenment to build some tests. Once it was done, phase two started, I have to diminish memory usage from 46 MB to less than 4MB, that is Nintendo DS limit.
Now comes the fun part, most programmers today are just lazy to optimize code and take as much memory as he can get, and often people find that the good games are the ones that need a complete upgrade on your system, so you can have and ultra modded PC with internal lazer lights, water cooling and other pimp foolishes. Gladly videogames are not plagued by this upgrade-often fashionism. So, first thing is to use smaller variables, as I'm dealing with values under 64k, all integers were converted to short. Next step is to limit color usage to 256 colors, using web-safe palette, that is nice because looks more like old NES 8 bits style. Finally, we can't load the whole stage in memory, because it is the thing that uses more space, as the program core footset by itself is very small. So, I've lowered the size of the map, and now the game uses only just around 5.1 MB in RAM!
But we need more, so I plan to use the same tricks old NES games used: breacking the stage in parts. Remember how slow was the scrolling when you changed screens on a starircase? Always wondered why some games had a middle-boss room? This is why, in that moment, you just freed one map, and loaded a new one. So, I believe soon, we'll be able to reduce the memory usage to 3MB.
Next step is learn how to edit the makefiles from SDL+DS examples to compile Rockbot to Nintendo DS and test. But as holidays are near, for now I've work on intro and graphics.
In other news:
- you can skip intro by pressing enter
- started to work on a tileset to build a scenary
- made a build to test PS2, works OK but still have bugs with delay/waiters
- PS2 needs adjustments to load necessary drivers according to the unity is is running from, also, set the FILEPATH with it.
- needs to re-work the animation frame delay - for some reason I've lost part of code
- must implement staircase and map "teleport" to another map
- implement sound using SDL_mixer and doomsdl_mixer (PS2)
quinta-feira, 10 de dezembro de 2009
Editor Update
Iniciei o trabalho na ferramenta de edição de NPC. Ela será mais complexa no futuro, já que o usuário terá que adicionar cada frame gráfico, mas atualmente é bastante fácil pois não possui suporte a animação de NPCs.
Started to work on the NPC editing tool. It will be kind of complex in the future, as the user will have to add each frame, but currently it is fair simple as it does not support animation for NPCs.
Started to work on the NPC editing tool. It will be kind of complex in the future, as the user will have to add each frame, but currently it is fair simple as it does not support animation for NPCs.
[editing a NPC]
segunda-feira, 7 de dezembro de 2009
Editando
Durante o fim de semana, foram feitos os últimos retoques no editor básico, que já conta com boa parte das funcionalidades do editor antigo e no motor do jogo para suportar o novo formato de mapas.
Uma desvantagem do novo formato, é ao contrário de idéia inicial de termos um arquivo por mapa, que decidimos por ter um número fixo de estágios e tamanho de mapas unificado em um único arquivo, para simplificar a programação do sistema. O problema reside exatamente no tamanho, um arquivo de jogo possui 34 Mega bytes, o que não é exatamente um problema hoje em dia, mas ainda desejamos diminuir, se possível, este valor, usando compressão via zlib ou outras alternativas.
O que está faltando são ferramentas como desenhar uma linha ou fazer preenchimento com um tile, para o usuário não cansar de clicar o botão do mouse. Além disso temos que começar a organizar e implementar suporte a objetos mais complexos como NPCs, objetos móveis (implementando um segundo nível de tiles) e outras características para poder finalmente produzir um pequeno jogo na versão 1.0.
Uma desvantagem do novo formato, é ao contrário de idéia inicial de termos um arquivo por mapa, que decidimos por ter um número fixo de estágios e tamanho de mapas unificado em um único arquivo, para simplificar a programação do sistema. O problema reside exatamente no tamanho, um arquivo de jogo possui 34 Mega bytes, o que não é exatamente um problema hoje em dia, mas ainda desejamos diminuir, se possível, este valor, usando compressão via zlib ou outras alternativas.
O que está faltando são ferramentas como desenhar uma linha ou fazer preenchimento com um tile, para o usuário não cansar de clicar o botão do mouse. Além disso temos que começar a organizar e implementar suporte a objetos mais complexos como NPCs, objetos móveis (implementando um segundo nível de tiles) e outras características para poder finalmente produzir um pequeno jogo na versão 1.0.
Editing
During the last weekend, some retouchs were made into the basic editor tool, that already have a good part of the functionalities from the old editor, and in the game engine to support the new maps format.
One disavantage of the new format is that, contrary to the initial idea of have one file for each map, that we decided to have a fixed number of stages and unified map size in just one file, to make the system programming simpler. The problem is that the size of the file containing the game is now 32 mega bytes, that is not a big problem nowadays, but we still want to lower this value, if possible, using compression with zlib or by using some other alternative.
What is missing are tools like drawing a line or filling with a tile, so the user does not get tired of clicking the mouse button. Besides that, we have to start to organize and implement support to more complex objects like NPCs, movable objects (implementing a second tile level) and other characteristics in order to be able to, at last, create a small game on version 1.0.
One disavantage of the new format is that, contrary to the initial idea of have one file for each map, that we decided to have a fixed number of stages and unified map size in just one file, to make the system programming simpler. The problem is that the size of the file containing the game is now 32 mega bytes, that is not a big problem nowadays, but we still want to lower this value, if possible, using compression with zlib or by using some other alternative.
What is missing are tools like drawing a line or filling with a tile, so the user does not get tired of clicking the mouse button. Besides that, we have to start to organize and implement support to more complex objects like NPCs, movable objects (implementing a second tile level) and other characteristics in order to be able to, at last, create a small game on version 1.0.
sexta-feira, 4 de dezembro de 2009
quinta-feira, 3 de dezembro de 2009
Editor
I finally learned what I needed to use Qt Creator + Qt Developer to create the editor UI in a easy way, so the plan to drop the Qt editor in favor of the SDL one is no-more. This weekend I plan to have an editor with the same functionalities of the SDL one, and then start improving until it is simular to the one in RPG Maker XP.
Eu finalmente aprendi o que precisava para usar o Qt Creator com o Qt Developer para criar a UI do editor de forma fácil, então o plano de abandonar o editor em Qt em favor do em SDL deixou de existir. Este fim de semana, espero deixar o editor em Qt par a par com o atual, em SDL, e daí em diante incrementá-lo até ficar semelhante ao existente no RPG Maker XP.
Eu finalmente aprendi o que precisava para usar o Qt Creator com o Qt Developer para criar a UI do editor de forma fácil, então o plano de abandonar o editor em Qt em favor do em SDL deixou de existir. Este fim de semana, espero deixar o editor em Qt par a par com o atual, em SDL, e daí em diante incrementá-lo até ficar semelhante ao existente no RPG Maker XP.
quarta-feira, 2 de dezembro de 2009
Pixels
I am no good ate creating pixel art, but slowly we get there:
Eu não sou muito bom em criar arte em pixels, mas devagar chego lá:
Eu não sou muito bom em criar arte em pixels, mas devagar chego lá:
[Ape Bot and Seahorse Bot]
In other news, I'm rethinking the editor plans. Ideally it should be written in C++ with Qt to be like a normal Desktop app, but more and more I'm kind of thunking the task ahead is too big to fit our needs. So I'm back to think about developing the editor also using SDL as it is simpler and keeps the dependencies low for the whole project. We lose some ease of use, but gain in not loosing time with something that is not the focus of the first release.
Em outro tópico, eu estou repensando os planos para o editor. Idealmente ele deveria ser escrito em C++ com Qt para parecer um programa desktop normal, mas estou pensando cada vez mais que a tarefa pela frente é muito grande para caber em nossas necessidades. Então, volto a pensar em desenvolver também o editor em SDL, já que é mais simples e mantém as dependências do projeto como um todo, baixas. Perderemos alguma facilidade de uso, mas ganhamos em não perder tempo com algo que não é o foco do primeiro lançamento.
segunda-feira, 30 de novembro de 2009
Primeiro build, história e gráficos
Um pouco após enviar o código, nós fizemos o upload de uma build para windows do motor do jogo. É bem básica, contém alguns bugs e é apenas uma prova de conceito, mas nós gostaríamos de ter retorno sobre seu funcionamento, então peguem uma cópia e comentem aqui :)
Enquanto o Betabot já é bem diferente dos gráficos originals, o Rockbot ainda parece.. uma simples modificação dos gráficos do Megaman. E é isso que ele é, por enquanto. Nós estamos trabalhando duro para criar o design de personagens bem distinto da série Megaman orginal. Primeiro desenhando a mão com lápis, então a Aris cria versões no Corel Draw (em breve postaremos aqui) the modificamos até achar que está bom o suficiente para para ser adaptado para pixels; então vem a última e mais difícil parte para nós e onde precisamos de ajuda, onde tentamos criar arte em pixels baseada nos designs. Mas eu espero ter até o final de semana, uma versão original dos gráficos do Rockbot, ou pelo menos uma versão bem alterada, como o Betabot.
A história é um tipo de animal bem diferente. É uma tarefa bem fácil e que nós já temos boas idéias de coisas que podemos melhorar sobre a série original:
- uma fase inicial antes da tela de seleção dos oito robôs
- diálogos em pontos chave; como na série X ou anniversary collection em que outros personagens explicam algo
- ambientação no mundo fictício de tokyo 20XX AD
- os chefes vão falar, como nos recentes jogos da série X
A história ocorre basicamente, quando Megaman e Protoman protegem a cidade (no jogo eles são chamados de "heróis" porque não vamos usar seus nomes), um jovem cientista chamado Canotus, inspirado pelas criações do benevolente Doutor Light, cria dois robôs de combate chamados Rockbot e Betabot, para ajudar em pequenas tarefas enquanto os "grandões" estão ocupados. Mas um novo ataque de inimigos ocorre e os heróis desapareceram, então Rock e beta terão que tomar a coroa e lutar com os bandidos em seu lugar.
First build, history and graphics
Some time after submitting the code, we uploaded a windows build of the engine. It is very basic, contains some bugs and is just a proof of concept, but we would like to have feedback about it, so go grab it and comment about :)
While Betabot is already very different than original graphics, Rockbot just looks like.. a mod over Megaman graphics. And that is what it is, for now. We are working hard to create character design to be distinct from the original Megaman series. First drafting in paper with pencil, then Aris creates Corel Draw versions (soon to be posted here) that we change until decide it is good enought and simple to adapt to pixels; then in the last part, we try to create pixel art based on the designs, and this is the part we have most difficulties and need help. But I hope by the end of the week, we will have a original version of its graphics, or at least a version moddified enought as betabot is.
History is a different animal. It is very easy task and we already have good ideas of things we can improve over the original megaman series:
- an intro stage like megaman x4 before selecting on of the 8 bosses
- dialogs in key parts. Like in megaman x series or megaman anniversary collection: other characters talk and explanin things
- tokyo 20xx ad enviroenment (based in the same kind of universe)
- bosses will talk, like recent megaman x games
Basically, while Megaman and Protoman protect the city (in the game they are cited as "heroes" because we won't use the names), a young scientist called Canotus, inspirated by the creations of the benevolent Dr. Light, creates two fighting robots, called Rockbot and Betabot, to help out in small missions while the big-ones are occupied. But a new raid of enemies happen and the heroes are now missing, so Rock and beta have to take the crown and fight the bad guys in their place.
While Betabot is already very different than original graphics, Rockbot just looks like.. a mod over Megaman graphics. And that is what it is, for now. We are working hard to create character design to be distinct from the original Megaman series. First drafting in paper with pencil, then Aris creates Corel Draw versions (soon to be posted here) that we change until decide it is good enought and simple to adapt to pixels; then in the last part, we try to create pixel art based on the designs, and this is the part we have most difficulties and need help. But I hope by the end of the week, we will have a original version of its graphics, or at least a version moddified enought as betabot is.
History is a different animal. It is very easy task and we already have good ideas of things we can improve over the original megaman series:
- an intro stage like megaman x4 before selecting on of the 8 bosses
- dialogs in key parts. Like in megaman x series or megaman anniversary collection: other characters talk and explanin things
- tokyo 20xx ad enviroenment (based in the same kind of universe)
- bosses will talk, like recent megaman x games
Basically, while Megaman and Protoman protect the city (in the game they are cited as "heroes" because we won't use the names), a young scientist called Canotus, inspirated by the creations of the benevolent Dr. Light, creates two fighting robots, called Rockbot and Betabot, to help out in small missions while the big-ones are occupied. But a new raid of enemies happen and the heroes are now missing, so Rock and beta have to take the crown and fight the bad guys in their place.
sábado, 28 de novembro de 2009
Estamos abertos (o código)!
Acabei de enviar todo o código do motor do jogo para o projeto no sourceforge.
A partir de agora, código, listas de lançamentos, bugs, tarefas e novas features serão concentradas no sourceforge. As notícias continuarão a ser publicadas aqui.
A partir de agora, código, listas de lançamentos, bugs, tarefas e novas features serão concentradas no sourceforge. As notícias continuarão a ser publicadas aqui.
Nosso endereço no sf.net: https://sourceforge.net/projects/rockman-engine/
We are now open (source)!
Just dropped the whole game-engine source in sourceforge project.
From now on, source, releases, bug, TODO and features lists will be placed in sourceforge. news will still be placed here.
Our address in sf.net: https://sourceforge.net/projects/rockman-engine/
From now on, source, releases, bug, TODO and features lists will be placed in sourceforge. news will still be placed here.
Our address in sf.net: https://sourceforge.net/projects/rockman-engine/
sexta-feira, 27 de novembro de 2009
Creation process [Processo de Criação]
A quick note to show the boss creation chaotic process.
[Apenas uma pequena nota para mostrar o processo caótico de criação dos chefes de fase]
Lidando com bugs
[nota do editor: a partir de agora vou recriar os posts em inglês e depois português]
Eu estou atualmente no processo de resolver alguns problemas com o motor do jogo. O primeiro é scrolling [movimento da tela para acompanhar o jogador], enquanto ele foic orrigido e também ajudou a fechar alguns outros bugs [defeitos] feios no código encontrados durante a re-implementação do scroll, ele ainda carece de suporte a dois jogadores, sendo baseado ainda apenas em um. Agora devemos ter o cuidado de não mover a tela de forma que qualquer um dos jogadores ficar fora da tela. Ao passo que mover a tela horizontalmente não é um problema, Rockbot é um jogo de plataformas, então o movimento da tela é mais complexo.
Pense sobre o caso de entrar em uma sala de chefe: como pode um jogador entrar nela sem o outro junto?
Ou quando você sobe ou desce numa escada e a tela é movida completamente para mostrar outra área? Como fazer isto se um dos jogadores sequer está na escada?
A solução, é claro, é impedir um jogador sair da tela enquanto o outro ainda não estiver também na saída desta. Ou seja, para entrear em uma sala de chefe, ambos os jogadores deverão estar na frente da porta ao mesmo tempo. Ou em uma escada simultaneamente para poder entrar em outra área.
Outro problema é que jogando apenas uma pessoa, quando você morre, retorna a um "ponto seguro", normalmente no início ou meio da fase. Em modo dois jogadores o jogador deve retornar para a mesma parte, mas não no mesmo ponto, porque isto pode fazê-lo morrer novamente - imagine morrer por cair em espinhos e voltar exatamente sobre os espinhos de novo e de novo. Uma solução bastante boa para este problema é encontrada no jogo Chip & Dale de NES, onde o personagem que morreu volta flutuando pela tela em um balão, e quando o jogador achar que está em uma boa posição, aperta o botão e o personagem cai sobre a plataforma.
Apesar de adicionar muitos problemas, ter dois personagens simultâneos adiciona um monte de diversão ao jogo, e é uma característica usada tão poucas vezes em jogos que chega a ser vergonhoso. Bons tempos em que havia Battletoads, Chip & Dale e Contra :)
Eu estou atualmente no processo de resolver alguns problemas com o motor do jogo. O primeiro é scrolling [movimento da tela para acompanhar o jogador], enquanto ele foic orrigido e também ajudou a fechar alguns outros bugs [defeitos] feios no código encontrados durante a re-implementação do scroll, ele ainda carece de suporte a dois jogadores, sendo baseado ainda apenas em um. Agora devemos ter o cuidado de não mover a tela de forma que qualquer um dos jogadores ficar fora da tela. Ao passo que mover a tela horizontalmente não é um problema, Rockbot é um jogo de plataformas, então o movimento da tela é mais complexo.
Pense sobre o caso de entrar em uma sala de chefe: como pode um jogador entrar nela sem o outro junto?
Ou quando você sobe ou desce numa escada e a tela é movida completamente para mostrar outra área? Como fazer isto se um dos jogadores sequer está na escada?
A solução, é claro, é impedir um jogador sair da tela enquanto o outro ainda não estiver também na saída desta. Ou seja, para entrear em uma sala de chefe, ambos os jogadores deverão estar na frente da porta ao mesmo tempo. Ou em uma escada simultaneamente para poder entrar em outra área.
Outro problema é que jogando apenas uma pessoa, quando você morre, retorna a um "ponto seguro", normalmente no início ou meio da fase. Em modo dois jogadores o jogador deve retornar para a mesma parte, mas não no mesmo ponto, porque isto pode fazê-lo morrer novamente - imagine morrer por cair em espinhos e voltar exatamente sobre os espinhos de novo e de novo. Uma solução bastante boa para este problema é encontrada no jogo Chip & Dale de NES, onde o personagem que morreu volta flutuando pela tela em um balão, e quando o jogador achar que está em uma boa posição, aperta o botão e o personagem cai sobre a plataforma.
Apesar de adicionar muitos problemas, ter dois personagens simultâneos adiciona um monte de diversão ao jogo, e é uma característica usada tão poucas vezes em jogos que chega a ser vergonhoso. Bons tempos em que havia Battletoads, Chip & Dale e Contra :)
Dealing with bugs
I'm now in the process to solve some problems with the engine.
The first one is scrolling, while it has been fixed and also helped closing other nasty problems in the code found while re-implementing the scroll, it still lacks support for two players, the scroll is still based in just one. Now, we must take care to not scroll the screen in a way any of the two players disappear from the screen. While in regular horizontal scroll this is not a problem, Rockbot is meant to be a platform game, so scrolling of screen change is more complex.
Think about the case of entering a boss room: how one player can enter it and the second one not?
Or when you go up/down a ladder and the screen is scrolled to show a new part of the stage. What to do that if the other player is not even in the ladder?
The solution, of course, is to now allow the player out of the screen while the second one is not also on the exit. Meaning that, to enter on a boos room, both must be in the door area, or to change area when on a ladder, both must be.. in the ladder!
Another problem is that in one player mode, when you die, you just return to a "safe spot", in the start or middle of the stage. In 2 player mode, the player must return to the same part, but not in the same spot, because this can make him die again - imagine diying by falling in spikes, then returning above the same spikes again and again. A good solution to this problem is found in chip & dale for the NES, the player that died returns floating in a baloon, and press a button the the character is at a good position.
While adding so many problems, having two player simultaneous adds a lot of fun to the game, and is a feature used so few times in games that it is a shame. Godd times of Battletoads, Chip & Dale and Contra :)
The first one is scrolling, while it has been fixed and also helped closing other nasty problems in the code found while re-implementing the scroll, it still lacks support for two players, the scroll is still based in just one. Now, we must take care to not scroll the screen in a way any of the two players disappear from the screen. While in regular horizontal scroll this is not a problem, Rockbot is meant to be a platform game, so scrolling of screen change is more complex.
Think about the case of entering a boss room: how one player can enter it and the second one not?
Or when you go up/down a ladder and the screen is scrolled to show a new part of the stage. What to do that if the other player is not even in the ladder?
The solution, of course, is to now allow the player out of the screen while the second one is not also on the exit. Meaning that, to enter on a boos room, both must be in the door area, or to change area when on a ladder, both must be.. in the ladder!
Another problem is that in one player mode, when you die, you just return to a "safe spot", in the start or middle of the stage. In 2 player mode, the player must return to the same part, but not in the same spot, because this can make him die again - imagine diying by falling in spikes, then returning above the same spikes again and again. A good solution to this problem is found in chip & dale for the NES, the player that died returns floating in a baloon, and press a button the the character is at a good position.
While adding so many problems, having two player simultaneous adds a lot of fun to the game, and is a feature used so few times in games that it is a shame. Godd times of Battletoads, Chip & Dale and Contra :)
terça-feira, 24 de novembro de 2009
Game concepts
While development is a little slow (using my free time for other kind of fun things) I've started to think about the game design itself. While player characters are basically done (Rockbot and Betabot) we need to start to think about bosses, enemies, and the most difficult part in my opinion: the background.
[Rockbot first draft]
For bosses, I've started, in the best Megaman's and Capcom's tradition, a contest between my friends for ideas, concepts and design. While they have priority, anyone is welcome to participate, just post a comment in this topic.
Enemies and background need to have bosses decided first to get started, and I'm afraid drawing backgrounds will take a long time so for now, we'll use very simple backgrounds, and eliminate as soon as possible the ones I've got from RPG Maker.
So, while the idea for this game is to have and editor, I'm focusing in harcoding most things, exept for the graphics and stages; so do not expect to create a game using it for a while, first we need to create a game for developing the engine with it. First version will be just a megaman-like game, not an editor like RPG Maker.
Enemies and background need to have bosses decided first to get started, and I'm afraid drawing backgrounds will take a long time so for now, we'll use very simple backgrounds, and eliminate as soon as possible the ones I've got from RPG Maker.
So, while the idea for this game is to have and editor, I'm focusing in harcoding most things, exept for the graphics and stages; so do not expect to create a game using it for a while, first we need to create a game for developing the engine with it. First version will be just a megaman-like game, not an editor like RPG Maker.
domingo, 15 de novembro de 2009
Better quality code
Most work being done in Rockbot lately is just the rewrite of old code. This is happening for several reasons, such as the original code being based on a RPG and not an action game, new need when engine envolves to support multiple players and projectiles, and finnaly because Rockbot is meant to be a kind of "learning" project, not only for me, but for people who will read the code, so I'm trying to make it more legible.
As news, we have working support for SDL_ttf and using some old-school fonts, some fixes in sprites, an shooting. For now, the shooting does nothing more than draw the projectiles on the screen, but it already led to a lot of bug fixes because it showed some fails, and some optimization. Now I need to fix the scroolling, that is based on a really old code and concept, that I need to re-work from scratch.
All in all, it is a boring phase for the project now, but things are looking really bright for the future.
[TTF fonts in action]
As news, we have working support for SDL_ttf and using some old-school fonts, some fixes in sprites, an shooting. For now, the shooting does nothing more than draw the projectiles on the screen, but it already led to a lot of bug fixes because it showed some fails, and some optimization. Now I need to fix the scroolling, that is based on a really old code and concept, that I need to re-work from scratch.
[shooting]
All in all, it is a boring phase for the project now, but things are looking really bright for the future.
domingo, 8 de novembro de 2009
Player 2 - READY
[English]
Just commited to our internal subversion repository a big update including a new, improved and easier animation system and support for simultaneous two player game. Also, a first version of our custom made graphics, that still need some work, but already gives and idea of things to come. We still need to work on self-made background graphis to move the project to sourceforge.
Just commited to our internal subversion repository a big update including a new, improved and easier animation system and support for simultaneous two player game. Also, a first version of our custom made graphics, that still need some work, but already gives and idea of things to come. We still need to work on self-made background graphis to move the project to sourceforge.
[Rockbot on left, and Betabot on right]
There are some bugs that need to be worked right now, such as redrawning all sprites after a screen scrolling (not only the sprite that caused the scroll), better handling os sprite erasing to avoid copying parts of other sprites and leaving those on the underscreen, animation duration, lock screen scroll if one player os on the extreme left/right and much more.
[Português]
Acabei de enviar para nosso repositório interno uma grande atualização, incluindo um novo, melhorado e simplificado sistema de animação e suporte a dois jogadores simultâneos. Também uma versão inicial de nossos gráficos próprios, que ainda precisam de trabalho, mas já dão uma idéia do que está por vir. Ainda temos que fazer os gráficos de fundo para podermos migrar para o sourceforge.
Existem alguns bugs que precisam ser trabalhados a partir de agora, tais como redesenhar todos os sprites quando mover a tela (não apenas o sprite que causou o movimento), melhorar o ocultamento na tela para evitar copiar partes de outros sprites e deixar estas na tela de fundo,
duração de animação, trancar o movimento da tela quando um dos jogadores está na extrema esquerda/direita.
sábado, 7 de novembro de 2009
Progresso
Ontem fiz diversas correções que fizeram o jogo funcionar novamente em Playstation 2 - o PS2 tem diversas limitações que precisam ser respeitadas, então eu faço o desenvolvimento no Linux e depois testo e arrumo no console, além de ter acelerado bastante a velocidade depois que achei a resolução certa para a tela da TV (640x448).
Hoje comecei programando umas telas de introdução, e como o tempo está feio demais para sair de casa, planejo ainda adicionar suporte a dois jogadores simultâneos na tela, o que já terminaria a base mais básica do jogo. Os próximos passos seriam adicionar suporte a tiros e NPCs, o que certamente vai exigir a reescrita de uma boa parte de código.
[tela de título]
[introdução e história]
[jogo em ação]
sexta-feira, 6 de novembro de 2009
Open Rockbot - página no ar
Já está no ar a página do projeto Open Rockbot: http://www.upperland.net/rockbot/index.php
A página ainda não possui muito material, mas colocamos um leitor de RSS para exibir as novidades publicadas aqui e em breve vamos colocar algumas informações sobre o desenvolvimento e telas.
A página ainda não possui muito material, mas colocamos um leitor de RSS para exibir as novidades publicadas aqui e em breve vamos colocar algumas informações sobre o desenvolvimento e telas.
quinta-feira, 5 de novembro de 2009
Apresentando o projeto Open Rockbot
Eis o nome do projeto para criar uma engine open-source similar aos jogos clássicos Rockman (Megaman nos EUA). O nome surgiu fácil, trocando man (homem) por bot (robô) e mantendo o Rock ao invés de Mega, pois a versão japonesa é mais legal.
Mais complexos são os objetivos: criar uma engine que seja flexível o suficiente para se criar um jogo praticamente igual a um Rockman clássico; para tanto o programa se dividirá em duas partes.
Primeiramente teremos um editor, programado em C++ e usando a biblioteca Qt para a criação de janelas e widgets, este editor deverá permitir ao usuário criar mapas, definindo pontos em que o personagem toma dano, morre, portas e outros, ponto inicial de saída do personagem, e vários aspectos dos npcs, tais como se eles disparam, se atacam ao se aproximarem, etc. Agora pense por exemplo na lógica de Toadman de Rockman 4: se atingido por um tiro, ele pula sobre o personagem. Isto é difícil de ser informado pelo usuário, de forma que alguns tipos pré-existentes de habilidades e NPCs terão de ser programados diretamente na engine e disponibilizadas como opções de escolha. A complexidade do editor portanto está em dar ao usuário, opções o suficiente para ele poder criar um jogo que não fique repetitivo.
O game-core, programado em C e utilizando a biblioteca SDL, e portado para Windows, Linux e Playstation 2, é o jogo em sí. Ele deverá abrir um arquivo de jogo, criado no editor, ler as fases e npcs e permitir ao usuário jogá-las. A engine em sí é basicamente simples, e como a idéia é reproduzir a série clássica de Rockman (1-6 e 9), um mínimo de diferenças em relação ao original deve ser feito, mas iremos adicionar alguns elementos inéditos à série, como a possibilidade de duas pessoas jogarem com dois personagens simultaneamente, ao melhor estilo Contra ou Chip & Dale.
Por enquanto é isso, acompanhem as novidades aqui na upperland.net que logo teremos mais informações sobre este projeto.
Mais complexos são os objetivos: criar uma engine que seja flexível o suficiente para se criar um jogo praticamente igual a um Rockman clássico; para tanto o programa se dividirá em duas partes.
Primeiramente teremos um editor, programado em C++ e usando a biblioteca Qt para a criação de janelas e widgets, este editor deverá permitir ao usuário criar mapas, definindo pontos em que o personagem toma dano, morre, portas e outros, ponto inicial de saída do personagem, e vários aspectos dos npcs, tais como se eles disparam, se atacam ao se aproximarem, etc. Agora pense por exemplo na lógica de Toadman de Rockman 4: se atingido por um tiro, ele pula sobre o personagem. Isto é difícil de ser informado pelo usuário, de forma que alguns tipos pré-existentes de habilidades e NPCs terão de ser programados diretamente na engine e disponibilizadas como opções de escolha. A complexidade do editor portanto está em dar ao usuário, opções o suficiente para ele poder criar um jogo que não fique repetitivo.
O game-core, programado em C e utilizando a biblioteca SDL, e portado para Windows, Linux e Playstation 2, é o jogo em sí. Ele deverá abrir um arquivo de jogo, criado no editor, ler as fases e npcs e permitir ao usuário jogá-las. A engine em sí é basicamente simples, e como a idéia é reproduzir a série clássica de Rockman (1-6 e 9), um mínimo de diferenças em relação ao original deve ser feito, mas iremos adicionar alguns elementos inéditos à série, como a possibilidade de duas pessoas jogarem com dois personagens simultaneamente, ao melhor estilo Contra ou Chip & Dale.
Por enquanto é isso, acompanhem as novidades aqui na upperland.net que logo teremos mais informações sobre este projeto.
sexta-feira, 30 de outubro de 2009
Desenvolvendo para Playstation 2 - ROUND 2, FIGHT!
Cerca de um ano e meio atrás eu brinquei um pouco de converter um pequeno game que estou desenvolvendo, parecido com Rockman (Megaman) para o Playstation 2 usando o SDK PS2DEV disponível em http://www.ps2dev.org. Este SDK, além de um toolkit próprio, chamado gsKit, tem suporta a uma biblioteca gráfica, muito utilizada para jogos em Linux mas também utilizada em Windows e Mac, chamada SDL, e para o qual eu já havia desenvolvido pequenos games. Após ligar com diversos problemas de compilação, consegui instalar todo o ambiente em meu Duron 1.6/512MB RAM rodando Ubuntu Linux e comecei a desenvolver.
O problema é que, do modo como eu estava desenvolvendo, eu tinha que copiar o executável (.elf) para um memory card ou pendrive USB, e toda vez ir5 do computador em um quarto, até o PS2 na sala. Isso até não era o maior problema, o problema é que desta forma, você não tem a mínima idéia se o seu programa deu um erro, você simplesmente fica olhando para uma tela escura, ou a tela do seu jogo travado. Utilizando códigos de cores para debugar (desenhando retângulos coloridos como forma de indicar por onde o programa passou), consegui algum sucesso, mas a dificuldade acabou me fazendo desistir.
Chegamos ao presente. Agora com um computador bem mais rápido (Core 2 Duo 2.2/2GB RAM), lá fui eu tentar um segundo método: rodar o programa via emulador de Playstation 2, chamado PCSX2. No linux este emulador mostra as mensagens de output (printf para quem sabe C) do processador IOP (entrada e saída do PS2), e então eu poderia finalmente debugar e corrigir os problemas do jogo, certo? Errado! O emulador simplesmente quebra com o OpenGL da minha máquina...
Bom, nesse ano e meio que se passou, eu adquiri um eeePC 701 e um roteador wifi. Com isso, um segundo método se abriu para mim: programar para o PS2 via rede. Na verdade sem o roteador eu poderia ter feito o trabalho usando um cabo USB ou um cabo cross ethernet, mas nunca me dispus, já com o cabo de rede e o roteador, eu posso também colocar o PS2 em rede, o que é um grande incentivo.
O sistema funciona basicamente assim, você grava um CD com um programa chamado ps2link e um arquivo de configuração que determina o endereço IP quie o PS2 irá requisitar ao seu roteador, e depois um cliente no Windows ou Linux, para acessar o PS2 e enviar para ele o seu programa via rede, ou seja, nada mais de atravessar a sala com o pendrive. Também permite dar um soft-reset - que já descobri não funciona direito com a SDL por alguma razão que ainda não tive tempo de achar.
Mas enfim, comprei um CD para gravar o programa e um cabo de rede de 6 metros, que se mostrou um metro mais curto do que seria recomendável... ninguém manda eu não usar o metro apra medir a distância antes. Gravei o programa, liguei o PS2 com ele e foi pura emoção no momento que consegui dar um ping ao endereço 192.168.1.10 e obeter respota! :D
A seguir comecei a fuçar no código, recolocando todos os printfs que eu havia retirado já que não apareciam mesmo, e rodar. Em uma hora eu consegui consertar o meu embrião de jogo, adicionei suporte ao joystick direito (esse era um dos bugs, o outro era ter muitos acessos aos arquivos, no PS2 ele tem poucos file pointers simultâneos) e unifiquei o sistema de sprites em uma variável única, otimizando a execução um bocado.
O resultado está nesta screenshot abaixo:
Os gráficos estão com alguns bugs porque eu não tive tempo de arrumar o mapa após criar o novo sistema de tiles/sprites, mas dá para ter uma idéia vendo o protoman lá na parte superior esquerda da tela.
Resumindo, se você tem paciência para fazer as configurações iniciais do SDK, programar para o Playstation 2 usando a SDL é uma grande barbada, e altamente recomendável pela diversão Nerd que irá gerar ;)
O problema é que, do modo como eu estava desenvolvendo, eu tinha que copiar o executável (.elf) para um memory card ou pendrive USB, e toda vez ir5 do computador em um quarto, até o PS2 na sala. Isso até não era o maior problema, o problema é que desta forma, você não tem a mínima idéia se o seu programa deu um erro, você simplesmente fica olhando para uma tela escura, ou a tela do seu jogo travado. Utilizando códigos de cores para debugar (desenhando retângulos coloridos como forma de indicar por onde o programa passou), consegui algum sucesso, mas a dificuldade acabou me fazendo desistir.
Chegamos ao presente. Agora com um computador bem mais rápido (Core 2 Duo 2.2/2GB RAM), lá fui eu tentar um segundo método: rodar o programa via emulador de Playstation 2, chamado PCSX2. No linux este emulador mostra as mensagens de output (printf para quem sabe C) do processador IOP (entrada e saída do PS2), e então eu poderia finalmente debugar e corrigir os problemas do jogo, certo? Errado! O emulador simplesmente quebra com o OpenGL da minha máquina...
Bom, nesse ano e meio que se passou, eu adquiri um eeePC 701 e um roteador wifi. Com isso, um segundo método se abriu para mim: programar para o PS2 via rede. Na verdade sem o roteador eu poderia ter feito o trabalho usando um cabo USB ou um cabo cross ethernet, mas nunca me dispus, já com o cabo de rede e o roteador, eu posso também colocar o PS2 em rede, o que é um grande incentivo.
O sistema funciona basicamente assim, você grava um CD com um programa chamado ps2link e um arquivo de configuração que determina o endereço IP quie o PS2 irá requisitar ao seu roteador, e depois um cliente no Windows ou Linux, para acessar o PS2 e enviar para ele o seu programa via rede, ou seja, nada mais de atravessar a sala com o pendrive. Também permite dar um soft-reset - que já descobri não funciona direito com a SDL por alguma razão que ainda não tive tempo de achar.
Mas enfim, comprei um CD para gravar o programa e um cabo de rede de 6 metros, que se mostrou um metro mais curto do que seria recomendável... ninguém manda eu não usar o metro apra medir a distância antes. Gravei o programa, liguei o PS2 com ele e foi pura emoção no momento que consegui dar um ping ao endereço 192.168.1.10 e obeter respota! :D
A seguir comecei a fuçar no código, recolocando todos os printfs que eu havia retirado já que não apareciam mesmo, e rodar. Em uma hora eu consegui consertar o meu embrião de jogo, adicionei suporte ao joystick direito (esse era um dos bugs, o outro era ter muitos acessos aos arquivos, no PS2 ele tem poucos file pointers simultâneos) e unifiquei o sistema de sprites em uma variável única, otimizando a execução um bocado.
O resultado está nesta screenshot abaixo:
Os gráficos estão com alguns bugs porque eu não tive tempo de arrumar o mapa após criar o novo sistema de tiles/sprites, mas dá para ter uma idéia vendo o protoman lá na parte superior esquerda da tela.
Resumindo, se você tem paciência para fazer as configurações iniciais do SDK, programar para o Playstation 2 usando a SDL é uma grande barbada, e altamente recomendável pela diversão Nerd que irá gerar ;)
terça-feira, 13 de outubro de 2009
[GBA] Megaman & Bass
Na época do declínio do Super Nintendo [SNES], uma das produtoras de jgoos que mais resistiu a abandoná-lo foi a Capcom, que fez vários jogos inclusive após lançar similares para Playstation [PSX]. Megaman & Bass (Rockman & Forte no Japão) é um destes jogos, lançado nos EUA somente em sua versão para Gameboy Advance, uma pérola produzida após o Megaman 8 de PSX.
O jogo é muito parecido com o 8, inclusive usando vários gráficos iguais, mas conseguiu melhorar algumas falhas do primeiro, como jogabilidade e dificuldade de algumas fases - quem é que já não amaldiçoou a fase do skate? Uma das principais mudanças é a inclusão de um segundo personagem, Bass com habilidades diferentes de Megaman, e que seria o equivalente a dificuldade easy, já que possui duplo pulo, apesar de seu tiro ser bem mais fraco.
De diferente também, o jogo vai abrindo caminhos após derrotar um chefe, ou seja,após derrotar um chefe, um caminho se abre atrás para que você possa acessar outras fases. O que ajuda bastante a descobrir a ordem de uso das armas. De igual, o velho esquema de loja de upgrade, iniciado em Megaman 7, Rush e o cão Forte basicamente ausentes, sem toda a importância que já tiveram como em Megaman 3 e 4 e a boa resposta dos controles, que alavancou a Capcom ao sucesso na época do NES e Super NES.
Este sem dúvida é um jogo que vale a pena ser terminado, mesmo que em um emulador no PC, pois é superior a Megaman 8 apesar de ter gráficos ligeiramente inferiores, ausência de vozes, é bem mais divertido e menos burocrático que o 8. Além disso tem uma database de personagens de TODOS os jogos, mostrando que este é o derradeiro encerramento da série clássica, e o fato de poder jogar com dois personagens, faz com que você queira revisitar as fases diversas vezes. Bem que a Capcom poderia ter colocado o Protoman como personagem secreto também...
Gráficos: 8 [conseguir gráficos de PSX no SNES foi uma proeza]
Som: 6 [na média, não ajuda nem atrapalha]
Diversão: 8 [jogar com o Bass e depois com o Megaman vale a pena]
Dificuldade: 5/7 [com o Bass é mais fácil]
O jogo é muito parecido com o 8, inclusive usando vários gráficos iguais, mas conseguiu melhorar algumas falhas do primeiro, como jogabilidade e dificuldade de algumas fases - quem é que já não amaldiçoou a fase do skate? Uma das principais mudanças é a inclusão de um segundo personagem, Bass com habilidades diferentes de Megaman, e que seria o equivalente a dificuldade easy, já que possui duplo pulo, apesar de seu tiro ser bem mais fraco.
[ reutilizaram até os chefes de Megaman 8]
[ quase igual ao 8, mas com o Forte jogável]
De diferente também, o jogo vai abrindo caminhos após derrotar um chefe, ou seja,após derrotar um chefe, um caminho se abre atrás para que você possa acessar outras fases. O que ajuda bastante a descobrir a ordem de uso das armas. De igual, o velho esquema de loja de upgrade, iniciado em Megaman 7, Rush e o cão Forte basicamente ausentes, sem toda a importância que já tiveram como em Megaman 3 e 4 e a boa resposta dos controles, que alavancou a Capcom ao sucesso na época do NES e Super NES.
[ caminhos vão se abrindo]
Este sem dúvida é um jogo que vale a pena ser terminado, mesmo que em um emulador no PC, pois é superior a Megaman 8 apesar de ter gráficos ligeiramente inferiores, ausência de vozes, é bem mais divertido e menos burocrático que o 8. Além disso tem uma database de personagens de TODOS os jogos, mostrando que este é o derradeiro encerramento da série clássica, e o fato de poder jogar com dois personagens, faz com que você queira revisitar as fases diversas vezes. Bem que a Capcom poderia ter colocado o Protoman como personagem secreto também...
[ jogar com protoman é o sonho de muitos]
Gráficos: 8 [conseguir gráficos de PSX no SNES foi uma proeza]
Som: 6 [na média, não ajuda nem atrapalha]
Diversão: 8 [jogar com o Bass e depois com o Megaman vale a pena]
Dificuldade: 5/7 [com o Bass é mais fácil]
sábado, 3 de outubro de 2009
Reboot!
Estou integrando o blog com meu site principal (http://www.upperland.net), e por isso vou voltar a utilizar ele para postar informações, novidades e reviews de jogos. Aguarde muitas coisas sobre Playstation 2 e Nintendo DS!
Assinar:
Postagens (Atom)