Fort Apocalypse

One more thing... the selection (1 or 2) at the beginning is for # of players. The second player plays as the elusive "dot" from the first Adventure, except that the players can see the dot. However, the dragon and eye cannot see the dot player, which makes him good for sneak attacks. The player and dot must leave the room at the same time (so no one gets left behind). The hardest parts about this game are: * Finding the cross (I may actually hide the cross in a random location in the next version). * Not getting stuck in an enemy castle/dungeon. * Shooting the wand in the desired direction. The easiest parts are: * Killing the dragons and eyes (who would have known killing a dragon would be so darn simple? ) I may hide the staff later on or make them faster to make this harder. In a future version there may be baby dragons, and possibly an large elephant (by request). Anyway... definitely looking for suggestions, so please let me know what you like, don't like, and if you can look at the code and make any suggestions, that would be way totally awesome.

Ok, since the game changed a bit from my original plan here is the description: * There is a cross somewhere south or just southwest of the blue castle (starting castle). The quest is to find the cross and bring it back to the castle. If so you win (you currently get killed when you win. If I can fit a win sequence in, I'll definitely add that later). * The black stick with the crook at the top (the staff) just outside of the castle lets you shoot. There is a bug with it that you can just shoot the missile and it stays (somewhat) stationary. If you can figure out what is wrong, let me know. * The wand (stick with big circle at top) lets you teleport. This is only useful currently to help you get out if you are trapped in an enemy castle (which will happen periodically and you have to turn it off/on to restart the game because I didn't have enough space left in 4k to reset. Will fix that eventually. * Dragon and eye will kill you if they attack you long enough. * If you're lucky or crafty you can walk through walls. It usually happens by accident for me. Whenever I've tried on purpose I have a hard time doing it. Walking through walls is a good way to get stuck in a dungeon. Let me know how it goes! Had to switch to non maze rooms for now to save space.

Wow! Man this is fun! I just played it a few times and I got through a few brown moving block screens and the rail car screen and got a key and a dot. I couldn't open the door with green walls and then I died in the rail car. Really good job! The monsters are way better looking than last time I played! I like the mosquito when it is really quick and bites you a lot. If you have any more room it might be neat to have a water scene where it is all blue background and you move slowly and there is a fish or octopus or something? It also might be neat to be in a room where shakescreen is always on and there are blocks quickly dropping from the ceiling (really quickly- faster than the slow moving brown block room). Great work!

Here it is! "Finished". Am too low on space to fit baby dragons in at the moment, but if you can help me find space, I'll add them in as well as ability to reset the game and a better win reward (currently you get death) 2padv0.5.bas2padv0.5.bas.bin

You need to place includes before anything else. Particularly, if you put them after the "set" directive, they might be ignored. Hmmm.... Maybe I should have the compiler generate a warning instead? Thanks! That was definitely it. Yes, it would be great to have a compiler warning if it's not too hard. The more compilation warnings the better, IMO.

0.4 release For one or two players. Dragon and Eye are enabled and attack and can kill you. You can kill them with the staff. Rooms make sense (somewhat) and there is somewhat of a map. Two castles. No point to game yet except to kill dragons and floating eyes with staff. What do you think? All ideas are welcome! 2padv0.4.bas2padv0.4.bas.bin 2padv0.4.bas.asm.txt

This is great! BTW - I love moon patrol! I'm not sure what a scrolling/jumping shooter would look like with this, but it would be interesting for sure. I think that having things run at you from the sides and having to jump over them, or having to jump from platform to platform and retrieve something would be cool. This reminds me a little tiny bit of Dark Castle (because of the bats and the cave). Boy Dark Castle would be neat to bring to the 2600. I just played it and had these thoughts: * I also experienced the deal with not being able to shoot the bat when it was too close, but it wasn't a big deal (In real life if a huge bat were that close, I'd be a little distracted and have a harder time shooting it, but some may make the opposite argument that it would be easier to shoot.) * When I wasn't using the shield and touched a bat I thought I'd die, but I didn't. It might be better to die and have a life counter instead of health? * If the bats either dropped their bombs when they were closer to you and if their bombs could drift toward the player, that would make it a little more difficult. * It might be better if the player could move just a little faster (but not much). * I think replacing some bats with more bats might be good. So something like if you kill a bat, more bats appear until you've killed like 20 bats. Having bats drop down from the ceiling would be cool.

0.3 released. slip through walls bug gone, wand makes you teleport, more rooms. no monsters yet. 2padv0.3.bas2padv0.3.bas.bin

Just curious if anyone is currently still working on this project at Atari, whatever it will be called. I'm guessing that it isn't dead yet, and I know we are in radio silence mode, but there was all that hubbub a couple of months back, and just want to make sure all is relatively ok and still on track for Spring 08 (even if there was a slip I won't complain).

Here's the full source 2padv0.3.bas

I've also tried including both in the top: include div_mul.asm include div_mul16.asm and then I get the error: ---------- Capture Output ---------- > "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\projects\fmadventure\2padv0.3.bas 2600 Basic compilation complete. DASM V2.20.07, Macro Assembler ©1988-2003 bytes of ROM space left --> cycle74_HMCLR f084 > Terminated with exit code 0.

Hey, I'm doing the following at the top of my bB game: include div_mul16.asm and then at one point I do this: handleroom temp6 = proom // 10 rem *** remainder (last digit) stored in temp1 if temp1 = 1 then gosub room1 if temp1 = 2 then gosub room2 if temp1 = 3 then gosub room3 if temp1 = 4 then gosub room1 if temp1 = 5 then gosub room2 if temp1 = 6 then gosub room3 if temp1 = 7 then gosub room1 if temp1 = 8 then gosub room2 if temp1 = 9 then gosub room3 if temp1 = 0 then gosub room1 return when compiling I get the following error. Can anyone see what I'm doing wrong? I want to get the remainder of dividing proom by 10 in order to get the last digit of that number (for now it is just as proof of concept). ---------- Capture Output ---------- > "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\projects\fmadventure\2padv0.3.bas 2600 Basic compilation complete. DASM V2.20.07, Macro Assembler ©1988-2003 bytes of ROM space left --> cycle74_HMCLR f084 914 bytes of ROM space left 914 bytes of ROM space left 914 bytes of ROM space left --- Unresolved Symbol List div16 0000 ???? (R ) Fatal assembly error: Source is not resolvable. > Terminated with exit code 0.

Thanks, Robert! This is really good info!

From removing pfcolors I noticed that it appears that the following is occurring: * if pfres is 32 then rows 1-21 (0 based) are being skipped for assignment by pfcolors * if pfres is 31 then rows 1-20 (0 based) are being skipped for assignment by pfcolors * if pfres is 30 then rows 1-19 (0 based) are being skipped for assignment by pfcolors ... (skipped a bunch) * if pfres is 15 then rows 1-3 (0 based) are being skipped for assignment by pfcolors * if pfres is 14 then rows 1-2 (0 based) are being skipped for assignment by pfcolors * if pfres is 13 then row 1 (0 based) is being skipped for assignment by pfcolors So pfres 12 is the best you can get away with. You'll also want to fix the x, y limits on daffy since he loses his eyes if he overlaps to the left too much. Looks neat! I think if you wanted to you could get by without any AI and just have daffy pick up diamonds and have to watch out for traps (flying pies, etc.).

This is totally awesome! The collision detection is great and bat swooping!

Actually I think maybe I'm going over the gosub limit. Batari said on Random Terrain's page that only 6 bytes are there for the gosub stack. Update: Robert was right. If anyone ever gets a black screen during the game and can't figure it out, look for somewhere in the code where you are doing something like: if gamebits{0} then gosub handlep1 else chkexitp0 instead of if gamebits{0} then gosub handlep1 else gosub chkexitp0 (it was missing a gosub, so when it did a goto to that tag, it would return once more than necessary)

For the colors question look at this (under colors): http://www.randomterrain.com/atari-2600-me...c-commands.html To use curtis's minikernel put his file in the "includes" directory under your "bB" directory (the batari basic directory, not the directory with your code in it). In other words, unzip the playerscores.zip and put the .asm files into that dir. Then at the very end of your game's source file (game.bas) put these lines in: (indent them all by at least one space, don't use tabs for ident, because it messes up bB in version 1.0) rem should be last lines in game inline playerscores.asm inline bcd_math.asm (note: the bcd_math stuff just makes it easier to add to the score) Then up above in the code you'll want to initialize the score to 00 (although it should start as 00 anyway) for each player and set the scorecolor: player0score = $00 player1score = $00 player0scorecolor = 0 player1scorecolor = 222 then use the following code to add 1 to the score (example): player1score = addbcd(player1score, 1) : rem Adds 1 to player1score

For the colors question look at this (under colors): To use curtis's minikernel put his file in the "includes" directory under your "bB" directory (the batari basic directory, not the directory with your code in it). Then at the very end of your game's source file (game.bas) put these lines in: (indent them all by at least one space, don't use tabs for ident, because it messes up bB in version 1.0) rem should be last lines in game inline playerscores.asm inline bcd_math.asm (note: the bcd_math stuff just makes it easier to add to the score) Then up above in the code you'll want to initialize the score to 00 (although it should start as 00 anyway) for each player and set the scorecolor: player0score = $00 player1score = $00 player0scorecolor = 0 player1scorecolor = 222 then use the following code to add 1 to the score (example): player1score = addbcd(player1score, 1) : rem Adds 1 to player1score

Rob, Thanks!!! That is awesome info!

Can anyone see why the screen is going black after game is started? Also, I'm ready to jump into ASM land if it helps me debug this stuff myself. If you can light a candle for the darkness about how you would go about figuring this out step by step it would really be helpful to me and probably a lot of other bB programmers. Also I have noticed that the multisprite kernel is not very forgiving when it comes to compilation. A lot of times you have no idea there is an invalid param name or similar, like when I named a param pfroom instead of proom in a conditional - it didn't say anything during compilation indicating that it was a bad var name. Would be nice if that could be a little better in the next bB version if that is possible. Finally I know I've started up a number of threads on this already, but there is something wierd about playfield collisions both in standard kernel (as I noticed when rewriting sprites in Ultimate Indy 500 that basically made me frustrated enough to quit it for a while) and in the multisprite kernel (in the 2 player Adventure game I'm working on below). It would be really nice if someone at some point could take a look at those also and if those are bB bugs to maybe fix those in a future release also (odds are it is something I'm doing wrong, but I can't see what it could be so I'm leaning toward bB bug for both of those). TIA!!! 2padv0.3.bas2padv0.3.bas.bin

Probably just stating what you already know, but you will need to do something after the collision so they don't keep colliding. Something good to do might be to offset the x and/or y coordinate(s) of one or both of the players enough so that after a collision is registered, they will not keep colliding. Like Michael said, since you only have two players, the most efficient way of doing this easily in bB is via setting a bit in one of the params. If you are playing traditional tag then one or the other player is "it" and whenever there is a collision you could change who is it if you are defining the first bit in the variable a to be that flag by doing the following: a{0} = !a{0} That basically just flips the first bit of the variable a. Then you can check that bit and highlight the player to indicate which is "it" if you wanted like: if a{0} then (change player0 to light blue and player1 to dark red) else (change player0 to dark blue and player1 to light red) For collisions then you could do: if collision(player0,player1) then player0x = player0x - 5 : player1x = player1x + 5 : gosub handlepoints : a{0} = !a{0} and then define handlepoints like: handlepoints if a{0} then (add point for player0) else (add point for player1) return Later on you might want to take a look at the player scores minikernel by curtisp. That will let you show two two digit scores in the color of each player. Good luck!

Ok, I forgot there is no pfpixel in multisprite so no shovel for now. Two items both have actions now: * Wand of Izgborsh - widespread mayhem * Staff of Grobazz - shoots magical burst of energy Thought that would be more interesting than a gun, and slightly less violent No monsters yet... that will be next 2padv0.2.5.bas2padv0.2.5.bas.bin

Maybe on a different level might be to have the adventurer have to leap from "floating" island to island. If you did that maybe to fire (up) you would have to point up while you pressed the button. It could be a little like joust, except with the flying bats/demons and no ostriches or eggs. And you could propel yourself upwards with a shield. Just an idea.

Only suggestions so far would be to use a life counter for lives and health counter for the "shield left" (if you are doing this in bB). And some sort of big boss at the end that you have to keep hitting to kill it.

That looks awesome!!! MausBoy taught me you could use Alt-P and F12 to take screenshots when there is a little flicker just so everyone else can see a glimpse, but I recommend everyone taking a look!