Deimos Lander

[jbanes]

You may want to make one more tweak of this. For one thing, I see a way for players to cheat by avoiding the screen by hopping above the obstacles. This is true in level 5 for instance. I didn't play level 5 enough to test that theory but it looks doable.

Nice catch! I wouldn't have considered trying that.

 

Looks like level 5 is the only example of this issue. I did some testing, and it looks like this isn't exploitable. I tried a few dozen times to make it work, and I always overshot or undershot the target. It seems that not seeing where you're going is a big problem for a span that large. So I'll leave it in as a challenge for players who like to struggle for secret shortcuts and such, but I'll keep it in mind when I do future level design.

 

BTW, congratulations on getting to level 5!

 

I'd say about 60% of the time I hit the pad at what I consider to be acceptable speed, but it said "TOO FAST"

Use the fuel gauge indicator at the bottom of the screen. I know it's one more thing to keep track of, but it will be green when you're going slow enough, red when you're going too fast. As long as you keep track of it with the corner of your eye, you should be able to judge your speed fairly well.

 

as long as you don't have one lander foot colliding with non-pad, (like if it's hanging off the edge or something) then let it count.

That's how it works today. You can have the very edge of the craft hanging off, but if you have a lander foot off, you crash. Here's a screenshot:

 

 

Thanks for your comments Mos. I think we're good to go.

Edited July 10, 2006 by jbanes

[cd-w]

This is a nice game, and fun to play - it is great to see what people are managing to do with bBasic now. I managed to get to level 5, but I think the difficulty level of the game is set a bit too high. It would be good to have a a beginners mode, where you have more fuel and/or the ship moves slower - also, I think a ship explosion effect is a must!

 

Chris

[vdub_bobby]

Also got to level 5. Very nice, polished game!

 

Agree that an explosion would be very cool.

[jbanes]

Agree that an explosion would be very cool.

Seems that this is a very popular request.

 

/me whips out notepad

 

"First feature in post-contest version should be massive, cool-looking, visceral explosions that make the player want to hide behind his couch."

 

Got it.

 

BTW, a tip for those of you on level 5. Go faster! Since you have only so much time to remain airborn, you need to tap the left direction a couple of times, then coast on an arc trajectory down the tunnel. When you are getting close to the bottom, use the fire button to thrust upwards. Give it enough thrust so that you pop above the left cliff just high enough to come back down on the pad. Use your remaining fuel to slow your descent onto the pad.

 

If this isn't making any sense, use the select button to go directly to level 7. (Remember, you need the latest version for this feature to work!) Once on level 7, try to land the craft with ONLY the fire button. It's pretty easy to do once you get the hang of it, and the skill might help you in levels 5, 6, and 8.

[Thomas Jentzsch]

An improvement suggestion:

When a level starts, often you have to press the right direction immediately or the you have no chance of success. Because a new level starts without a pause, this is somewhat annoying. Some kind of countdown or joystick input before the start would help here.

[jbanes]

Because a new level starts without a pause, this is somewhat annoying. Some kind of countdown or joystick input before the start would help here.

This should be in the post-contests* bankswitched version. There is actually a short pause before the game starts, but the lack of visual or audio feedback makes it difficult to extend for longer than a half-second or so.

 

I was originally trying to add a countdown, but I couldn't find a suitable method that would fit in the remaining space. (Using the score took the viewer's eyes away from the playfield.) I also considered checking the joystick, but that could put the player on an unintended course. Especially on level 7 where you have a rather high base velocity.

 

Just so you guys have an idea of how little space I have left, adding the check for the difficulty switch put me over. I had to go through and remove or rewrite every bit of redundant code I could find. It was barely enough to make it fit. Definitely time to figure out bankswitching.

 

* I've also submitted the game to the Minigame compo. I figured, as long as I've got a game in a completed state, why not?

[+atari2600land]

* I've also submitted the game to the Minigame compo. I figured, as long as I've got a game in a completed state, why not?

Because it and Rainbow Invaders will mop the floor with my stupid Ants game.

[Thomas Jentzsch]

I was originally trying to add a countdown, but I couldn't find a suitable method that would fit in the remaining space. (Using the score took the viewer's eyes away from the playfield.) I also considered checking the joystick, but that could put the player on an unintended course. Especially on level 7 where you have a rather high base velocity.

How about three beeps then?

[+batari]

* I've also submitted the game to the Minigame compo. I figured, as long as I've got a game in a completed state, why not?

Because it and Rainbow Invaders will mop the floor with my stupid Ants game.

I wouldn't worry about how well you think your game will do - the minigame compo is just for fun and to get constructive criticism for your work.

 

I might finish up my own invaders game, which is far worse than Rainbow Invaders.

[jbanes]

How about three beeps then?

Thought about that too. All I had space for was a for loop around "drawscreen". Doing three beeps would require cycling on and off the speaker. One "if" condition (maybe two if I cut some features) would kill me.

 

It sucks, but bBASIC isn't the most efficient on code. Or to put it another way, genericity has its price.

 

Don't worry. I'll get it into the bankswitched version.

[+batari]

How about three beeps then?

Thought about that too. All I had space for was a for loop around "drawscreen". Doing three beeps would require cycling on and off the speaker. One "if" condition (maybe two if I cut some features) would kill me.

 

It sucks, but bBASIC isn't the most efficient on code. Or to put it another way, genericity has its price.

True. Though bB does optimize a little. Combining multiple assignments in one line can sometimes save space. For example, the first will be shorter than the next two because bB attempts to remember register values:

(1)
 a=4:c=4:b=5

(2)
 a=4:b=5:c=4

(3)
 a=4
 b=5
 c=4

 

Also, I've started on a post-compilation code optimizer that can recover a little space from some programs. It might screw things up, so use at your own risk. To use it, modify your bB batch file and change the line "postprocess>%1.asm" to "postprocess|optimize>%1.asm"

 

EDIT: forgot to post the program.

optimize.zip

Edited July 10, 2006 by batari

[jbanes]

Also, I've started on a post-compilation code optimizer that can recover a little space from some programs. It might screw things up, so use at your own risk. To use it, modify your bB batch file and change the line "postprocess>%1.asm" to "postprocess|optimize>%1.asm"

Thanks for your help, Batari! Unfortunately, I didn't gain any space with the optimize program. While the diff program showed differences, a quick diff with the "ignore whitespace" and "ignore case" showed that there were no real differences in the assembly files. So either I've already squeezed all the optimizations out, or I'm bloody unlucky.

 

I'll take a look at rearranging the variables when I get a chance. I don't think I'll find much, but it's worth a shot.

[+batari]

Also, I've started on a post-compilation code optimizer that can recover a little space from some programs. It might screw things up, so use at your own risk. To use it, modify your bB batch file and change the line "postprocess>%1.asm" to "postprocess|optimize>%1.asm"

Thanks for your help, Batari! Unfortunately, I didn't gain any space with the optimize program. While the diff program showed differences, a quick diff with the "ignore whitespace" and "ignore case" showed that there were no real differences in the assembly files. So either I've already squeezed all the optimizations out, or I'm bloody unlucky.

 

I'll take a look at rearranging the variables when I get a chance. I don't think I'll find much, but it's worth a shot.

I took a look myself, and while the optomizer does appear to have optimized some code, it didn't save any space. I would guess this is because when graphics data might wrap a page, bB just inserts a bunch of zeros right now. So with optimization, it probably just inserts more zeros, but the end result is the same.

 

You might be able to free up some space by moving the player and pfcolors declarations around. Or not, as I looked in your source code and see that you found a page-wrapping bug with pfcolors and put in dummy code to compensate...

[jbanes]

You might be able to free up some space by moving the player and pfcolors declarations around. Or not, as I looked in your source code and see that you found a page-wrapping bug with pfcolors and put in dummy code to compensate...

Yeah, that area is kind of touchy at the moment. If I could do something about that portion of code, I could free up a bit of space. Unfortunately, there seems to be a bug that I don't fully understand yet. For some reason the code to test if the branch is within 128 bytes fails during assembly. It appears to chose the code that branches 128 bytes when the branch is actually out of range. Or so it would seem. It's hard to tell.

 

I haven't reported it yet because I haven't figured out if it's a bBASIC problem or a DASM issue.

[+batari]

You might be able to free up some space by moving the player and pfcolors declarations around. Or not, as I looked in your source code and see that you found a page-wrapping bug with pfcolors and put in dummy code to compensate...

Yeah, that area is kind of touchy at the moment. If I could do something about that portion of code, I could free up a bit of space. Unfortunately, there seems to be a bug that I don't fully understand yet. For some reason the code to test if the branch is within 128 bytes fails during assembly. It appears to chose the code that branches 128 bytes when the branch is actually out of range. Or so it would seem. It's hard to tell.

 

I haven't reported it yet because I haven't figured out if it's a bBASIC problem or a DASM issue.

IIRC, the 6502 can branch between -128 and +127 bytes (or is it -127 to +128?) It's possible I got this one backwards and it's trying to branch exactly 128 bytes one way when the real limit is 127.

 

If you have an .asm file that exhibits the problem, can you send it to me?

[jbanes]

IIRC, the 6502 can branch between -128 and +127 bytes (or is it -127 to +128?) It's possible I got this one backwards and it's trying to branch exactly 128 bytes one way when the real limit is 127.

It's -128/+127. (At least, that's what the docs I have say.) It doesn't matter, though, because DASM complains of -129. Here's the output:

DASM V2.20.10, Macro Assembler (C)1988-2004
lander.bas.asm (1817): error: Branch out of range (-129 bytes).
lander.bas.asm (1866): error: Branch out of range (-129 bytes).
  bytes of ROM space left
Unrecoverable error(s) in pass, aborting assembly!
Complete.

 

If you have an .asm file that exhibits the problem, can you send it to me?

Certainly. REMming out line 2040 plus the three lines below it produces the output you see above. Here's the BAS and ASM files:

 

lander.baslander.bas.asm.txt

 

Let me know if I can be of any assistence.

[+batari]

IIRC, the 6502 can branch between -128 and +127 bytes (or is it -127 to +128?) It's possible I got this one backwards and it's trying to branch exactly 128 bytes one way when the real limit is 127.

It's -128/+127. (At least, that's what the docs I have say.) It doesn't matter, though, because DASM complains of -129. Here's the output:

DASM V2.20.10, Macro Assembler (C)1988-2004
lander.bas.asm (1817): error: Branch out of range (-129 bytes).
lander.bas.asm (1866): error: Branch out of range (-129 bytes).
  bytes of ROM space left
Unrecoverable error(s) in pass, aborting assembly!
Complete.

 

If you have an .asm file that exhibits the problem, can you send it to me?

Certainly. REMming out line 2040 plus the three lines below it produces the output you see above. Here's the BAS and ASM files:

 

lander.baslander.bas.asm.txt

 

Let me know if I can be of any assistence.

I see the problem. I calculated the branch target distance from the beginning of the branch instruction instead of the end. For now, you can avoid the problem by changing the offending lines to "then goto" which will always put in code for a "long" branch.

 

Frankly, I'm surprised that this hasn't come up yet, as the bug has been there since the beginning!

[jbanes]

I see the problem. I calculated the branch target distance from the beginning of the branch instruction instead of the end. For now, you can avoid the problem by changing the offending lines to "then goto" which will always put in code for a "long" branch.

Well, that works for getting rid of those extra IF statements. Thanks!

 

Unfortunately, there's another problem right behind it. If the PFColors section is deleted right after line 2050, there are tons and tons of Label Mismatch errors. It appears that the errors start on bBASIC line 580 (1616 when assembled), then pretty much encompass every label after that.

 

Frankly, I'm surprised that this hasn't come up yet, as the bug has been there since the beginning!

Indeed. Perhaps most coders naturally use "goto" instead of smart branching?

 

Edit: Here are the files:

 

lander.baslander.bas.asm.txt

Edited July 12, 2006 by jbanes

[+batari]

I see the problem. I calculated the branch target distance from the beginning of the branch instruction instead of the end. For now, you can avoid the problem by changing the offending lines to "then goto" which will always put in code for a "long" branch.

Well, that works for getting rid of those extra IF statements. Thanks!

 

Unfortunately, there's another problem right behind it. If the PFColors section is deleted right after line 2050, there are tons and tons of Label Mismatch errors. It appears that the errors start on bBASIC line 580 (1616 when assembled), then pretty much encompass every label after that.

Check to see if the assembly was successful anyway. I've run into this issue, and often the errors are bogus. Based on my research, it is caused when DASM guesses that labels point to absolute addresses, but in later passes they are resolved to zero page, which causes the whole binary to shift by a few bytes, and suddenly some other labels don't jibe. Or something like that.

 

There seems to be no way to eliminate the bogus errors, so I'm tempted to hack in a new command-line option to DASM to not show them unless assembly actually fails.

[jbanes]

Check to see if the assembly was successful anyway. I've run into this issue, and often the errors are bogus.

Sadly, no. The file only assembles to 1,534 bytes. From what you're saying, though, it sounds like it's a DASM problem. (Not too surprising.)

 

Thankfully, it's not that big of a deal. Being able to move the PFColors would save me some space, but not such a tremendous amount that I can't live without it. The 4K version is "done" for now. I'm on to the bankswitched version.

 

On another topic, I did up a label for the game:

 

 

I even printed one up to see what it would look like on a cart:

 

 

Note that the PNG label above isn't a version for printing. It's lacking the extra print area. If anyone is interested in the complete image, I can provide that. (Not sure what you'd do with it... ) I also have a GIMP template for making labels if anyone is interested. I can't open the PSD files that 8bitclassics posted (which is actually the first time I've ever seen GIMP not able to handle a Photoshop file!), so I had to reverse engineer a template from the JPG he posted.

[+thegoldenband]

Regarding the difficulty level, for future builds -- for what it's worth, I just had a session of Deimos Lander in which I managed to beat every level on the first try, except for Level 5 which took me 2 attempts.

 

However, (a) I was having an unusually good run, and (b) if in the future you make this into a larger-scale game, with a scoring system and/or some form of level-to-level inheritance, then this level of difficulty -- i.e. tricky, but it can be mastered -- could actually work really well.

 

(I still think there should be a final, super-tricky level!)

[jbanes]

Regarding the difficulty level, for future builds -- for what it's worth, I just had a session of Deimos Lander in which I managed to beat every level on the first try, except for Level 5 which took me 2 attempts.

Awesome! I tend to do pretty similar runs at this point. I've never made it through all the levels without a death, but I've come within one crash of it.

 

However, (a) I was having an unusually good run, and (b) if in the future you make this into a larger-scale game, with a scoring system and/or some form of level-to-level inheritance, then this level of difficulty -- i.e. tricky, but it can be mastered -- could actually work really well.

I think so too. I think I'll probably add a lives system, but give the player a generous number. That way he won't feel quite as frustrated as, say, Thrust when his meger 3 lives run out.

 

I still think there should be a final, super-tricky level!)

Believe it or not, level 8 was supposed to be a super-tricky level! Unfortunately, nearly everyone proved to be a bit more skilled at this game than I had anticipated.

 

BTW, no one has commented on the new font. Do you like it, or do you think it's not very readable?

[jbanes]

I don't want to give away too much yet, but I've been plugging away pretty hard at this lately. Expect to see some pretty neat stuff in the near future.

 

 

16K and still chugging!

[SeaGtGruff]

Awesome pics, is it an all-bB game, or an assembly game? Just wondering about the computer printout screens...

 

MR

[jbanes]

Awesome pics, is it an all-bB game, or an assembly game? Just wondering about the computer printout screens...

As you surmised, it's a combination. The printout screens, for example, are handled via a modification to the 6 character score routine. (Each screenful of text is rather costly in terms of ROM space, but I think you will find that it adds to the gameplay immensely.) There are several other ASM thunks I'm developing, including a scrolling screen for selecting from a list of in-game options. Once the gameplay is down, I'm also hoping to add SaveKey support so that players can Load their games from the last level they completed.