Jump to content
splendidnut

Chaotic Grill (BurgerTime remake) in progress

Recommended Posts

Thank you for the update!

 

Here's a few things I noticed...

- The game currently doesn't give you any extra lives. In the original version, you get an extra life every 10,000 points (maybe dependent on DIP switch settings).

- The music sounds a bit strange with both voices being the same, only played in a different register, and the level start and dying music doesn't correspond well to the original one.

- There seems to be bad debouncing on the pepper... it sometimes happens to me that I want to spray pepper once, but lose two units of pepper in the process. Also, when starting the game with the fire button, one pepper usually gets wasted because it's being fired right at the start.

- The enemies spawn pretty suddenly and may spawn on top of the player (which happened to me once) while in the original version they always come in from the side so you can see them before they collide with you.

- There seem to be some scoring defects. If you end the round by completing all the burgers, and the last burger part has got enemies riding on it, you don't get the score for the enemies riding the burger.

- The bonus items are in different positions to the original versions. On the 6th screen the bonus item is even in an unreachable position!

- After completing the 6th screen, the title screen reappears and has to be ended by the fire button (wasting pepper) before the cycle repeats.

- On some occasions I "squashed" an enemy being on the same platform as me which should have been resulted in the enemy riding the burger part instead.

Edited by Kurt_Woloch

Share this post


Link to post
Share on other sites

- There seems to be bad debouncing on the pepper... it sometimes happens to me that I want to spray pepper once, but lose two units of pepper in the process. Also, when starting the game with the fire button, one pepper usually gets wasted because it's being fired right at the start.

 

Stop holding the button down :) While pepper is spraying, the button is ignored until the spray is done (spray currently lasts for 0.5 seconds). Once the spray is done, it can be immediately retriggered if the button is still pressed. As a fix, I can lengthen the spray time a bit and add a lock-out until button is released. A flaky button would still potentially cause issues regardless of any software fix.

Share this post


Link to post
Share on other sites

well, i havent tossed my M-network cart just yet- it being such a unique cart ive held onto it, and even though the new game has way better controls, theres something sort of nostalgic about the original sticky controls and color scheme but if you had to big a better one it would have to be yours still.

Share this post


Link to post
Share on other sites

Probably should give one last update for this year (2018)....with a buggy yet feature complete (maybe?) version.

 

Notes from week of December 17th (12-21-2018):

- converted to using new level layout structure..

code paths are still similar to previous implementation

Level Data was 52 bytes... now is 60

(nibbles specifing allowed directions at intersections)

 

- worked on level drawer which utilizes new level layout data

- will help reduce storage required for levels

 

- played around with burger colors

- partly as an attempt to fix remaining burger dropping issues

- partly because of tomatoes appearing like purple onions on some systems

 

 

Notes from last week of December 2018:

- finished new level loader code

Now uses the same data structure that is used to control movement (player/enemy)

- tweaked Pepper spray

- added scoring for enemies riding to the bottom

- added lives and pepper counters

- added items using current flicker method (when item is shown, all sprites flicker at 20hz, so it's pretty harsh)

- added makeshift title screen (displayed using the main game kernel)

- scoreboard flashes between score and lives/pepper

- fixed music engine to allow selection of music playing (for start of level, player death, and level victory music)

 

Things missing:

- Flicker management (lots of code written... but not finished yet, so cannot be turned on... it's an all or nothing kind of thing)

- Floating scores for enemies dropped onto burger pile (little more involved since multiple enemies need to be hidden)

 

Still need to:

- load level layout data into DPC memory and access it that way

which would allow level data to be stored in only one bank

(as opposed to 3 copies, burger/movement/level banks)

- work on enemy logic (handle dead ends, avoid turn arounds, etc...)

 

There are probably a few other things I added or broke in this build.

 

Enjoy!

 

attachicon.gifchaoticGrill-2018-12-31.bin

 

 

edit: Had to fix the year in the notes... apparently I was a little too ready for the new year to start.

 

It's very difficult to control when you are trying to turn onto or off of a ladder.

  • Like 1

Share this post


Link to post
Share on other sites

 

It's very difficult to control when you are trying to turn onto or off of a ladder.

 

 

I thought I may have broken that when reworking the level structure. Thank you for confirming my suspicions.

  • Like 2

Share this post


Link to post
Share on other sites

Fixed a few things:

  • Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...)
  • Added extra life bonus for every 10,000 points.
  • After completing level 6, the levels should loop back around without ending up at the title screen.

Enjoy.

chaoticGrill-2019-01-08.bin

  • Like 6

Share this post


Link to post
Share on other sites

Fixed a few things:

  • Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...)
  • Added extra life bonus for every 10,000 points.
  • After completing level 6, the levels should loop back around without ending up at the title screen.

Enjoy.

attachicon.gifchaoticGrill-2019-01-08.bin

 

Really wonderful work here, SplendidNut! :thumbsup:

  • Like 1

Share this post


Link to post
Share on other sites

Hi Splendidnut! Appreciating the hard work!

 

The bonus items are certainly better now, but what does actually trigger them appearing? Is it a timer or something? As far as I know, in the arcade version you have to place a certain number of burger parts on the final plates in order for the bonus item to appear... if you just run around and no burger parts fall, it certainly doesn't appear. I think it was for every 3 burger parts placed or so... also, as far as I remember, on Level 4 the bonus item should be at the top of the screen, not in the middle.

 

I also managed to accumulate 10 pepper and noticed that the peppers are counted in hexadecimal, thus after 09 peppers it counts up to 0A.

 

Otherwise, good work!

 

Fixed a few things:

  • Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...)
  • Added extra life bonus for every 10,000 points.
  • After completing level 6, the levels should loop back around without ending up at the title screen.

Enjoy.

attachicon.gifchaoticGrill-2019-01-08.bin

  • Like 1

Share this post


Link to post
Share on other sites

Fixed a few things:

  • Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...)
  • Added extra life bonus for every 10,000 points.
  • After completing level 6, the levels should loop back around without ending up at the title screen.

Enjoy.

attachicon.gifchaoticGrill-2019-01-08.bin

 

Awesome. I'll check it out.

Share this post


Link to post
Share on other sites

Fixed a few things:

  • Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...)
  • Added extra life bonus for every 10,000 points.
  • After completing level 6, the levels should loop back around without ending up at the title screen.

Enjoy.

attachicon.gifchaoticGrill-2019-01-08.bin

On the first screen I lured one of the baddies to the 3rd floor and had him follow me onto the (second) burger part and the baddie ended up on the first floor (instead of under it) in the stunned state instead of beneath the screen. I couldn't reach it in time to find out what would happen if I ran into it. I'm assuming that is not supposed to happen. The baddies are able to switch direction in the middle of the bun. I noticed this in the old version too. Turning off of and onto the ladders is better, but it still requires a good deal of precision.

Looks great though. Hopefully it will look even better with your sprite driver.

Share this post


Link to post
Share on other sites

I spent some time playing the latest version yesterday and it's remarkable what you've created, splendidnut! Great job!

 

..Al

  • Like 2

Share this post


Link to post
Share on other sites

This is really amazing and so glad someone decided to create an updated version of Burger Time for the 2600. So, thank you splendidnut! I've tested the ROM. In the third maze, the enemies got stuck trying to get to me on one of the platforms. They just didn't seem to know how to get to me because when I moved to a different part of the maze they started to chase me again. THe control is smooth also. So, thanks again.

  • Like 1

Share this post


Link to post
Share on other sites

Hi Splendidnut! Appreciating the hard work!

 

The bonus items are certainly better now, but what does actually trigger them appearing? Is it a timer or something? As far as I know, in the arcade version you have to place a certain number of burger parts on the final plates in order for the bonus item to appear... if you just run around and no burger parts fall, it certainly doesn't appear. I think it was for every 3 burger parts placed or so... also, as far as I remember, on Level 4 the bonus item should be at the top of the screen, not in the middle.

 

I also managed to accumulate 10 pepper and noticed that the peppers are counted in hexadecimal, thus after 09 peppers it counts up to 0A.

 

Otherwise, good work!

 

 

I completely didn't realize that the bonus items weren't timer driven. I basically threw them in there the easiest way I could, with a timer that makes them appear after a certain time (~16 seconds) and then disappear if not grabbed quick enough (after ~16 seconds). And I definitely didn't think about the hex vs decimal issue. Thanks for pointing that out.

 

Also, thank you for providing your ideas on how to implement the enemy logic... it's definitely given me additional things to think about. I'll probably opt for a more code based solution as opposed to a table driven solution since RAM usage is tight (saving space for flicker management usage) and the directional data would probably need some translation code, thus eliminating any speed advantage. I haven't quite got the chance to implement any of this yet since working on the level data structure/loader code over the Christmas holiday. I needed a break and ended up working on the missing game features instead.

 

I appreciate the feedback and bug reports. Please keep them coming :)

Share this post


Link to post
Share on other sites

On the first screen I lured one of the baddies to the 3rd floor and had him follow me onto the (second) burger part and the baddie ended up on the first floor (instead of under it) in the stunned state instead of beneath the screen. I couldn't reach it in time to find out what would happen if I ran into it. I'm assuming that is not supposed to happen. The baddies are able to switch direction in the middle of the bun. I noticed this in the old version too. Turning off of and onto the ladders is better, but it still requires a good deal of precision.

Looks great though. Hopefully it will look even better with your sprite driver.

 

Burger pieces fall one story when knocked down... they fall one additional story for each enemy riding them. So if I'm understanding your description correctly, it sounds like they are functioning correctly.

 

I definitely need to look at the player code because I know that it lost some functionality after reworking the level data structure code.

 

Thanks!

Share this post


Link to post
Share on other sites

well, i havent tossed my M-network cart just yet- it being such a unique cart ive held onto it, and even though the new game has way better controls, theres something sort of nostalgic about the original sticky controls and color scheme but if you had to big a better one it would have to be yours still.

 

There definitely is some charm in the original game. After working on this project, I definitely have a better understanding of why it is the way it is... there's a lot going on game-logic wise.

Share this post


Link to post
Share on other sites

 

Burger pieces fall one story when knocked down... they fall one additional story for each enemy riding them. So if I'm understanding your description correctly, it sounds like they are functioning correctly.

 

I definitely need to look at the player code because I know that it lost some functionality after reworking the level data structure code.

 

Thanks!

 

Well, that's different from the arcade version. I just replayed it, and there burger parts definitely fall down two additional stories for each enemy riding them. With two enemies on them, in the first level you can clear a whole burger by knocking down the uppermost burger part.

 

And I've also checked the bonus items, and at least in the first levels, they appear after each 4 burger parts dropped onto the plate.

  • Like 1

Share this post


Link to post
Share on other sites

Well, I thought a bit about what a more code-based solution could look like, and it doesn't rule out tables beforehand. In my original proposal, you probably would have needed up to 4 bytes (one for each direction) to keep score, and then, temporarily, two more to keep the best value so far and which direction it belongs to. You could spare some of the bytes by doing all the checks for each possible direction at once, scoring it and then check if it's better than the previous best direction. That way you would only need 3 bytes total (one for the running total for the currently checked direction, one for the best score so far and one for the direction it belongs to... and you could probably pack the last two values into one byte since the best direction only needs 2 bits and the score only needs 4.

 

The flicker management probably is a different beast... the question is, what do you need all that RAM for? I think you should differentiate RAM that has to be retained from frame to frame (while other logic is being done) and RAM that only gets used temporarily. In this case, the 3 bytes for doing the direction scoring only are being used temporarily... once the enemy has decided where to go, all that needs to be retained is its direction, and the other bytes can be reused as temporary storage for another enemy or a different block of logic.

 

As a more code-based solution, you could of course also do a decision tree of sorts, but this could get HUGE... example:

 

Current dir. right? -> CR
Current dir. left? -> CL
Current dir. up? -> CU
Current dir. down? -> CD

CR:
Ladder up? -> CRLU
Ladder down? -> CRLD
Platform right? -> CRPR
Platform left? -> move left
-> move up (out of bounds)

CL:
Ladder up? -> CLLU
Ladder down? -> CLLD
Platform left? -> CLPL

Platform right? -> move right
-> move up (out of bounds)

(The "out of bounds" code applies if the enemy has been knocked to the plates and has to return to the proper maze - this would probably move it up).

 

The further labels not displayed here then would do more checks for the other ladders / platforms and the player position in order to come to a decision. That way you would probably use the least possible number of checks, but also much code duplication.

 

Also, thank you for providing your ideas on how to implement the enemy logic... it's definitely given me additional things to think about. I'll probably opt for a more code based solution as opposed to a table driven solution since RAM usage is tight (saving space for flicker management usage) and the directional data would probably need some translation code, thus eliminating any speed advantage. I haven't quite got the chance to implement any of this yet since working on the level data structure/loader code over the Christmas holiday. I needed a break and ended up working on the missing game features instead.

Share this post


Link to post
Share on other sites

The flicker management probably is a different beast... the question is, what do you need all that RAM for? I think you should differentiate RAM that has to be retained from frame to frame (while other logic is being done) and RAM that only gets used temporarily. In this case, the 3 bytes for doing the direction scoring only are being used temporarily... once the enemy has decided where to go, all that needs to be retained is its direction, and the other bytes can be reused as temporary storage for another enemy or a different block of logic.

 

Mentioning flicker management probably was not the best thing to do since the RAM usage only really applies to flicker management code not used in the public builds.

 

You don't think I've made it this far without keeping track of RAM usage? :)

 

RAM usage is as follows (not necessarily in this order):

  • 38 bytes for player, 4 enemies, bonus item, pepper spray
  • 6 bytes for sound/music routines
  • 36 bytes for tracking burgers in motion (stationary burgers only exist as Display Data in DPC+ RAM)
  • 5 bytes for miscellaneous game variables
  • 16 bytes reserved for future flicker management code (most are currently used when the code recompiled with the flag enabled)
  • 9 bytes for game variables that exist between levels (score, lives, etc...)
  • 18 bytes for temporary variable storage and call stack (call stack can take upto 10)

There are a couple of places where a byte or two could be saved to expand the temporary variable space, but I'm trying to hold off on that for now. Ultimately, I only have around 8 temporary variables to use. In the case of the enemy movement code, I believe they are mostly used up... although, I know I did free a couple after converting the level structure.

Share this post


Link to post
Share on other sites

As a more code-based solution, you could of course also do a decision tree of sorts, but this could get HUGE... example:

 

Current dir. right? -> CR

Current dir. left? -> CL

Current dir. up? -> CU

Current dir. down? -> CD

 

CR:

Ladder up? -> CRLU

Ladder down? -> CRLD

Platform right? -> CRPR

Platform left? -> move left

-> move up (out of bounds)

 

CL:

Ladder up? -> CLLU

Ladder down? -> CLLD

Platform left? -> CLPL

Platform right? -> move right

-> move up (out of bounds)

(The "out of bounds" code applies if the enemy has been knocked to the plates and has to return to the proper maze - this would probably move it up).

 

The further labels not displayed here then would do more checks for the other ladders / platforms and the player position in order to come to a decision. That way you would probably use the least possible number of checks, but also much code duplication.

 

 

This can be reduced if you concentrate on just the axes, combining to form left/right and up/down code branches. The out of bounds is already taken care of when the enemy recovers from being dropped; it's a completely separate code branch.

 

For the general decision logic, my thinking is as follows (slightly more minimized pseudo-code than yours)

 

At intersection:

Current Direction LR? CUD

Current Direction UP? CLR

 

CUD:

Compare with player Y

If Up, switch to up if possible, exit

If Down, switch to down if possible, exit

Check current direction, if can't move, use opposite direction, exit

Use same direction

 

CLR:

Compare with player X

If Left, switch to left if possible, exit

If Right, switch to right if possible, exit

Check current direction, if can't move, use opposite direction.

Use same direction

 

Current direction is stored in the same form as the level layout data, each of the four directions uses a bit:

;-- Directions  (uses different bits for each direction to allow multiple directions)
DIR_RIGHT = 8
DIR_LEFT = 4
DIR_UP = 2
DIR_DOWN = 1

Check current direction would be a simple AND and branch statement.

 

This follows along in similar ways to how the code flows now... my code just hasn't evolved to this point yet.

Share this post


Link to post
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.

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