2600 RPG - codename, "CiE"

[brpocock]

But one of the important features of Atari Adventure is the persistent world that extends beyond your immediate observation.  This is something a lot of other RPGs don't do, (especially console RPGs, because they load from CD-ROM.)  Of course, the world presented is very small in Adventure, but it's kind of sad how few games do this.  The fact the 2600 did this was even more remarkable.

 

I think Star Raiders did a similar thing on the Atari 8-bit with things like the fore-aft view, a feature that was largely absent on other similar games (including the 2600 port of that game).

 

The idea of a game updating a larger persistent world in realtime beyond your immediate frame of reference is something that has really only recently become commonplace.  In the console realm, game worlds are largely linear "spooled" adventures that do not have this aspect.

1023178[/snapback]

 

Incidentally... I'm not really doing it in this game, but there should be the impression that I am to the player due to a moderately large number of boolean "did (x) happen?" flags.

 

But you definitely can't bake bread.

[NovaXpress]

2600 Battlezone did it as well, though on a smaller scale than Adventure.a moderately large number of boolean "did (x) happen?" flags.

Ah, my time-honored trick for homemade text adventures.

 

2600 Battlezone did it as well, though on a smaller scale than Adventure.

Hell, if that counts then what about Defender, Sinistar and every other game with a radar screen. Moving a ship from point A to point B off the screen is no biggie. But behavior and events which change offscreen over time are rare on the 2600.

[Cybergoth]

2600 Battlezone did it as well, though on a smaller scale than Adventure.

1023230[/snapback]

 

Would be interesting to compile a list of such 2600 titles:

 

Explorational games that track items and/or enemies:

Adventure, Secret Quest, E.T., Superman, Pitfall, Pitfall II

 

Simulated environments:

Battlezone, Air Raiders, Starmaster, Solaris, Star Raiders

 

Sidescrollers with Radar screen:

Defender, Stargate, Empire Strikes back, Chopper Command

 

What else do we have here?

[NovaXpress]

Would be interesting to compile a list of such 2600 titles:

 

Explorational games that track items and/or enemies:

Adventure, Secret Quest, E.T., Superman, Pitfall, Pitfall II

 

Simulated environments:

Battlezone, Air Raiders, Starmaster, Solaris, Star Raiders

 

Sidescrollers with Radar screen:

Defender, Stargate, Empire Strikes back, Chopper Command

 

What else do we have here?

1023243[/snapback]

Yet another thread hijacking from the looks of it.

[Cybergoth]

Yet another thread hijacking from the looks of it.

 

Oh I bet it'll quickly go back ontopic when Milestone 1 get's posted in... *skipsback5pages* ...March!

[NovaXpress]

All in all, I thnk this does indeed rate as one of the geekiest threads in Interweb history. High-level tech talk, senseless role-playing game debates and listing video game titles for the sheer sport of it. Good times.

 

Is it really impressive to track off-screen objects ala Adventure and Superman? I did that in the Atari 800 games I wrote when I was 10 years old. I have a rule about game programming: if I can do it then it must not be very difficult.

[supercat]

Incidentally... I'm not really doing it in this game, but there should be the impression that I am to the player due to a moderately large number of boolean "did (x) happen?" flags.

1023231[/snapback]

 

I'm curious to know what realistic plans you have to make a playable and interesting game with only 128 bytes of RAM, unless you're planning on gobbling up huge amounts of ROM for playfield bitmaps. I don't think there are enough cycles to generate playfield data from a tileset in real time, and 128 bytes isn't enough to hold a screen's worth of high-resolution playfield data.

 

If you migrate to something like 4A50, you'll have adequate RAM available to hold things without need for such boolean flags.

[supercat]

Is it really impressive to track off-screen objects ala Adventure and Superman? I did that in the Atari 800 games I wrote when I was 10 years old. I have a rule about game programming: if I can do it then it must not be very difficult.

1023253[/snapback]

 

What is impressive, by the day's standards, is the number of objects that were tracked. In a computer with 16K of RAM, tracking dozens of objects is no big deal, but on smaller micros that were really seen as "hardware replacements" rather than computers, it was pretty impressive.

[supercat]

But one of the important features of Atari Adventure is the persistent world that extends beyond your immediate observation.  This is something a lot of other RPGs don't do, (especially console RPGs, because they load from CD-ROM.)

1023178[/snapback]

 

One level in Doom or Quake has more stuff in it than the entire world of Adventure, but your point regarding the overall game structure is still well-taken.

[brpocock]

I don't think there are enough cycles to generate playfield data from a tileset in real time, and 128 bytes isn't enough to hold a screen's worth of high-resolution playfield data.

1023272[/snapback]

 

At the moment, I'm cramming trying to prove that wrong

 

The travel kernel is, in fact, tile-based. There are some strange limitations (for example, I can't possibly decode tiles and change playfield colours as often as I'd like, so there are horizontal "blocks" of tiles sharing common colours), but basically, yes, it's tile-based. Tile bitmaps are 4×9, "four-colour" images, on an 8×10 tile grid. That does, sadly, leave the screen looking a little letterboxed on the sides. (180 scanlines, only using the four center playfield registers.)

 

The "18lk" basically does the decoding "interleaved" between various scanlines. There is a small amount of RAM used to precache the "next" playfield register values, but mostly I just try to stay one scanline ahead of the raster. The "excess" cycles on each row are needed to do things like colour decoding and sprites.

 

By unrolling the kernel, I can do different things on each scanline without the extra cost of a compare-and-branch operation after each scanline. That cost only occurs every 18 scanlines. I also don't have to have a set of logical tests like "if the current scanline (within the tile row) is (n), then do (x)." Those tests are performed by the m4 macro preprocessor.

 

Here's a snippet of the source. At this point, $1 is which pair of scanlines (0.. on the tile row, and $2 is 0 or 1 for whether we're on the "even or odd," the first or second scanline of the pair.

 

      ;; prefetch colour data in rows 7e,7o,8e and 2o,3e,3o
       if $1 == 7 && $2 == 0
       PREFETCH_COLOUR(pfc_left_next, tile_colours_lower)
       endif
       if $1 == 7 && $2 == 1
       PREFETCH_COLOUR(pfc_mid_next, tile_colours_lower)
       endif
       if $1 == 8 && $2 == 0
       PREFETCH_COLOUR(pfc_right_next, tile_colours_lower)
       endif
       if $1 == 2 && $2 == 1
       PREFETCH_COLOUR(pfc_left_next, tile_colours_upper)
       endif
       if $1 == 3 && $2 == 0
       PREFETCH_COLOUR(pfc_mid_next, tile_colours_upper)
       endif
       if $1 == 3 && $2 == 1
       PREFETCH_COLOUR(pfc_right_next, tile_colours_upper)
       endif

      ;; this must happen after PF1/right has been drawn
       if [ [ $1 == 8 && $2 == 1 ] || [ $1 == 4 && $2 == 0 ] ]
      ;; promote cached colours
       lda pfc_left_next
       sta pfc_left
       lda pfc_mid_next
       sta pfc_mid
       lda pfc_right_next
       sta pfc_right
       endif

 

At last count (from memory) I have about 2 lines out of every 18 that are "over" by 6 cycles, still, and at least 4 lines that aren't meeting the playfield register update timings -- i.e. they change the PF2 too soon or too late. But those numbers fluctuate regularly as I try different things. I'm afraid I'm wont to just compile and count on something this complex

 

The worst limitation of the travel kernel, imho, is that only the player sprite can move "freely," and at that, not entirely smoothly. At the moment, other sprites are stuck in place because of some really really nasty baroque HMOVE crap I do to position them. See, I can't afford to just "sleep and whack" the horizontal position register, so sprites are positioned basically by HMOVE relative to the row before. Sprites in the travel screen are basically just used for variety against the lowres playfield bitmaps, though, so it's not a huge loss.

[MayDay]

Oh I bet it'll quickly go back ontopic when Milestone 1 get's posted in... *skipsback5pages* ...March!

1023251[/snapback]

 

March?! oh crap.... *ignores bleeding fingers and starts working again*

 

j/k...

 

I don't think there are enough cycles to generate playfield data from a tileset in real time, and 128 bytes isn't enough to hold a screen's worth of high-resolution playfield data.

1023272[/snapback]

 

When I first began working on this, I eventually came to two conclusions:

 

1. it COULD be done.

2. there was no well in hell the person doing it would be ME.

 

Hence, the pleading for help, and brpocock coming to my programming rescue. Naturally, a few compromises have been made, but overall I think the effect will work very well. It should definetely look and feel different than any other 2600 game by the time we finish (or get to milestone 1, for that matter). I'm still excited every day when I work on this, because I think this game will make people stop and wonder what really *is* possible when they see it. I'm just saying that based on the comments I've got from several programmers along the way, suggesting other hardware as better or even saying outright it's not possible to do on the VCS (you know who you are! ). And after seeing Andrew's color demos and Paul's homestar demos, I'll NEVER say anything is impossible on a 2600! (just ill-advised )

 

-JD

[mos6507]

Is it really impressive to track off-screen objects ala Adventure and Superman? I

1023253[/snapback]

 

It's not even because it's technically hard. It's because so few game designers saw the value of doing it. I'm speaking both of tracking offscreen objects and randomization (a related issue).

 

For instance, compare Adventure to something like Smurfs. Normally when you enter a screen in Smurfs the enemy starts from the opposite end. If you jump offscreen and then pop back into the screen, the enemy POPS back to the opposite end. Yeah, this prevents you from being cheap-shotted. But it also kind of hinders the reality quotient. In Adventure, if you do this sort of thing you'll see the dragon where you'd generally expect him to be based on how he was moving since he's stilll moving offscreen. Pitfall II has this same "reset" effect.

 

Or in Adventure if you leave an object somewhere, and then you come back to the room, it may be gone or a different object will be there based on the activity of the bat. The world as a whole is dynamic and unpredictable in a way that most games don't exhibit. In most spooled RPGs you are railed down a single narrative path and things are exposed to you the same way every time. The world is static. It doesn't evolve. It just gets displayed as the designer hardcoded it to. They call this "story".

 

Or in Superman because of the subway system and the X-ray vision you really get a sense of the objects shuffling around on their own even more.

 

It's something you feel more than experience.

 

From a design standpoint, Adventure has the most in common with first-person-shooters and MMORPGs, but not console RPGs.

[supercat]

The travel kernel is, in fact, tile-based. There are some strange limitations (for example, I can't possibly decode tiles and change playfield colours as often as I'd like, so there are horizontal "blocks" of tiles sharing common colours), but basically, yes, it's tile-based. Tile bitmaps are 4×9, "four-colour" images, on an 8×10 tile grid. That does, sadly, leave the screen looking a little letterboxed on the sides. (180 scanlines, only using the four center playfield registers.)

1023650[/snapback]

 

So two tiles per playfield byte, then. If you're using an 18-line unrolled loop, that would look like each line would have, at minimum,

 lda #color
 sta COLUPF
 lda (tile1),y
 ora (tile2),y
 sta PF1
 lda (tile3),y
 ora (tile4),y
 sta PF2
 lda (tile5),y
 ora (tile6),y
 sta PF2
 lda (tile7),y
 ora (tile8),y
 sta PF1
 iny

That's without doing anything with sprites, any loop control, or anything. By my count that's 61 cycles already. Adding a player graphic will be another 5 cycles minimum (assuming you have separate copies of the code for every different player shape), so you're up to 66. Adding another sprite will add another 8 cycles--74. Since five of the cycles are only necessary on rows where the player is displayed, and you won't display the player twice in succession, you could afford a DEX/BNE to handle that, but the kernel as I described would be a massive hog of both code and RAM (eighteen bytes of RAM per line for all the zero-page pointers).

 

What am I missing?

 

If you had enough RAM to really afford a self-modifying kernel, you could free up nine cycles per line or even more, but on a bare 2600 you really don't.

[danwinslow]

Personally, I find it ludicrous that anyone would claim to be able to do an 'RPG' on a 2600, but what do I know.

[MayDay]

Personally, I find it ludicrous that anyone would claim to be able to do an 'RPG' on a 2600, but what do I know.

1023955[/snapback]

 

Personally, I find it ludicrous that anyone would claim we can't do an 'RPG' on a 2600, but what do I know.

[MayDay]

So two tiles per playfield byte, then.  If you're using an 18-line unrolled loop, that would look like each line would have, at minimum,

...

That's without doing anything with sprites, any loop control, or anything.  By my count that's 61 cycles already.  Adding a player graphic will be another 5 cycles minimum (assuming you have separate copies of the code for every different player shape), so you're up to 66.  Adding another sprite will add another 8 cycles--74.  Since five of the cycles are only necessary on rows where the player is displayed, and you won't display the player twice in succession, you could afford a DEX/BNE to handle that, but the kernel as I described would be a massive hog of both code and RAM (eighteen bytes of RAM per line for all the zero-page pointers).

 

What am I missing?

 

If you had enough RAM to really afford a self-modifying kernel, you could free up nine cycles per line or even more, but on a bare 2600 you really don't.

1023941[/snapback]

 

You're not missing anything... and clearly understand the challenge involved. And while brpocock can maybe give you more information on the travel kernel, the way I understood his description to me was that it would be self-modifying in a sense, but just not working very far ahead. Of course that's pretty much hearsay (and may have even changed since I last heard about it), but there are absolutely no free cycles to spare (and a few lines are still over). We have a couple of other things involved with it that I'm not sure you've taken into account either, but I'll let him tell you about it since it is his beast to tame.

 

-JD

 

EDIT- grammar was never my strong point...

Edited February 25, 2006 by MayDay

[danwinslow]

Personally, I find it ludicrous that anyone would claim to be able to do an 'RPG' on a 2600, but what do I know.

1023955[/snapback]

 

Personally, I find it ludicrous that anyone would claim we can't do an 'RPG' on a 2600, but what do I know.

1024038[/snapback]

 

I wasn't trying to be insulting, just truthful. I tell you what...when I see it I will officially 'eat' my words.

[MayDay]

I wasn't trying to be insulting, just truthful. I tell you what...when I see it I will officially 'eat' my words.

1024232[/snapback]

 

Have you seen Paul Slocum's Homestar RPG demo? Anyone who has seen that and doesn't think a 2600 RPG isn't possible... well, just please check a little into something before you say it can't be done next time. I always appreciate feedback, but reacted the way I did because your comment was in no way constructive (or accurate). There won't be any need to eat your words, no hard feelings from this end, just be sure to check out the game when we're done.

 

-Jason

[danwinslow]

It was perhaps not constructive, but it was accurate, as thats really what I think. But actually I added 'what do I know' as a serious comment, not as a sarcastic tag line. I wasn't kidding; I really don't know much about the subject. I will check out the homestarrunner thingy. Thanks.

[ZylonBane]

Since you're so sure the 2600 can't do an RPG, you must have a very specific definition of "RPG" in mind. Care to share it?

[danwinslow]

No, I don't. You folks don't seem too friendly on the subject.

[ZylonBane]

Well that's certainly convenient for you.

[supercat]

And while brpocock can maybe give you more information on the travel kernel, the way I understood his description to me was that it would be self-modifying in a sense, but just not working very far ahead.  Of course that's pretty much hearsay (and may have even changed since I last heard about it), but there are absolutely no free cycles to spare (and a few lines are still over).  We have a couple of other things involved with it that I'm not sure you've taken into account either, but I'll let him tell you about it since it is his beast to tame.

1024042[/snapback]

 

Well, on the 2600, you either make your cycle counts or you don't. If you're hard up against a wall, you have to lose something. And I don't know what you want to lose. Maybe it's possible to eke out a cycle somewhere; I offered Andrew Davies a spot to save a couple cycles in notBD, though since the kernel was done and working by that point he didn't need it; if you'd like me to look at the code I could see what I could suggest.

 

My RPG kernel requires extra memory (present version works with SuperCharger) but allows tile-level scrolling and actually has some cycles left over (though I don't really have anything more to do with them since I already get five players, six misisles, the playfield, and the Ball all were I want them). I'm not really interested in designing a full-fledged RPG, but I'd like to see someone make one that could take advantage of the 4A50 platform.

[MayDay]

Well, on the 2600, you either make your cycle counts or you don't.  If you're hard up against a wall, you have to lose something.  And I don't know what you want to lose.  Maybe it's possible to eke out a cycle somewhere; I offered Andrew Davies a spot to save a couple cycles in notBD, though since the kernel was done and working by that point he didn't need it; if you'd like me to look at the code I could see what I could suggest.

1024628[/snapback]

 

This is very kind of you, and the offer is highly appreciated. I think he's still playing around with it, and isn't down to the "I must have two cycles on line x" thing yet. Since it is his kernel though, I'm going to defer the use of any outside help to him. And, for the record, as I recall you did some fine work back when you were dealing with "notBD".

 

-JD

[supercat]

And, for the record, as I recall you did some fine work back when you were dealing with "notBD".

1025562[/snapback]

 

I offered a way to save a couple cycles, but as noted it wasn't needed. The only homebrew game I'm aware of which has any of my directly-contributed code is Hunchy 2 (I contributed the ending).