Deimos Lander

[jbanes]

Since my laptop was on the fritz this weekend (meaning I couldn't get any real work done), I decided to mess around with Batari BASIC a bit. It's a fun language, because with only a smidge of effort I am able to give you...

 

Deimos Lander

 

Story

 

In an attempt to colonize Mars, NASA has established a base on Mars' moon Deimos. You are one of the elite pilots selected for the dangerous mission of delivering crew and supplies to the new base. It may sound simple, but there's nothing simple about running out of fuel on final approach. Hit the landing pad at the right velocity, and you'll be remembered as a pioneer of a new generation. Hit the pad too fast or run out of fuel, and the only ones who will remember you are the obituaries that time forgot...

 

Gameplay

 

Press the reset button on your console to begin your approach. NASA has provided your craft with a mere 250 tonnes of fuel. It may sound like a lot, but it's barely enough for something the size of your lander. So use your thrusters sparingly!

 

To thrust upward, press the fire button on your controller. For lateral thrust, press the joystick left or right. Keep an eye on your fuel gauge. Not only will it help you budget your fuel, but it will inidicate if you're loosing altitude too fast. When you're at a safe landing velocity, the indicator will be green. When your velocity is too high, the indicator will be red. Use more vertcial thrust to slow your approach!

 

Screenshots

 

 

Author's Notes

 

Currently there's no sound, and the terrain is the same every game. These are things I will either fix in the future (if I have the time and energy; no promises) or you can feel free to fix yourself. I've attached both the binaries and source code, so you should be able to compile the code with any Batari BASIC 3.5 or higher installation. Feel free to learn from it and share your modifications on the AtariAge board, but please speak with me before you distribute it anywhere else.

 

I have not tested the game on a real 2600 as I lack the means to do so. If you have a CuttleCart or some other development environment, I'd love to hear if it works on a real console.

 

I hope you all enjoy the game!

 

Download

lander.bas

lander.bas.bin

[vdub_bobby]

Pretty good.

 

Needs some work/expansion to be a real game, but nice for a weekend's worth of effort.

[jbanes]

Pretty good.

Thanks!

 

Needs some work/expansion to be a real game, but nice for a weekend's worth of effort.

 

Indeed. It pretty much got one day of attention. I was really just looking to play around with Batari BASIC, and I honestly think the results were pretty good. I wouldn't have thought its little kernal would be so useful, but there you are.

If I have another day, I'll probably add in a terrain generator to liven up the game. Perhaps even some sort of levels ala Planet Lander. While I'm at it, I'll see if I can add some thrust sounds, and perhaps a few explosions and successful landing ditties.

[MausBoy]

It looks great, and the control is very precise and well done. For a first effort done in one day, it's definately making me wish you would keep going with bB. Don't forget that bB does scrolling really well, so you could add some longer levels with fuel pods if you wanted.

 

Is it ok if I rework your source and repost? Those pfpixel/line commands keep it from even compiling for me with the latest kernel, I get -26 bytes free. They need to be replaced with playfield: tables.

[jbanes]

Is it ok if I rework your source and repost? Those pfpixel/line commands keep it from even compiling for me with the latest kernel, I get -26 bytes free. They need to be replaced with playfield: tables.

Certainly. The current version is based on the latest "official" release of bB, 3.5. So, of course, it wasn't able to use features like PlayField: Tables. I thought about bit-packing the screens, but it was easier in the short-term to just rework the pfpixel plots a bit. (Generated by bBpf editor, as you've probably figured out already.)

 

Given the amount of wasted space, I suppose I'll either need to upgrade to the bleeding edge or bit-pack the data in the long term. The latter seems more likely at the moment, but feel free to work your own version.

 

It looks great, and the control is very precise and well done.

Did you have the opportunity to try it on a real console? I can nail the pad rather frequently with a keyboard, but I don't know how a real joystick would feel.

 

Don't forget that bB does scrolling really well, so you could add some longer levels with fuel pods if you wanted.

Perhaps. Personally, I'm more considering the idea of grafting in a custom scrolling kernel. Something more like this:PACMAN.BIN

[MausBoy]

I replaced the pf commands with tables, and added a little color.

 

 

I haven't had a chance to try it on my 2600 yet, sorry. I think the controls are pretty close to perfect though. There is no reason not to upgrade to the latest build, it looks a lot nicer and saves quite a bit of space. I like the scrolling demo you posted, but I can't really see what it has over bB's built in scrolling.

 

landerB.bin

landerB.bas

[Glenn Jupp]

I've just tried it on my 2600 (I love my KrocoCart) and it goes just fine with a regular joystick. I did notice one thing that you don't see on the emulators; the screen does a quick flip/roll when the playfield is being redefined. Since that's just at the beginning and end of the game, it's no big deal.

 

One suggestion I would make would be a little countdown between pressing reset and starting gameplay.

[+batari]

Is it ok if I rework your source and repost? Those pfpixel/line commands keep it from even compiling for me with the latest kernel, I get -26 bytes free. They need to be replaced with playfield: tables.

Certainly. The current version is based on the latest "official" release of bB, 3.5. So, of course, it wasn't able to use features like PlayField: Tables. I thought about bit-packing the screens, but it was easier in the short-term to just rework the pfpixel plots a bit. (Generated by bBpf editor, as you've probably figured out already.)

 

Given the amount of wasted space, I suppose I'll either need to upgrade to the bleeding edge or bit-pack the data in the long term. The latter seems more likely at the moment, but feel free to work your own version.

 

It looks great, and the control is very precise and well done.

Did you have the opportunity to try it on a real console? I can nail the pad rather frequently with a keyboard, but I don't know how a real joystick would feel.

 

Don't forget that bB does scrolling really well, so you could add some longer levels with fuel pods if you wanted.

Perhaps. Personally, I'm more considering the idea of grafting in a custom scrolling kernel. Something more like this:PACMAN.BIN

That's a great game for just a weekend of effort!

 

Putting in a custom kernel can be easy or hard depending on how you do things. As inline asm, it's a snap. As .asm modules in an includes file, it's a little harder but still doable. Fully integrated, it's really tough. I may write a kernel adaption guide at some point to explain how it's done, with an example of how a real kernel may be adapted.

[+batari]

I replaced the pf commands with tables, and added a little color.

 

 

I haven't had a chance to try it on my 2600 yet, sorry. I think the controls are pretty close to perfect though. There is no reason not to upgrade to the latest build, it looks a lot nicer and saves quite a bit of space. I like the scrolling demo you posted, but I can't really see what it has over bB's built in scrolling.

 

landerB.bin

landerB.bas

Looks nice - BTW, Mausboy is using a new build of bB, which is how he's able to suppress blank lines and add colorful playfields. These are some of the options that will be available soon.

 

Anyway, the PACMAN kernel appears to be full-width (40 pixels wide) while bB's is 32, but I suspect that the PACMAN kernel is reflected.

[jbanes]

I replaced the pf commands with tables, and added a little color.

 

 

Very nice! You've got a good eye for color. It looks like there's a LOT of great new features in the upcoming version. I can't wait until it's out!

 

(As a general rule, I never target an unreleased platform unless I'm intimately familiar with it.)

 

BTW, it looks like you've updated the code to allow for restart on fire button. Even with a delay, this doesn't work right. What you need is to use a flag that checks for when the fire button *isn't* pressed. Only after it isn't pressed should you accept the continue. There are still some problems with doing that, but it's better than nothing.

 

I like the scrolling demo you posted, but I can't really see what it has over bB's built in scrolling.

Unless the newer version has significantly updated playfield scrolling and rendering, the key is that it's smooth scrolling. i.e. A single line of pixels at a time. For something like Lunar Lander, this is really important. At least, it is in my opinion. Using the chunker playfield is perfectly acceptable on the 2600, but if I'm going to bother, I'd rather try for Thrust-type smoothness.

 

 

I've just tried it on my 2600 (I love my KrocoCart) and it goes just fine with a regular joystick. I did notice one thing that you don't see on the emulators; the screen does a quick flip/roll when the playfield is being redefined. Since that's just at the beginning and end of the game, it's no big deal.

I had a feeling that might happen. The playfield redef is kind of computationally intensive. I might look at adding a few drawscreens in there to smooth it out. I'm glad to hear that it has a good feel on a joystick. I was hoping I got it right, but the only way to be sure is to test, test, TEST!

 

One suggestion I would make would be a little countdown between pressing reset and starting gameplay.

Noted.

 

 

That's a great game for just a weekend of effort!

Thanks Batari!

 

Putting in a custom kernel can be easy or hard depending on how you do things. As inline asm, it's a snap. As .asm modules in an includes file, it's a little harder but still doable. Fully integrated, it's really tough.

From what I can tell in 3.5, there are two ways of doing it. Either I can write my own drawscreen function and call it something different, or I can hack out the old drawscreen/kernal jumps and replace it with my own.

 

Both seem like they'd be workable, but neither one is very appealing. Some of the APIs will need to change regardless. (Unless I decide to maintain backward compatibility.)

 

I may write a kernel adaption guide at some point to explain how it's done, with an example of how a real kernel may be adapted.

Actually, I was hoping I might convince you to create a kernal plugin mechanism. From what I see, the kernal you've written is great. It does some general purpose stuff that makes it easy for programmers to write games. But for more specialized games beyond what the default kernal is capable of, we either need to hack bBASIC, or keep bugging you for features. (Which makes your life more difficult as the kernal gets more complex.)

 

What I'm thinking you should do is extract the kernal-specific functions into their own files, then wrap up the kernal, functions, additional memory map, and intialization routines into a subdirectory. (Or a ZIP file, if you're willing to link against InfoZip.) Have the bBASIC engine default to a specific kernal, but allow it to be overridden by either a "set" option, or a command line parameter. The bBASIC engine would then look in the specified subdirectory (or ZIP file) for the correct plugin.

 

The advantages to this are numerous. A few off the top of my head:

• Both the multisprite and the monosprite kernals can co-exist.
  
• bBASIC users would be encouraged to dive into assembly by writing their own kernals (or hacking a custom version of yours).
  
• The community could get involved in improving bBASIC.
  
• A library of kernals could be tracked, allowing programmers to choose the one that best meets their needs.
  

It's food for thought, anyway.

 

Anyway, the PACMAN kernel appears to be full-width (40 pixels wide) while bB's is 32, but I suspect that the PACMAN kernel is reflected.

IIRC, I did code it to be reflected. However, at some point it wasn't (for reasons that I can't remember), so I know I can make the code workable both ways. With Pacman, there's not much reason not to reflect the playfield.

Edited June 20, 2006 by jbanes

[+batari]

Putting in a custom kernel can be easy or hard depending on how you do things. As inline asm, it's a snap. As .asm modules in an includes file, it's a little harder but still doable. Fully integrated, it's really tough.

From what I can tell in 3.5, there are two ways of doing it. Either I can write my own drawscreen function and call it something different, or I can hack out the old drawscreen/kernal jumps and replace it with my own.

 

Both seem like they'd be workable, but neither one is very appealing. Some of the APIs will need to change regardless. (Unless I decide to maintain backward compatibility.)

 

I may write a kernel adaption guide at some point to explain how it's done, with an example of how a real kernel may be adapted.

Actually, I was hoping I might convince you to create a kernal plugin mechanism. From what I see, the kernal you've written is great. It does some general purpose stuff that makes it easy for programmers to write games. But for more specialized games beyond what the default kernal is capable of, we either need to hack bBASIC, or keep bugging you for features. (Which makes your life more difficult as the kernal gets more complex.)

 

What I'm thinking you should do is extract the kernal-specific functions into their own files, then wrap up the kernal, functions, additional memory map, and intialization routines into a subdirectory. (Or a ZIP file, if you're willing to link against InfoZip.) Have the bBASIC engine default to a specific kernal, but allow it to be overridden by either a "set" option, or a command line parameter. The bBASIC engine would then look in the specified subdirectory (or ZIP file) for the correct plugin.

 

The advantages to this are numerous. A few off the top of my head:

• Both the multisprite and the monosprite kernals can co-exist.
  
• bBASIC users would be encouraged to dive into assembly by writing their own kernals (or hacking a custom version of yours).
  
• The community could get involved in improving bBASIC.
  
• A library of kernals could be tracked, allowing programmers to choose the one that best meets their needs.
  

It's food for thought, anyway.

Yeah, you can write your own drawscreen function or hack bB's existing kernel(s). I think the former is acceptable (see level 1 below), but the latter isn't necessary (see "includesfile" in docs for how to specify your own set of kernels/modules, such as described in level 2.) There is some irony here, in that the includesfile directive doesn't work properly in any released version of bB, though it does work now...

 

Here's something I wrote while back about adapting new kernels and the 3 levels of complexity:

 

Level 1: A kernel can simply be pasted in as inline asm. But this is the least efficient way to do it, and I only recommend it for simple kernels like title screens.

 

Level 2: More complex kernels (but those only capable of a limited number of games) should be modularized. That is add a few hooks so the bB code can access it directly, and make an includes file so you can simply specify to use the kernel as a line in bB and call it with drawscreen. Most likely you will need to specify equates for some fundamental bB variables (temp vars, a-z, maybe others I can't remember.) I should make a "kernel adapting guide" so others can do this without pulling out their hair.

 

Level 3: Full native support by modifying bB source code itself. It gives the highest level of functionality but is by far the hardest to do. Most likely, you'll have to wait for me to do this. And I'm unlikely to do it unless the kernel is capable of a wide variety of games.

 

I agree that I need some subdirectories, especially if you use includesfiles. It would make things a lot easier. I'm not sure about the Infozip thing - I'd rather just have a bunch of files in various subdirectories. I've just been too lazy to do this part, though others have shown how it can be done.

 

BTW: co-existing standard and multisprite kernels aren't possible yet because of some fairly simple logistics (like duplicate labels) so it's really just more laziness on my part.

[+atari2600land]

Maybe I just suck at this game, but every time I land on the pad it says "Too fast!" , and most of the time, I crash. Maybe if you kept the score to 0 (making whatever score represents infinite) it would be a lot easier. I did, however, find a semi-bug. If you reset and don't touch the joypad (keyboard keys on an emulator, like what I'm using), the ship falls to the right of the land and doesn't say Crash!

[jbanes]

Maybe I just suck at this game, but every time I land on the pad it says "Too fast!"

You have to touch down VERY slowly. Watch the fuel gauge. (The area used for the score in most games.) It's green when you're going slow enough, red when you're going to fast. Make sure you touch down with it green, or you'll get the "Too Fast!" message. Be extremely sparing about pressing the fire button, though. You only have about four seconds of thrust, so it's VERY easy to run out of fuel.

 

most of the time, I crash. Maybe if you kept the score to 0 (making whatever score represents infinite) it would be a lot easier.

That's not the score. It's your fuel. If it hits zero, you're going to crash.

 

I did, however, find a semi-bug. If you reset and don't touch the joypad (keyboard keys on an emulator, like what I'm using), the ship falls to the right of the land and doesn't say Crash!

Thanks for mentioning that. I found the bug a little while ago, but I haven't taken the time to fix it yet.

[Gateway]

YAY!

 

Can anybody can more than 15 fuel units left?

 

The second picture is interesting. It shows me on the pad with green fuel, but it says "CRASH!"

 

Keep up the good work on this game!

[MausBoy]

YAY!

 

Can anybody can more than 15 fuel units left?

 

The second picture is interesting. It shows me on the pad with green fuel, but it says "CRASH!"

 

You actually have to get both rocket jets on the pad or you haven't successfully landed. It is kind of addictive, and I haven't even gotten close to that score.

[jbanes]

Can anybody can more than 15 fuel units left?

My record is 69 fuel units.

 

Here's a tip: When you first start the game, crow hop to the left. (i.e. Thrust up and left quickly.) As you descend over the pad, kill your horizontal momentum, and come straight down. Fall until you're below the mountain, then hit the thrusters at full power. If you time it right, you'll nail the pad with gobs of fuel left. If you thrust too early, don't worry. You can use spurts of fuel to set it down gently.

 

The second picture is interesting. It shows me on the pad with green fuel, but it says "CRASH!"

As MausBoy said, you have to be square on the pad. You're about one pixel off, so I can see how you might be confused. Note that being off the pad is easily distinguishable by the "Crash!" message. Had you simply gone too fast, you would have received the "Too Fast!" message.

 

Keep up the good work on this game!

It is kind of addictive, and I haven't even gotten close to that score.

I'm glad you guys like it! I would have thought that everyone would have moved on by now. Of course, your modifications, MausBoy, probably helped with that.

[MausBoy]

I finally got a nice score, beat this!

[kirin jensen]

It's a nice li'l game. Took me little while to get a landing without a "you crash!" result.

 

If you redo this in assembly instead of bBasic, might I suggest you take a look at the Planet Lander homebrew for the O2? It's a pretty nice version of the concept.

Edited July 2, 2006 by kirin jensen

[jbanes]

I finally got a nice score, beat this!

That's going to be a little tough to follow up on.

 

It's a nice li'l game. Took me little while to get a landing without a "you crash!" result.

Thanks! Glad you like it.

 

If you redo this in assembly instead of bBasic, might I suggest you take a look at the Planet Lander homebrew for the O2? It's a pretty nice version of the concept.

Maybe I'm weird, but I love Lunar Lander games in general. Planet Lander is one of my favorites, especially since the random terrain keeps things fresh and interesting. Kudos to Mr. Foolery.

[jbanes]

New Version!

 

Extended Story

 

Darn that NASA, they just can't let a pilot enjoy his victory, can they? Nope, now they've tasked you to refuel and move supplies to all the new bases popping up on Deimos' surface. But watch out! Those pesky scientists think that setting up shop in "geologically interesting places" is a great way to go. Too bad you have to fly the ship that brings them in.

 

Don't screw this up pilot. NASA is counting on you!

 

 

Download

 

There are two versions of the software. The first one is in full color, but requires an unreleased version of bBASIC to compile. The second one uses the original color scheme, and merely requires the bleeding-edge .99b build from Batari's March blog entry. Both have exactly the same gameplay. If you didn't understand a word of that, just download the BIN under "color" and run it.

 

Color

 

lander.bas.bin

lander.bas

 

Monochrome

 

lander.bas.bin

lander.bas

 

Notes

 

I've still got a few tweaks to implement, but I think it's getting pretty close to a "real" game. I guess I'll know I'm there when I hear calls for cartridges.

 

I'm particularly interested to know if the game is hard enough. I know quite a few players struggled to get the ship on the ground in the last version. As far as I'm concerned, that's fine. Challenge is what keeps you coming back for more. As a result, I'm more concerned that the game may be too easy. I've been playing it so much that I can't tell if I'm winning because of my finely honed skills, or because I need to keep tweaking things. So give me a holler if you keep getting to the end.

 

To all you tweakers out there, I'm afraid that you'll need to upgrade to the bleeding edge. PFTables ended up being too tempting to pass up, and I feel pretty comfortable with the platform at this point.

 

Have fun! And send me a postcard when you land on Deimos, you hear?

Edited July 7, 2006 by jbanes

[jbanes]

Oh, I almost forgot. If anyone loads the new version up on their 2600, can they confirm that the roll/flip bug is fixed? Apparently it was doing this every time the screen changed. Thanks!

[Gateway]

The new version is definitely more fun!

 

I'm playing the color version on z26 using keyboard to control my ship.

 

The forum software doesn't seem to want to put my pics in the right order, but I've played up to base #6( the one that says "CRASH". I averaged about 5-6 tries per screen to succeed and I played for about 15 minutes. I would play longer but I have to go soon.

 

The game is challenging and fun, but I'd increase the difficulty a bit more if possible. Though I'm not sure what I'd suggest. Maybe and obstacle floating to by you have to avoid or something?

 

Don't change the fuel amount though, if you can help it! I found I needed almost every ounce of fuel to navigate a few of those caverns!

 

This is a great game so far! I'd encourage you to submit it ( when completed ) to mos6507's bBasic programming contest if it is not to late!

 

I'll play some more when I get some more free time. Gotta go now...

[jbanes]

The new version is definitely more fun!

Excellent! (*steeples finger*) I just love it when a plan comes together! BWHAHAHA!

 

The forum software doesn't seem to want to put my pics in the right order

Here's a secret for you: After you click on the "Add this Attachment" button, the image will show up in a list below your post. Next to it will be a button that says "Add in post". This puts a special tag in your post that makes it appear wherever the tag is. Hopefully that will be useful to you in the future.

 

The game is challenging and fun, but I'd increase the difficulty a bit more if possible. Though I'm not sure what I'd suggest. Maybe and obstacle floating to by you have to avoid or something?

Hmm... tricky. I don't have much space left (at least not without going to bank-switching, and I'm not quite ready for that), so I may not be able to do more than play with a few variables.

 

Don't change the fuel amount though, if you can help it! I found I needed almost every ounce of fuel to navigate a few of those caverns!

Especially if I can't change that. Or can I?

 

Wait until you get to level 7. I'm not sure if I'm allowed to have one (since I wrote the game), but it's my favorite.

 

This is a great game so far! I'd encourage you to submit it ( when completed ) to mos6507's bBasic programming contest if it is not to late!

MOS6507 just extended it a smidge, so that's why I'm throwing in this bit 'o polish. I was actually going to work on a bigger and better game when I got the time, but this is faster and is coming out quite well.

[+thegoldenband]

I managed to complete it, but I think the difficulty level is just right. I'm torn about whether the infinite lives issue is a good thing -- though I think the game would be too frustrating without it.

 

(Maybe there could be some sort of reward for completing a level without losing a life? A hidden level, or a special ending, or something?...)

[jbanes]

I managed to complete it, but I think the difficulty level is just right. I'm torn about whether the infinite lives issue is a good thing -- though I think the game would be too frustrating without it.

Actually, giving the player bunches of lives might make this a workable idea.

 

e.g. With 8 lives, players would have plenty of opportunity to play the game while still feeling the sting of defeat when they fail.

 

Thanks for the idea!

 

(Maybe there could be some sort of reward for completing a level without losing a life? A hidden level, or a special ending, or something?...)

This is a REALLY good idea. Unfortunately, it's going to have to wait until I move to bankswitching. Which won't be anytime in the near future.