Chaotic Grill (BurgerTime remake) in progress

[Kurt_Woloch]

OK... as they say, a picture says more than thousand words, so I just sketched up a diagram of the possibilities which may occur...

 

 

The first up arrow gives the direction the enemy comes from, black arrows give the following direction if it's not dependent from the player position.

In the right 3 pictures, the colored dots give possible player positions which give the new directions pointed to by the arrows in the same colors.

 

An asterisk says that the mirror of this case may occur and has to be accounted for as well.

 

To explain this, there are six possible patterns an enemy may encounter on an intersection...

 

1. Continuation... in tnis case, continue direction

2. Dead end... in this case, reverse direction

3. L piece... in this case, continue along the L (this may have to be mirrored to a left or right L)

4. T piece with possibility to continue along the same direction... here the direction depends on the player position, and this pattern has to be mirrored as well.

5. T piece leading left or right... here, again, the player position decides which way gets taken

6. Intersection with all ways open... here, again, the player position decides which way to go

 

All of those possibilities can occur relative to any of the 4 directions the enemy may come from.

 

In the pseudo code you've given, I think the "L" is not properly accounted for in all cases.

Let's take, for example, my 3rd drawing, and let's assume that the player is to the upper right of the enemy... in this case, your pseudocode does the following:

 

At intersection:

Current Direction LR? CUD (No, it's up)

Current Direction UP? CLR (-> CLR)

 

CLR:

Compare with player X (which actually should be irrelevant here because there's only one way to continue)

If Left, switch to left if possible, exit (no, player is right)

If Right, switch to right if possible, exit (not possible)

Check current direction, if can't move, use opposite direction. (this would take the opposite direction, not along the L)

 

Sorry for critizising you...

Edited January 13, 2019 by Kurt_Woloch

[+splendidnut]

OK... as they say, a picture says more than thousand words, so I just sketched up a diagram of the possibilities which may occur...

 

Chaotic Grill Enemy Movements.PNG

 

The first up arrow gives the direction the enemy comes from, black arrows give the following direction if it's not dependent from the player position.

In the right 3 pictures, the colored dots give possible player positions which give the new directions pointed to by the arrows in the same colors.

 

An asterisk says that the mirror of this case may occur and has to be accounted for as well.

 

To explain this, there are six possible patterns an enemy may encounter on an intersection...

 

1. Continuation... in tnis case, continue direction

2. Dead end... in this case, reverse direction

3. L piece... in this case, continue along the L (this may have to be mirrored to a left or right L)

4. T piece with possibility to continue along the same direction... here the direction depends on the player position, and this pattern has to be mirrored as well.

5. T piece leading left or right... here, again, the player position decides which way gets taken

6. Intersection with all ways open... here, again, the player position decides which way to go

 

All of those possibilities can occur relative to any of the 4 directions the enemy may come from.

 

In the pseudo code you've given, I think the "L" is not properly accounted for in all cases.

Let's take, for example, my 3rd drawing, and let's assume that the player is to the upper right of the enemy... in this case, your pseudocode does the following:

 

At intersection:

Current Direction LR? CUD (No, it's up)

Current Direction UP? CLR (-> CLR)

 

CLR:

Compare with player X (which actually should be irrelevant here because there's only one way to continue)

If Left, switch to left if possible, exit (no, player is right)

If Right, switch to right if possible, exit (not possible)

Check current direction, if can't move, use opposite direction. (this would take the opposite direction, not along the L)

 

Sorry for critizising you...

 

Ahhh, that explains it

 

So it looks like I should be able to use my pseudo code to handle cases 4, 5, and 6 well, but I should probably check for cases 1, 2, and 3 and handle them separately since they each only have one outcome based on the incoming direction.

[Kurt_Woloch]

By the way, I created some pseudocode as well in order to see how huge it would really get...

 

If I didn't make any mistake, the code for the enemy incoming in the "up" direction would be the following:

   if ladder_up and not ladder_left and not ladder_right then move up
   if not ladder_up and not ladder_left and not ladder_right then move down
   if ladder_left and not ladder_up and not ladder_right and ladder_down then move left
   if ladder_right and not ladder_up and not ladder_left and ladder_down then move right
   if ladder_left and ladder_up and not ladder_right and player_left then move left
   if ladder_left and ladder_up and not ladder_right and not player_left then move up
   if ladder_right and ladder_up and not ladder_left and player_right then move right
   if ladder_right and ladder_up and not ladder_left and not player_right then move up
   if ladder_left and ladder_right and not ladder_up and player_left then move left
   if ladder_left and ladder_right and not ladder_up and not player_left then move right
   if ladder_left and ladder_right and ladder_up and player_left then move left
   if ladder_left and ladder_right and ladder_up and player_same_ladder then move up
   if ladder_Left and ladder_right and ladder_up and player_right then move right

Since this duplicates many checks, this could be folded into:

If ladder_up then
   if ladder_left then
      if player_left then
         move left
      else
         if ladder_right then
            if player_same_ladder then
               move up
            else
               move right
            end if
         else
            move up
         end if
      end if
   else
      if ladder_right then
         if player_right then
            move right
         else
            move up
         end if
      else
         move up
      end if
   end if
else
   if ladder_left then
      if ladder_right then
         if player_left then
            move left
         else
            move right
         end if
      else
         move left
      end if
   else
      if ladder_right then
         move right
      else
         move down
      end if
   end if
end if

In this code ladder_xx means there's a ladder or platform in that direction leading from the intersection and player_xx means the player is in that direction seen from the enemy.

 

This pseudocode is in VB style... in C style it would look a bit differently.

 

:-)

Edited January 13, 2019 by Kurt_Woloch

[+splendidnut]

Thanks to Kurt Woloch (as seen in previous posts), I believe all the enemy movement issues have been eliminated.

 

Enjoy.

 

chaoticGrill-2019-01-20.bin

[NostAlgae37]

Thanks to Kurt Woloch (as seen in previous posts), I believe all the enemy movement issues have been eliminated.

 

Enjoy.

 

chaoticGrill-2019-01-20.bin

 

I just played this and on stage 3 the enemies walk upwards on invisible ladders in the center of the screen until they either disappear completely at the top (never to return) or emerge at the bottom of the screen (and keep cycling in that fashion), so it appears that there are still bugs to be ironed out.

[Kurt_Woloch]

I just played this and on stage 3 the enemies walk upwards on invisible ladders in the center of the screen until they either disappear completely at the top (never to return) or emerge at the bottom of the screen (and keep cycling in that fashion), so it appears that there are still bugs to be ironed out.

 

Yes, this happens to me as well. In addition to that, I've sometimes seen the enemies turn around on the spot (on a three-way intersection) which they are only supposed to do on a dead-end, and I've also seen them leaving the platform for a ladder even though I was on the same platform in front of them, or leaving a ladder for a platform even though I was on the same ladder. But with platforms, they do this in the arcade version as well sometimes, so this may not be such a big mistake.

[hizzy]

Was just about to post about stage three and the enemies.

 

This is really a great version!!! Thank you for your hard work

[TrekMD]

I've experienced the same glitch but, otherwise, this plays great! It si one awesome port of the game.

[iesposta]

“Burger Diner”
All our chefs make are burgers.
So popular, they say they dream of making burgers!

Self-serve soda, ice cream, pepper, etc.
New this year! Self serve instant fries made the way you choose - always hot (also includes salt & pepper packets).

[+splendidnut]

It's been awhile, (been busy/taking a break).. so I'll give an update:

• Fixed most/all of the occurances of the enemies walking of the screen (bad layout data)
• New SCOREBOARD... 96pixels wide... flickering at 30hz.
• New scoreboard font.. thanks to NostAlgae37
• Fixed issue when pepper button is held down during gameplay.... you won't accidentally use all your peppers now.
• Improved enemy/burger collision detection so that they should no longer get squashed instead of riding the burger.
• Fixed positions of bonus items.

I've almost got the new flicker management done... there are still some issues (especially when items are displayed) that need to be worked out, so it's not enabled.

 

Enjoy.

 

 

chaoticGrill-2019-02-17.bin

[hizzy]

AMAZING!!!!!

[Kurt_Woloch]

Thank you for posting this new version! The enemy movement code looks better now, and that scoring panel on top looks good as well, but there's still a few things that occured to me...

 

If you're on a ladder, and enemies are on the same ladder as you and come to an interception, they usually don't continue to follow you, but turn left instead (that's the absolute left side of the screen, not relative to their movement), whereas in the arcade they would continue to follow you.

 

If you let enemies ride down on a burger part, in the arcade version they get a badge showing the scoring (I think it uses one of the enemies' sprites for that because that enemy disappears while the badge displays). Your version doesn't do this. Also, I'm not sure how many layers get added for each additional enemy riding the burger part. Could it be it's the same number of levels a burger part falls whether there's one or multiple enemies on it?

 

The game looks pretty easy and stays that way, I think the arcade version is a bit harder. You could make it harder in progressive rounds by speeding up the enemies once you've cleared all the patterns once.

It's been awhile, (been busy/taking a break).. so I'll give an update:

• Fixed most/all of the occurances of the enemies walking of the screen (bad layout data)
• New SCOREBOARD... 96pixels wide... flickering at 30hz.
• New scoreboard font.. thanks to NostAlgae37
• Fixed issue when pepper button is held down during gameplay.... you won't accidentally use all your peppers now.
• Improved enemy/burger collision detection so that they should no longer get squashed instead of riding the burger.
• Fixed positions of bonus items.

I've almost got the new flicker management done... there are still some issues (especially when items are displayed) that need to be worked out, so it's not enabled.

 

Enjoy.

 

 

chaoticGrill-2019-02-17.bin

[xybot67]

Thanks for the update. Brilliant as usual!

[+splendidnut]

Thank you for posting this new version! The enemy movement code looks better now, and that scoring panel on top looks good as well, but there's still a few things that occured to me...

 

If you're on a ladder, and enemies are on the same ladder as you and come to an interception, they usually don't continue to follow you, but turn left instead (that's the absolute left side of the screen, not relative to their movement), whereas in the arcade they would continue to follow you.

 

If you let enemies ride down on a burger part, in the arcade version they get a badge showing the scoring (I think it uses one of the enemies' sprites for that because that enemy disappears while the badge displays). Your version doesn't do this. Also, I'm not sure how many layers get added for each additional enemy riding the burger part. Could it be it's the same number of levels a burger part falls whether there's one or multiple enemies on it?

 

The game looks pretty easy and stays that way, I think the arcade version is a bit harder. You could make it harder in progressive rounds by speeding up the enemies once you've cleared all the patterns once.

 

Enemies will follow you in certain directions / certain cases. In general they favor turning at intersections, especially at 4-way intersections. There are certain cases in which they will follow you... but at this point in time, I'm not too concerned. The arcade seems to be somewhat inconsistent in whether they follow you or not.

 

With enemies riding the burgers, they only add a single layer per enemy vs. the arcade which adds two. They can also able be sent for a ride again due to this. Both of these could be changed to match the arcade, but I'm not really sure they need to be. I like being able to race to send the enemy for a ride again.

 

As for the "floating score", that's not implemented yet... it's been on the TODO list since December as can be seen in a previous post. Increasing difficulty is also on the list (requires more enemy movement reworking).

[+splendidnut]

I probably should clarify that I'm not going for complete arcade accuracy. I am trying to get close, just not worried about being perfect

 

Part of this is due to my personal goal of avoiding the use of ARM programming in this project. I've already bumped into "not enough time" issues already and have done quite a bit of work behind the scenes to make sure every build I post still works without issue (solid 262 scanlines). And this is part of the reason why you haven't seen better flicker management revealed.

 

There are also things that I've enjoyed in the past that I've lost with code updates/changes related to making things more arcade accurate. Previously, there was a nice opening move in which you could squash 3 enemies in one go if you ran up the ladder and waited in a certain spot... which was lost with the big enemy code rewrite/rework. So, in that aspect, I'm trying to preserve the fun little things I've got left

 

I will say that one of the BIG goals in this project is to release the source code at some point and maybe do a postmortem. I started the blog with that goal in mind. But, after picking this project back up again in August of last year, I decided to focus my energy working on the game itself.

 

 

There are also some ideas I've been tossing around after seeing the things some other projects have done... and yes, I'm being vague on purpose. There was almost a big surprise over Christmas, but playing Mappy stole some time and so I didn't even work on that (<redacted>) item.

 

 

I'd really like to finish this project up... I already have a few prototypes started for other projects.

[StephenJ]

Splendidnut,

"...I'm not going for complete arcade accuracy. I am trying to get close..."

That's perfectly fine with me and I would think most other folks as well.

"...I'd really like to finish this project up..."

I hear that. As I said before..."Can't wait to get the cartridge..."

[BIGHMW]

Nice!!! Now we get a complete scoreboard with lives, peppers and the score at the same time, and the font looks great!!!

[BIGHMW]

Well, I got to level 3 for the first time (I am using the difficulty switch set at B) and this game is slowly becoming one of my favorites, of my almost 650 games I have on my Harmony Encore Multicart, this is in the top 10, alongside Missile Command, Asteroids, Tempest, Pac-Man 4K, Centipede, and Yars' Revenge among them.

[+D Train]

happy memorial day weekend!

 

hope that all is well!

[Kurt_Woloch]

I just played the last version again and got a strange error... I died by being touched by two enemies at once, and strangely, the game didn't go on from the dying sequence even though I still had at least 4 lives in reserve. I also had > 9 peppers.

[+splendidnut]

On 6/1/2019 at 2:40 PM, Kurt_Woloch said:

I just played the last version again and got a strange error... I died by being touched by two enemies at once, and strangely, the game didn't go on from the dying sequence even though I still had at least 4 lives in reserve. I also had > 9 peppers.

Yeah... I believe there's a race condition that can occur where half of the game logic believes the level is done and the other half doesn't.  I believe the issue lies in the "last minute" burger scoring code.  I thought I had fixed it, but apparently it's still lurking... that or I have fixed/tweaked something AFTER posting that last build.  I'm not sure which as the issue seems to be a rare occurence.

 

Currently, events are loosely coupled - there is no central event system.  I probably need to make one to prevent this sort of issue. 

[+splendidnut]

On 5/26/2019 at 3:29 PM, D Train said:

happy memorial day weekend!

 

hope that all is well!

Thanks... the past several weekends have contained lots of time outdoors doing yard work and gardening... And I just got back from a much needed vacation from the mid-south (Virginia, North Carolina, Tennessee).

 

Hopefully, I've been rejuvenated enough to get back to work on ChaoticGrill.

[+splendidnut]

So here is another build/update...a bit oldish (last month, from May 7th).... which has "buggy" flicker management code BUT much improved music.

 

I've been putting off posting a build since I've only been working sporadically on it AND that work has been all over the place, mainly involving small tweaks and code reorganization.  The biggest accomplishment was sitting down using TIATracker (by @Kylearan) to work out the level start and main theme music, and then rewriting my music code to play the 2 track music thru the TIA (can't use DPC+ music/sound capabilities).

 

I've also started work on a new title screen (not shown yet)... And added an AtariAge splash screen.

 

Currently I'm in the midst of looking at the Burger handling code... as it is probably the most CPU intensive portion of the game which is probably the main cause of the jitter in the attached build.

 

Enjoy!

chaoticGrill-2019-05-07.bin

[hizzy]

You should be very proud of this! It's an amazing accomplishment. I can't believe how much better your game is than the OG that came out for the 2600. I hope this ends up on a cart!

[TrekMD]

Thanks for continuing to work on this excellent port!