Reventure -- a batari BASIC adventure

[SeaGtGruff]

Okay, here's the first version of my simple adventure game in batari BASIC. It's still very much in the early stages, so there isn't much to it yet.

 

Use joystick 1. The "instructions" (such as they are) are in the zip file, along with the batari BASIC code and the bin file. It's written for batari BASIC 0.2a; I tried to modify it for 0.3a, but it uses a lot of bit operations, and they aren't working yet in 0.3a. Once 0.35a is released, I'll start working on it some more.

 

Michael Rideout

Reventure.zip

[potatohead]

Okay, here's the first version of my simple adventure game in batari BASIC. It's still very much in the early stages, so there isn't much to it yet.

 

Use joystick 1. The "instructions" (such as they are) are in the zip file, along with the batari BASIC code and the bin file. It's written for batari BASIC 0.2a; I tried to modify it for 0.3a, but it uses a lot of bit operations, and they aren't working yet in 0.3a. Once 0.35a is released, I'll start working on it some more.

 

Michael Rideout

918272[/snapback]

 

Gave this a shot just now. I'm seeing a lot of flicker as if the game does not always have enough time to draw the frames, or the background color is always changing. Didn't get a chance to look too closely, but I see more than one drawscreen. (maybe it's just the colore and my monitor timing clashing. Ignoring that, I checked out the various rooms, avoided the monster and had some fun. Like the sprite shapes.

[+Random Terrain]

Yeah, it looks like the walls and doorways are being constantly redrawn instead of just once a every screen. Maybe that's causing the flicker?

[Thomas Jentzsch]

The scanline count isn't constant and PAL (not NTSC).

[SeaGtGruff]

Gave this a shot just now.  I'm seeing a lot of flicker as if the game does not always have enough time to draw the frames, or the background color is always changing.  Didn't get a chance to look too closely, but I see more than one drawscreen.  (maybe it's just the colore and my monitor timing clashing.  Ignoring that, I checked out the various rooms, avoided the monster and had some fun.  Like the sprite shapes.

918285[/snapback]

 

I don't see any flicker when I run it on my computer-- which is pretty old :-) -- but I wouldn't be surprised if the routines during the vertical blank are too long, since there's a lot going on. I'm going to have to start paying attention to the timing, but I figured I was still okay since I'm not seeing any flickering (maybe it's my version of Stella, coupled with the monitor speed, etc.?).

 

One thing I *have* noticed is that the speed of the player isn't always constant; sometimes you'll enter a room and zip through it a little faster than usual. I don't know why that is.

 

The multiple drawscreens are in different loops-- the main loop, the loop that shows the bomb exploding, and the loop that shows the tombstone-- so there's only one drawscreen being used at any one time, and no conflict between them (you're either in one loop or the other, although the bomb-exploding loop drops down into the tombstone loop after a bit).

 

Right now the only real fun you can have (for a "challenge") is to avoid the seeing eye as well as the monster, since once you pick up the seeing eye you'll be able to see the mines. So if you deliberately avoid picking up the seeing eye, you can run around and see if you can deliberately hit a mine-- which is sometimes hard to do, most likely because it's in the same room as the monster or the seeing eye.

 

My high score so far is only 27-- after which the monster popped up in the same room as the stairs, so I had no way to get back to the other level and keep looking for more gold! :-)

 

My plan is to alternate weapons and special objects on different levels, as follows:

 

Level 1 -- The player starts by being able to throw an unlimited number of rocks (since they're all over the floor of the maze; you don't even have to pick them up, they're just available to you), but there's a sling on the first level which enables the player to throw the rocks better (i.e., they fly faster and do more damage).

 

Level 2 -- There is no additional weapon, just the seeing eye that lets you see where the mines are.

 

Level 3 -- There is a dagger.

 

Level 4 -- Another special object (I haven't decided what; probably another kind of seeing eye).

 

Level 5 -- There is a sword (does more damage than the dagger, and has a little more range).

 

Level 6 -- A special object.

 

Level 7 -- There is a bow and arrows (with a limited supply of arrows).

 

Level 8 -- A special object.

 

Level 9 -- There is a quiver of arrows (with another limited supply of arrows).

 

Level 10 -- A special object.

 

Level 11 -- There is a crossbow and bolts (with a limited supply of bolts).

 

Level 12 -- A special object.

 

Level 13 -- There is a quiver of bolts (with another limited supply of bolts).

 

Level 14 -- A special object.

 

Level 15 -- There are grenades or throwable bombs (a limited number).

 

Level 16 -- Your father's bones are hidden here.

 

The weapons may change; for example, I might add a club or mace and take away the crossbow, or something like that. But I want some weapons to be good for distance fighting, and some to be good for close fighting.

 

I plan to make the fighting as easy as possible, meaning you don't have to choose your weapon. (After all, there's no "inventory strip"!) If you're far enough away from a monster, you'll throw a rock, use your sling, fire the bow, fire the crossbow, or throw a grenade, depending on whichever of those is available to you-- and you'll automatically use the most powerful one, until it's all used up, at which time you'll automatically switch to the next most powerful one. But if you aren't far enough away, then you'll use either the dagger or the sword (if you have either one), again using the more powerful one if you have it. And I'm thinking of not making the player "aim"-- the weapon will automatically fire (or be swung) in the general direction of the monster, maybe with the accuracy increasing with experience-- but I might change that, or have it depend on the skill level (i.e., the self-aiming weapons might be for beginners, whereas the harder skill setting would require the player to aim manually).

 

I'm also thinking about having locked doors blocking some exits, with matching keys that must be found, and some "secret doors" that are visible only if you're carrying a certain object-- but you can still stumble through them if you run into them. And as for the traps, I want some levels to have trapdoors that plunge the player to a deeper level-- possibly more than one level down-- with the amount of damage suffered depending on how far the player has fallen. And I'm also thinking about teleportation traps that whisk you off to another room or level-- possibly to a place that is monster-ridden, or that can't be escaped from unless you've got a special object. There will probably be different colored seeing eyes, with each one enabling the player to see a different kind of trap or hidden exit.

 

Right now the code is kind of funky, because I've had to program around some of batari BASIC's current (0.2a) bugs and lack of features. The limited number of variables (and ROM) is also a challenge, so I've tried to squeeze some things together, like using one byte for the gold's (and bomb's, and seeing eye's) room number, x position, and y position.

 

Once multiple player sprites get added, and especially once I migrate the game to assembly and bankswitching, I'll be able to do a lot more. For now, I'm avoiding using inline assembly code, because I want to see how far I can go with it using just batari BASIC. The current version of the game is actually not much more than a prototype to test batari BASIC.

 

Michael Rideout

[+batari]

The scanline count isn't constant and PAL (not NTSC).

918299[/snapback]

Sounds like the game is using too many cycles per frame.

 

Most likely, there are too many playfield drawing calls - these take a lot of cycles. These should be reduced in number or spread across more than one frame if possible.

[SeaGtGruff]

Yeah, it looks like the walls and doorways are being constantly redrawn instead of just once a every screen. Maybe that's causing the flicker?

918291[/snapback]

 

The scanline count isn't constant and PAL (not NTSC).

918299[/snapback]

 

Thanks for the feedback; I'll check into these possibilities. Since I'm not seeing any flickering, I thought it was all good as far as timing and such.

 

By the way, I'm using Stella version 1.3, because 1.4.1 and 1.4.2 either don't run on my Windows 95 computer (1.4.2: I'm missing a missing DLL that it needs?), or the screen display was really bad (1.4.1), so maybe that's the difference. Hmm, I'll have to try it on z26 and PCAE as well.

 

In the meantime, try it on Stella 1.3 and see if it looks any better!

 

Michael Rideout

[SeaGtGruff]

Sounds like the game is using too many cycles per frame.

 

Most likely, there are too many playfield drawing calls - these take a lot of cycles.  These should be reduced in number or spread across more than one frame if possible.

918305[/snapback]

 

There's only one drawscreen per loop, so I don't think it's the number of them, but I *do* use the pfvline, pfhline, and pfpixel to draw the room in every loop, so that must be the culprit-- coupled with all of the other logic, of course. I'll try splitting some of the tasks across alternate frames.

 

I might also be able to speed up the room-drawing by using inline assembly to set the playfield bytes.

 

Oddly enough, it isn't flickering in Stella 1.3, so I wasn't aware of the problem until tonight.

 

Michael Rideout

[+batari]

By the way, I'm using Stella version 1.3, because 1.4.1 and 1.4.2 either don't run on my Windows 95 computer (1.4.2: I'm missing a missing DLL that it needs?), or the screen display was really bad (1.4.1), so maybe that's the difference. Hmm, I'll have to try it on z26 and PCAE as well.

 

In the meantime, try it on Stella 1.3 and see if it looks any better! 

 

Michael Rideout

918308[/snapback]

On z26, you can use the -n parameter to see if the scanline count is constant and/or correct. bB 0.2a should give a steady and constant 259 lines. 0.3a does 260. 0.35 will have 262 (which is actually the "correct" number.)

[jjsonique]

There's only one drawscreen per loop, so I don't think it's the number of them, but I *do* use the pfvline, pfhline, and pfpixel to draw the room in every loop, so that must be the culprit-- coupled with all of the other logic, of course. I'll try splitting some of the tasks across alternate frames.

 

Yes, in my project, I found that doing a lot of playfield drawing every loop can induce flicker. To get this playfield --

-- flicker-free I had to split the drawing across two seperate frames.

 

Despite the flicker, your game's basic room layout/movement works well and seems a good basis for an adventure game. Good luck with this.

[SeaGtGruff]

Thanks, everyone, for the feedback and suggestions re the flickering. After I got off the internet last night (this morning), I tried it in z26 before falling into bed, and for what it's worth, z26 and Stella 1.3 both display the game without any flickering (at least on my system). I wonder what's different between them and the other versions of Stella? (Different graphics drivers???)

 

Anyway, this brings up a question about the various pf draw commands. Since the playfield bits/bytes are being stored in an array in RAM, does that mean I could just draw the playfield once, and then not worry about redrawing it until part of it changes (i.e., when the player goes from one room to another), in which case all I really need to do is draw the part that changed? I'm actually using that approach in my humongous M-Network bankswitched assembly game that I'm currently not working on-- I'm using the extra RAM to store the playfield data and player/missile data for the screen, somewhat similar to a screen map and p/m graphics memory area on the 800 or 5200. I hadn't even considered that I might not need to keep redrawing the playfield for each frame in batari BASIC. (D'oh!)

 

When I get home, I'll clean it up, add a rock-throwing routine, randomly select the level 1 maze from one of 30 different possible layouts, take the seeing eye off of level 1 (since it won't be available until level 2), add the sling to level 1, and then repost everything.

 

I'll be a happy camper when 0.35a gets released, since Reventure won't work in 0.3a, and I desparately need to be able to use more gosubs, multiplication and division by 16, and subtracting from the score!

 

And I'll see about posting some examples of other strange things I've seen, such as remarks that compiled anyway. And I don't know if anyone mentioned it yet, but on-goto is buggy (or was in 0.2a).

 

Michael Rideout

[+batari]

Anyway, this brings up a question about the various pf draw commands. Since the playfield bits/bytes are being stored in an array in RAM, does that mean I could just draw the playfield once, and then not worry about redrawing it until part of it changes (i.e., when the player goes from one room to another), in which case all I really need to do is draw the part that changed? I'm actually using that approach in my humongous M-Network bankswitched assembly game that I'm currently not working on-- I'm using the extra RAM to store the playfield data and player/missile data for the screen, somewhat similar to a screen map and p/m graphics memory area on the 800 or 5200. I hadn't even considered that I might not need to keep redrawing the playfield for each frame in batari BASIC. (D'oh!)

Yes, the playfield will stay the same until you change it.

And I'll see about posting some examples of other strange things I've seen, such as remarks that compiled anyway. And I don't know if anyone mentioned it yet, but on-goto is buggy (or was in 0.2a).

918737[/snapback]

The only change I made to on goto for 0.3 was allowing labels as well as linenumbers. Was this the problem you were having?

[Gregory DG]

Nice beginnings to the game! Reminds me of Secret Quest. Now just add some stuff in every room.

[jussts]

And I'm thinking of not making the player "aim"-- the weapon will automatically fire (or be swung) in the general direction of the monster, maybe with the accuracy increasing with experience-- but I might change that, or have it depend on the skill level (i.e., the self-aiming weapons might be for beginners, whereas the harder skill setting would require the player to aim manually).

918304[/snapback]

 

I like that idea... it'll actually make "experience points" count for something that makes sense. And the idea of an auto-aimed arrow going slightly off target, alerting a monster to your whereabouts has a bent appeal. I can't wait to see where this game goes.