Still on Lightning!

With every little moment I inch towards completion of one task.  Today I have gotten the collision between Bag Boy and the lightning closer to being done. Now, when collision is detected the Bag Boy sprite cycles through an electrocution shock graphic.  To save space with variables I tied the graphics to the manager and customer movement variable since they are always walking.  This way once shocked the code just reads the new information for the Bag Boy sprite.  

I had dealt with an over cycle issue at first but I believe that was a result of some old "god mode" code so the playfield kept redrawing whenever the score hit a certain number and/or the cart counter hit a certain number.  this caused a lot of subroutines to be jumping back and forth.  As soon as I eliminated the old code I did not see any more over cycling.  

The next step would be to work on the player "death" code.  Currently he respawns at the entrance immediately.  When hit by a car I wanted to change the graphic to Bag Boy fall down and as with the lightning, I want Bag Boy to remain at the last place he was until the button is hit.  I had found a delay would be good because immediately re-spawning can cause the player to repeatedly run into the same obstacle and lose all their lives in an instance.  I may still let the time go so the loss of life also acts as a penalty and encourages the player to restart instead of waiting it out for when it is advantageous. 

Lightning

• I have the lightning code almost done. It flashes, appears, and then stays on the screen. I altered the code to have the lightning chase you if Bag Boy is holding the shopping cart but for some reason the lightning will stay when there is a stage change so I suspect there is a line somewhere that I forgot about that is interfering with the game. 

Altered and Stage Ideas

Typically when I get a chance to program during the week, it is usually during my lunch. Because of time limitations I try to tackle small projects in these sessions so today I decided to play around with the lightning code since this was an issue mentioned by the Zero Page Homebrew channel.

I had tried extending the lightning Sprite while keeping with the quick flash of the sky. I didn't get it to work probably because of how I implement the flash by changing the background color set to a variable. As I was playing around with the code, I eventually had the lightning flash a couple times as it had before and then have it go in the direction of Bag Boy. I will probably change this to only follow Bag Boy when he has the cart in his possession.

This action has a couple functions. First, it causes the lightning to remain on the stage (as some mentioned) while also retaining the quick flash element from before (that I personally liked more). I thought this also makes more sense being Bag Boy would be holding a metal cart.  I may decide on a slightly different method since I want to avoid flicker or may have behavior of the lightning Sprite tied to difficulty progression, kind of like how the manager's movement changes as things get harder.

Also as a side note, my 6-year-old suggested I make another stage that is at night. I really liked this idea because I was trying to think of something else I could do to increase difficulty. I was thinking of having pfpixels appear down the middle of the aisles to act as a barrier but using nighttime should be easy once I get the stage code done. The hardest part would be changing the graphics of the cars.

What I considered was either swap the sprites with one of just headlights and brake lights because I could utilize the same code for every Sprite, or I would just change the colors of the cars, but that may fill up my graphics bank and I may not want that if I decide to add more animations.

Playfield Change!

I had been wracking my brain for the last couple months on the playfield change.  My goal was to have "stages" where the game would alternate every so often to a "rain stage" or "snow stage."  Essentially I had wanted some gameplay variation and difficulty progression and to do this I wanted to simulate changing weather.  For testing purposes I made the playfield change when the score hit a certain number.  That seemed to work but the only problem I was experiencing was that the playfield colors never reverted back to normal after the stage was completed... until now.

While I am sure there are better ways to accomplish this goal (I am still working on learning the code for changing the colors for certain lines of the playfield), currently when conditions are met the playfield colors will change. Based on some of the suggestions from the Zero Page Homebrew channel, I am shifting the stages from score-driven changes to cart-driven, meaning that each stage is completed when x number of carts are collected. For example, if every stage lasts 10 carts, the rain stage would begin at 10, snow at 20, and so on.

What I am thinking of doing is having a variable for the number of carts collected.  Once that hits the chosen number it will set off another variable which will then determine which stage. I was considering 25 as a good number of carts and I think I might have a sprite animation appear each time the cart is delivered to the manager (maybe once every 5 carts so as to not waste space). 

I only have the beginnings down but now that this hurdle is met it should be no time until I have the parameters for each stage met, such as altered movement.  I do plan on keeping the additional cars to appear at different score intervals so that if players try to rush power ups they are met with increasing difficulty sooner than later.

Not Much New Except Some Profanity!

I have had a couple busy months (not on the programming front).  I have made some minor code adjustments here and there but no significant game developments.  I am still working on implementing the stage change code, with the lightning and rain, so that once I have that solidified making the snow stage should be easier.

Over the last couple months Bag Boy! was featured on Zero Page Homebrew channel where they played the game in essentially a God mode, where they got the general feel for what was going on.  One suggestion someone had made on their channel was to make the top customer the manager yelling at Bag Boy Q-Bert style.  I loved this for multiple reasons, one being it easier to identify the sprite in my code and typing so instead of referring to "Customer 1" and "Customer 2" or whatever, I can refer to one of the sprites as a "Manager."  The other reason was for aesthetics and visual variation.  It is a simple way to add something to the game without really adding something to the game.  I also thought it is a nice callback to the classics.

I spent a couple days trying to develop some sprites and code for the talk bubble but after some thought and simplification, I worked it into the power-up code since I had intended to have the power-ups appear less frequently.  I didn't quite like the appearance since I had to place the bubble several pixels above the Manager to avoid flicker.  I do not want any prolonged flicker in the game other then the periodic flicker from the shopping cart crossing the path of a car.  I had also planned on programming the sprite to be activated only when the symbol would be over one of the letters that spell "GROCERY" since it would stand out since the sprite was single color, with the symbol being clear.

Then today I was playing Q-Bert on my Flashback Portable and noticed the way the speech was implemented in the game.  While I was thinking more along the lines of the arcade game with the speech bubble, the Atari port had the symbols just off to the side of Q-Bert.

A quick rewrite of some code got me this:

So while this little bit of code was a slight detour, I am quite pleased with the outcome.

I will probably mess with the configuration of the symbols.  I have so far settled on this:

I had thought that having them bunched up a little closer with the pound symbol on top made it more readable. Saved 400 bytes doing it this way.  Adding the cursing added virtually nothing to the original code.