Robot Robbery released!

[Zack]

Yay! I finished the game. More levels, Keith.

[KeithKosh]

WoW! I didn't expect to get so many replies! lol...it'd prolly be too much work to say a little blurb about what each one of you has said, and you know how much I hate work, so, I'll skip that Instead, I'll comment on a select few.

- Yea, the tile by tile scrolling is terrible. BUT, I didn't want to go with screen-by-screen, because then Jeff wouldn't be able to go UP in the levels like he currently does. And yea, pixel by pixel is theoriteically possible in QB 1.1, but not as a full game. I've seen demos, and they just run real slow, besides being only half the screen.

- More levels! Well then! I ran out of memory actually with the code I have, so I didn't want to add any more levels, because If i did, I'd want to put in a cinema. And cinemas are coded right from the BAS file (bad idea), so I didn't have room for that. Oh, well. I probably COULD make a custom level and upload it seperately, but they are a lot of work. I'm in college now and, yea, again with the work thing

- I prolly should have used a parabolic (sp) jump routine. Oh, well, the jumping isn't THAT bad...I notice more how he falls so slow

BTW, there's also the (included) level editor. The interface is terrible, terrible, terrible, but one can almost get used to it. If any of you guys make levels, I could put them up on the page. I guess you'd have to be pretty obsessed with the game to do that, though. But meh, it's there, who knows, maybe someday...

Thanks so much for all the compliments tho! :bounce: You guys rock!

Keith

[relsoft]

P*P scrolling is very much possible in Qbasic. No libs not even QB LIB.

Wanna see it?

[Mango]

Keith...nice game. I think you can skirt the memory issues (and get your code to be compilible) easily.

Your program is in one 'module'.

If you break it into multiple modules, it can be bigger.

To do this, load robotrob.bas into the QB4.5 editor. Then goto filecreate file and make sure 'module' is selected. You need to give the module a name...for example "CharMove". This will create an empty file called "CharMove.bas". Now, from the 'view subs' menu you can 'move' the SUBS 'CharMoveHorz' and 'CharMoveVert' into the newly created MODULE 'CharMove.bas".

Then do a 'SaveAll' Now...your program robotrob is broken into 2 modules. the "Main Module" is Robotrob.bas. CharMove.bas is a non main module. A new file, RobotRob.mak will now exist. It contains path information about where CharMove.bas resides. don't modify or move this file. When you move enough code so that no module is larger than 64 Kb, it should compile just fine.

A note about the auxillary modules. These are kinda wierd things. Only the subs contain any data...if you open the file charmove.bas, you will find that it contains nothing but the subs. You can now write code in the main module of charmove.bas to call and test the subs. However, this code will not affect how Robotrob.bas operates...it will *NEVER* be executed when charmove is loaded as an auxillary module.

EDIT: One more thing about these aux. modules...if you load up the main part of these with code, it will cause bloat in your compiled code...so...when you use old subs in a new program by "loading" an old program into your new program, make sure you save the whole project in it's own directory...This way you can strip the loaded non-main modules of unused code...without screwing up the original program that you are now using as an aux. module...If you don't understand what I'm talking about, I'll try to make it more clear.



I hope this helps. Cheers

[citpes]

Now someone wasnt pating attention! It done in Qb1.1 Mango....

[Mango]

Actually...he said that he was unable to get the code to compile...so...I took that to imply that he has access to 4.5 or 7.1. Anyway...adding more modules would require minimal additional effort...and I thought he may be unaware of how they work...

cheers.