Game review – Mr.Bree+

No final de 2012, participei de uma pequena palestra do pessoal da Taw Studio, um pequeno estúdio localizado na cidade de Pindamonhangaba no interior de São Paulo, promovida nas instalações do Acrópolis estudio de Arte e escola de mangá, a respeito de seu principal game na época, o Mr. Bree+.

Mr.Bree+ Wallpaper

Mr.Bree+ Wallpaper

Desde então, fiquei bastante interessado em adquirir o game, uma vez que os autores disseram que em breve o mesmo estaria disponível em algumas game stores nacionais. Pouco tempo depois me tornei parceiro para reviews de jogos da SplitPlay desde o inicio de suas operações, mas naquela época a SplitPlay ainda estava se organizando e fechando parcerias com diversos estúdios indies nacionais e o Mr. Bree+ ainda não estava em sua loja, entretanto em menos de 2 meses, felizmente o mesmo foi adicionado à sua lista de jogos. Lembrando que hoje a SplitPlay lança jogos indies nacionais instantaneamente a seu lançamento no mercado, tendo alguns lançados primeiramente lá.

O Jogo

O jogo começa com uma excelente apresentação do porquinho (Mr.Bree) caindo ferido na floresta, visivelmente perdido e sem memória. Após a apresentação o jogo inicia em um pequeno labirinto, onde Mr. Bree deve avançar, passando por obstáculos que vão dificultando a cada novo estágio. Além de passar pelos obstáculos, Mr.Bree deve coletar umas peças vermelhas no formato de um quebra-cabeças, que de fato são as “suas memórias”.

Ao coletar uma “memória”, Mr. Bree vai relembrando as suas habilidades, que lhe serão essenciais para a finalização do jogo.

Mr.Bree+ Promo

Mr.Bree+ Promo

Foi impossível não comparar o Mr.Bree+ com alguns jogos de MSX, como o The Goonies e principalmente o jogo onde Popolon (e Aphrodite) são protagonistas da saga Knightmare, The Maze Of Galious, pois em minha opinião esses jogos estão na mesma categoria (platform puzzle games).

The Goonies.

The Goonies (MSX)

Kinghtmare - The Maze of Galious

Kinghtmare – The Maze of Galious (MSX)

O porquinho Mr.Bree, de fato é um porquinho fazendeiro que repentinamente é aprisionado e separado de sua família. A partir daí a sua saga se inicia em busca de suas lembranças e de seus familiares.

Análise técnica

A arte do jogo é excepcional, sendo cada detalhe gráfico muito bem desenhado e cuidadosamente detalhado. As animações que ocorrem no decorrer do jogo também são muito bem feitas, seguindo o mesmo padrão gráfico do jogo.

A partir da segunda fase é possível perceber que os desenvolvedores utilizaram pelo menos 3 layers de fundo, o que proporcionou um ótimo efeito no scroll parallax a medida que o Mr.Bree se movimenta.

Apesar de todas as 45 fases e das 15 secretas que o jogo possui, o diferencial do Mr.Bree+, em minha opinião, ficou por conta da excelente música e como todo bom jogo, Mr.Bree+ tem em suas músicas o  essencial para manter o interesse dos fans no jogo durante todas as fases.

Infelizmente o jogo não está disponível para todos os principais sistemas operacionais e só é compatível com Windows e MacOSX.

Notas finais

  1. Gráficos  10
  2. Efeitos sonoros 10
  3. Trilha sonora 10
  4. Jogabilidade 10
  5. Portabilidade 6.5
  6. Nota final 9.3

Um ótimo jogo nacional, e ainda por um ótimo preço na SplitPlay.

[]’s
PopolonY2k

Referência na internet

Taw Studio
http://tawstudio.com/

SplitPlay (PopolonY2k rulezz)
http://www.popolony2k.com.br/?p=2331

The Goonies (Wikipedia – MSX)
http://en.wikipedia.org/wiki/The_Goonies_%28MSX%29

Maze of Galious (Wikipedia)
http://en.wikipedia.org/wiki/The_Maze_of_Galious

Platform games (Wikipedia)
http://en.wikipedia.org/wiki/Platform_game

Parallax Scrolling (Wikipedia)
http://en.wikipedia.org/wiki/Parallax_scrolling

10 regras da NASA para desenvolver código seguro.

Recentemente postei nas comunidades GDMSX do FaceBook e do G+ um texto bem interessantante sobre algumas dicas da NASA de como desenvolver código seguro.

Isso é muito interessante principalmente para aqueles que desenvolvem código para sistemas/dispositivos que nunca pode se dar ao luxo de uma exceção não tratada ou um core dump, comuns no mundo UNIX ou os famosos GPF’s bem conhecidos para programadores do mundo Windows.

Alguns membros da comunidade GDMSX me pediram para traduzir, então eu decidi fazer uma tradução livre, com algumas considerações pessoais que estão marcadas no texto como “(*) Notas do tradutor” 🙂 .

Vamos ao texto.

10 regras da NASA para desenvolver código seguro.

NASA Computers

NASA Computers

A NASA tem escrito software de missão crítica para a exploração espacial por décadas e agora a organização está transformando esses guias de programação em um padrão de desenvolvimento de software da indústria.

O laboratório de propulsão a jato da NASA para softwares confiáveis (JPL), recentemente publicou um conjunto de guias de programação (code guidelines), “Potência de 10 – Regras para o desenvolvimento seguro de código crítico“. O autor do texto, o cientista chefe Gerard J. Holzmann, explicou que a quantidade de codificação existente é inconsistente e cheia de regras arbitrarias, raramente permitindo tarefas essenciais como verificação de conformidade de código baseado em ferramentas de checagem de código. Os guias existentes, ele disse, inundam os programadores com regras vagas, diminuindo a qualidade do código da maioria das aplicações críticas.

“Projetos mais sérios de desenvolvimento de software usam guias de codificação,” escreveu Holzmann. “Esses guias destinam-se a firmar as regras básicas para o qual o software está sendo escrito: como ele deveria ser estruturado e quais características da linguagem deveriam e não deveriam ser usadas. Curiosamente, existe um pouco de consenso sobre o que é um bom padrão de codificação.”

 Holzmann definiu 10 regras rígidas para o desenvolvimento de software, tendo em mente a segurança do código. As regras foram especificamente escritas levando em consideração a linguagem C (uma linguagem recomendada pela NASA devido a sua longa história no desenvolvimento de software crítico e seguro e também pelo extensivo suporte de ferramentas a essa linguagem como por exemplo analisadores de código, depuradores, ferramentas de testes, dentre outras), embora essas regras possam ser facilmente generalizadas para codificação em qualquer outra linguagem, principalmente as que tem forte similaridade com C no nível de estruturação, como é o caso de Pascal e suas variantes.

  1.  Restrinja toda a construção de seu código a um fluxo de controle muito simples. Não use declarações GOTO, construções com setjmp ou longjmp, ou recursividade direta ou indireta;

    (*) Nota do tradutor:
    Quanto ao GOTO não é preciso nem escrever muito a seu respeito pois um de seus “males”, que é o de deixar o código confuso através de saltos incondicionais, já são amplamente conhecidos ao longo dos anos. O mesmo acontece com a dupla setjmp/longjmp que causam o mesmo efeito do GOTO, mas infelizmente esse recurso ainda é muito defendido por programadores experientes de C que muitas vezes se recusam a abandoná-los.
    Quanto à recursividade direta ou indireta, realmente essas tornam o código mais complexo entretanto por diversas vezes o seu código pode se tornar mais eficaz do que utilizando métodos tradicionais para resolução de um problema. Um exemplo é o algoritmo de multiplicação reconhecidamente veloz conhecido como algoritmo de Karatsuba e que é recursivo.
    Eu particularmente sugiro que se utilize métodos recursivos pequenos e de baixa complexidade, pois dessa forma pode-se evitar possíveis pontos de falhas que são invisíveis na maioria das vezes em tempo de desenvolvimento, mas que são comuns em uma situação de missão crítica.
    Quando se optar por implementar métodos recursivos, tenha em mente que a cobertura de seus testes unitários deverá ser extremamente abrangente a ponto de se testar as mínimas situações de falha.

  2. Todos os loops devem ter um limite superior fixo. Isso deve ser trivial para uma ferramenta de checagem que prove, estaticamente, que um dado limite no número de iterações não pode ser excedido. Se o limite do loop não puder ser comprovado estaticamente, a regra é considerada violada. Caso os limites sejam violados, o método deverá disparar um assert a ser verificado pelo chamador.

    (*) Nota do tradutor:
    Essa regra pode ser checada através da implementação de testes unitários com os devidos cenários mapeados.

  3. Não use alocação dinâmica de memória após a inicialização.

    (*) Nota do tradutor
    Realmente alocação dinâmica em linguagens que não são gerenciadas por um Garbage Collector é algo crítico e que deve ser utilizado de maneira cuidadosa, principalmente para principiantes no desenvolvimento de software. No artigo original, o autor cita diversos dos problemas conhecidos em se utilizar alocação dinâmica como a não liberação de recursos corretamente, o que causam os famosos vazamentos de memória ou memory leaks, e também cita sobre o cuidado de não ultrapassar os limites da memória alocada, esse último sendo também um problema quando se está usando memória alocada estaticamente em C.
    Entretanto existem casos que a alocação dinâmica é necessária e não há como escapar, nesses casos o mais comum a se fazer é alocar o buffer desejado em um ponto único, fazer toda e qualquer referência a esse buffer através de ponteiros passados para as funções que irão manipulá-lo e por fim liberá-lo nesse mesmo ponto único em que foi alocado, de preferência. Dessa forma você restringe toda a construção de seu código a um fluxo de controle muito simples, que é exatamente o primeiro item sugerido por esse guideline.
    Muitos dos desenvolvedores de softwares novatos sequer tem conhecimento de problemas de fragmentação de memória, decorrentes do abuso excessivo de alocação e liberação dinâmica de memória, principalmente em dispositivos de missão crítica que geralmente são hardwares embarcados dedicados e com recursos limitadíssimos de memória e armazenamento.

  4. Nenhuma função deve ser tão extensa que não possa ser impressa em uma única folha de papel (em uma referência ao formato padrão com uma linha por instrução e uma linha por declaração). Tipicamente isso significa não mais do que 60 linhas de código por função.

    (*) Nota do tradutor
    Manter o código com poucas linhas por função é sempre uma excelente prática pois facilita na manutenção do mesmo, entretanto algumas vezes principalmente em se tratando de código que gerencia máquinas de estado complexas, é melhor que a função fique um pouco maior do que as 60 linhas sugeridas ao invés de quebrá-las em mais funções para que comporte as 60 linhas, pois se ganha em performance, uma vez que se reduz o custo das passagens de parâmetros entre funções, ainda mais em se tratando de passagem de parâmetros de grandes estruturas por valor, que nesse caso é também uma péssima prática e que deveria ser substituída por passagem por referência ou ponteiro. Em linguagens orientadas a objeto, a regra de 60 linhas por método (função) é mais plausível e fácil de se atingir por conta da capacidade de encapsulamento dessas linguagens.

  5. A quantidade de asserts por função deve ser de no mínimo duas por função. Asserts não devem causar nenhum efeito colateral no código e deveriam ser definidos como testes booleanos.

    (*) Nota do tradutor
    Linguagens com um rico pré-processador como são C e C++ são propensas a inserção de asserts que estarão ativos dependendo do modelo de compilação em que o  binário/executável foi gerado, com isso pode-se gerar compilações de software específicas para testes.

  6. Dados devem ser declarados no menor nível de escopo possível.

    (*) Nota do tradutor
    O uso de variáveis globais é algo que vem sendo desestimulado no decorrer dos anos, pois é reconhecido que manter os dados encapsulados em escopos cada vez menores é um grande facilitador na hora de se descobrir bugs ou realizar qualquer tipo de manutenção ou melhorias no código, então declarar variáveis específicas de cada escopo é uma boa prática de programação.

  7. Cada função chamadora deve checar o retorno de funções não void (que retornam valores) e a validade dos parâmetros devem ser checadas dentro de cada função.

    (*) Nota do tradutor
    Isso é algo óbvio……bom, pelo menos deveria ser 🙂 .

  8. Uso de pré-processador deve ser limitado a inclusão de arquivos header e definição simples de macros. Macros complexas como as recursivas e com listas de argumentos variáveis, devem ser evitadas.

    (*) Nota do tradutor No texto original o autor descreve que o uso de macros de compilação condicional é algo dúbio entretanto não pode ser sempre ignorado. Eu concordo plenamente com a ideia de que não pode ser ignorado, uma vez que sempre tivemos diversas plataformas diferentes e dominantes na história da computação moderna, e o uso do pré-processador para se ter suporte a compilação condicional é uma excelente técnica que tem possibilitado manter um código portátil entre as diversas plataformas que vão desde os diversos sistemas operacionais disponíveis em PC’s até aos diversos dispositivos mobile existentes hoje.

  9. O uso de ponteiros deve ser restrito. Especificamente, não mais do que um nível de deferenciação é permitido. Operações de deferenciação de ponteiro não podem estar escondidas em macros ou dentro de declarações typedef. Ponteiros de função não são permitidos.

    (*) Nota do tradutor.
    Talvez esse seja o mais polêmico item do guia. Operações com ponteiros são algumas vezes complexas dependendo do nível de deferenciação. São raros os casos em que é necessário o uso de ponteiros duplos ou triplos, entretanto pode ser evitado e sugiro que seja evitado.
    Quanto ao uso de macros para deixar a deferenciação mais “limpa e clara”, para mim isso tem um nome e se chama “armadilha”. Fuja de quaisquer construções que “escondam” a complexidade de alguma operação, e essa regra não deve ser considerada apenas nas operações de ponteiros.
    Entretanto há ressalvas quanto ao uso de typedefs na declaração de um tipo ponteiro,  como por exemplo as definições de ponteiros para funções amplamente utilizadas nas API’s do Windows e UNIXes em geral, nesse caso não há como escapar uma vez que esses sistemas operacionais fazem uso extensivo de callbacks para proporcionar respostas a eventos requeridos e necessários para a aplicação do usuário.
    Quanto a proibição de ponteiros para função, talvez para a maioria das aplicações comuns de desktop seu uso realmente não seja necessário, entretanto para aplicações de missão crítica embarcadas como as que utilizam algum kernel real-time, como por exemplo o uC de Jean Labrosse e que fazem extenso uso de ponteiros para função para implementar as diversas tasks da aplicação do usuário, o uso de ponteiro de função é algo bem comum.
    A construção de softwares kernel real-time é repleta de ponteiros de função, até mesmo para proporcionar uma abstração de tasks, timers dentre outras estruturas típicas desse tipo de software.

  10. Todo código deve ser compilável desde o primeiro dia de desenvolvimento, com todos warnings do compilador ativados. Todo código deve compilar com essa configuração, sem gerar nenhum warning ou erro. Todo código deve ser checado diariamente com pelo menos um – de preferência mais do que um – excelente analisador de código estático (o que ele cita como analisador estado-da-arte), e a análise deve passar sem warning algum.

    (*) Nota do tradutor
    Quanto ao detalhe dos warnings de compilação, acredito que já seja bem comum em grandes projetos, entretanto a parte do analisador “estado-da-arte”, não creio que sequer mercados corporativos em países avançados a utilizem, exceto empresas de altíssima tecnologia que dependam de que seus softwares funcionem 24×7 ou de forma embarcada em algum dispositivo.

 Holzmann incluiu diversos comentários no documento original para cada uma das regras descritas acima, mas a essência do documento é que quando as regras forem utilizadas em conjunto, garantam um fluxo claro e transparente que tornem fácil a construção, testes e análise de código amplamente aceitos como livres de falhas. A JPL tem desenvolvido softwares automatizados para missões espaciais como a Mars Curiosity and a Voyager, e o laboratório já está usando essas regras em uma base experimental para escrever software de missão crítica.

Holzmann acredita que seguir as regras da NASA minuciosamente, pode diminuir a carga sobre os desenvolvedores e levar a uma melhor segurança e clareza do código.

“Se as regras parecerem draconianas no inicio, tenha em mente que elas foram criadas para que se possa checar códigos onde a sua vida pode depender muito de que haja precisão: código utilizado para controlar o avião em que você voa, a usina nuclear a poucas milhas de onde você vive, as aeronaves que carregam os astronautas em órbita”, escreve ele.

“As regras agem como o cinto de segurança em seu carro: Inicialmente eles parecem ser um pouco desconfortáveis, mas depois de um tempo seu uso se torna natural e não usá-los se torna inimaginável.”

O texto acima foi traduzido do original que pode encontrado no link do site SDTimes abaixo:

http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/

[]’s
PopolonY2k

R.I.P MSN !!!

Finalmente a rede MSN está fora do ar. No ultimo dia 31 de outubro a Microsoft iniciou o desligamento dos servidores que ainda mantinham a rede MSN ativa.

Apesar do anúncio feito há quase 2 anos de que o MSN seria desativado em favor do Skype, a Microsoft manteve os servidores MSN ativos graças ao mercado Chinês que obrigava a empresa a manter o serviço, principalmente por conta de contratos com empresas locais de telefonia que contavam com o MSN como parte do pacote de serviços mobile disponíveis em seus planos aos usuários chineses.

Por conta disso, desde o anúncio da “morte” da rede MSN em 2012, ainda era possível acessar essa rede utilizando clientes não oficiais como o PlanetaMessenger.org, Adium, PidginIM e MirandaIM. Um pouco mais de 1 mês após o último anúncio da desativação dos servidores MSN, finalmente chegou o momento em que podemos dizer que a rede está fora do ar e dessa vez foi para talvez nunca mais voltar.

Damned skype

Damned Skype

Digo isso pois essa semana o plugin MSN do projeto Open Source que mantenho há mais de 13 anos, o PlanetaMessenger.org, não consegue mais estabelecer conexão com o Dispatcher Server (*) do serviço MSN, bem como outros clientes mobile para Android, como o IM+.

(*) Dispatch Server é um dos servidores da rede MSN que informam qual o Notification Server (*) está disponível para o cliente se conectar.

(*) Notification Server é um dos servidores da rede MSN que providenciam alguns serviços como login, notificação de presença, lista de contatos, etc…

Isso já havia acontecido no passado, exatamente em outubro de 2003, entretanto naquele mesmo ano, alguns meses antes já era conhecido que a Microsoft bloquearia os clientes não oficiais que usavam a rede MSN com protocolos anteriores ao MSNP8. Por esse motivo eu fiz a engenharia reversa do protocolo MSNP8 do cliente oficial e implementei o novo modelo de autenticação SSL e demais pacotes necessários, na biblioteca do plugin MSN do PlanetaMessenger.org denominada JMML (Java MSN Messenger Library), e voilá, após isso a Microsoft nunca mais conseguiu retirar o PlanetaMessenger.org da rede MSN.

Se passaram mais de 10 anos e nesse intervalo eu vi o PidginIM, Adium e o MirandaIM terem suas implementações do protocolo MSN bloqueadas várias vezes, obrigando-os a fazer patches de correção para manter seus clientes conectados na rede MSN, entretanto a implementação do protocolo MSN do PlanetaMessenger.org (JMML) se manteve firme e forte nesse intervalo de tempo, nunca tendo sido afetada por esses bloqueios, apenas recebendo atualizações pertinentes a correções de bugs e problemas de segurança.

O mesmo aconteceu para os projetos que utilizaram a biblioteca JMML para se conectar na rede MSN, pois até onde sei alguns grandes nomes desse mercado de clientes e servidores de mensagens instantâneas, como o projeto OpenFire da Ignite realtime/JiveSoftware jamais tiveram nenhum problema de acesso à rede MSN, enquanto utilizaram a JMML em seu core.

R.I.P MSN

R.I.P MSN

Agora apenas me resta deixar que a JMML descanse em paz junto com a rede MSN……ou quem sabe fazer um servidor compatível com MSN . 🙂

Enjoy.

[]’s
PopolonY2k

Referência

MSN – Windows Live Messenger (Wikipedia)
http://en.wikipedia.org/wiki/Windows_Live_Messenger

Skype official website
http://www.skype.com/

Microsoft official website
http://www.microsoft.com

PlanetaMessenger.org official website
http://www.planetamessenger.org

Adium official website
https://adium.im/

PidginIM official website
https://pidgin.im/

MirandaIM official website
http://www.miranda-im.org/

IM+ mobile messenger
https://plus.im/

MSNP8 Protocol (Wikipedia)
http://en.wikipedia.org/wiki/Microsoft_Notification_Protocol#MSNP8

PlanetaMessenger.org Libraries (JMML, DJcq2k, ComVC, …)
http://sourceforge.net/projects/pmlibs/

OpenFire (Ignite realtime/Jive Software)
http://www.igniterealtime.org/projects/openfire/

Ignite realtime/Jivesoftware about page
http://www.igniterealtime.org/about/index.jsp

PlanetaMessenger.org’s Sourceforge.net project’s page
http://sourceforge.net/projects/planeta/

News about MSN network ending.
http://www.neowin.net/…/msn-messenger-will-finally-shut-dow…
http://www.windowscentral.com/msn-messenger-shut-down-china…

Pop!Dev – Primeiro concurso de desenvolvimento de software para MSX (MegaRAM edition)

Memória de computador, um recurso tão infinito atualmente que a maioria das pessoas mais novas e mesmo os mais antigos não sabem ou se esqueceram que no passado esse recurso era algo precioso ou até mesmo inexistente devido a tecnologia pouco desenvolvida da época. Me lembro que em meados dos anos 80 os micros pessoais ou tinham 64Kb de RAM, exatamente o caso dos micros de 8Bits como o MSX, ou tinham de 512Kb a 640Kb por default, sendo esse o caso dos micros da linha IBM-PC.

Para piorar um pouco mais as coisas, aqui no Brasil vivíamos a famigerada reserva de mercado que nos impedia de ter acesso às mesmas tecnologias top de mercado existentes em outros países na época. Independente disso eu particularmente acredito que quando o ser humano enfrenta adversidades devido a alguma limitação física ou técnica, ele termina desenvolvendo soluções criativas para burlar tais limitações.

Enquanto isso no Japão.

O MSX ia de vento em popa no Japão e em diversos países da Europa e até por conta disso o consórcio MSX, capitaneado pela ASCII japonesa, decidiu aperfeiçoar o padrão a partir dos MSX2, o que possibilitou softwares mais complexos e que exploravam melhor a capacidade do padrão através do uso de mais memória nessas máquinas. Foi assim que nasceu a expansão de memória padrão do MSX, denominada Memory Mapper, solução essa que envolve padronização da camada física e lógica para ser ter acesso a mais memória nos micros do padrão.

MSX Memory Mapper

MSX Memory Mapper cartridge

Enquanto isso no Brasil

No Brasil estávamos muito distantes do resto do mundo em todos os quesitos tecnológicos não importando se o padrão era o IBM-PC, Amiga ou MSX. O fato é que precisávamos manter o mercado nacional aquecido de alguma forma, mesmo que acompanhando o mercado internacional utilizando soluções independentes e desenvolvendo assim um “padrão próprio”.

Nesse cenário em meados dos anos 80 um famoso projetista de periféricos de MSX, na época, desenvolveu um dispositivo de memória denominado MegaRAM e que poderia estender os míseros 64Kb do MSX para 256Kb, 512Kb e 768Kb, sendo esses os modelos mais comuns de MegaRAM naquela época. O nome desse projetista é Ademir Carchano, que é membro ativo da comunidade MSX nacional até os dias de hoje, onde lança constantemente diversos produtos relacionados ao universo MSX, sob o selo ACVS.

MegaRAM ACVS

MegaRAM ACVS

A criação da MegaRAM possibilitou que diversos usuários brasileiros tivessem acesso a jogos incríveis, lançados no Japão, que utilizavam mais do que 64Kb, só que armazenados em ROM e conhecidos lá fora como MegaROM.

Aleste é um dos games MegaROM, portados para MegaRAM.

Aleste é um dos games MegaROM, portados para MegaRAM.

MSX Today

Hoje o cenário de desenvolvimento de novos hardwares e softwares para MSX no Brasil está bem aquecido, como há anos não se via. Atualmente contamos com a fabricação de dispositivos IDE, incluindo a IDE com Memory Mapper, novos kits que convertem um MSX comum para MSX2+, como é o caso do M5X e também novos games como o Flappy Bird para MSX e music players como o Pop!Art.

Flappy Bird for MSX

Flappy Bird for MSX

Mas independente dos novos lançamentos, sempre há quem busque alguns antigos e consolidados dispositivos como é o caso da MegaRAM. Ainda mais depois do anuncio da nova MegaRAM de 2MB feito pelo próprio Ademir Carchano, na comunidade MSX Brasil no FaceBook.

Incentivo aos produtores nacionais.

Logo que recebi a notícia da nova MegaRAM de 2MB fiquei entusiasmado principalmente pelo fato de contarmos com um espaço de 2MB para futuras aplicações que assim desejarem usar essa área “infinita”  de memória. O meu primeiro impulso foi adquirir a minha MegaRAM de 2MB, mas como eu já estava com a mão na massa e também como já havia citado no grupo GDMSX do FaceBook e G+ sobre um possível concurso de desenvolvimento de software para retro-máquinas, decidi então patrocinar o primeiro concurso do grupo GDMSX e do meu blog, adquirindo uma MegaRAM 2MB que será entregue ao futuro vencedor da competição.

O concurso

Bom, definido o prêmio vamos ao nome do concurso e às regras do mesmo, e entrando na onda Pop!*, nomeei o concurso como Pop!Dev :). Quanto às regras, elas serão breves, simples, diretas e sem muita burocracia 🙂

Objetivo

Primeiro, o grande objetivo desse concurso é fomentar o desenvolvimento de software para a plataforma MSX, sendo assim só serão válidos softwares desenvolvidos para essa plataforma, não importando o modelo utilizado, seja MSX1, MSX2, MSX2+ ou MSX TurboR.

Outra questão principal é referente ao uso da MegaRAM, sendo que os softwares inscritos na competição deverão ser compatíveis com a MegaRAM, independente do modelo (256Kb, 512Kb, 768Kb ou 2MB) e fabricante, pois o intuito dessa competição é justamente fomentar o desenvolvimento e a troca de conhecimento sobre a MegaRAM, lembrando apenas que se alguém fizer algo que utilize uma MegaRAM de maior capacidade, esse terá uma vantagem sobre os demais competidores, pois quanto maior a capacidade de memória utilizado por um software, geralmente mais complexo ele tende a ser.

Com base nessas premissas, vamos às regras.

As regras

  1. O software participante deverá ser compatível com MSX, independente do modelo escolhido (MSX1, MSX2, MSX2+ ou TurboR).
  2. O software participante deverá ser compatível com a tecnologia MegaRAM, sendo independente de fabricante e modelo (256Kb,512Kb, 768Kb ou 2MB).
  3. Apenas participantes do grupo GDMSX, tanto do FaceBook quanto do G+ poderão participar da competição, portanto, se você quiser participar da competição entre em uma das comunidades do GDMSX (FaceBook ou G+) para que possa apresentar seu projeto e estar apto a participar da competição.
  4. Seu projeto deverá ser original, ou seja, ser de sua autoria. Não serão aceitos ports com base no código fonte ou binários de programas ou jogos feitos para outras plataformas, por outras pessoas/empresas, tendo sido apenas modificados por você. O software deve ser desenvolvido e concebido inteiramente por você. Claro que você pode utilizar técnicas concebidas por outras pessoas, mas o código deve ser implementado por você.
  5. O software poderá ser feito por um grupo de mais de uma pessoa, entretanto se os desenvolvedores optarem por fazer dessa forma, deverão marcar seus nomes no momento da apresentação do projeto no post em uma das comunidades do GDMSX.
  6. O código fonte deverá ser aberto e liberado por alguma licença open source, seja alguma GNU (como GPL), Creative Commons ou BSD, afinal o intuito do concurso é a troca de informações e experiências.
  7. O participante poderá inscrever mais de um software na competição.
  8. Os membros da comissão julgadora não poderão participar da competição.

 Votação

Vou escolher alguns membros do GDMSX que não estiverem participando da competição para formar a comissão julgadora e essa comissão será apresentada no decorrer do desenvolvimento do concurso. Quanto a parte técnica, o que mais contará pontos nesse concurso está relacionado a melhor arquitetura de software e solução desenvolvida. Mas o que isso quer dizer ?

Bem vou enumerar abaixo os itens mais relevantes.

  1. Software mais bem modularizado. Isso é importantíssimo para reuso futuro por outros membros da comunidade em outros projetos.
  2. Software mais bem documentado. Importante pelo mesmo motivo acima citado.
  3. Software que utilize MegaRAM de maior capacidade terá pontuação maior, ou seja, um software que utilize 512Kb terá maior peso sobre um feito para rodar com uma MegaRAM de 256Kb, no caso de um empate técnico.
  4. Qualidade “profissional” do software. Isso envolve interface com o usuário e usabilidade. Softwares com aparência mais profissional serão mais bem avaliados e pontuados. Isso não quer dizer que softwares gráficos serão mais bem avaliados do que softwares em texto, uma vez que existem softwares em modo texto que tem um visual “estupidamente” profissional, as vezes mais profissionais do que softwares em modo gráfico. Mas não adianta ser bonito e tecnicamente pobre pois em nosso concurso o “tecnicamente bom/ótimo” supera um que tenha apenas a interface com o usuário bonita, entretanto se o software for ótimo nos dois quesitos, teremos um campeão. 🙂

Duração do concurso.

A duração do concurso será de 6 meses a partir da publicação desse post, ou seja, 25 de Abril de 2015 o concurso será finalizado e entrará em fase de avaliação dos projetos participantes. No mês seguinte deverá ser anunciado o vencedor, tanto aqui no blog quanto nas comunidades do GDMSX no FaceBook e G+.

O que poderá ser desenvolvido

Tudo o que você quiser, desde jogos, utilitários de disco, editores gráficos, editores musicais, music players, demos, enfim, a sua imaginação é o limite. 🙂

Em que linguagem posso desenvolver.

Qualquer uma, desde ASM, C, Turbo Pascal, MUMPS, ADA, Prolog, ou seja, qualquer uma que você domine.

Premiação

O vencedor do concurso será premiado com uma MegaRAM 2MB da ACVS.

Conclusão

Esse é o primeiro de muitos concursos que estarei organizando, via blog e GDMSX e espero que consigamos desenvolver muita coisa legal para a plataforma MSX. Futuramente vou buscar patrocínios de fabricantes nacionais e talvez até internacionais que atuam no cenário MSX, mas esse primeiro é 100% patrocinado pelo Blog PopolonY2k e comunidades GDMSX.

Divirtam-se.

[]’s
PopolonY2k

Referências na internet

Memória RAM (Wikipedia)
http://en.wikipedia.org/wiki/Random-access_memory

Default (Wikipedia)
http://en.wikipedia.org/wiki/Default_%28computer_science%29

Reserva de Mercado (Wikipedia)
http://pt.wikipedia.org/wiki/Reserva_de_mercado

ASCII Entertainment
http://www.ign.com/companies/ascii-entertainment

Memory Mapper (Blog MSX All)
http://blog.msxall.com/2011/01/memory-mapper.html

ACVS (Ademir Carchano)
http://www.carchano.com.br/loja/

MegaRAM (Marcelo Eiras blog)
http://www.marceloeiras.com.br/msxsite/msxmega.htm

MegaROM (BiFi website)
http://bifi.msxnet.org/msxnet/tech/megaroms.html

M5X (OptoTech)
http://optotech.net.br/fzanoto/m5x.htm

Dissecando o Flappy Bird (Retrocomputaria blog)
http://www.retrocomputaria.com.br/plus/?p=8843

Pop!Art – Music Player (Retrocomputaria blog)
http://www.retrocomputaria.com.br/plus/?p=8015

MegaRAM 2MB (ACVS website)
http://www.carchano.com.br/loja/produtos_descricao.asp?lang=pt_BR&codigo_produto=43

MSX Brasil (FaceBook)
https://www.facebook.com/groups/182223775136806/

GDMSX (FaceBook)
https://www.facebook.com/groups/gdmsx/

GDMSX (G+)
https://plus.google.com/u/0/communities/105926991534247611226

GPL (Wikipedia)
http://en.wikipedia.org/wiki/GNU_General_Public_License

Creative Commons (Wikipedia)
http://en.wikipedia.org/wiki/Creative_Commons

BSD Licenses (Wikipedia)
http://en.wikipedia.org/wiki/BSD_licenses

ASM language (Wikipedia)
http://en.wikipedia.org/wiki/Assembly_language

C language (Wikipedia)
http://en.wikipedia.org/wiki/C_%28programming_language%29

Turbo Pascal (Wikipedia)
http://en.wikipedia.org/wiki/Turbo_Pascal

MUMPS (Wikipedia)
http://en.wikipedia.org/wiki/MUMPS

ADA language (Wikipedia)
http://en.wikipedia.org/wiki/Ada_%28programming_language%29

Prolog language (Wikipedia)
http://en.wikipedia.org/wiki/Prolog

SplitPlay

Quem viveu a adolescência nos anos 80 sabe que indústria dos vídeo games era completamente dominada pelo Japão, principalmente após a crise de 1984 que deixou essa indústria vulnerável nos EUA no início dos anos 80.

Naquela época a Europa também tinha uma indústria forte, principalmente na Inglaterra onde diversos estúdios se dedicavam ao desenvolvimento de jogos para a plataforma ZX Spectrum, sendo essa uma das plataformas mais promissoras da época tendo diversos ótimos jogos lançados no mercado, inclusive sendo portados para outras plataformas como MSX e Amstrad CPC.

Também nessa época me lembro que os espanhóis começavam a desenvolver muitos jogos para MSX e ZX Spectrum, sendo muitos deles excelentes e outros de qualidade contestável. Mas como é se fazendo que se chega a perfeição, já naquela época fomos agraciados com excelentes jogos espanhóis, como por exemplo Astro Marine Corps.


Astro Marine Corps (ZX Spectrum, MSX e Amstrad CPC)

Felizmente o tempo passa e hoje os espanhóis também são bastante reconhecidos no mercado internacional de desenvolvimento de jogos, conforme já descrevi em um texto aqui há algum tempinho atrás.

Enquanto isso no Brasil

Infelizmente o Brasil é um País em que os empreendedores tem que gastar muita energia e dedicação para colocar seus sonhos em prática, pois há pouco ou quase nenhum investimento por parte do governo no fomento da indústria nacional de jogos. Entretanto graças ao espírito empreendedor dos estúdios nacionais, muitas vezes caseiros, esse mercado tem se desenvolvido ainda que lentamente, mas se considerarmos o cenário de 10 anos atrás, estamos vivendo um momento de extrema inovação e principalmente se desenvolvendo rapidamente.

SplitPlay

Os estúdios e desenvolvedores brasileiros sempre tiveram dificuldades principalmente no que diz respeito a facilidade de distribuição no mercado nacional. Me lembro que na década de 80 mesmo os grandes desenvolvedores da época, a maioria dedicados ao mercado de computadores MSX, tinham muita dificuldade em distribuir seus softwares, dentre eles diversos jogos feitos na época para essa plataforma. O meio mais efetivo na época era a publicidade em revistas especializadas, o que era caro e na maioria das vezes não significava retorno do investimento, uma vez que o fator pirataria também influenciava para que a quantidade de cópias fosse bem limitada aqui no Brasil, mais do que nos dias atuais.

Nesse cenário desfavorável o mercado nacional de games foi se desenvolvendo e hoje podemos dizer que é impressionante o número estúdios e desenvolvedores nacionais existentes por aqui, entretanto faltava uma boa alternativa nacional às grandes game stores internacionais, como a Steam, GooglePlay e iTunes, que na maioria das vezes não traz retorno nem reconhecimento algum aos estúdios nacionais, mantendo-os pequenos e muitas vezes irrelevantes no mercado mundial.

Para minha surpresa, no início do ano recebi um contato por parte do pessoal da SplitPlay, que é uma game store dedicada 100% a distribuição de jogos desenvolvidos aqui no Brasil onde, após algumas trocas de emails, estabelecemos uma parceria que me permitirá fazer uma análise dos jogos disponibilizados na SplitPlay :).

SplitPlay

SplitPlay Game Store website

Tenho recebido jogos de excelente qualidade e apesar da maioria ter um preço final que chega a ser 10 vezes menor que o de um jogo estrangeiro, posso afirmar que a maioria deles não deixa nada a desejar aos desenvolvidos por estúdios internacionais que tem acesso a mais recursos financeiros em seus desenvolvimentos.

Bom, esse é o primeiro de muitos posts que farei a respeito dos jogos nacionais disponibilizados na SplitPlay e nas análises posteriores tentarei pontuar os jogos considerando a qualidade gráfica, recursos computacionais utilizados, qualidade sonora, jogabilidade e portabilidade.

Quem viveu na época de ouro do MSX, deve se lembrar das análises de jogos feitas pela revista MSX Micro, portanto devem lembrar o estilo utilizado por essa publicação na época…..para quem não era nascido só posso sugerir que aproveitem e divirtam-se.

[]’s
PopolonY2k