Jump to content
atari2600land

Castle of Doom

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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)?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Edited by atari2600land

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

 [url=http://pastebin.com/BgQHBN0q]new_castle14new.bas[/url]

 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

 [url=http://pastebin.com/g8J0Q6hi]new_castle14new_3.bas[/url]




  Edited by bogax

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 
 [url=http://pastebin.com/35uTpXW6]new_castle14new_4.bas[/url]

 

Edited by bogax

Share this post


Link to post
Share on other sites

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.


 [url=http://pastebin.com/rNqKQkwh]new_castle17new.bas[/url]

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites


 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

 [url=http://pastebin.com/GRSnUWLS]new_castle17new_3.bas[/url]





 

Edited by bogax

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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...