Jump to content
IGNORED

Medieval Mayhem - 2600


SpiceWare

Recommended Posts

I've redone the fireball/shield collision routines. This should address the bounce-thru problem when the fireball would hit the left/right* side of the shield. Side bounces are now redirected forwards.

 

Fireball Flareups are now in place. You'll take out your own castle walls if you hold onto a fireball for too long.

 

Also did some minor font fixes in the main menu.

 

 

* front of shield always faces away from castle, back of shield always faces towards castle, so left/right are the other 2 sides

mm20060819NTSC.bin

mm20060819PAL.bin

Link to comment
Share on other sites

No comments on the flareups :?

 

In this update I changed the ball's priority so the flareups are visible over the shields. I think it looks better this way.

 

Also added preliminary AI catch routines working.

 

I played two games this morning - really hard! I couldn't score a single point! The fireballs look great.

 

Here are some minor problems I noticed:

 

* Shallow angles can fail to reflect. I saw a ball moving slowly downward bounce and continue downward, busting out most of one of the computer players' walls

* Computer players on the right side tend to dribble exceedingly long - some variation in how they align themselves to the ball might encourage slightly different outcomes, or maybe have them grab the ball at different intervals when holding is allowed, like have one player "like" to hold the ball, while another doesn't.

* The upper-right player would reflect the ball at me, but never took advantage even if I left my guard down on that side - he would grab the ball, wave it in my direction, but then release it at the guy in the lower-right corner - always!

* Computer should play more defensively when he has a hole all the way through his wall, if possible. By moving to the lower-right corner with the ball, then zipping as fast as I could to the lower left and releasing, I could always bait the lower-left player away from the growing hole in his wall. BTW, the same technique would not work against the upper-right player, who was always too fast - he even seemed to jump to block the ball.

* Screen shifted somewhat in Z26 when a lot was happening - you may need to dedicate a few more scan lines to processing time.

 

Other than that, amazing game!

 

I think some "personality" settings (like differences in how much they like to hold the ball, which could change from round to round) for each computer player would help the game avoid falling into a "patterns" solution for the human player, and solve the minor issue of the tedious dribbling between computer players.

Link to comment
Share on other sites

Thought of one more thing about the AI (I know it's still preliminary, but I don't want you to think I missed this), which is that after I got killed, the lower-right-corner player seemed to actually *prefer* to shoot diagonally at my former castle rather than targeting either of the other two players.

Link to comment
Share on other sites

I played two games this morning - really hard! I couldn't score a single point! The fireballs look great.

Yeah, it is hard, I can get a point or two, but purple tends to win the game. The AI players each move at a different speed with 1 (grey) the slowest and 4(purple) the fastest. That makes the game hardest if you play as grey and easiest if you play as purple. I'm going to change the order so grey is fastest. I also think I'm going to have the game default to speed 3 instead of 4, and maybe call the speeds Childs, Slow, Fast and Wicked instead of 1-4. Thanx!

 

Here are some minor problems I noticed:

 

* Shallow angles can fail to reflect. I saw a ball moving slowly downward bounce and continue downward, busting out most of one of the computer players' walls

I've noticed that on occasion as well after adding the "arkanoid bounce" routines that supercat suggested. The original routines would "return to sender" and bounce back the way it came. The new ones try to figure out which side of the brick the fireball hit and bounce back accordingly. Something that sounds easy, but doesn't turn out as easy as expected because the fireball is 2x2 instead of 1x1. I check the 4 points that make up the fireball until one is found that overlaps a brick :ponder: possibly the order the 4 points are checked is causing the problem. The overall result of "arkanoid bounce" is better, but this one thing is annoying. I'll see what I can do.

 

* Computer players on the right side tend to dribble exceedingly long - some variation in how they align themselves to the ball might encourage slightly different outcomes, or maybe have them grab the ball at different intervals when holding is allowed, like have one player "like" to hold the ball, while another doesn't.

Hadn't noticed that - for some reason I tend to play the lower right corner. I really need to get in the habit of testing all four corners.

 

* The upper-right player would reflect the ball at me, but never took advantage even if I left my guard down on that side - he would grab the ball, wave it in my direction, but then release it at the guy in the lower-right corner - always!

The AI player's don't have a strategy per say. If they caught the solitary fireball they start moving left-right-left-right and will, in theory, release it in a random direction. If there's more than 1 fireball then they'll track the closest and also, in theory, release the caught one in a random direction. The problem here is the "random", like all my other "random" is being driven by the FrameCounter which counts from 0-255(wrapping back to 0). I think I'll have to look at using a random number generator for at least some of the events. Problem is I'm down to 1 byte of free RAM...

 

* Computer should play more defensively when he has a hole all the way through his wall, if possible. By moving to the lower-right corner with the ball, then zipping as fast as I could to the lower left and releasing, I could always bait the lower-left player away from the growing hole in his wall. BTW, the same technique would not work against the upper-right player, who was always too fast - he even seemed to jump to block the ball.

I'm not sure I have enough CPU time to also have the AI players look for holes in the wall. I do need to revise the AI player's movement tables so that left/right move faster than up/down(the screen's drawn using 160x100 so moving 1 up/down is further than 1 left/right). The tables are already set up for it, I just haven't calculated the proper values yet. Likewise, I've noticed occasional issues with "which fireball the track" calculation that I need to review.

 

* Screen shifted somewhat in Z26 when a lot was happening - you may need to dedicate a few more scan lines to processing time.

Over in the blog cd-w noticed some screen rolls as well. I use Stella(I'm on a Mac) and hadn't notice. Guess I need to take Ladybug off my Krok Cart and add some more real-Atari testing. Last night I did add breakif { _scan==#263 } into Stella's debugger sure enough, the line count was fluxuating. I made some minor tweeks that reduced, but did not eliminate the problem. I'll be looking at this closer this weekend.

 

 

Other than that, amazing game!

thanks! :D

 

I think some "personality" settings (like differences in how much they like to hold the ball, which could change from round to round) for each computer player would help the game avoid falling into a "patterns" solution for the human player, and solve the minor issue of the tedious dribbling between computer players.

That's an idea, though changing how "random" works might fix it. If not, then I see what I can come up with to free up some RAM to store player personalities.

 

Thought of one more thing about the AI (I know it's still preliminary, but I don't want you to think I missed this), which is that after I got killed, the lower-right-corner player seemed to actually *prefer* to shoot diagonally at my former castle rather than targeting either of the other two players.

probably related to the "random events" all being driven off the frame count. Hopefully the random number generator will solve that.
Link to comment
Share on other sites

One thing I've always wondered about Warlords... How come the fireball never burns out? It'd be interesting if fireballs burned out occasionally to add a sense of urgency to the game.

That would be interesting, though probably complicated to implement. I'd also need RAM to hold "fireball age", which is in short supply.

Edited by SpiceWare
Link to comment
Share on other sites

Over in the blog cd-w noticed some screen rolls as well. I use Stella(I'm on a Mac) and hadn't notice.

 

When I was developing Strat-O-Gems, my kernel started with an INTIM check; if it was 125 or less, it would jump to an error screen; otherwise, it would wait for INTIM to count down to 125 and proceed. The error screen would show the PC of the current kernel call until the fire button was pushed, whereupon the game would resume.

 

You'd probably want to disable the error screen in the released game (if your timing target gets missed occasionally, missing a scan line or two would be far less annoying than jumping out to an error screen!) but it can be very useful for ensuring that any missed scan lines get noticed during testing.

Link to comment
Share on other sites

I used up the last byte of RAM for a random variable and that seems to be helping some of the issues. I then did some rearranging of RAM usage and freed up 4 bytes :D

 

When I was developing Strat-O-Gems, my kernel started with an INTIM check; if it was 125 or less, it would jump to an error screen; otherwise, it would wait for INTIM to count down to 125 and proceed. The error screen would show the PC of the current kernel call until the fire button was pushed, whereupon the game would resume.

While I understand the idea, I'm not sure I follow using 125 or less for INTIM to determine the jump to the error screen. When I'm checking INTIM it's always less than 125 unless I ran out of time, in which case it's > 128. I've started using Stella's breakif command, breakif { _scan==#263 }, and that's catching the screen issues. If I compiled for debug the scores show me which section overran, though I do need to check using #265 as setting debug adds 2 scanlines to prep the digits.

Link to comment
Share on other sites

I have hopefully fixed the screen rolling problem by revamping the distance calculation routines, which are used to determine which fireball to track. The new routines use 8 bit instead of 16 bit math. Let me know if anybody sees any other occurances of screen rolling.

 

I've implemented the random number routines and used them to modified the way the AI players catch fireballs. I've also modified how the AI players work when they've caught a solitary fireball.

 

I removed the "smooth" routines for the AI players when I was trying to save processing time. You'll notice purple moves "jerky" compared to before when it's tracking a slow moving fireball. It's jerky because it'll overshoot in one direction, then overshoot in the other. I plan to add them back since the 8 bit math routines worked so well.

 

I'll be visiting my grandparents for the weekend - my grandpa turns 86 next week! Also plan to visit keilbaca as well and play some mayhem :D

mm20060901PAL.bin

mm20060901NTSC.bin

Edited by SpiceWare
Link to comment
Share on other sites

I have hopefully fixed the screen rolling problem by revamping the distance calculation routines, which are used to determine which fireball to track. The new routines use 8 bit instead of 16 bit math. Let me know if anybody sees any other occurances of screen rolling.

 

Do you really need Euclidian distance? I would think you'd want to track the fireball that will cross the movement line of the castle first, regardless of your distance to it, unless it can't be reached in time (in which case, go to the first-arriving one that can be reached). Time of arrival can be figured by determining which side of the movement line the fireball will cross first, and performing a subtract of X or Y coordinate as appropriate, and then doing a table lookup of that value and the fireball's speed.

Link to comment
Share on other sites

Darrell:

 

The AI is awesome now! I like how they 'sometimes' hold the fireball and seem to try to aim it. I also think it's cool how, if there is more than one fireball on the screen and they are holding on to one already, they still go and attempt to block the other one if it's coming at them.

 

(Can you say 'run-on sentence'?) :ponder:

 

I actually started a one-player game and just watched them for a few rounds... Which got me thinking... Do you have enough room to add an 'attract mode' of no button is pressed at the start screen? It's be fun to watch all four of them battle it out for a few seconds, and then go back to the select screen...

 

:)

 

Bob

Link to comment
Share on other sites

Thanks! I like how the AI is shaping up too. I need to revamp the speed tables for them so they'll move faster left/right than up/down to compensate for the pixel size.

 

I had been wondering that myself and added a 0 players option to test it. I see I forgot to disable it, so you can try it out - 0 players shows up after Doubles. It plays OK until the 2nd fireball comes out - the screen will jitter if 4 players are still alive. It's possible I could have an attract mode that ran until the 2nd fireball is released and return to the menu at that point - but I'll make that determination once the AI routines are done as there may not be enough CPU time for 4AI players with the final routines.

Edited by SpiceWare
Link to comment
Share on other sites

I had been wondering that myself and added a 0 players option to test it. I see I forgot to disable it, so you can try it out - 0 players shows up after Doubles. It plays OK until the 2nd fireball comes out - the screen will jitter if 4 players are still alive. It's possible I could have an attract mode that ran until the 2nd fireball is released and return to the menu at that point - but I'll make that determination once the AI routines are done as there may not be enough CPU time for 4AI players with the final routines.

 

That's cool! Maybe you could alternate which players are active (temporarily "lobotomize" one at a time, for instance), to make it work if the CPU requirement is too much for four simultaneous players?

 

Anyway, I just played a few very challenging games against the computer from different corners. It was good to see that which computer player beats me (always!) depends on relative position to me. Whoever is diagonal to me will always win, regardless of which corner I choose. :)

Link to comment
Share on other sites

Hmm - that's a good idea. I wouldn't want to do that for a real game, but it would be fine for attract mode.

 

Had screen jitter today - this time from the overscan section, which processes fireball collisions and movement. It occurred when all 3 fireballs collided with something on the same frame. The routines check time remaining to decide if will process the last fireball collision or wait until next frame. I've increased the value it checks for and haven't seen it happen since.

Link to comment
Share on other sites

possibly later tonight - I've got it running in the background with breakif { _scan==#263 } to confirm it's fixed. I've also fixed it so the AI players once again track the dragon waiting for the initial fireball, and changed the tables for the AI players to move faster left/right than up/down to compensate for pixel sizes.

Edited by SpiceWare
Link to comment
Share on other sites

Had a fun visiting my relatives, went to my first rodeo and to the town's Celebrate Bandera festival. I brought my new MacBook and we had a nice 3-way video conference with my parents and my brother & his family. My sister-in-law just about filled the screen - she gave birth less than 12 hours later: Mason, 6 lbs 14 oz and Logan, 4 lbs 9 oz. Both boys are doing well, as is Kristin.

 

Had a great time visiting keilbaca on my trip back to Houston! We found a Greek restaurant and had some excellent gyros for lunch. Headed back to his place and played a long game of Medieval Mayhem - it was still compiled with 15 games to win from my testing. Keilbaca won the game, and we found a few bugs I need to fix, included another screen roll(grrr). Keilbaca also gave me an extra Coleco Galaxian Table Top Arcade Unit he had. Powered it up as soon as I got home and played a few rounds, way cool. Thanx again, keilbaca :thumbsup:.

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