Jump to content
IGNORED

2-player Adventure


batari

Recommended Posts

This is a detour from other projects. Anyway, it's just like Adventure with one new feature - the right joystick can control one of the dragons.

 

The game starts out normally. If you press the right joystick button once, the right joystick will take over control of Grundle. Press again and you take over Yorgle, again and you control Rhindle. Again and the game goes back to normal and the cycle repeats.

 

I wish more games let you play the bad guy :evil:

adv_2player.bin

Edited by batari
Link to comment
Share on other sites

This is a detour from other projects.  Anyway, it's just like Adventure with one new feature - the right joystick can control one of the dragons.

 

Sounds like fun!

 

The game starts out normally.  If you press the right joystick button once, the right joystick will take over control of Grundle.  Press again and you take over Yorgle, again and you control Rhindle.  Again and the game goes back to normal and the cycle repeats.

 

What, you can't control the bat, too?!? :D

 

I wish more games let you play the bad guy :evil:

 

What was that game where you got to play Godzilla or some other monster?

 

Michael Rideout

Link to comment
Share on other sites

What, you can't control the bat, too?!? :D

1024636[/snapback]

That would be fairly easy to change, but since you can only see what's going on when you're on the player's screen, your ability to steal things would be a little limited. Besides, it's more fun to eat the player than to swipe objects...

Link to comment
Share on other sites

So, the second player waits for a dragon to come on the screen, and then he can take control of it?

Basically, yes. You can control the dragons while offscreen too, but you can't see where they are going.

 

I think this game needs a two player linky option.

1024889[/snapback]

I may be leading up to that. I first need to figure out what data needs to be shared. Since the game relies on hardware collision registers, controller data is not enough. At the very least, one byte per frame?

 

Slave needs joystick, collision data and console switch data from master, and maybe other things.

Joystick=4 bits, button=1 bit, collision data=3 bits minimum (?)

 

Although all 8 bits seem to be used, the joystick only represents 9 of 16 possible states (if we assume up+down and/or left+right at the same time are prohibited) and console switches (select and reset) may override the joystick, so they could be encoded in.

 

Then master only needs joystick data from slave - 4 bits. Again, since there are available states here, a 0000 could be used to signal a NAK.

 

To begin games in the correct state, a reset occuring from screen zero (the number screen) could first jump to a special routine that syncs up all of RAM. Should be possible with a few moments of screen blanking.

 

I could be wrong - these are just ideas. Of course this all requires real hardware so the development time is much slower...

Link to comment
Share on other sites

I may be leading up to that.  I first need to figure out what data needs to be shared.  Since the game relies on hardware collision registers, controller data is not enough.  At the very least, one byte per frame?

1024963[/snapback]

 

Hardware collision registers should be entirely deterministic provided reasonable care is used in accessing them. If the game is synced at startup, controller data should be sufficient to keep it that way.

Link to comment
Share on other sites

I may be leading up to that.  I first need to figure out what data needs to be shared.  Since the game relies on hardware collision registers, controller data is not enough.  At the very least, one byte per frame?

1024963[/snapback]

 

Hardware collision registers should be entirely deterministic provided reasonable care is used in accessing them. If the game is synced at startup, controller data should be sufficient to keep it that way.

1025024[/snapback]

Only if the same screen is rendered on both systems. In the case of a networked Adventure, one screen would display the player's screen and one a dragon's screen, and so the registers could differ. The only hardware collisions that really matter are those on the player's screen, so sending those bits to the other system along with controller data should be enough.

Link to comment
Share on other sites

Only if the same screen is rendered on both systems.  In the case of a networked Adventure, one screen would display the player's screen and one a dragon's screen, and so the registers could differ.  The only hardware collisions that really matter are those on the player's screen, so sending those bits to the other system along with controller data should be enough.

1025046[/snapback]

 

(bonking head) Yeah, you're right. Since the dragon/bat don't use collision detection except in relation to the player (I would expect that the dragon can safely run into the sword when not on the player's screen?) one-way passing of collision information would probably suffice. Good thing, since I think the dragon player's screen would probably have to lag behind the other player's by a frame.

Link to comment
Share on other sites

  • 2 years later...
  • 3 weeks later...
Now if only this was in cartridge form...

We'll hopefully have the Chimera cartridge one of these days that just about everyone will be able to afford and you can throw this hack and more on a microSD card and play your brains out on a real Atari.

Link to comment
Share on other sites

  • 5 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...