Manatee Madness!

Stage work is coming along nicely, with the foundations laid down for the Rain, Snow, and Volcano stage. The Black Friday stage is proving a little more difficult but I believe part of that lies with the car movement code which needs reworking since it is a remnant of the early program - the car code was some of the first things I programmed.

While working on Bag Boy I had created several test programs to work on various ideas to see if they worked and then I'd they did I would integrate them into Bag Boy. If things didn't work out I discarded the program and moved on. This is how I came to use the DPC+ kernel. After initial progress with the standard kernel learning batari Basic I quickly learned of some of the limitations and tested out the Multi-Sprite kernel before landing on the DPC+ kernel.

One such test program survived these periodic purges and has gained a life of it's own.  It is called Manatee Madness!

I created that program to work in a simpler framework to determine better movement code, difficulty progression, and stage selection. I also wanted to continue working on sound effects, bit operations, and a higher definition titlescreen.

Essentially this program works similar to Bag Boy!  You play as a Manatee and must survive the day avoiding boaters, tourists and divers, fishermen, red tide, and alligators. Each stage is a part of the day - morning, afternoon, evening, and night. Each part has its own threats. The manatee must surface for oxygen periodically and not get hurt. Some injuries take health, some oxygen, and some both.

Anyway, here is a link to Manatee Madness test video. Bag Boy is not being abandoned but I was surprised at how quickly this test program turned into a game of it's own and will continue to serve as a test for my main project - Bag Boy!

Stages!

After a little bit of work I started hammering out some of the foundations for each stage.  While I already had the rain stage established with lightning and playfield changes, I wanted to start making other stages so that I can move onto the game logic some more.  I made 2 more stages - a snow stage and a volcano stage.

Now I know what some may be thinking - why have a volcano stage in a shopping cart game.  Part of the reasoning behind such a strange choice was that years ago when I worked for Albertsons I found an illustrated disaster preparedness guide in the offices.  It covered everything from storms to riots, earthquakes, and volcano eruptions.  I wish I could find that book again because it was truly amazing and it has been so long and so obscure that I am slowly questioning the validity of my memory.

Anyway, while I got these stages set up, I started on a transition playfield and this is where I got into a problem - cycle overrun.

The television screen would display the news forecast for each stage - rain, snow, lava, etc.  This would be kind of reminiscent of Paper Boy and the newspapers.  I also considered adding a fun easter egg using this as a game over screen...


I believe it stems from the previous game logic conflicting with the code for the transition screen.  While I needed to reprogram some of those sections, now it is pretty much necessary to redo those portions of the game before proceeding.

Mainly, it is the movement code for the virtual sprites and the power up generation code.  The latter should be easier but I am considering various other possibilities.  My thoughts are moving most of the movement game logic to a different bank and utilize bitwise operations to select the various conditions and some skip codes for the transition or game over screens.

Overall, I am pretty satisfied with what I am coming up with.  I want some more stages with varying elements but I think this next step will make everything else simpler.

Let it Snow...

It has been a few months since the last update. A change in commute has eaten up much of my programming time and my time to type during the day has been iffy at best. I finally had a vacation to tackle some of my game issues. While this was not the reason for my vacation, I decided I would work on my game. Unfortunately life got in the way of significant progress but I did make one development - the playfield for the other stage or wave of carts.

Previously I had just a rain stage and was hung up on just how exactly the levels would progress. I somewhat settled using number of carts. Now I made the snow stage. The logic for the stages will come later as I determine difficulty but my plans are to alter movement and the lack of visible parking spaces make judging distance a little more difficult.

I am considering a couple other playfields, including a volcano stage. These scenarios are based out of an emergency guide I had seen when working at Albertsons years ago.

If the transitions of stages works well enough I may make some bonus stages. Right now I am in the beginning phases. I decided to place the playfield change code in bank 3 and I currently have plenty of space. I still have much more to implement but it is nice to progress a little.

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.

Fixed Collision Code

I had a lot of unnecessary or wrong code in my program from when I first learned it. I had collision statements between player1 and the virtual sprites. I simplified things immensely by consolidating like code and deleting the offending statements.

Overall I freed up about 700 bytes in the last few edits. This definitely helps. As I work on the rain stage (I just made the umbrella and am working on how it is initiated) I will hammer out the details on the remaining power-ups, mainly the energy drink. 

As for difficulty progression, the big thing I need to figure out is best way to collide with NUSIZ copies, how to incrementally increase speed the best way, and when to start changes.

If I figure out the rain stage easily, I will maybe do a snow stage too... 

Rain and Lightning

I was having trouble creating rain using either the ball or missile sprites as they would take on the color of the virtual sprites as they crossed y-coordinates but I had considered using another virtual Sprite for lightning. Player8 will be used and will flash when the playfield flashes. The lightning stays at the top of the screen but randomly appears on the x-axis and disappears.

I am not sure of the consequences but this would act as a deterrent for lingering around the top while cars pass. I had also played around with mirroring some of the car sprites and will stagger some of the duplication at different difficulty intervals.

This is something rather simple. The hard part I have been dealing with was music and Titlescreens. I had tried adding some sound effects to the lightning and could only manage a simple noise.  I was wanting to play a little series of notes whenever hit by a car to give the player some time while the car passes to prevent rapid life losses. I also want a transition screen for rain so that it doesn't immediately change colors and flash. 

Fixed Car Spawning Again!

I haven't checked the cycle issue on hardware yet but in my search for a fix I discovered why my car spawning was off on a couple of the cars.

For power ups I utilize virtual Sprite player7 for all of the power ups since only one is on the screen at a time so I have a variable pick which Sprite will he player7. Before I did that I used several virtual sprites, each associated with a power-up.

When I had made the change to player7 I had forgotten to delete the redraw for a couple sprites so when I wrote the code using those virtual sprites for something else, when I ran the program it would seemingly redraw the placement of the cars in the course of the power up generation. I finally erased this code and now the car movement works fine.

I will update the movement of the cars for increased difficulty soon, especially since I freed up some space.