Jump to content
StupidBunny

My first homebrew WIP - Braqing Badd Balloon

Recommended Posts

Hi y'all¬†ūüĎč

 

So this is a project that, as the changelog shows, has been sitting in my work queue for a very long time, and like most projects I do has seen flurries of activity interspersed with long stretches of working on other things in my life.

 

I conceived this to be something very simple, what with it being my first Atari project and all (and, indeed, the first computer game of any sort that I've programmed from scratch and seen through to completion.)  The gameplay is similar to...I guess the dinosaur game in Chrome, complete with very primitive cacti, although there's a broader array of enemies with somewhat varied behaviors that come at you.  I don't envision the game to expand into much more than that.

 

Because this is my first serious game programming project of any sort I'm completely sure it's full of inefficiencies and tons of clumsy ugly messy bits that could be implemented a lot better, but it's at least playable in this state and I wanted to put it out here for you good folks to look over and offer some review and suggestions :)

 

HOW TO PLAY

 

Since there's no manual yet here's the Cliffnotes version of it.  Your goal is to jump over stuff.  At lower right is a timer: the longer you hold out, the better you do, there is no scoring besides that.  However if you manage to jump over 10 monsters in a row without dying then you are awarded an extra life.  If you die, then the streak resets.

 

BUTTON: jumps

FORWARD: hop/jump forward faster

BACK: hop/jump forward more slowly

UP: when jumping, makes you jump higher

DOWN: accelerates you downward when in mid-jump

 

If you turn on Speed Mode (set with difficulty switch 2) then the rules are the same with the addition of one more: there's a meter, which I'm calling the Doom Meter, under you, which you should always keep above 0.  The meter increases (good!) if you run forward, and decreases (bad!) if you don't; it decreases extra fast if you move slowly. In other words, move as fast as you can.  As soon as the meter hits 0, everything dies and the game ends.

 

Known bugs, and other things for possible implementation:

  • Delay, and maybe startup sound if I've got room, when game is initialized or restarted
  • ūüźě¬†Second lives reflects when monster is reflected (easy enough to fix, bar the space limitations I've run into)
  • ūüźě¬†Last line of player graphic appears on top of counter for some reason when player drops below ground level on downward acceleration
  • ūüźě¬†Get rid of that line under the purple worm's neck when it goes back into the ground
  • ūüźě¬†Ditto with the funny pixels appearing above the Eye
  • ūüźě¬†Sometimes when there are two munchers onscreen they both disappear at the same time when the first one runs off (EDIT:¬†I think I might have fixed this one, but we'll see)
  • Another really fun idea that I hope I have enough ROM for

 

UPDATES (older ones in spoiler box for viewing concision)

  • Spoiler

     

    • I've managed to recover some 60-70 bytes so far by using BRK to generate random numbers and by cleaning up a lot of redundant variable definitions.¬† Not an exciting update but it gives me a fair bit of room to do other cool things.¬† Also used delay to keep player from jumping each time the game is resumed.
    • I've got a simple but working lives counter in place onscreen.¬† I'll upload an updated version once I squish a few bugs and get it cleaned up a bit.
    • 11/18: The updated version is up.
    • 11/19: Have already saved a whole bunch of bytes by replacing some SLEEP macros with delay loops, and finding some redundant load/stores.¬† Gonna keep picking through...
    • Am trying out some new, slightly more animated graphics for the little running Muncher guy
    • 11/20: Have some flashing letters on the title screen!!! New animations for Muncher, not sure if they're any better.¬† Most fun of all, if you hold down while in the air the player goes down faster, offering a little more jump control (there is an occasional glitch with this that I'm still trying to iron out, but it doesn't seem to affect gameplay at all.)
    • Added button start from game over screen (turns out this was a dire necessity).¬† Reorganized some code and rejiggered the counter routines to save a whole bunch of bytes.¬† Edited leveling procedures to be more gradual and flexible.

     

     

  • 11/26: A major update.¬† Since there are a whole 46¬†bytes left free in the ROM it's probably the last major update too.
    • The majorest part of the update is that there is now a¬†Speed Mode¬†(which I might change the name of to something more fun, once I have written the game manual), which can be enabled with difficulty switch 2.¬† In this mode, there is a Doom Meter pictured beneath the player--let the meter drop to 0, and the game ends.¬† The only way to refill the meter is to run forward; regular speed won't cut it (and slow speed will drain it faster).
    • I found a sneaky bug in how the monster frames are loaded, which means that the problems of weird pixels appearing above/below the floating eye and purple worm things are no longer a problem, and also that monsters' vertical movements are a lot smoother now.
    • Leveling has been made a bit more gradual.
    • Accelerating downward now works while moving forward and backward, offering even more jump control.
    • The flash algorithm has been changed, making it a bit more subtle.
  • 11/28:¬†I fixed both of the remaining bugs I'm aware exist (and, in the process, finally figured out how that vertical delay register works! Seems like some fun could be had with that...)

 

LATEST:

BBB_20201128.zip


OLDER VERSIONS

Spoiler

 

11/26:

BBB_20201126.zip

 

11/20:

BBB_20201120.zip

 

11/18: 

BBB_20201118.zip

 

11/15:

BBB_20201115.zip


 

 

Edited by StupidBunny
  • Like 4

Share this post


Link to post
Share on other sites

Cool project.

 

Looked thru the code real quick and noticed your VSYNC code might cause issues:

 

Frame:      LDA #2
            STA VSYNC   ;start vertical sync
            
            STA WSYNC   ;three WSYNCs are needed for vertical sync
            STA WSYNC   ;here's the second WSYNC
            STA WSYNC   ;and 3 WSYNCs
            
            LDA #44
            STA TIM64T  ;Timer for vertical blank
                        ;EQUATION: scanlines = (timer * 64) / 76            
            LDA #0
            STA VSYNC   ;end vertical sync

You might want to add/or make sure a STA WSYNC occurs right before both of the STA VSYNCs to make sure it's turned on/off at the exact same time during the scanline.  This helps prevent sync/bounce issues on newer TVs.

Share this post


Link to post
Share on other sites

Alright, now to give some actual feedback on the game itself.

 

I like how you've setup the control scheme.  Left/Right - slow, fast... Up/Center/Down + Button = Jump Hi/Mid/Low.   That really adds a nice touch.  I kind of wish the controls had a bit more control over the player... but overall it works.  Definitely need to use a joystick for best results :)

 

I really like the level of detail the main player has and the bird animation is great.  The other enemies could do with a bit of work... but it looks like you're pretty tight on space at this point.

 

Great first project... Looking forward to seeing where you go from here.

Share this post


Link to post
Share on other sites

Thanks for the feedback splendidnut.

 

Yeah I haven't touched any of the animations in a good while, I can think of at least a couple of them that could be easily touched up without the overhead of new frames.  I wrote off doing color tables for the enemies a while ago but if I come up with some way of saving space elsewhere it's something else I'd consider.

 

I'm currently trying to rejigger the Random subroutine to be a BRK routine instead; I stand to save a small but useful number of bytes doing so, but need to study up a bit more on how BRK actually works since I'm getting glitches with the hoppy blue guy.  It's fun getting into the nuts and bolts of all the machine's inner workings, but I guess that's what VCS programming is.

 

 

Share this post


Link to post
Share on other sites

VSYNC code can be much smaller - look at the one in macro.h

The code looks fine - there are small savings here and there.

One I spotted that will be useful is incrementing/decrementing the high byte of a 16-bit value on addition/sutraction...

 

.SetPlrCol: LDA plrClrPtr
            SEC
            SBC plrYpos
            STA plrClrPtr
            LDA plrClrPtr+1
            SBC #0
            STA plrClrPtr+1
 

can be replaced by

 

.SetPlrCol: LDA plrClrPtr
            SEC
            SBC plrYpos
            STA plrClrPtr

            bcs .nocarry

            dec plrClrPtr+1

.nocarry
 

saving 2 bytes each time.

similarly, any 16-bit adds use. bcc/inc

IMHO your random routine is major overkill.  There are simpler ones that seem to do OK.
 

Another...  I'm just dumping randomly at the moment. 5am here and pottering...

 

            DEC hop             ;decrement hop distance (through negative)
            LDA hop
            CLC
            ADC #HOP_HEIGHT     ;when -HOP_HEIGHT + HOP_HEIGHT = 0
            BNE .Input          ;if not, skip to input testing
 

Couldn't that be...

 

    dec hop

    lda hop

    cmp #-HOP_HEIGHT

    bne Input

 

?

Edited by Andrew Davie
  • Thanks 1

Share this post


Link to post
Share on other sites

Lol I saw your post just as I was about to upload an updated version of the game and code.  I squeaked in a couple of your suggestions but will go hunting for other 16-bit adds/subs when I have time, which isn't right now.

 

I haven't touched the VSYNC section or the Random bit in the update (apart from making Random into a BRK sequence) but I may be able to shave off just enough that I'll have room to jazz up the title screen a bit.  There's also a couple of the playfield graphics that probably could be automated and don't need tables, I might be able to save a couple bytes that way too.

 

Thanks for the feedback, glad it looks fine at 5 AM anyway and let me know if you find anything glaring in there.

Share this post


Link to post
Share on other sites
4 hours ago, StupidBunny said:

Lol I saw your post just as I was about to upload an updated version of the game and code.  I squeaked in a couple of your suggestions but will go hunting for other 16-bit adds/subs when I have time, which isn't right now.

 

I haven't touched the VSYNC section or the Random bit in the update (apart from making Random into a BRK sequence) but I may be able to shave off just enough that I'll have room to jazz up the title screen a bit.  There's also a couple of the playfield graphics that probably could be automated and don't need tables, I might be able to save a couple bytes that way too.

 

Thanks for the feedback, glad it looks fine at 5 AM anyway and let me know if you find anything glaring in there.

I'm confident with some tweaking you could find about 100 bytes :)

 

Share this post


Link to post
Share on other sites
On 11/15/2020 at 11:45 AM, StupidBunny said:

11/18: The updated version is up.

It seems that the attachments are missing for both versions. Boths say "Unavailable".

Share this post


Link to post
Share on other sites
4 hours ago, vitoco said:

It seems that the attachments are missing for both versions. Boths say "Unavailable".

*grumble grumble*

 

The server didn't seem to be playing nice with me when I uploaded it last night.  It seems to have pulled itself together today, I've reuploaded both so you can try and give the most recent one a look.

  • Like 1

Share this post


Link to post
Share on other sites

ZeroPage Homebrew will be playing Braqing Badd Balloon on tomorrow's (Fri Nov 20) stream LIVE on Twitch at 6PM PT | 9PM ET | 2AM GMT! Hope everyone can watch!

 

Games:

 

113571525_20201120-LetsPlay.thumb.jpg.c640141a84746b48787ed7bb74e23b31.jpg

Edited by ZeroPage Homebrew

Share this post


Link to post
Share on other sites

I've posted another update.  With some of the extra bytes I found I made something resembling a real title screen.  I've also edited the control scheme slightly, so that now you can make the player return to the ground faster after jumping which offers a wee bit more control. @ZeroPage Homebrew I'm not sure if it's too late to use the updated version in the stream tonight but I suppose it doesn't make an enormous difference either way. ;) 

  • Like 1

Share this post


Link to post
Share on other sites
23 minutes ago, StupidBunny said:

I've posted another update.  With some of the extra bytes I found I made something resembling a real title screen.  I've also edited the control scheme slightly, so that now you can make the player return to the ground faster after jumping which offers a wee bit more control. @ZeroPage Homebrew I'm not sure if it's too late to use the updated version in the stream tonight but I suppose it doesn't make an enormous difference either way. ;) 

Not too late at all, thanks for the alert about the update! Hope you can make it to the chat on Twitch for questions that people have about your game, thanks for making it!

 

- James

Share this post


Link to post
Share on other sites
11 hours ago, ZeroPage Homebrew said:

Not too late at all, thanks for the alert about the update! Hope you can make it to the chat on Twitch for questions that people have about your game, thanks for making it!

 

- James

I will certainly if I'm still up, although that'll be starting 3 AM my time so we'll see how much of a grandpa I feel like I need to be tonight.  Either way I look forward to watching it!

 

By the way, I've reuploaded the game with a couple minor bugfixes.  I expect this'll be my last update for the night, there's not a whole lot left to do to the game to begin with bar stomping a couple small lingering bugs and general code optimization (which, if successful enough, might leave room for one or two little extra goodies but who knows.)

 

EDIT: @ZeroPage Homebrew sorry I couldn't hop in to the chat after all--as anticipated, I was asleep--but nonetheless thanks for giving the game a play! (And some other cool looking ones too of course.)  Definitely gave me some good notes for things to change and add moving forward.

Edited by StupidBunny
  • Like 1

Share this post


Link to post
Share on other sites
On 11/20/2020 at 2:40 PM, StupidBunny said:

EDIT: @ZeroPage Homebrew sorry I couldn't hop in to the chat after all--as anticipated, I was asleep--but nonetheless thanks for giving the game a play! (And some other cool looking ones too of course.)  Definitely gave me some good notes for things to change and add moving forward.

Super fun game @StupidBunny, thanks for making the game. It has great difficulty scaling as the levels progress and it's a lot of fun learning how to best deal with the different enemy types. I'm looking forward to playing it again on the show as development progresses.

 

- James

  • Thanks 1

Share this post


Link to post
Share on other sites

As noted at the top, I've posted another update, probably the last one before I call the game final since I'm running out of space and I'm resolute on keeping this below 4K.  There are a couple minor bugs left, none of which that I've found influence gameplay in any way, but mainly I'm posting this semi-final version to see if anybody has some last suggestions to either improve the gameplay or tighten up the code (which I probably need to do anyway, to fix aforementioned bugs.)  Obviously I don't want to eliminate any features in the name of freeing up space--and I don't think I'll need to--but won't dismiss the option if you think something is unnecessary.

 

If anybody can playtest this with an actual Atari controller of one sort or another, that would be a big huge help especially (since I've been testing this on my keyboard and, at least for me, the keyboard is a way easier way to control the game than the joystick).  How is the pacing?  Is the provisionally named Speed Mode too merciful?  Too insane?  How about the regular game?  Is the source code hideous?  And so forth.

 

Either way, I'm starting on writing the manual and drawing up the manual and cartridge art for the game.  Once you guys give me some ideas/suggestions/thoughts/beratement I'll get the game finalized and hopefully have a finished product before too long :)

  • Like 1

Share this post


Link to post
Share on other sites

I've uploaded a minor fix of the last version--I found a way to squeeze in just a few more bytes, and also figured out why I needed to redefine GRP0 twice (the vertical delay thing is very weird).

 

I'd like to do a PAL conversion now and want to know what the standard is, i.e. should I go to the extra trouble to making the game PAL 50 compatible or just change the color definitions to be PAL friendly and be done with it?  I figure even if I do the former, I'll probably just make the top/bottom areas of the screen extra wide and keep the actual gameplay area as is, and just let the framerate change be what it'll be.  I read in a different, old thread that most PAL versions of NTSC-original homebrews go the latter, PAL 60 route, but I'm not sure how many PAL TVs actually work with 60 Hz games.

  • Like 2

Share this post


Link to post
Share on other sites

PAL60 would be suitable for my setup, but I don't know if it will work on most PAL TVs.

ūü§∑‚Äć‚ôāÔłŹ

 

  • Like 1

Share this post


Link to post
Share on other sites

I've gone and tested the game with developer settings enabled (something I probably should've done initially, but better late than never I guess) and I've noticed that the hopping blue guy glitches with them on.  Instead of hopping like he should, he instead flies horizontally across the screen, and appears to "scan" rapidly across the whole vertical range of the screen.  My first reaction is that this has something to do with one of the ADCs, in particular trying to ADC a negative value, but I'm not sure why it wouldn't happen under normal emulation.  Nothing else in the game that I can see changes behavior in dev settings, so it's specific to this one enemy.

 

Does anyone know what might be going on here?  Here's the code for his generation and hop routine.

 

BlueBoi:    .SUBROUTINE
            
            LDA #BLUEBOI_COL
            STA mnstrCol
            
            LDA #BLUEBOI
            BIT mnstrFlags
            BNE .Spec

.Init:      LDA mnstrFlags
            ORA #BLUEBOI
            STA mnstrFlags
            LDA #BB_HEIGHT-1
            STA mnstrHeight
            LDA #BB_HEIGHT+7
            STA mnstrYpos
            INC mnstrYpos
            LDA #160
            STA mnstrXpos       ;start monster at right of screen
            LDA #1
            STA mnstrSpeed
            
            BRK
            .BYTE $0E           ;randomize initial hop
    
            AND %00000110
            CLC
            ADC #3
            STA bbHopHeight
            STA bbHop
            
            LDA #7
            STA mnstrFrame
            
            LDA #0
            STA mnstrUnder
            
            LDA #<BBFrames
            STA tempPtr
            LDA #>BBFrames
            STA tempPtr+1
            JSR GetFrames

            RTS 
            
.Spec:      LDA #DEAD
            BIT gameState
            BNE .Return         ;skip jumping if player is dead
            
            LDA #%00000001
            BIT animDelay
            BNE .Return         ;skip jumping every other frame of animation, to avoid
                                ;weird animation clipping
            LDA mnstrFrame                                
            CMP #6
            BNE .NoSound
            LDY #SFX_BB
            JSR SFXtrigger 
                       
.NoSound:   LDA mnstrFrame
            BNE .Return         ;skip jumping if blue boi is still winding up    
            
        ;is jumping        

            LDA #7              ;this is actually the frame BEFORE the jumping
                                ; animation, since it always INCrements in the Monster
                                ; routine
            STA mnstrFrame      ;keep at "jumping" frame while in the air
            
            LDA mnstrSpeed
            EOR %00000001
            STA mnstrSpeed      ;one way of doing 1/2 monster speed

            LDA mnstrYpos
            CLC
            ADC bbHop           ;add "hop" to Y position
            STA mnstrYpos
            
            DEC bbHop           ;decrement hop distance (through negative)
            LDA bbHop
            CLC
            ADC bbHopHeight
            BNE .Return         ;if not, skip to input testing
            
        ;has landed

            LDA #BB_HEIGHT+1    ;otherwise, reset Y position...
            STA mnstrYpos
            BRK                 ;randomize next hop
            .BYTE $0E
            AND %00000110
            CLC
            ADC #3
            STA bbHopHeight     ;set new hop height with each jump
            STA bbHop    
            INC mnstrFrame      ;start advancing animation once on ground
            LDA #0
            STA mnstrSpeed      ;monster doesn't move forward while winding up to hop

.Return:    RTS 

.Init is only run once, when the monster is first generated.  .Spec runs every frame.

Share this post


Link to post
Share on other sites

Have you got a "CLD" at the beginning of your program?  Perhaps the adds are being done in decimal mode because you haven't done that initialisation.

Share this post


Link to post
Share on other sites
1 hour ago, Andrew Davie said:

Have you got a "CLD" at the beginning of your program?  Perhaps the adds are being done in decimal mode because you haven't done that initialisation.

I do, yeah.

 

I noticed also that when the blue boi's X position is near the left side of the screen, an extra scanline appears in the screen area where the monster's X position is reset.  Again, this does not happen with any of the other monsters, no matter what their X positions.  And it does not happen in non-dev mode.

 

I guess it's also worth noting that @ZeroPage Homebrew tested this on an actual 2600 via a Harmony cartridge (@ZPH correct me if this isn't true) and this problem didn't seem to happen.  In the interest of thoroughness, I went and tested the version that they played with dev settings enabled and the same problem happened.  So what I have to wonder now is: is this problem actually something likely to repeated on a 2600, or is it only something that's only likely to happen in emulation?  It's a pretty game-breaking bug and I don't like it there but I also don't want to get sucked down a rabbit hole of trying to fix something that isn't a real problem.

Edited by StupidBunny

Share this post


Link to post
Share on other sites

Hi there,

 

On 11/28/2020 at 2:31 PM, StupidBunny said:

I'd like to do a PAL conversion now and want to know what the standard is, i.e. should I go to the extra trouble to making the game PAL 50 compatible or just change the color definitions to be PAL friendly and be done with it?  I figure even if I do the former, I'll probably just make the top/bottom areas of the screen extra wide and keep the actual gameplay area as is, and just let the framerate change be what it'll be.  I read in a different, old thread that most PAL versions of NTSC-original homebrews go the latter, PAL 60 route, but I'm not sure how many PAL TVs actually work with 60 Hz games.

This has been asked a couple of times before. I believe the majority lean toward PAL60 by this poll.

 

I live in an NTSC region but prefer seeing PAL50 to give true fractional positioning. If you can go further and give a true PAL50 display instead of a compressed NTSC display on a PAL50 TV then that would be icing on the cake. Not many games did this.

Share this post


Link to post
Share on other sites
8 hours ago, StupidBunny said:

I guess it's also worth noting that @ZeroPage Homebrew tested this on an actual 2600 via a Harmony cartridge (@ZPH correct me if this isn't true) and this problem didn't seem to happen.

That's correct, my setup is a RGB modded Light-Sixer with a Harmony Encore cartridge.

 

- James

  • Like 1

Share this post


Link to post
Share on other sites
On 12/1/2020 at 5:31 PM, DEBRO said:

Hi there,

 

This has been asked a couple of times before. I believe the majority lean toward PAL60 by this poll.

 

I live in an NTSC region but prefer seeing PAL50 to give true fractional positioning. If you can go further and give a true PAL50 display instead of a compressed NTSC display on a PAL50 TV then that would be icing on the cake. Not many games did this.

Oooooh.  I might have to take you up on that challenge if I can get everything else squared away.

 

...Which I think I've just done.  The problem mentioned above with the X positioning on the blue boi going all screwy only occurred when "Drive unused TIA pins randomly on a read/peek" was enabled.  I quickly found a helpful suggestion on another thread with a fix I would probably not have thought of otherwise but which makes total sense when I think about it.

 

So PROTIP: mind your #s before anything you want to be an immediate value.  Otherwise weird stuff happens.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

√ó
√ó
  • Create New...