Old School Computer & Games

Curiosidade sobre o jogo USF CHESS (XADREZ) do Intellivision.

Olha que coisa interessante: Nos níveis mais altos (o jogo oferecia 6 níveis de dificuldade), um único lance do computador podia demorar HORAS ou até mesmo DIAS!!!!

A Inteligência Artificial parece não ter sido feita pela Mattel e sim baseada num programa já existente ofertado por uma empresa, ou seja, a "IA" foi adaptada dentro do cartucho.
Obviamente que inserir uma IA dentro de um cartucho onde mal cabia 4 kbytes de dados é uma tarefa de Hércules (nem SONHO como eles fizeram isso).

O carinha que fez o lay-out da tela do jogo foi testar e constatou que a IA do Intellivision era boa, mas um pouco... demorada [quá! quá! quá!]. O cara ia pra casa e deixava o pobre do console pensando...

Então acharam por bem inserir um aviso na caixa (ou no manual) informando sobre essa lentidão.

Eu testei algumas partidas em níveis diferentes e realmente constatei que nos níveis menores a resposta é mais veloz, no entanto no Nível 7 ele demorou mais de 5 min para mover a primeira peça. Só que esse teste foi feito no emulador e não no console. Pensei que por esse fato o computador responderia mais rápido mas aí me toquei que se trata de um EMULADOR (ou seja, ele reproduz com fidelidade o hardware do Intellivision), portanto a resposta vai ser a mesma do console.

Bem, curiosidades à parte, o jogo USF CHESS era sem dúvida o mais formidável game de XADREZ da época. Disponibilizava não somente vários níveis de dificuldade mas também duas opções de SETUP BOARD, que é a montagem de uma SITUAÇÃO DE JOGO para treinar situações de xeque-mate.

Não encontrei informações sobre o CHECKER da ATARI para uma comparação, portanto se alguém souber de alguma coisa por favor poste aqui.

AUTORACING

Essa também é interessante, principalmente porque joguei muito (mas muito mesmo) esse jogo.

Foram lançadas DUAS VERSÕES deste jogo. A primeira permitia aos jogadores controlar o carro do ponto de vista do interior do carro, ou seja, um NÓ TOTAL no cérebro humano.

A segunda permitia controlar o carro de forma intuitiva, levando em conta o que era visto NA TELA.

Parece que o pessoal "se perdeu" na hora identificar as versões e ambas foram lançadas no mercado. O problema é que NINGUÉM SABIA DIZER qual era a versão que estava em qual caixa. Enfim, a única forma de saber qual o usuário comprou era... JOGANDO! [quá! quá! quá!]

Poxa... eu acabei de comprar um AUTORACING e ainda não o joguei... Qual será a versão que eu consegui?

Alguém sabe quantos SPRITES o processador do Intellivision consegue mover ao mesmo tempo?

Estou terminando minha versão do jogo NIGHT STALKER e já estou pensando em acrescentar algumas "novidades" nele, porém gostaria de respeitar as limitações do console para não enfeitar demais e assim desagradar os fãs que venham a curtir essa minha versão do jogo.

Ah, outra curiosidade. Qual seria o tamanho do PIXEL dos games do Intellivison? Se eu for desenhar alguma figura nova em algum jogo eu precisaria fazer isso usando como "pincel" o tamanho desse PIXEL. Se não me engano, uma boa referência seria o olho do ZÉ PIMENTA do BurgerTime, ou então a "menor estrela" no céu do jogo ASTROSMASH, correto?

Eu entendo por SPRITE algo como sendo qualquer figura na tela que tenha MOVIMENTO, mas acho que a coisa deve ser um pouco mais complexa do que isso.

Por exemplo, um objeto ESTÁTICO (como uma NAVE ou METEORO), porém que tenha DESLOCAMENTO me parece custar bem menos processamento do que um PERSONAGEM ANIMADO como o TRON ou PITFALL, correto? Não sei qual desses dois objetos são considerados verdadeiramente SPRITES.

Em todo caso, minha dúvida surgiu por causa do jogo HE-MAN. Eu fiz um videozinho dele enquanto jogava e marquei nada mais nada menos que 19 (dezenove) objetos se movendo na tela ao mesmo tempo (incluindo HE-MAN e o ESQUELETO). Detalhe: São todos objetos ANIMADOS (tudo o que o esqueleto joga no He-Man tem animação e movimento). E não me parece que nenhum objeto nessa tela fica piscando (acho que o pessoal chama isso de FLICKER, não?). Se puderem jogar o HE-MAN pra dar uma olhada e me dizerem o que acham seria interessante.

Já li algo a respeito de 8 sprites.
Segundo o manual da General Instrument, o chip permite "8 coordenadas de objetos" (entendo que é possível manipular 8 objetos simultaneamente).

Nunca me aventurei a tentar criar um jogo para o Intellivision, mas acho que uma técnica para evitar o ''flicker'' seria mover um grupo de 8 sprites de cada vez.
Bastaria deixar o sprite na tela (visível) enquanto os outros sprites são movimentados e só "sumir" o sprite quando o processador já tivesse calculado a nova posição (diminuindo o tempo entre o "sumiço" e o "reaparecimento", evita-se o flicker).

Obviamente o processador do Intellivision não é tão rápido e talvez essa minha ideia não dê certo com um número grande de sprites.

Li em algum lugar que esse (d)efeito de piscar os sprites (comum em jogos do Atari) era abominado pela equipe da Mattel.
Realmente, os caras faziam mágica com o Intellivision.

Tem o lance de mover um background para dar a ilusão de movimento que é bastante interessante e deve ser o caso (por exemplo) do ENCOURAÇADO do jogo DESAFIO ESTELAR.
Porém, quando é preciso fazer ANÁLISE DE COLISÃO entre dois objetos eu acho que essa técnica não funciona. Imagino que para fazer PIXELS acenderem e apagarem em certos pontos da tela seria algo fácil, mas para detectar colisão eu acho que é preciso analisar POSIÇÕES DE MEMÓRIA (vixi... dá pra viajar na maionese!)

Eu fiz uma pesquisa em cima dessa informação e em toda informação técnica a respeito do processador há sempre uma referência em cima dos 8 MOBS (Moving Objetcs).

Olha que texto interessante que encontrei no INTELLIVISIONLIVES a respeito da versão do jogo SMURFS da Coleco:

"Because a sprite could only be one color, the Smurf and Smurfette were made up of multiple sprites: hat, hair, body, shoes, etc."

A tradução disso aí acho que mais CONFUNDE do que EXPLICA.

Acho que vou esquecer esse lance de LIMITAÇÃO DE SPRITES já que não conseguimos definir O QUE SÃO ELES num game do Intellivision.

Ah, em tempo: Minha versão do NIGHT STALKER está sendo feita no aplicativo GAMEMAKER, ou seja, não existe LIMITAÇÃO DE SOFTWARE ou HARDWARE.

Minha duvida é que eu não quero enfeitar demais o jogo e sim fazer algo mais ou menos parecido com o que foi feito na versão do BURGERTIME, limitando graficamente o jogo (em CORES e SPRITES).

O GAMEMAKER é de uma empresa chamada YOYOGAMES.

É um aplicativo todo voltado para permitir que um usuário leigo possa criar um joguinho simples, ou seja, ele tem na verdade uma "interface" toda voltada para "arrastar e soltar", o que permite a qualquer pessoa criar um jogo sem precisar digitar nenhuma linha de código.
Esse método de arrastar e soltar, falando francamente, dá para fazer no máximo um jogo estilo ATARI, sem muito gráfico e pouquissima interação por parte do computador.

Porém, se a pessoa tiver mais experiência pode usar a linguagem de programação do aplicativo que nada mais é do que SCRIPT puro e aplicado (semelhante ao JAVA ou até mesmo PHP). Nesse caso sim dá para fazer trabalhos mais complexos como um SUPER MARIO ou DOOM por exemplo, porém a turma usa mais para fazer JOGOS DE NAVE ou jogos tipo PUZZLE, mais fáceis de criar com essa ferramenta.

A utilização do programa é bastante simples, o "manual" em PDF é bastante abrangente mas foca mais na parte do "arrastar e soltar" (o que é uma pena).

Eu acho que os programadores tinham a mesma dificuldade na época, e não sei se tem algo a ver com RESOLUÇÃO.

Quando você pressiona uma tecla para mover um OBJETO, ele se move TANTOS PIXELS em uma determinada direção. Vamos supor que o TRON tenha, inicialmente (quando o jogo começa), uma velocidade de 5 PIXELS.

Então cada vez que você pressiona o DISCO ele vai andar esses 5 PX em uma direção. Isso implica dizer que, o menor movimento do TRON no começo do jogo, é de 5 PIXELS (por menor que seja o seu toque no direcional, ele vai andar 5 PX).

Então vamos supor que a coordenada VERTICAL de tela exata para o TRON ficar na hora de atirar no RECONHECEDOR seja Y = 100;

Se o RECONHECEDOR parar na tela e o seu olho parar na coordenada 101 (ou 102, 103, 104) por exemplo, o TRON NUNCA o acertaria, porque o jogador tentaria alinhar (movendo o TRON para cima ou para baixo) e ao invés do TRON se mover 1PX, ele se moveria 5PX (que é a velocidade normal dele). Então sua posição iria de 100 para 105 ou 95 (dependendo se ele sobe ou desce).

Claro que os programadores deram um jeito nisso, fazendo o RECONHECEDOR se posicionar numa coordenada que o TRON pudesse acertá-lo (por isso ele para sempre nos mesmos lugares).

Porém no decorrer do jogo a velocidade do TRON aumenta, então vamos supor que salte de 5 para 7 PX. Como o RECONHECEDOR para sempre no mesmo lugar, o TRON sempre tem DIFICULDADES para se posicionar, pois vai cair no problema acima.

Muitos já devem ter percebido que isso ocorre. Acima de 20 mil o TRON passa a ter problemas para se posicionar na hora de acertar o RECONHECEDOR, ficamos dando "toquinhos" e o TRON passa do ponto, porém geralmente ele para no lugar certo.

Eles devem ter resolvido isso "ajustando" a coordenada "Y" do TRON para o lugar correto (ao invés de reposicionar o RECONHECEDOR).

O que ocorre com essa ferramenta que eu utilizo (o GAMEMAKER) é o que parece ocorrer com qualquer outro aplicativo.

Se você diz "Objeto, vá de X=100 para X= 105, ele obedece, porém agora imagine que entre o 100 e o 105 exista um objeto qualquer que impeça o movimento? O que ocorre?

Eu tive MUITO esse problema quando programei o NIGHT STALKER. Eu mandava o HEROI caminhar 5 px para a direita, e a 3 px do seu local há uma subida (para onde eu desejo virar). Como o computador é notório em fazer o que você MANDA e não o que você QUER, ele obedecia os 5 px de deslocamento e ignorava a "curva" para onde eu queria subir.
Isso me obrigou a inserir uma quantidade INSANA de código para "prever" o que havia à frente do Heroi e REDUZIR SEU SPEED antes de uma curva. Tive que fazer isso com todos os personagens (Heroi, Robôs, Morcegos...).

Mas sei lá... minha versão do GAMEMAKER é meio antiga, acho que vou fazer o upgrade para GameMaker Studio e ver no que dá.

Até porque o GameMaker que estou usando é bem chato no que tange a detalhes de "colisão de sprites", eu perco mais tempo em cima dessas bobagens do que efetivamente em cima da lógica de programação do jogo...

Acho que era mais ou menos isso que eu imago que seja um SPRITE no console do INTELLIVISION:

São vários CARDS, um ao lado do outro, que compõem a imagem toda. No jogo TRON eu tomo como base o canto direito porque eu notei que a referência para movimentação desse sprite é o seu DISCO (a imagem nunca ultrapassa a imagem do disco). A largura está maior porque obviamente esse cara, ao correr, estica as pernas.

Eu imagino que seja dessa forma que eles criam os sprites. Devia haver uma ferramenta especial para essa criação, eu DUVIDO que eles criassem isso apenas usando CÓDIGO e "testando" pra ver como fica, seria uma PIRAÇÃO. Salvo é claro que eles fizessem isso numa FOLHA DE PAPEL.

Entendo que para formar um SPRITE eram necessários vários CARDS juntos, o que me remete à questão de como ''montar'' um sprite inteiro. Sendo blocos 8x8, então um personagem como o TRON por exemplo tem 36x48 (pelo que pude verificar nas imagens BITMAP que extraí).

Isso implica dizer que ele é formado por 6 blocos na VERTICAL e 5 blocos na HORIZONTAL. Teoricamente faz sentido e se for isso é uma descoberta interessante, pode ajudar a criar até mesmo personagens novos para eventuais futuros jogos.

Ah sim, certamente eles deviam ter um editor de sprites.
Imagino que eles usavam os 8 do seguinte modo:

1- Tron
2- disco do tron
3, 4, 5 - inimigos na tela
6, 7, 8 - discos dos inimigos (ou bastões dos Guardiões Laranja)

Isso explica porque os inimigos tem que sair da tela para o Reconhecedor entrar!

James Halliday escreveu:
Ok, MacGyver, eu pesquisei o esquema FB/COLOR STACK. Segue o que "aprendi":

Pelo que entendi, na época do intellivision não existiam SPRITES e sim MOVING OBJECTS. Cada sprite tinha no máximo 8x8 de tamanho, ou seja, se eu quisesse ter um objeto maior que isso, só poderia fazê-lo de 16x8, 16x16 e por aí vai (ou o dobro de largura, ou o dobro de altura, ou o seu próprio dobro). Achei isso interessante, pois agora sei qual tamanho de SPRITES eu posso ter se eu for me aventurar em outros jogos.

O HARDWARE só permitia mover 8 objetos ao mesmo tempo (8 sprites). Então a primeira pergunta é: Como fizeram o SPACE ARMADA, que move TROCENTOS SPRITES ao mesmo tempo?
Para isso usaram um algoritmo espertinho que APAGAVA e REDESENHAVA um SPRITE em nova posição, dando a impressão que ele "se moveu". Isso explica porque o tiro da nave PASSAVA DIRETO quando os monstros tocavam um dos cantos e desciam uma linha... Na verdade o monstro era apagado e redesenhado na linha de baixo e se nesse "intervalo" um tiro tocasse o sprite, ele "vazava"... (HAUHAUAHA).

Opa ! Vamos lá:

Space Armada

Não lembro qual emulador tem uma tecla pra ver os MOBs que estão na tela. Ele os identifica com um quadrado em volta, de maneira mais clara.
O Space Armada não usava sprites (MOBs) pra fazer os inimigos, se fizesse ia ter que usar algo chamado "multiplexing" pra ficar alternando, daí os inimigos iam ficar piscando feio.

Color Stack

Quanto ao Color Stack, o único que me lembro que usava era o Snafu. Não era comum a sua utilização. Acho que o Tron não usava mesmo.

Bem lembrado. Não usaram o recurso de apagar e redesenhar sprites no SPACE ARMADA pois isso é o que se chama MULTIPLEXING, e isso causa FLICKER (piscar), o que era proibido (engraçado, nos jogos de NAVE que eu jogava nos consoles Nintendo, Mega e até Arcade esse "flicker" era bastante comum quando a tela enchia de inimigos).

Na verdade, no SPACE ARMADA usava outro recurso, algo relacionado a "acesso direto à memória", mas isso apenas ESCOVADOR DE BIT sabe o que é... HUAHUAHUA!

Como conseguiram usar MULTIPLEXING no SNAFU sem causar flicker é um mistério...

Fui atrás da paleta de cores do Intellivision e encontrei algo sobre programação do Intellivision. Encontrei um link interessantíssimo para uma ferramenta (web) que me entregou de LAMBUJA a paleta de cores do Intellivision. Parece que dá pra montar um SPRITE de forma completa através das ferramentas disponíveis. Dá para usar FB ou COLOR STACK, coisa muito, mas muito interessante mesmo.

Fiquei curioso agora em como montar um sprite completo, como o personagem do TRON por exemplo. Achei que ele tivesse sido feito EM UM ÚNICO SPRITE, mas pelo visto não foi assim.

MacGyver escreveu:
Ah sim, certamente eles deviam ter um editor de sprites.
Imagino que eles usavam os 8 do seguinte modo:

1- Tron
2- disco do tron
3, 4, 5 - inimigos na tela
6, 7, 8 - discos dos inimigos (ou bastões dos Guardiões Laranja)

Isso explica porque os inimigos tem que sair da tela para o Reconhecedor entrar!

É, faz sentido no caso do TRON, mas esses 8 MOBs com certeza não eram uma limitação, eles parece que usavam bastante o recurso de "sequencing GRAM".

Ah sim, existe a criatividade.
Mas daí você perde toda a comodidade do controle de colisão, animações, etc.
Deve ter que fazer tudo na unha e deve dar um trabalho.

Imagino que a preferência seria usar os MOBs primeiro, depois recorrer a este tipo de solução...

Será que o Reconhecedor era um MOB em modo ampliado?

No He-Man, eu assumo que eles devem ter usado esse recurso de sequencing também porque gastaram os MOBs todos nos personagens do He-Man e do Esqueleto!

Lembre-se que um MOB só tem uma cor... E se você olhar o He-Man, ele tem 2, e o Esqueleto tem 3...

Só nisso são 5 na tela o tempo todo...

No He-Man acho que usaram COLOR STACK.

Olha, pelo que entendi não havia limitação de uma única cor para um MOB.

O esquema de cores FOREGROUND e BACKGROUND eram usados nos CARDS. Cada "pixel" no CARD podia receber 2 cores. O pixel FOREGROUND (da frente) podia receber as 16 cores, porém o pixel BACKGROUND só permitia as 8 cores primárias.

Como um MOB era constituido de diversos CARDS agrupados, podia-se fazer MOBs com diversas cores, bastando apagar ou acender os pixels da frente.

Então por que é que os MOBs geralmente eram todos CHAPADOS de uma única cor?

Se formos apenas examinar os CARDs, veremos que era 1 milhão de vezes mais fácil manipular MOBs chapados do que multicoloridos, pois se UM CARD de uma linha tinha variação de cores, TODOS OS DEMAIS daquela linha teriam que variar também de forma idêntica.

Por isso era mais fácil, por exemplo, pintar toda a CABEÇA de um MOB de uma única cor, pois entendo que a cabeça usava os CARDS DO TOPO e se apenas esses tivessem variação de cor, seria fácil gerenciar.

No caso do TRON, há situações em que ele AGACHA. Quando isso ocorre, a cabeça dele, que ocupava os CARDS DO TOPO vão ocupar os CARDS DO CENTRO (a cabeça dele é desenhada lá na cintura). Se eles tivessem feito a cabeça dele de cor diferente, na hora que a cabeça fosse redesenhada na cintura, eles teriam que saber QUAIS CORES foram usadas lá no topo para aplicar nos CARDs da CINTURA, entendeu? Seria o CAOS!

No caso do HE-MAN me parece que aplicaram neste jogo novas técnicas de programação, pois usaram (e abusaram) das cores, acredito que ele tenha sido todo feito em COLOR STACK. Durante o jogo aquelas "bolinhas" brancas e amarelas, se você reparar, elas ficam "piscando" enquanto caminham, ou seja, um forte indício de alternância de cores (tipica do COLOR STACK).

Solucionado: número de cores no MOB

Tirado do site dos Blue Sky Rangers:

"Moving objects can have only ONE color each; a multicolor character must therefore be made up of more than one of the only eight moving objects."

Color Stack no He-Man? Não acho.

Esse jogo não pode ter usado Color Stack, só olhando o seu screenshot eu contei pelo menos 6 cores diferentes usadas nos cards (não estou incluindo os MOBs, apenas as montanhas e as bolas de fogo).

Como a pilha de cores só pode ter 4 cores, logo esse jogo deve operar mesmo em F/B.

Na dúvida, acho que um emulador em modo debug pode comprovar.

Também não sei qual a vantagem do Color Stack, talvez seja performance?

Boa!

É isso mesmo. Eu até li essa frase que você pegou do site. Ali diz mesmo que para produzir MOBs multicoloridos é preciso combinar MAIS DE UM MOB.

Pelo visto foi o que fizeram com o HE-MAN. Realmente, o fato dele ter cabeça e pés em cores diferentes e aquele "duelo de espadas" sugere que foram usados mesmo mais de um MOB para cada personagem.

Quando ao COLOR STACK do HE-MAN, teria que ver um jogo onde isso tenha sido usado para ter uma ideia de como seria, não consigo conceber o funcionamento desse modo de cor.