+atari2600land Posted September 1, 2013 Share Posted September 1, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 1, 2013 Share Posted September 1, 2013 You might want to adapt the jumping code from a program like this: atariage.com/forums/topic/179473-fake-gravity-platformer-test/ Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted September 1, 2013 Author Share Posted September 1, 2013 I added two more levels. I think the jumping code timing going down might ruin the completability of levels 2 and 3. castle2.bas.bin Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted September 3, 2013 Author Share Posted September 3, 2013 (edited) I changed the code around. Here is level 4. castle4.bas.bin Edited September 3, 2013 by atari2600land Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted September 3, 2013 Author Share Posted September 3, 2013 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. castle7.bas.bin Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted September 4, 2013 Author Share Posted September 4, 2013 I made a change: You can only use a door if you're on the ground. I also added a new level. castle8a.bas.bin Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted September 5, 2013 Author Share Posted September 5, 2013 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 5, 2013 Share Posted September 5, 2013 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 5, 2013 Share Posted September 5, 2013 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)? Quote Link to comment Share on other sites More sharing options...
pacgreg Posted September 8, 2013 Share Posted September 8, 2013 Neat, and difficult, very difficult. almost inspires me to drop all the half done projects I have going now and make an IWBTG game. Quote Link to comment Share on other sites More sharing options...
RetroFiends Posted September 10, 2013 Share Posted September 10, 2013 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 3, 2014 Author Share Posted August 3, 2014 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 26, 2014 Author Share Posted August 26, 2014 (edited) 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 400y = x - 4 : if y < 4 then on y gosub 500 600 700 800y = 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 August 26, 2014 by atari2600land Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 26, 2014 Share Posted August 26, 2014 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 27, 2014 Author Share Posted August 27, 2014 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 27, 2014 Share Posted August 27, 2014 That release doesn't force your game to be 64k. Its just the last bB + many fixes + the new "set romsize 64k" Quote Link to comment Share on other sites More sharing options...
bogax Posted August 27, 2014 Share Posted August 27, 2014 (edited) You can put the labels in data statementswith 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 August 27, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 27, 2014 Author Share Posted August 27, 2014 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. Quote Link to comment Share on other sites More sharing options...
bogax Posted August 27, 2014 Share Posted August 27, 2014 (edited) 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 August 27, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 27, 2014 Author Share Posted August 27, 2014 OK, thanks again. I've added a few levels. Is level 20 too hard? It is beatable. If I did it, so can you. castle17new.bas.bin castle17new.bas Quote Link to comment Share on other sites More sharing options...
bogax Posted August 28, 2014 Share Posted August 28, 2014 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 28, 2014 Author Share Posted August 28, 2014 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. Quote Link to comment Share on other sites More sharing options...
bogax Posted August 28, 2014 Share Posted August 28, 2014 (edited) 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 August 28, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
bogax Posted August 29, 2014 Share Posted August 29, 2014 (edited) 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 August 29, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 30, 2014 Author Share Posted August 30, 2014 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.