Anyone familiar with Adventure code?

[Sacred Will]

Hi all,

 

I recently posted something in Atari 2600 Hacks. I was hoping to get some help with an Adventure hack I'm working on. I'm a noob so i'm having a hell of a time trying to figure out this code. Going through the forums for the past couple months and a few tutorials here, I have learned quite a bit but I still have a long way to go. Any help would be greatly appreciated, or if you're just an Adventure fan check out what I have done so far. Let me know what you think.

 

http://atariage.com/forums/topic/227598-need-help-with-my-adventure-hack/

Edited July 13, 2014 by Sacred Will

[+Gemintronic]

It sounds like what you want to do has gone beyond a simple hack. If you're serious about keeping it a hack then you might check out SpiceWares new series on creating a simple 2k game: http://atariage.com/forums/topic/227629-tutorial-for-developing-a-game-from-scratch/

 

More work but a less steep learning curve would be to make your own engine in batari BASIC: http://atariage.com/forums/forum/65-batari-basic/

[+SvOlli]

If you dig through the archives here, there's a Windows based editor for Adventure which lets you modify quite a lot in cases of graphics and layouts.

[+Atarius Maximus]

Ha, yeah, that windows based editor is my old "Create your own adventure" tool. I wrote that about 10 years ago as an easy way to make extensive changes to the map, colors, sprites,and item locations in the original game, but you can't add any new features to the game with it.

 

I've talked to Sacred Will and what he's doing is definitely a pure assembly hack and would require some expert help to make the changes he's trying to make. I'm going to take a look too but I think it's a bit beyond my skill level. Take a look at what he's already done, it is pretty cool. He's already added extra objects to the code and I really like his idea. It's definitely worthy of some help if someone has the time.

[Nukey Shay]

Object states: each of the 4 fragments could use a state table that has all 4 shapes listed (1/4,1/2,3/4,complete). Each fragment then uses the same byte of ram to determine which state it's in (1/4 at game start for each of them). When 2 objects collide, check if they are both a "fragment" object, and then (this is important) if one is held by the player. If so, increase the state byte and send both objects into hyperspace (just assign an invalid room number to them). The game engine will automatically correct the room number of the fragment object held by the player. When you want to know if the object has been fully assembled, just examine the state.

[Sacred Will]

Thanks Nukey, I somewhat understand what you're saying but i'd have a hell of a time trying to write the code for this. I'm such a noob.

[Nukey Shay]

Nevermind, that won't work under certain circumstances. Somebody could potentially join 2 quarter pieces, and then drop it and join the other 2 quarter pieces (locking out the final quarter if the 2 halves are joined). It would be better to break it down fully...so that each quarter object has it's own state variable in ram - each one using a specific bit position in the state variable. So that when pieces are colliding, the state variables are merged instead of just being increased. Piece1 has a starting state value of %1, piece2 starts with %10, piece3 has %100, and piece4 has %1000. If piece1 hits piece4, the state would become %1001. That's altogether 15 individual states that need bitmaps...1 bitmap per combination. 4 bytes of ram needed for states, and 12 more for the room/x/y of each (16 bytes of ram total). How much did you have unused in your WIP?

[Sacred Will]

This is what I'm using with the pieces added:

;object variables...

SurroundR = $B1 ;(3 bytes)

DotR = $B4 ;(3 bytes)

;all dragons must be consecutive

RDragonR = $B7 ;(5 bytes)

YDragonR = $BC ;(5 bytes)

GDragonR = $C1 ;(5 bytes)

MagnetR = $C6 ;(3 bytes)

SwordR = $C9 ;(3 bytes)

ChaliseR = $CC ;(3 bytes)

BridgeR = $CF ;(3 bytes)

;all keys must be consecutive

YKeyR = $D2 ;(3 bytes)

WKeyR = $D5 ;(3 bytes)

BKeyR = $D8 ;(3 bytes)

RKeyR = $DB ;(3 bytes)

AKeyR = $DE ;(3 bytes)

;Amulet Pieces

Piece1R = $E1 ;(3 bytes)

Piece2R = $E4 ;(3 bytes)

Piece3R = $E7 ;(3 bytes)

Piece4R = $EA ;(3 bytes)

Piece5R = $ED ;(3 bytes)

Piece6R = $F0 ;(3 bytes)

;all gates must be consecutive

YGateR = $F3

WGateR = $F4

BGateR = $F5

RGateR = $F6

AGateR = $F7

;------------------------------------------------------------------------------------

;Ram locations E5-FA free (F9/FA -might- be used by the stack if JSR's nested further)

;------------------------------------------------------------------------------------

[Nukey Shay]

I thought you only had 4 amulet pieces to join? But the above method will work if the castle gate routine is altered so all of their states are combined into a single byte of ram (this is present in the most-recent 16/32 version...so it can be cut'n'pasted from there). The bad news is that you'd end up with 63 bitmap variations for the 6-section amulet...which might not work at all.

[Nukey Shay]

BTW you are still allocating 3 bytes for the Surround object, but your thread mentions not using it.

[Sacred Will]

Object states: each of the 4 fragments could use a state table that has all 4 shapes listed (1/4,1/2,3/4,complete). Each fragment then uses the same byte of ram to determine which state it's in (1/4 at game start for each of them). When 2 objects collide, check if they are both a "fragment" object, and then (this is important) if one is held by the player. If so, increase the state byte and send both objects into hyperspace (just assign an invalid room number to them). The game engine will automatically correct the room number of the fragment object held by the player. When you want to know if the object has been fully assembled, just examine the state.

I actually like this idea here even though there is the possibility of someone making the mistake of joining the other two pieces separately. That's just something i'd have to put in the instructions; to make sure not to do that or you will not be able to win the game.

 

I have 6 different pieces: Each of the four 1/4 pieces is an individual object (I want them to look different) then the 1/2 piece, then the 3/4 piece = 6 The completed piece is actually a key that uses a different bitmap than the other keys.

 

What I was thinking was at the start of the game, the 1/2 piece, the 3/4 piece and the completed piece would be assigned to an invalid room (inaccessible) and when you collide a 1/4 piece with another 1/4 piece they would both be replaced (exchanged) with the 1/2 piece. Collide another 1/4 piece with the 1/2 piece and they will be replaced (exchanged) with the 3/4 piece etc. Just wish I could figure out the code to make it work.

 

I decided I'm still going to use the Surround in a secret room when I make some changes.

 

Check out the three rooms just below the Yellow Castle.

 

 

beyond.bin

 

Beyond.asm

[Sacred Will]

Object states: each of the 4 fragments could use a state table that has all 4 shapes listed (1/4,1/2,3/4,complete). Each fragment then uses the same byte of ram to determine which state it's in (1/4 at game start for each of them). When 2 objects collide, check if they are both a "fragment" object, and then (this is important) if one is held by the player. If so, increase the state byte and send both objects into hyperspace (just assign an invalid room number to them). The game engine will automatically correct the room number of the fragment object held by the player. When you want to know if the object has been fully assembled, just examine the state.

Hey Nukey Shay, can you show me how to put together a "state table"?

[Nukey Shay]

Follow the rules in the Objects table. The first word (2 bytes) defines which address an objects base information is held at (room#, hpos, vpos). For anything movable, this would be the 1st ram address used for that object. The next word sets the address of where an object's state can be found. If this is anything that changes shape, you'd need to use a ram address. The 3rd word points to an object's rom list of states. As an object's state variable changes, the program compares the value to the ones in this list...and uses the corresponding bitmap address from the list. Take a look at RDragonData, for example. The DragonStates data table it points to holds the 4 states a dragon can be in and the bitmap to use: 0=roaming, 1=dead, 2=eaten player, and the last state value listed should be $FF so the program knows where the data table ends (in this case, the biting dragon bitmap).

[Nukey Shay]

To do the amulet, you only need 4 objects (not 6 + a key), and a state variable for each. Each of the 4 quarter pieces should point to it's own state variable in the Objects table, and a list of states in rom that has the 15 combinations listed:

 

AmuletStates:
 .byte %0001, {bitmap address of 1st quarter}
 .byte %0010, {bitmap address of 2nd quarter}
 .byte %0011, {bitmap 1st + 2nd quarters}
 .byte %0100, {bitmap address of 3rd quarter}
 .byte %0101, {bitmap 1st + 3rd quarters}
 .byte %0110, {bitmap 2nd + 3rd quarters}
 .byte %0111, {bitmap 1st + 2nd + 3rd quarters}
 .byte %1000, {bitmap address of 4th quarter}
 .byte %1001, {etc...}
 .byte %1010, {etc...}
 .byte %1011, {etc...}
 .byte %1100, {etc...}
 .byte %1101, {etc...}
 .byte %1110, {etc...}
 .byte $FF, {amulet key bitmap}

 

In the Game1Objects and Game2Objects data tables, assign the values 1, 2, 4, and 8 as the starting state values for the 4 pieces.

 

In the Objects data table, assign the size value of 8 to the amulet pieces (bit 3 is ignored by the register, but this will be an easy way to check if 2 amulet pieces touch).

 

A subroutine can then update the state of the carried object and banish the other one out of the game:

 

 

Check_Amulet:
       BIT    CXPPMM              ;Get Player00-Player01
       BPL    Nothing_Hit         ;If nothing, Branch
       LDX    CurrentObject+2     ;
       LDY.wy CurrentObject+3     ;
       LDA    Store8,X            ;
       AND    Store8,Y            ;
       CMP    #$08                ;2 amulet pieces hit?
       BNE    Nothing_Hit         ;No
       CPX    CarriedObject       ;Carried by player
       BEQ    Amulet_Carried      ;Yes
       CPY.wy CarriedObject       ;Carried by player
       BNE    Nothing_Hit         ;No
       LDX    CurrentObject+3     ;Switch the order
       LDY.wy CurrentObject+2     ;
Amulet_Carried:
       LDA    Store1,Y            ;Get and store
       STA    ObjAddress          ; the vector of
       LDA    Store2,Y            ; the object
       STA    ObjAddress+1        ; not carried
       LDA    Store1,X            ;
       STA    CurrentObject       ;Do the same
       LDA    Store2,X            ; for the
       STA    CurrentObject+1     ; carried object
       LDY    #$03                ;
       LDA    (CurrentObject),Y   ;Get the state
       ORA    (ObjAddress),Y      ;merge with the other
       STA    (CurrentObject),Y   ;Update State of carried object
       LDY    #$00                ;
       LDA    #$7F                ;Set invalid room #
       STA    (ObjAddress),Y      ;And store to other object
Nothing_Hit:
       RTS                        ;end

 

Then all that is left is to alter the portcullis subroutine to recognize a completed amulet as a key. If this becomes too troublesome, you could check the state value after it was updated to see if it is equal to $0F...and manually assign a separate key as the carried object.

[Nukey Shay]

Added more code to the Portals subroutine (the first pass handles the amulet gate and opens for a completed one...so make sure it's always last on the list if you add castles).

 

Removed the amulet key and the other 2 pieces...and you'll see where the states for each piece is set up.

 

I didn't add or subtract any bitmaps...so combining 2 sets of pieces results in the same half-amulet bitmap for both (when combining them separately). Joining any 3 pieces also results in the same 3/4 image. You may choose to expand the number of bitmaps if you want them to look different for each of the 15 states. I added tags for each variation.

 

Too much cycle time was being spent outside of the display...resulting in a screen jitter on some screens (taking an amulet to the black castle, for example). So I corrected this problem as well.

 

NOTE:

You really ought to be using a newer assembly file. There's still many optimizations (saving both time and ram) that are not present in this older one. But here ya go...

Beyond.asm

[Sacred Will]

Thanks Nukey!!! You are AWESOME!!! It's so cool to see my idea working just the way i envisioned. You were right, your way is definitely better than the way i was thinking. I tested it every way imaginable and it's perfect. Just need to do a few more things and I will upload the final version soon. Your help with this is very much appreciated

[Nukey Shay]

BTW it's possible to "repurpose" the remaining 3 pieces (particularly since you can't gain entrance to that area without a completed amulet in the first place). Just change the key's state to $0F in the state table and add more states below it...then add some instructions to put them in that area instead of "banishing" them. You'd need to tweak the stuff I wrote so they couldn't be joined to the completed amulet, tho. Something else you might want to add is sound effects for joining amulet pieces. #'s 0 thru 5 are already in use, but you could add more.