Cards vs. MOBS/Sprites

[PlanetJanus]

If this topic is covered elsewhere, please direct me to it. I haven't found any thread specific to my level of understanding: barely.

So, Cards are preset graphics in the GROM that can be placed in Card spots that are preset, like a game board. MOBS can move independently.

If I wanted to make a board-like game, This could be done using just cards, with COL being set to the card location and card locations able to be checked and manipulated to account for movement in a board type game. This would essentially, to my understanding, mean that I am working with a preset grid that already has positions accounted for on the predetermined 20X16 card grid.

There seems to be some intersection between MOBS and Cards in function, These I do not understand. It seems that a MOB is a MOB, but a card is also similar to a MOB in certain ways.

I think, my ultimate question is: Can a game be made completely of cards, with a screen of cards updated between every movement, as in a turn based card game?

[intvnut]

OK, back up a tick.

 

There are four different things here:

1. GROM. This is a set of 8x8 pictures stored in ROM, including the alphabet and some graphic tiles. There's 256 GROM pictures, but only the first 220 or so are interesting.
2. GRAM. This is a set of 8x8 pictures stored in RAM, which means your program can change what the pictures are. There's 64 GRAM pictures.
3. BACKTAB. This is the 20x12 fixed grid of characters that fills the screen. You can use pictures from both GRAM and GROM here. Each position in BACKTAB has a foreground color for "on" pixels, and a background color for "off" pixels. Every position in BACKTAB is 8x8*.
4. MOBs. These are the Movable Objects. There are 8 of these, and they have programmable position, and to some extent, programmable size. They too can use pictures from GRAM or GROM. Each MOB may be placed in front of or behind the BACKTAB. If it's in front, its "on" pixels will cover the contents of BACKTAB. If it's behind, then the "on" pixels in BACKTAB will cover it.

I've avoided using the term "card" above, as it's sometimes used to refer to a picture coming from GRAM/GROM, and sometimes used to refer to a position in BACKTAB. I think the term "card" probably is a hold-over from an earlier video chip General Instrument built that really was hard-coded for card games. (See decle's StudioVision emulator.)

 

This is just a high level summary, but hopefully it clarifies a few things.

 

There are games, such as Checkers, Chess, Reversi, and Backgammon that don't make much use of MOBs. (Mainly, they're used as "cursors.")

____

 

* Except the rightmost column, which is only 7 pixels wide. I only mention this as I know pedants are watching.

[PlanetJanus]

Thanks. Making More sense of this.

So, What I am thinking of is the BACKTAB: Which is essentially a grid that CARDS in GRAM/GROM can be assigned to, Cards not being unique to the BACKTAB but can also be MOBS.

This also makes it possible to function between two different environments. A MOB environment overlaid over a BACKTAB environment, and these environments can be programmed to interact with one another.

I'm going to buy Nanochess' book asap. Most of my BASIC programming was VIC20/C-64: I'm used to having lines numbered. I still haven't gotten used to unnumbered code; It looks very floating. I taught myself some C and Java script, but to make games I had to make the environment the game existed in. By the time I had built maps for graphics to interact with I had no idea how to interact with the structure I made.

Slogging through this, but this is incredibly fun. I always wanted to make a game for one of these old systems, just for the fucksies.