Jump to content
IGNORED

Castle of Doom


atari2600land

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.

castle1.bas

castle1.bas.bin

  • Like 1
Link to comment
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.

castle10.bas.bin

post-9475-0-24498500-1378348341_thumb.png

Link to comment
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)?

Link to comment
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.

Link to comment
Share on other sites

  • 10 months later...

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.

castle1.bas.bin

castle1.bas

Link to comment
Share on other sites

  • 4 weeks later...

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?

castle14new.bas

Edited by atari2600land
Link to comment
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.

Link to comment
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.

castle14new.bas

castle14new.bas.bin

Link to comment
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)

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
Link to comment
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.

Link to comment
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.

 

 

new_castle14new_4.bas

 

 

Edited by bogax
Link to comment
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.

 

 

new_castle17new.bas

 

 

Link to comment
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
Link to comment
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.
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...