My only real suggestion for improvement: Sometimes it can get a little hectic trying to manage your anti-gravity ball, dodge enemies by jumping and positioning oneself correctly to punch other ones. Maybe simplify the anti-matter weapon since that takes the most concentration as one always has to consider if the projectile is still moving, stopped or returning.

Yeah, probably would help a bit to remove the returning portion and have it fade out over time. 

When I get to the stage as shown in the attached screenshot, I can leave my character and she never loses any lives or energy despite being hit by the laser bombs. :)

The bombs fade out shortly after they're fired, so hopefully you're just at the perfect distance for them to disappear right before hitting you.

I thought I was done, but was hit with a compilation error at literally the last minute, so that's that I guess. I can reuse some of the code elsewhere, at least.

You know the Hi Lo Number Guessing Game where you keep guessing until you guess a secret number between 1 and 100.

Could you tell if the game had no secret number? Can you create such a game?

A correct answer would be generated by high/low responses regardless of whether it was chosen before the game started, and reaching that value is exactly where players would be able to tell no such number existed.

So the goal of such a program would be to keep track of previous guesses and responses and give false information for as long as possible without getting caught. Basically looking for an opportunity to tell the player that 31 is low, after it already said 30 is high, without the player noticing.

It's doable, but probably needs to be based on a more complex game in order to really pull it off.

Something like a Rubix Cube that shuffles squares around when  you aren't looking.

Cloning seems like it would work extremely well with creating expansion packs for older games. I played a few roms that were hacked to do something similar, but that obviously provides a lot less freedom on the development end than reverse engineering the entire engine.

With IMP, 0 always turns a bit on and 1 always leaves it alone, so it works kind of like a bit mask where you can turn on a set of bits without effecting the rest:&B11101110 IMP X would be used to flip on the first and fifth bit in a byte, for instance.

so if a=1 and c=3 then, assuming they're unsigned bytes

c IMP a would equal 253. Only the second bit would be off.
Likewise a IMP c would equal 255, just flipping everything on

If you're not looking for those kinds of values,IMP won't help you form an association between a and c. You want to introduce some kind of unique change that you can then identify later.

Hoping to input a color which is then to imply a gender but I'm missing something.

This doesn't use IMP, but it does tag colors with gender values:



TYPE ColorType

    val AS INTEGER 'holds color value and gender tags
    title AS STRING 'name for the color

END TYPE

CONST Male = 1 'first bit
CONST Female = 2 'second bit

'A color with both bits off has no assignment, only the first bit is on is for males, only the second bit is on is for females, and both on would count as unisex

DIM Colors(10) AS ColorType

RESTORE colors
FOR i = 1 TO 10

    'since the first two bits are used to identify sex, the base color values are multiples of 4; then a random sex assignment value is added to them

    Colors(i).val = (4 * i) + INT(RND * 4)
    READ Colors(i).title

    PRINT "Color #";i; " is "; Colors(i).title; ", a color for "; GetGender$(Colors(i).val); " as can be seen by the color assignment value which is "; Colors(i).val MOD 4

NEXT i




colors:

DATA "RED","GREEN","BLUE","PURPLE","ORANGE","BROWN","BLACK","HEART","ATTACK","JACK"



FUNCTION GetGender$ (v)


    IF v AND Male THEN m = 1
    IF v AND Female THEN f = 2

    'v MOD 4 would have worked too, but only because everything in this example program is neatly arranged with multiples of 4.

    SELECT CASE m + f

        CASE 0

            GetGender$ = "which there are currently no assignments"

        CASE 1

            GetGender$ = "males!"

        CASE 2

            GetGender$ = "females!"

        CASE 3

            GetGender$ = "everyone!"



    END SELECT


END FUNCTION




Qbasic had a solid development community. The "this was made in Qbasic!?" you heard with Black Annex was the exact same thing you heard with games made almost 20 years before that. Some people think modern systems allow for Qbasic to be able to muscle its way through games that would have been impossible in the past, but the reality is that older games were all made at lower resolutions with less color using less RAM, so no one would have run into any walls trying to make similar games back then. I think the big limits in Qbasic were file size and native RAM limitations rather than the language itself holding people back, but libraries that removed a lot of the limitations were available.

The biggest lesson for me in developing games was how simple the basic design for them could be.And of course, the design had to be simple because hundreds of games were being released every year, but the fact that the complexity of my favorite shooter might have just been the same as a version of Pong where your paddle shoots balls that blow up other paddles was a revelation. Something like Final Fight uses the same basic system, but you have an animation play before the collision detection, and instead of making the other character disappear, you check their state and play the appropriate response animation. That's it. Under the hood, a substantial portion of 2D action game catalog can be reduced to Pong ports.

if you can move an object around on the screen, tell when it touches another object, and make something happen as a result, you've created a basic core engine for 2D action games


Because of that, I think Fellipe's Particle simulation is actually a perfect introduction to game design and how simple it actually is. Ignoring all of the design theory and game loops and all that for a moment; Fellipe created, in a few minutes, a program that put objects on the screen, moved them around, had them react to each other and respond to player input. How much time would it take to fully gamify that?

You could base the game around protecting some vital cell from attack by surrounding the invaders. The player can use the mouse to control a boss particle that sends commands to and tugs on the particles it connects to. You can create multiple types of particles that behave differently, increasing the strategic range; gain power ups for every enemy surrounded,etc.   You can spend 3 days optimizing it all to a Game Jam level of quality. You can spend months working on graphics, sound and interfaces to create a polished indie game, or spice it up for a year with a full fledged story mode and completely overhauled graphics engine.

But the majority of the work on the game itself would have been done on that first day of putting together the basic system. Everything that follows is just deciding what to do with the game you've already created. A lot of the QB64 games in text mode or using simple line art simply aren't devoting a lot of energy to dressing the games up in obvious ways.

h~& is being blended with black when you draw the box, so you end up with a different color.  You'd have to calculate what the new color is in order to clear it properly, and POINT is perfectly up to the job.