Player Width?

[Player Width?]

That is interesting. I started to play around with using balls or missiles, as the background and playfield are the same colors at that spot. Not quite sure if I will use the missiles yet. What I had worked on as a temporary fix was have the sprite scroll back and forth and then I have a spot where it can scroll up. But since I am playing around with with these ideas I am not sure what may stick. 

 

I have plenty of space so I may just make 8 different sprites. But if it turns out I don't use them I may just do that as an effective workaround. I did realize that I was doing the sprite masking all wrong in the past and, as I encountered this issue with Bag Boy. Now I know!

[[WIP] CROSSDOCK]

Took a break to have a little fun.  Can't take too long a break or these bootlegs might make it to market!

[Unholy]

The changes are really nice. I love the blood forming on the floors. It is an amazing effect that brings a eerie sense to the screen. The sprites are great too. The improvements made are very good and this game only looks to keep getting better with your development.

[Pitkat]

4 hours ago, Jamtex said:

Feel free to play it, the download is on the 3rd post and works well in Stella.

I must have skipped over that post! I will definitely have to check it out! It is sad a game like this had not came out during the life of the system.

[Pitkat]

I finally got a chance to watch the gameplay on ZPH. Impressive! Everything from the sound, tiles, gameplay, rewind, etc!

 

[[WIP] CROSSDOCK]

On 7/4/2020 at 9:10 PM, Karl G said:

I spent some time playing the latest version, and I'm enjoying it quite a bit. I agree about tweaking the timing to add more challenge, though. 

 

I also got my palette stuck on the conveyor belt at one point, and couldn't retrieve it.

 

Edit: I also didn't notice any screen jumps with this version. 

 

So I went back through the code to see if I can add another check so that there is no chance to get the pallet stuck in the conveyor belt. As I was trying to replicate it I noticed a brief moment where the scanlines jumped to 263 so I went back through the code to see if I can fix the issue AND find room for the check.  I initially tried to add it to where I have my other boundary code but it kept interfering with the pallet drop code. I was extremely limited in space so after looking at it I reworked the movement code and slipped in the check which also freed up some space.

 

I changed this:

 if joy0right && joy0fire && collision(player1,player0) then player1x=player0x+5:player1y=player0y:goto SKIP_JACK
 if joy0left && joy0fire && collision(player1,player0) then player1x=player0x-5:player1y=player0y:goto SKIP_JACK
 if joy0up && joy0fire && collision(player1,player0) then player1x=player0x: player1y=player0y-5:goto SKIP_JACK
 if joy0down && joy0fire && collision(player1,player0) then player1x=player0x: player1y=player0y+5
SKIP_JACK
 if joy0right && joy0fire && collision(player1,player0) && collision(player1,missile0) then missile0x=player0x+8:missile0y=player0y-1:goto SKIP_MISSILE_COLLISION
 if joy0left && joy0fire && collision(player1,player0) && collision(player1,missile0) then missile0x=player0x-6:missile0y=player0y-1:goto SKIP_MISSILE_COLLISION
 if joy0up && joy0fire && collision(player1,player0) && collision(player1,missile0) then missile0x=player0x: missile0y=player0y-8:goto SKIP_MISSILE_COLLISION
 if joy0down && joy0fire && collision(player1,player0) && collision(player1,missile0) then missile0x=player0x: missile0y=player0y+5

into this:

  if joy0fire && collision(player0,player1) && player0x<110 then goto _JACK else goto SKIP_JACK
_JACK
 if joy0right  then player1x=player0x+5:player1y=player0y:goto SKIP_JACK
 if joy0left  then player1x=player0x-5:player1y=player0y:goto SKIP_JACK
 if joy0up then player1x=player0x: player1y=player0y-5:goto SKIP_JACK
 if joy0down then player1x=player0x: player1y=player0y+5
SKIP_JACK
 if joy0fire && collision(player1,player0) && collision(player1,missile0)  && player1x<110 then goto _MISSILE_COLLISION else goto SKIP_MISSILE_COLLISION
_MISSILE_COLLISION
 if joy0right  then missile0x=player0x+8:missile0y=player0y-1:goto SKIP_MISSILE_COLLISION
 if joy0left then missile0x=player0x-6:missile0y=player0y-1:goto SKIP_MISSILE_COLLISION
 if joy0up  then missile0x=player0x: missile0y=player0y-8:goto SKIP_MISSILE_COLLISION
 if joy0down then missile0x=player0x: missile0y=player0y+5

That seemed to take care of the scanline issue (I think) and now if your player goes into area of the conveyor belt he will let go of the pallet jack. This will also prevent the pallet from getting stuck in that area as well. After some testing the new code seems to have the same interactions as the old code so it should not change gameplay any. 

 

There were also a couple of other things from the ZPH show that I liked.  One was having the box move on the conveyor belt in the bonus round/minigame (TheDTrain37 mentioned this).  This was something I had planned on doing but then kind of forgot about so I slipped some code in there so that the box moves down the conveyor belt and a new one reappears in the truck once the other box disappears.

 

The other ZPH-inspired idea was someone mentioned the possibility of not knowing what bay doors you had filled, so that you must remember which doors are closed off (Tanya had mentioned this).  I really liked this idea as I have been trying to come up with a different difficulty setting for one of the switches (or swap random jacks with the switch and make this a door option).  Currently one switch sped up the conveyor belt and the other sped up Dock Boy (which I felt caused more annoyance than difficulty).  I decided to add this setting to the speed setting, reducing the fast speed by a bit as well.  So now if selected there is zero indication which doors you had already filled making for a nice game of memory.  

 

I updated the .bin on the first post.  

 

Hope people like these changes as I continue to dial in the balance of the game!

[Player Width?]

Here is an example of what I was considering:

 

Have quad-sized sprite move right (player6x=player6x+1). Once it hits the end have it appear to gradually go off screen as if it was 8 pixels wide... Then 7... Then 6... Etc. So that it doesn't reappear immediately non the left side of the screen.

 

I had considered either drawing 7 different sprites and swap them out each increment of players+1 or a combination of sprites and as it shrinks change the size (I thought the virtual mask covers 8 pixels but I may be wrong) so I can start with quad, use virtual mask, shrink to double sized and so on...

 

But I thought there might be a better way or maybe a different way than what I was thinking, like something I can swap out like when I have read about swapping a sprite for a score sprite...

 

[Player Width?]

I thought that is what it said on RT's site.

[Player Width?]

I might be able to do something with missile0. I am not 100% sure how that would look for my intended use. Wouldn't the max width for the missile be 8 pixels, where as the quad-sized sprite would be 16 pixels wide? 

 

I had thought of using a mix of missile0 and then also decreasing the NUSIZ size of the sprite. 

[[WIP] Bag Boy]

I last worked on it in January. I hit a problem that I needed to work out in regards to difficulty progression which resulted in me making some test programs (in which Crossdock) was part of. 

 

One of the first things I programmed when I switched to DPC+ was the cars moving. I was at the point where I had programmed each stage (debating on keeping some or adding) and wanted to do the cars and collision with the virtual sprites but with the code changing so much and my learning some methods in the test programs, I need to change out a chunk of code.  I was actually looking at it today to see how difficult it may be to adjust. 

 

I was looking to probably get rid of the volcanic eruption stage, as while I found it funny (especially since it was a reference to training material from Albertsons), I felt it wouldn't make much sense but I was going to add a Black Friday stage. This is what caused me to do some test programs because it required me to change the sprites from cars, change how they move, and then change them back. This is something I did with Crossdock in the bonus round and I think it would work well in Bag Boy.

 

Now I just have to stop procrastinating and make the plunge.

[Player Width?]

I was aiming to not have it go behind a playfield, as I have other sprites that would need to remain above the playfield.

 

I am not sure if the other example would be applicable. More specifically, I would be using the DPC+ and getting to the edge of the screen, since I wouldn't be doing anything like PF0=%11110000 to hide it off screen. I had considered virtual sprite masking but I also am using a quad-sized sprite.

[Player Width?]

I am familiar with the melt away effect using playerheight but I was curious if there was a method of changing player width to kind of shrink the sprite.

 

My thought was the sprite going into something where it appears to disappear without making sever different sprites and just swapping the sprites out as their x coordinate changes. 

[[WIP] CROSSDOCK]

Wow. Haven't seen the jack get stuck in there before. I don't think I had any checks for if the pallet jack x-coordinates were to be greater than whatever the conveyor belt is.  I'll probably put something in there to stop it from going there.  Thanks!

 

I am also glad to hear no screen jumps!  That problem has been with me for probably a couple months and it confused me why I didn't experience any on any of my TVs or systems.  I find it hard watching the corner of Stella for that red number to appear while playing and seeing under what conditions it jumps. I've tried putting in breaks in Stella to stop the program when it occurs but I admit I have a hard time processing the information in the debugger but watching ZPH play helped immensely, as I was able to narrow down the cause.

 

I'll go back to tweaking!  I feel like it is almost there.  Before this latest version it seemed to decrease too fast whenever the game sped up so I added the statusbar replenishment after the first ZPH playthrough when James commented about the bar not filling back up after all bays were filled.  But now it seems it is too easy.  It is reminds me of when I tried to level a counter top - adjust one leg and then you got to adjust 3 more.  

 

I thank everyone for the time playing as this helps greatly.  Plus I have other projects I want to work on and am trying very hard not to start multiple things at once!

[[WIP] CROSSDOCK]

Thank you again for playing Crossdock!

 

As I had mentioned there are still some tweaking needed.  As it is the game seems too easy.  It is kind of a race-against-the-clock game where the timer is constantly going down while you must complete tasks (loading pallets and bays) but so far the game kind of just goes on forever with little challenge.  The obstacles and speeding up do change the gameplay but I am still trying to find that balance but it was fun to see how differently it is played, whether running around with the jack or parking it and loading it.  

 

I also saw the screen jump a little when being played.  It is odd that I didn't get that on my hardware or TV.  I have to check my settings in Stella, as I had only seen any screen movement over 263 scanlines.  Over time I would tweak the code and I would get the jump to occur less frequently but after last night I looked through the code.  I had noticed that it only occurred on the bottom half of the screen so I took a look at the code and I think I found the issue.  Originally I had thought I just had too much stuff going on at once so before I would shift code around here and there which seemed to only make minor changes in frequency or I would make a change, seemingly fixing the issue, only to have it return when I added more code. So I rewrote this little bit of code this morning:

 if !d{0}  then goto THROW_BALL
  
 if d{0} then ballheight=3:ballx=player0x+6:bally=player0y-5
 if d{0} && joy0left then ballx=player0x 
 if d{0} && s{7} && joy0up then ballx=player0x+3:bally=player0y-7
 if d{0} && s{7} && joy0down then ballx=player0x+3:bally=player0y+3
 if d{0} && !joy0left && !joy0right && !joy0up && !joy0down then ballx=player0x+3:bally=player0y-3

to this:

 if !d{0}  then goto THROW_BALL

 if d{0} then ballheight=3:ballx=player0x+6:bally=player0y-5
 if joy0left then ballx=player0x 
 if !s{7} then goto SKIP_UPDOWN
 if  joy0up then ballx=player0x+3:bally=player0y-7
 if  joy0down then ballx=player0x+3:bally=player0y+3
SKIP_UPDOWN
 if  !joy0left && !joy0right && !joy0up && !joy0down then ballx=player0x+3:bally=player0y-3

and so far (fingers crossed) and it seemed to have stopped.

 

There was also that bug when they went from the minigames to the main game and it was back on the bonus round with the rain dropping.  While I added variable resets, I had forgotten that in that particular minigame it also uses the code from the bonus round so I forgot to reset the variables from that part of the code.  I think that might have been the issue so I added a couple more resets.

 

I updated the .bin with the fixes in the first post, which also has some other minor fixes to the mini-games. I thought I had updated it yesterday but it looked like I never added the newer file.

 

 

 

 

[[WIP] CROSSDOCK]

So I had thought I had finished 98% of the game, with most if not all main bugs rooted out leaving just some tweaking.  And for the most part everything runs fine leaving me the tweaking to do... but then I let my son play the game and found a few more bugs but I will still share most recent build!

 

As I had mentioned in previous posts, I had expanded to 16k and added a bonus round that featured Dock Boy unloading a truck on an outside loading area while avoiding various animal and environmental obstacles.  After James' comment regarding the bonus round looking almost like a stand alone game, it got me thinking how difficult it would be to insert a few lines here and there and make a separate minigame.  I thought that sounded like a fun challenge to see if I can figure it out and to my surprise it wasn't that hard.  

 

But...

 

Since the lines of code that I needed to make a standalone minigame were only a couple hundred bytes, I had plenty of space so I had a couple other game ideas that were simple that I thought I could implement reusing some of the code from the maingame, such as sprites or movement code.  This was something I used to love in old games growing up, like being able to play the Melee in Star Control so I thought it would be cool to add. 

 

I added 2 other minigames - one where I took the code from my first Batari Basic game (the original Bag Boy), cleaned it up, and then added some things that were from my notes from 2 years ago, as well as a couple elements similar to what was in Crossdock and the new Bag Boy.  The other game a "pong" game.

 

Here is a brief description:

 

Carts - grab a cart, dodge the cars, and return the cart to the moving cart corral at the top of the screen.  As you play some varying obstacles will appear.

 

Trolley Volley is a pong game.  I originally was going to call it Cart Pong but remembering what was mentioned about Joust Pong, I looked for a retail themed alternative.  Seeing my Pong clones had many Volley Ball and Tennis variations, and some call shopping carts Trolleys, I found the name fitting and fun.  This is a 2-player only game.  Each player controls a bar.  While the cart trolley bounces back and forth, Dock Boy can be seen dropping boxes.  If you hit the box with the cart the box kind of enters the play and will bounce back and forth.  If a player misses the box their bar will shrink.  The statusbar shows which player is winning the round and will change color based on who is in the lead. You can also grab the trolley, move up or down, and release it. 

 

Dock Boy! is the ZPH-inspired stand alone that is basically the bonus round from Crossdock, but with some minor changes.  Basically you have never-ending trucks to unload from an outside dock.  I think each truck has about 14 boxes on it that you must unload but you must avoid the various animal and environmental nuisances. 

 

And now the bugs my son found (FIXED 7/2/20):

 

1. After playing minigames and then playing the main game, the conveyor belt stopped working.

2. With box throwing and small pallets selected, after playing the minigames, when the boxes were thrown they made no sound and did not move down - just to the side.

3. With the same options as #2 DockBoy stopped moving, even after the timer ran out.

4. Also it seemed the statusbar had stopped working and remained full.

5. When moving down and hitting a box, the life color changed colors. 

 

My guess is that I did not reset all the variables used in the minigames for the first 4.

 

 - All but the lifecolor is fixed and updated.  Looks like a variable might have been responsible for the statusbar so when my son scored points in Carts it flipped a bit in the main game that locked in the statusbarlength.

 

Here is a gameplay video on YouTube.

Anyway, I will add a new binary in the first post.

[Doggone It!]

Thank you for sharing both your game and your story.  From watching and playing your game and reading your post one can sense your personal experiences in the care in which you presented every aspect, from the playfield to the people and dogs.  I wish you well in your continued journey.  I look forward to showing your creation with my children, as I believe they would truly enjoy it as well.

And I had commented on the video but was unaware that the game does speed up.  Your chart and instructions are very nice too.  If you ever get this made into a cart that would be awesome, as I think this is a perfect example of a game that deserves to be out there in every possible way! 

[Question about DPC+ kernel and playfield resolution]

I thought playfield does not extend to the edge of the screen but background does. Is that what you are referring to?

[Cross Platform Playfield / Sprite Creator]

23 minutes ago, Random Terrain said:

 

You can copy just the code when using VbB:

 

randomterrain.com/atari-2600-memories-batari-basic-vbb.html#playfieldedgrab

Learn something every day! Some of these features had escaped me. On the plus side with this new editor, I can probably play around with things on the go. Either way, the more tools the better!

[Doggone It!]

Now this is cool! I just played it briefly on Javatari on my phone but I love everything - the gameplay, graphics, power ups, theme. All are great and work well. 

[Cross Platform Playfield / Sprite Creator]

Another tool that looks great! I currently use Visual Batari Basic but sometimes it can be finicky and I find myself constantly tweaking the playfield, inserting the playfield, and running the program to see if I like it.  Your program is something I could definitely benefit from, as I could then quickly whip up a playfield and copy just the code.

[Knight Guy in Low Res World: Castle Days]

I bet these would go well in Orlando, home of the UCF Knights...

[HMOVE in Standard Kernel]

I was curious.

 

I was using a standard kernel but was wondering if it is possible to use HMOVE to reuse Player1 sprite and if they got close one would switch to a missile or would it require more than it is worth?

 

I had tried alternating sprites using a counter (if q{0} then..., If q{1} then...) And for one of the sprites it didn't look to bad but the other it seemed to flicker more noticeably. I didn't know if there was a trick to use. I had only tested them when stationary so I didn't know if moving would help or if I used something like a 8.8 variable or if that wouldn't apply.

 

 

[[WIP] CROSSDOCK]

In Crossdock I had started playing around with playfield variables to save space and cycles. I had a thought about using this tool.

 

You load bays in the top of the screen. Once each bay is filled a line is drawn "closing" the bay. I had originally used pfhline but changed to using playfield variables. 

 

When I added a second screen for the bonus and switched back and forth between the two, I experienced an issue - the bays would be reset because the whole playfield will draw. Another issue is that I would have liked to try and save the values of the bay doors but I was out of variables. 

 

I had the thought of redrawing the entire playfield using playfield variables and in my second screen I don't use the top row. Since I use pfheights and pfcolors, I was considering using the top row color bug to save the values of the doors using the playfield variables and then change the color to black to conceal them and when it is time to return I swap the values, essentially saving your progress.

 

This tool looked to make that task easier in drawing the playfield.  I want to test this out as I think it could be an interesting way to not only redraw parts of the screen but also using those variables. I could also see this being useful in other ways

[atari-sound-forger (intro vid) - jam and code up music riffs in your browser]

I cannot wait to play with this. I would say sound is one of my weakest points so this looks fun.

[[WIP] CROSSDOCK]

31 minutes ago, ZeroPage Homebrew said:

The bonus section looks really fun, it could almost be a stand alone game in itself!

 

- James

I was hoping to give some variation to the gameplay. I was thinking with the different screens, chosen randomly, and the potential for extra points, it would be more fun than just loading pallet after pallet. The 8k version was more an exercise for me so while this version may have some code bloat, I think this achieves my goal. I also looked at a way of integrating some of the ideas I had for my Forklift game idea as a way to play around and see what may work.

 

Many of the screens were a result of me asking my son what he wanted me to try and program.

 

I was just testing it on my AFP and only encountered one bug so far and it is a minor fix. May also change the random generation on a "extra" bonus screen, as I think the probability it appears would be about once every 4000 screens. Should have a chance to work on it tomorrow so hopefully i can get closer to finishing it. 😀