[KM] It's Official!

Followers 0

Entry posted by Hornpipe2 · February 2, 2009

530 views

Karate Master

http://www.richard.hutchinson.dsl.pipex.com/new_page_6.htm

# 0E 0380 - 03BF Karate Master (Greg Kennedy)

Now to finish it! LOL.

I've got two main branches going on with my code right now and I'm stumped on both ends, which explains the lack of progress.

On the menu front: The biggest issue I am having is that it is hard to justify the ~2k expense on an elaborate menu system if I only have two options on it - "one or two players" and "choose player color". Some more options would be a plus (I'm presently considering things like player handicap, etc) but I have not yet figured out how it would work. Suggestions for more menu options are welcome - as this also helps drive the feature set in the game!

I think overall though I will be replacing some of the font (text) with something smaller and less "flourished" (i.e. more readable), cramming a few more options on the page, etc. Probably will make the "Record" display a highlighable option when the SaveKey is present, and clicking that takes you from a Top 1 to a full-screen Top 16 (3 bytes score + 1 byte color).

I may also see about making use of that System Settings page on the SaveKey. Character heights are as high as I can get them, so PAL folks will be playing with shorter (and slower...?) fighters, but I may be able to make up the difference in lines through a little bit of letterboxing and enlarged background images. But how do I work this around players who don't have the SaveKey? Drat.
On the gameplay front: How in the world am I going to tackle collision detection?! For the frames that are "dangerous" (i.e. should be checked for hits) I've defined a "dangerous point" corresponding to a fist or foot. But now how do I rig up the vulnerable locations on the opponent per-frame? I've considered adding up to three or four hitboxes to be checked, but don't know if that will be enough or not, and the space of that (2 bytes/coord * 2 coords/box * 4 boxes/frame * 42 frames = 672 bytes) what a waste!! This stopped me cold last time and I haven't figured a better solution yet.

Thinking... perhaps I can get a collision handler that is capable of reading the gfx data. Since the info is already there it would be pixel-perfect and probably not so expensive.

Followers 0

1 Comment

Recommended Comments

cd-w 439

Posted February 2, 2009

I'm glad to see that you are going to be using the SaveKey/AtariVox in your game. As one of the PAL folk, I'm quite happy for you to use PAL60, i.e. the game is identical to the 60Hz NTSC version, but the colours are mapped onto the PAL palette. Most PAL TVs that I have encountered can support a 60Hz refresh rate without difficulty, but they don't generally support NTSC colours. This could also be one of the options on your menu.

I don't fully understand the collision detection issues, but I think you are going to have to cheat a bit! The fastest way is to use the hardware collision detection to find sprite overlaps. If you have space in the kernel you could clear and test the collision detection registers only on important lines. If you are going with regions, a fast technique for overlap testing was posted in the 6502 killer hacks thread.

Your karate game is coming along very nicely and I'm looking forward to seeing how it turns out.

Chris