Jump to content

Photo

Castle of Doom


64 replies to this topic

#1 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • 11,301 posts
  • Location:Salem, Oregon

Posted Sat Aug 31, 2013 11:16 PM

It has been years since I wanted to do a game like this, but didn't have the skills to do so. Every time I tried to do something like this, it just kept messing up. Even now when I tried to do this, I spent hours on it even though I tried to recycle some code from level 3 of Plim. So anyway, the point of the game is to get out of the castle. I don't know how many rooms will be in the castle yet. All I have now is room 1 which, when you get to the door, it loops because I haven't designed room 2 yet. The enemy is supposed to be a bat. I need a good sprite artist to draw a good bat. If you touch it, you'll restart the room, likewise if you fall down a pit. You'll have infinite lives because I think in the later rooms, I'd like it to get harder as the game progresses. So anyway, please download this and tell me if you see any bugs. To exit the door, press up when you reach it. Like I said, it just loops to the same room over and over again. Also, tell me what you think of the game.

Attached Files



#2 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,688 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Sep 1, 2013 2:35 AM

You might want to adapt the jumping code from a program like this:

 

atariage.com/forums/topic/179473-fake-gravity-platformer-test/



#3 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Sun Sep 1, 2013 3:38 PM

I added two more levels. I think the jumping code timing going down might ruin the completability of levels 2 and 3.

Attached Files



#4 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Mon Sep 2, 2013 7:21 PM

I changed the code around. Here is level 4.

 

Attached Files


Edited by atari2600land, Mon Sep 2, 2013 7:21 PM.


#5 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Tue Sep 3, 2013 2:58 PM

I added a few new levels. There are now 7 of them. I also changed the code around and made the game 8k so it can hold more room data. Gameplay is in bank 1 and room data is in bank 2. Let me know if you spot anything unusual.

Attached Files



#6 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Wed Sep 4, 2013 2:45 PM

I made a change: You can only use a door if you're on the ground. I also added a new level.

Attached Files



#7 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Wed Sep 4, 2013 8:32 PM

Like I said in my blog entry, I made a title screen for this game. I have a problem. The castle is not sitting on the ground. It "floats" one pixel above it. The ground is RevEng's score background trick. I'm just wondering if there was a way to make the castle sit on the ground or does it have to do this. (see picture.) I've also attached the latest binary.

Attached Thumbnails

  • castlets.png

Attached Files



#8 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,810 posts
  • Bitnik
  • Location:bottom of the stack

Posted Thu Sep 5, 2013 4:46 PM

It has to do this. The blank line is a result of bB taking some time off from drawing the display in order to prepare for drawing the score.

#9 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Thu Sep 5, 2013 5:05 PM

Like I said in my blog entry, I made a title screen for this game. I have a problem. The castle is not sitting on the ground. It "floats" one pixel above it. The ground is RevEng's score background trick. I'm just wondering if there was a way to make the castle sit on the ground or does it have to do this. (see picture.) I've also attached the latest binary.

 

If the castle is made up of the two players, can you extend the players for another line so they overlap the ground slightly (by 1 pixel)? Or if you can't do that, can you set the last (12th/"hidden") playfield row and then scroll the playfield up 1 line (pfscroll up)?



#10 pacgreg OFFLINE  

pacgreg

    Chopper Commander

  • 199 posts
  • Location:Florida

Posted Sat Sep 7, 2013 11:05 PM

Neat, and difficult, very difficult. almost inspires me to drop all the half done projects I have going now and make an IWBTG game.

#11 RetroFiends OFFLINE  

RetroFiends

    Chopper Commander

  • 166 posts

Posted Tue Sep 10, 2013 2:03 AM

I think with some refining you might have a nice game on your hands.
Some notes:
-The door or exit really ought to be more clear, somehow. There are many ways to tackle this. Perhaps a door sprite with 15 hz flicker on the door with priority 45 hz flicker on the sprites. Or, with playfield pixels create an arch with a hollow center instead of just a square.
-Although the game might be easier as a result, you might gain something from lowering the player's height a bit. The guy is all legs and his maneuverability doesn't reflect that. You'll also benefit from some simple animation. The biggest problem with him facing the screen is that you don't have an intuitive grasp of where his lower half actually is in conjunction with a jump left or right.
-Your gravity and jumping ability needs some work. In the real world, when you jump, you accelerate upwards at a remarkable speed against the force of gravity pushing you down. This means that your ascent is slowed down until gravity overpowers you and you start being pulled towards the earth again. In general, good platformers reflect this to a degree to give smooth and intuitive jump archs, even if they often ignore horizontal velocity.

#12 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Sun Aug 3, 2014 12:51 AM

I decided to rework this game from scratch and start all over again because I think I found a bug in the previous versions. I had to borrow some code from RT's maze demo and tweak it a lot to get this result. If you get to the door and press up, the game just starts over again. This is just a test room to see if everything works OK. Actual rooms will be more treacherous, with even bat enemies. Let me know if you find any bugs. Fire is for jumping and left and right moves the stickman left and right.

Attached Files



#13 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Tue Aug 26, 2014 3:52 PM

The info on RT's bB page is incorrect.

 

 

Too Many Labels

There seems to be a limit of around 45 labels on a single line when using on … gosub. If you have too many jumps to put comfortably in a single on … gosub statement, you can break it up into multiple on … gosub statements. Example:

if x < 4 then on x gosub 100 200 300 400
y = x - 4 : if y < 4 then on y gosub 500 600 700 800
y = x - 8 : if y < 4 then on y gosub 900 1000 1100 1200

 

 

 

I've tried countless things and all it seems to do is crash (instead of going to level 18). What am I doing wrong?

Attached Files


Edited by atari2600land, Tue Aug 26, 2014 3:59 PM.


#14 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,810 posts
  • Bitnik
  • Location:bottom of the stack

Posted Tue Aug 26, 2014 5:29 PM

IIRC, you can only approach that 45 limit if you use two letter labels. The whole limitation is a function of the line length and the number of substrings in a line, so if you start with if...then you're already limiting things based on the line length.

I gave a whack at expanding the limit in the last bB I released. Try that, or shorten your labels.

#15 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Tue Aug 26, 2014 6:45 PM

If I try that bB release, would my game have to be 64k? Because I don't want it to be. Anyway, I tried shortening my labels, and it still didn't work. I guess 45 is ok, since I probably can't fit 45 different rooms in anyway. Well, here is the latest release. I changed the "room #" font so it looks better. I also added room #18. To start at the beginning, press up+fire.

Attached Files



#16 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,810 posts
  • Bitnik
  • Location:bottom of the stack

Posted Tue Aug 26, 2014 7:01 PM

That release doesn't force your game to be 64k. Its just the last bB + many fixes + the new "set romsize 64k"

#17 bogax OFFLINE  

bogax

    Dragonstomper

  • 761 posts

Posted Wed Aug 27, 2014 12:36 AM

You can put the labels in data statements
with just a dash of asm.
This allows for 256 labels.
If you want on gosub just gosub on_x_goto

 gosub on_x_goto




on_x_goto
 temp1 = labels_lo[x] : temp2 = labels_hi[x]

 asm
 jmp (temp1)
end


 rem labels are 2 bytes
 rem < specifies the lo byte
 rem > specifies the hi byte
 rem bB prepends a . to the name so the actual label is .whatever_name_you_gave

 data labels_lo
 <.some_label, <.some_other_label, <.yet_another_label, <.more_labels_etc
end

 data labels_hi
 >.some_label, >.some_other_label, >.yet_another_label, >.more_labels_etc
end



some_label
  rem some code
  return

some_other_label
  rem some other code
  return


yet_another_label
  rem yet more code
  return

more_labels_etc
  rem even more code
  return


 I couldn't resist meddling with your
 code a little bit. (untested)

 new_castle14new.bas

 Edit:
 It occurs to me that there maybe
 an advantage to using your own
 data tables for the labels in this
 instance. You could leave the label
 data statments for the playfield
 selection (the c labels) in bank 1
 and just put the asm bit in bank 2
 and free up some space in bank2.

 Going to get_new_level would have
 just one jump into bank2 which would
 also free up some code 

 again, untested

 new_castle14new_3.bas




 

Edited by bogax, Wed Aug 27, 2014 1:24 PM.


#18 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Wed Aug 27, 2014 1:47 PM

Wow! Thank you very much. Instead of 1,100 bytes in bank 2, I now have 1,400 bytes. Looking through the code, though, I don't know why you put "return" at ae, ak, and ap. Other than that, I think I understand the new code. I knew there had to be a better way to do this, I just didn't know how. I just tested the new code, and it works OK.



#19 bogax OFFLINE  

bogax

    Dragonstomper

  • 761 posts

Posted Wed Aug 27, 2014 3:12 PM

Wow! Thank you very much. Instead of 1,100 bytes in bank 2, I now have 1,400 bytes. Looking through the code, though, I don't know why you put "return" at ae, ak, and ap. Other than that, I think I understand the new code. I knew there had to be a better way to do this, I just didn't know how. I just tested the new code, and it works OK.

 

 I get 1540 bytes free in bank 2 with
 new_castle14new_3.bas

 ae, ak, and ap and all the other
 empty labels above them that don't
 have returns still need returns

 I made them subroutines because
 a return is one byte and a goto
 is 3 bytes

 I left the empty labels in there as place
 holders just in case.

 With so many empty labels it might be just
 as well to change them back to gotos

 Since I was making an example of using
 the data staments for on gosub/goto
 I didn't try to put the few odd assignments
 that are left in individual routines
 in to eg data statments like the rest of
 the assignments. The data statements would
 be mostly empty.
 If you did you'd have mostly empty data
 statements for the player1x, player1y values
 instead of mostly useless data statements for
 the on goto (equvalent) I think it would be
 faster but number-of-bytes wise I think it
 would be about the same. So I left the empty
 labels/routines in case they have some (future) use.



 edit:
 here I got rid of the on gosub and put it all into
 data statements (except for an if for the one 
 assignment to player1y) frees another 104 bytes.

 
 new_castle14new_4.bas

 


Edited by bogax, Wed Aug 27, 2014 3:31 PM.


#20 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Wed Aug 27, 2014 4:33 PM

OK, thanks again. I've added a few levels. Is level 20 too hard? It is beatable. If I did it, so can you.

 

Attached Files



#21 bogax OFFLINE  

bogax

    Dragonstomper

  • 761 posts

Posted Thu Aug 28, 2014 12:07 AM

OK, thanks again. I've added a few levels. Is level 20 too hard? It is beatable. If I did it, so can you.

 

 

 I haven't made it past level 1 yet

 Here I did away with the on gotos
 altogether and put the playfield
 data in to a data statement and added
 a little more asm.

 The first playfield in bank 2 was
 12 lines is there a reason for that?
 I reduced it to 11 lines.

 I don't think any of the data statements
 are in line so you could save a few bytes
 by using the noinlinedata optimization.


 new_castle17new.bas

 



#22 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Thu Aug 28, 2014 12:45 AM

Thanks. But if I add a new level, I'd have to add 2 other consts, right? I'll fiddle around with it and see what I can do.



#23 bogax OFFLINE  

bogax

    Dragonstomper

  • 761 posts

Posted Thu Aug 28, 2014 1:15 AM

Thanks. But if I add a new level, I'd have to add 2 other consts, right? I'll fiddle around with it and see what I can do.

 Yes there's also an if statement in the
 get_new_level routine that traps r if it
 points one past the end and resets the
 level and score and goes to level_info
 (you had it jumping to aa originly)

 The data for the playfield has every other
 byte reversed.

 Probably the simplest thing would be to
 compile just a playfield statement then
 copy the data from the bB.asm file
 remove any extraneous stuff (asm .byte
 directives or such) and paste the data
 into the end of the playfield data statement
 (PF_dat in this case) (I used some javascript
 to pull it out of a piece of the .lst file)

 I think RT had a tool that would massage the
 data (reverse bytes and stuff) for you but
 I'm not sure.



 edit:
 The pfdatlo and pfdathi are just a
 look up table for level * 44 + PF_dat
 you could do that in code.
 It would probably use less ROM than
 the look up table (especially if you
 add more levels) but it would be a lot
 slower.
 The mutiply could be 8 bit * 8 bit with
 a 16 bit result.
 The addition would have to be 16 bit

 The 16 bit multiply in bB was bugged the
 last time I checked.

 


Edited by bogax, Thu Aug 28, 2014 2:37 PM.


#24 bogax OFFLINE  

bogax

    Dragonstomper

  • 761 posts

Posted Fri Aug 29, 2014 3:14 AM


 Here I've added a dedicated multiply by 44
 routine and removed the look up tables
 It will fail if level is more than 63

 new_castle17new_3.bas





 


Edited by bogax, Fri Aug 29, 2014 3:18 AM.


#25 atari2600land ONLINE  

atari2600land

    Channel F Viewer

  • Topic Starter
  • 11,301 posts
  • Location:Salem, Oregon

Posted Fri Aug 29, 2014 6:19 PM

Is there an easy way to make playfields the way you did in your code (0 and 1 instead of X and .) and make it look and be right?






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users