Jump to content
IGNORED

[WIP] Bag Boy


KevKelley

Recommended Posts

So I got a chance to run it in emulation and used ALT-L. I see where the the cycles flash red on my second playfield so I have an idea how to narrow down the error. This will be great for me to work things out. I can see where I would never catch it without the debugger - it happens so fast I had to run it for a while to catch it without thinking I was blinking.

 

If my idea of how to program this part of the game doesn't pan out at least I will have learned something.

 

 

Also as RT suggests, you can set the debugger to hard stop if the scanline count is exceeded. I use both methods, sometimes I like to let it run and watch the cycle count go red to see if there are patterns to the overcycle.

 

The debugger also lets you step through frame by frame, i've found that invaluable for tracking cause.

Link to comment
Share on other sites

I've used the various methods discussed and seem to be at an impasse. Not sure if it is something simple that I am just overlooking but it seems the over-cycling occurs when the score goes over a certain point and I change part of the playfield (I have the sky turn gray and flicker white to simulate lightning) but the cycles seem to change at random, which make me think it has something to do with the power-up generation. I'll post the .bas of what I was playing around with here while I continue to try and locate this issue. On the plus side I found some other issues that I was able to fix but sadly they were not the cause of my current headache.

 

BBPv030119.bas

Link to comment
Share on other sites

So I still couldn't figure out why it was having the issue but I decided to try and clean up my code a bit and consolidate some redundant lines. For example, since the result of collision between Bag Boy and any car is the same I deleted each individual player/car collision result lines and combined them into one. I had also started doing the same for the cart/car collision lines. I freed up a couple hundred bytes in Bank 2.

 

When I ran a test to check if everything worked, everything seemed fine. The odd thing was that when I made the jump to the "raining" playfield I did not experience any increase in cycles. I had the program running for a couple of minutes and using the breakif {_scan>#262} in Stella debugger the game never crashed. I also noticed the counter in the top left never went red.

 

I will test this on my hardware in the morning as I wonder if I had actually fixed the issue or am just missing something simple.

 

Here is the .bas of the little changes I had made from moving the code around.

BBPv030919.bas

Edited by KevKelley
Link to comment
Share on other sites

This probably doesn't have anything to do with your problem, but search your program for the word collision. Any time you see a collision check that includes player1 and player2 (or anything higher), smack yourself in the face with a rubber chicken. :D For example, you can't do this:


   if !collision(player1,player6) then goto _skipcheck2



You can't check for a collision between player1 and player6 that way because they are the same sprite. You'll have to check their positions instead. I better not mess with the code until you rework it.
Link to comment
Share on other sites

Yeah... Those are remnants of when I first started using virtual sprites and copied the example code about collision with player1 thinking it applied for all. You had suggested I change it a month ago when I was having another unrelated issue but I never got around to changing it because I didn't see an immediate priority since it didn't seem to impact my game. And then I forgot about it.

 

Maybe I'll fix it once I get a rubber chicken, or need to free up some bytes.

Link to comment
Share on other sites

I'm hoping to clean up some code tomorrow. I spent the day out so didn't get a chance today and with clocks going forward I doubt I can tonight. Better to spend my lunch playing Atari programmer than waste money on lunch.

Link to comment
Share on other sites

This probably doesn't have anything to do with your problem, but search your program for the word collision. Any time you see a collision check that includes player1 and player2 (or anything higher), smack yourself in the face with a rubber chicken. :D For example, you can't do this:


   if !collision(player1,player6) then goto _skipcheck2


You can't check for a collision between player1 and player6 that way because they are the same sprite. You'll have to check their positions instead. I better not mess with the code until you rework it.

 

I was playing around with this for the last couple of days.

 

I changed a few things to see what works and what doesn't to eliminate my collision statements with virtual sprites.

 

I changed

 if player1x <= player8x + 8 && player1x + 8 >= player8x && player8y + player8height >= player1y && player8y <= player1y + player1height then goto _CART_HIT
 if !collision(player1,player8) then goto _SKIP_CART_HIT

to this

 if player1x <= player8x + 8 && player1x + 8 >= player8x && player8y + player8height >= player1y && player8y <= player1y + player1height then goto _CART_HIT else goto _SKIP_CART_HIT

and I seemed to get the same effect, where the collision box is created around the virtual sprite and if no collision then the code skips to the next section. The only "else goto _SKIP_CART_HIT" line I have is at the last check so it runs through the code for all cart/car interactions. I haven't really seen anything crazy come from this as a result of the change.

 

Do you think this is a reasonable fix?

 

The only other thing I seem to be having an issue with collision with NUSIZ copies of virtual sprites and player0 or player1. I was able to get it to work earlier when I was playing around with collision statements yesterday but I cannot remember what I was doing to get it to work (and of course I still had my screwy collision statements in place then).

 

If this works I will work to remove my other screwy collision statements tomorrow.

BBPv031319.bas

Edited by KevKelley
Link to comment
Share on other sites

  • 1 month later...

We'll be featuring Bag Boy LIVE on tomorrow's (Wednesday) ZeroPage Homebrew stream on Twitch at 11AM PT | 2PM ET | 7PM GMT! Hope everyone can watch!

Twitch Stream: http://twitch.tv/zeropagehomebrew/

 

Games:
- Doom Patrol (2015) by Ed Riley aka winkdot
- Bag Boy (2019 WIP) by KevKelley
- Miner 2049er (2018 Faster Hack) by Thomas Jentzsch (speed up hack), OmegaMatrix (reset bug fix), and doctorclu (sprite hack)

 

EDIT: Updated with Archived Show

Edited by ZeroPage Homebrew
  • Like 2
Link to comment
Share on other sites

Sadly I work tomorrow when this airs but I can't wait to watch. I am curious as to thoughts and how people other then myself play it and any feedback to make it better.

 

I know I haven't updated in over a month. I have still been working on it but haven't made any huge developments since last post. I had a couple week break from it and have started working on parts. I had got hung up on the collision (getting the code to work as desired). There is no real difficulty progression yet. I use the fire button to change the score so I could test things and haven't set intervals for things like extra cars or speed to start.

 

Things I am currently working on:

 

Collision with copies of virtual sprites.

Screens in between "stage." (Currently just a raining stage)

Changes in between "stages" (example: playfield changes don't revert back)

Lightning strike effect.

Power Up interactions.

Delay in player spawning after collision.

Music and sound effects.

Difficulty progression.

Titlescreen.

End screen.

 

Hope you guys have fun! I am anxious being this is my first game.

  • Like 2
Link to comment
Share on other sites

I just watched the show! Some great ideas and feedback.

 

You guys are right as in this is more like a demo. I am trying to get the basics down to where I can then start adding so I got the basic gameplay of getting the carts. Then I added a little more elements, like the power up spawning. I am kind of working on the different "stages" now and I had planned on doing a snow stage as well with white and altered inertia. Once I get the rain stage down I think it would be much easier to make additional stages.

 

I figured I can mention some things discussed in the video.

 

I can try to make the lightning longer. To make the rain stage I just redraw the top few lines of the playfield background. To make that effect I have a counter that changes the playfield a few times each run through of te counter. To make the lightning I have it generate during those couple moments but it disappears as soon as the variable changes. I can try to make it last longer.

 

The eventual purpose of the lightning was to increase difficulty. When you bring the cart back I have found myself dodging cars to then walk the sidewalk to the customer. I figured the risk of getting struck would force the player lower on the screen where they would have to time their meeting to drop off the cart. Getting struck would provably make you die and I was considering a Sprite of a flashing skeleton if possible. As for sound that is one area of basic I have been having problems learning

 

I had also tried something like a tornado. I like the idea but I found the flickering got pretty annoying because the size would make multiple lines of cars and the cart flicker. I considered a kind of car-less of multiple carts and a tornado but that would be later once I learn to program the main game. I am sure this will probably go over 32k.

 

I had also thought of making levels or stages. Something to determine difficulty progression. I thought of timers or scores to advance the game. Currently there is a timer but only to get te cart back and forth to the top. I like the idea of having a set amount of carts and then advance. I might be able to make pfpixels off to the bottom to show carts remaining or a goal, something like Duck Hunt. Haven't gotten that far yet.

 

A like the idea of the power ups getting collected with the cart as a risk reward. I thought more that by getting the power up instead of the cart you risk the customer grabbing it or a car collision. Maybe a game variation in the future?

 

I LOVE the idea of making the customer into the manager with Q*bert style talk bubbles saying "hurry" or "you're fired." Also love calling the cart thief Bubbles, being he tries to steal the carts from you.

 

I have been trying to work on the lot customer spawning so he doesn't immediately grab the cart. The bottom y-coordinates of the screen are off limits to grabbing because I found he kept getting it too soon. The cart goes towards the second car from the top so I thought having the cart get grabbed towards the lower middle forces you to get further from the top and take time off your timer making you rush to get it. I had thought of playing with interactions as a variation.

 

Currently all the cars have a set way and speed of moving. Eventually I may change that as things progress or different variations are selected.

 

There is much I want to accomplish and much I have to learn but watching you guys play was great. Some really great feedback! Got some inspiration. Now I just need some moments to program!

  • Like 3
Link to comment
Share on other sites

So I was playing around with some of the suggestions. I haven't made any huge developmental leaps in the last few weeks. I backed off on the whole virtual sprite collision thing for a bit to focus on the playfield switching so I can get better defined stages. Right now I have it to where once the score goes after a certain point it goes to the raining stage. Currently the only differences with rain is that there will be sporadic lightning to act as an obstacle/risk at the top of the screen. I had also considered other things like wind or tornadoes but I was thinking I may just keep the lighting as the sole risk for the rain level, since my idea for the snow stage would involve more sliding movement if I could get it right and I thought the concept of wind would be lost on the gameplay. I did like the idea of a tornado but because of flicker I thought that would be annoying to look at but like an idea of another stage of solely avoiding a tornado while collecting carts, kind of like a bonus stage.

 

The main issue I had been finding with implementing playfields is having it change back. Right now, when the score hits a certain amount I change the playfield background color for the lot to look blue and convey a wet image while I set to a variable so that a couple lines of the foreground color change giving the appearance of a lightning flash in the sky. This is also when the lightning sprite appears briefly. What I had noticed is that if the score then goes to a certain amount the parking lot remains blue. I have to follow the code to see if I can figure out why it stays but other things do not, such as the lightning sprite.

 

I loved the idea of making the customer the manager and having him yell Q*Bert style so I added a talk bubble to appear at certain intervals of the bottom left timer, so that eventually when time is running out it will appear. I use a sprite for the talk bubble and I will eventually randomize the symbols shown. I have it placed a little high to try to avoid flicker. Kind of related to my playfield issue is that I noticed when the rain stage starts it then causes the lightning to follow the manager but the talk bubble doesn't show up.

 

On a lesser note, I want the talk bubble to only appear so that the symbol only appears over the grocery letters for readability purposes but that is easy to figure out.

 

 

 

 

BBPv050319.bas

BBPv050319.bas.bin

post-65677-0-17299400-1557183359_thumb.png

  • Like 3
Link to comment
Share on other sites

  • 4 weeks later...

My work has been rather busy so I have not gotten to too much but I finished up the little talk bubble code to try and ease back into things. I originally had it initiate using all new variables and counters, checks, and sprites for how much time is remaining on the clock but I realized I didn't need all that and I would save the space and just use the power up generation code.

 

For testing I had the random number for the powerups equal to just the number of powerups to test if they worked. Since they work, I wanted to reduce the frequency in which power ups appear anyway and so I increased the range for the random number generation and have some of those numbers go towards the talk bubble. I still want to add a sound for the talk bubble and maybe have it cycle through the bubbles (or shorten the time the bubbles appear so that they may switch quicker then a normal powerup) but for now I am happy with how it works.

 

My next thing to work on is having the playfield change back now that I have an opportunity to look at Lillapojkenpåön's code. Once I get that down I want to create a "snow stage" and then start working on the difficulty progression some more. I may also work on my NUSIZ virtual sprite copy collision detection code since I had an idea the other day that I think may work by using my original collision code that had glitch issues with causing collision with other sprites but fitting that code into certain y-coordinate ranges so that it turns on and off, that way it will not interact with the sprite not designated in that range.

 

 

BBPv052619.bas

BBPv052619.bas.bin

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

BBPv061619.bas_7.pngI have had some small opportunities to program recently so I am almost done working some kinks out of the stage changing. 

 

I did play around with the manager cursing, making it resemble the exclamations Q-Bert uses in the 2600 version. I had also altered the way the lightning works. Suggestions were for it to stay on the screen a little bit longer.  I personally like the quick flash but what I have done is make it flash a couple times and then stay on the screen a bit longer and if you are touching the shopping cart then it will start to move left or right in your direction. I am still playing around with the timing since I had taken an easy route and just had the lightning appear along side the playfield change and there seemed to be a glitch where when I make the collision check for the bag boy and the cart the lightning stays on the screen after stage change.

 

And as for the stage change, as I mentioned I may have it straightened out. In my original "god mode" for testing I had levels change with the score but I liked the suggestions of having the stages change after a wave of carts. Once I get the stage swaps down to where there are no issues, like sprites remaining on the screen or environmental issues staying in  then I will work to add the additional stages, which will currently be a snow stage and what my son suggested - a night stage.  

 

My thoughts on how the stages alternate was to use a data table with certain values for the stages so that there be a pattern (I may have that randomize once I start adding difficulty). I don't know how to use data tables or the switches yet so I figured it would be a good exercise to learn. And while the stages will be determined by waves of carts, I think I may keep things like additional cars tied to score.

  • Like 3
Link to comment
Share on other sites

Cool unique little game. The lightning is a nice effect. Controls well. Nice colour choices.

 

This is a completely personal choice, you seem to have the lightning how you want it. I would probably make it stay just a little longer and have it reflect (REFPX) a few times before disappearing. But I mean, it's your game, and it looks great so far. Keep it up man ??

Link to comment
Share on other sites

I had considered making it reflect a little bit. I saw when I tested it on a real TV how it is easy to miss the flashes. I was working on the collision detection between the bag boy and the lightning right now but I have been playing with how it displays. I'm thinking a couple frames longer might be good. 

 

And personally unloved the suggestions and love trying to integrate them in my game. It is sometimes a challenge and will push me to do better  but I feel overall I think it will make for a better game. Plus it is cool to involve the community. I remember when I was little I used to write letters all the time to companies and game developers. I'm older now but would still love getting a response or have an idea at least listened to. 

Edited by KevKelley
  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

Slick!  Neat game idea.  

IMG_1788.thumb.jpg.45f7708773d18aebbe3cf4a147f363c8.jpg



The controls remind me of one of my favorites, Imagic's Dragonfire.

 

Whenever you post a new build, you may want to update the first post with a link to the reply containing it. To get that link:

 

  1. click on the reply # in the upper-right of the reply
    1822183018_ScreenShot2019-07-07at8_25_43PM.thumb.png.e21d1571f869ccdea41ed9af0aa1e183.png
  2. copy the link from the pop-up dialog
    1886813343_ScreenShot2019-07-07at8_25_48PM.thumb.png.3001f18c5856b03dbfc3382e238da605.png

 

Makes it easier to find the latest build once addition comments have been posted, such as in Space Rocks where the latest build is in reply 609 and there's 20+ replies after it.

Link to comment
Share on other sites

Thanks. I had tried keeping the first page updated as I had seen others do it. I guess the later versions down the line were kind of progress reports. I didn't want people to look at the latest build and be disappointed that I made minor changes when something simple may have been a huge development for me.

 

I will also have to definitely revisit Dragonfire. Right now the controls are rather basic. I kind of want to add a little momentum in Bag Boy's normal  movement.  After playing using the Harmony cart I get the feeling that I have a lot of tiny things to implement and maybe a handful of big things I want to knock out. I just get mad because the few moments I have that I want to program my mind is fatigued and useless to perform any task involving logic.

Link to comment
Share on other sites

  • 4 weeks later...

Just a quick update:

 

I haven't had too much free time these last couple months due to a variety of issues but I am indeed still working on this game!  Previously, one of the big issues I was approaching was that I wanted various "stages" where after a certain goal was achieved, such as collecting a number of carts, you would go to a stage with different gameplay.  So far I was programming the "rain stage," which changed the color of the parking lot to a blue to give the appearance of being wet, as well as added lightning on the top of the screen.  

 

The wall I hit at the time was how to change back to a regular stage afterwards.  Well, I had figured that part out by using a variable that is attached to the collision detection between the cart sprite and the manager sprite. Collect a number of carts and it will change the level. Collect x amount more and it will change back.  There are other things that I would want to implement, like maybe a quick stage change screen, but I figured that would be much easier to make once I get the meat and potatoes done.  

 

So far I want the following: various stages (regular, rain, snow) and one bonus stage.

 

Now my brain is stumped on how exactly to change the levels. Should I use a pattern? Should I use a data table somehow to run through a set number of stages and use that number to also alter gameplay in the various stage? Should I randomize the weather?  

 

Not sure how to use data tables but from my understanding of reading it I was thinking that it sounds like something I might be able to utilize for a variety of things, like having the various stage selected and the conditions of each stage (# of cars, speed, physics, etc.) and that this may be the way to go.  

 

I will update the first post (link below) with my newest working files.  Don't expect much difference! I only have a some minor changes, with I think the biggest being the way the lightning stays on the screen and follows Bag Boy when he grabs a cart.

 

 

 

 

 

  • Like 2
Link to comment
Share on other sites

  • 2 months later...

I just wanted to provide a brief update in an effort to keep me accountable. My work on Bag Boy! has ground down to a slow crawl due to a change at my work. A long commute has eaten into my programming time so I haven't made much changes yet. I just cleaned up my workplace at home so hopefully that will help facilitate somewhat.

 

I have had a couple things I tried working on in the meantime that I can implement in my game when the time comes and I am still actively reading about programming to try and improve my understanding  I hope my next update is one of more progress! 

 

Thanks! 

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

I optimized your source file just for fun and to show some optimizations - (thanks for sharing).

It may have broken the game, I didn't have time to test.

366 bytes lighter.

 

Some things I did were:

-Swap player5 and player6, so that some code could use "player4-5:" sprite data (they were the same data). (Saves bytes in both banks and "graphics bank".)

-Use "return otherbank" and "return thisbank"

-Moved the goto Bank5 routine into the Bank2 that was calling it.

-Line up declarations of "same value" to one line, as in "thingA=200: thingC=200, thingC=200". (Can make source harder to read/change in future.)
-Dropped some goto in "if, then, goto". (Can save bytes if the goto label is close.)

 

BBPv080519alt2.bas

Link to comment
Share on other sites

I cannot wait to check this out. When I first started this project my code was a mess. I tried keeping things organized and it was exciting the first time I tried optimizing and seeing bytes freed up. I would love to see the comparisons between the changes made. Your explanation makes sense and makes me wonder why I didn't think about it before. 

Edited by KevKelley
Link to comment
Share on other sites

1 hour ago, KevKelley said:

I cannot wait to check this out. When I first started this project my code was a mess. I tried keeping things organized and it was exciting the first time I tried optimizing and seeing bytes freed up. I would love to see the comparisons between the changes made. Your explanation makes sense and makes me wonder why I didn't think about it before. 

It is just a fact that the same source, formatted differently, can make smaller compiled code. 

(If the compiler were still being developed, some of these optimizations could be automated.)

 

You have to choose sometimes while coding, because some changes make it tough to go back and make changes.

Some optimization should wait until nearly the end when things are the way you want them. Then it is nice when you can free up hundreds of bytes to add polish or some additional feature or sound. 

 

There was more I saw, but I ran out of time today. Like a “goto _label”, but the next line IS that _label. Those goto’s are probably not needed?

 

Also it does not matter if the source code is a mess. Most optimizations can be done without knowing everything the code is doing.

 

And also, the goal is usually to make faster binaries, but sometimes code may be smaller but take longer to execute. (I’ve seen that when combining duplicated code into a single subroutine.)

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...