the problem in zelda is that you can only shoot your arrow in one of four directions. now, i can see why they did this; its a simple interface - you press the button and you shoot the arrow in whatever direction you were facing. but it's no good for me. i often want to shoot on angles; it would often be helpful to do so. in a game where you're going to rely on your arrows (as the rogue would in diablo) you need to be sure they're effective, and they're really limited in zelda.
on the diablo side of things, though it was fixed up in diablo2, the arrow collision detection was shitty at best. there's no real need to explain this one in great detail, if the target wasn't on one of the tiles the arrow travelled along, there was no hit. it woulda been a little more difficult to try to do pixel-perfect on this, because its a tile-based location deal.
the idea originally was to go with a crystal chronicles magic type deal. press the arrow button and hold it to get an aiming cursor, release to fire. i like the idea of it, it lets you have nearly any angle you want to fire your arrows, but after playing a bit with the rogue and thinking it over, you wouldn't be able to fire alot of arrows very fast if you had to line up the cursor over and over.
so you'd press the button down, and the targetting cursor would appear under you. you'd use the d-pad to move it around in the range you were allowed, and when you let go, it would shoot the arrow. if you needed to realign quickly, you could move in the direction you wanted to start it at and then press the button; the cursor would start at its maximum distance in that direction, and you could reposition it from there a little more quickly.
even with that, though, you can't rapidfire like you can with the rogue. you hold in shift and start clicking everywhere and you machinegun arrows all over hell. though it isn't as obvious to do, let's say instead you hold in the button for the cursor as before, and press the other button each time you wanted to shoot an arrow. hmm. i really don't want this to be too complicated, and the two button method is sorta that way. suppose you pressed the button and held it to get the cursor, and released it to shoot, but the cursor stayed onscreen. you press and hold to move the cursor again, and let go to shoot yet another arrow. you could just quickly press and release the button for more arrows in the same direction. to cancel the arrow shooting, you could press the other button. if you moved around while in targetting mode, you would keep your arrow ready and face that direction until you cancelled, like in LoZ: minish cap / four swords.
i think the arrowhead should have a clip area for it, 8x8 standard, and if that overlaps a monster clip, there's a hit. having the whole arrow checked would be wierd - if the tail collided, it would look wrong if the head wasn't colliding at all. we might want to go with collision circles in this too, but if i'm going for the gameboy feel, i'll be doing rects. also, if i'm doing the gameboy feel, i'm going to want to have 16 direction sprites for the arrow. 8 won't quite do justice. the bow should have 8dirs, and an arrow/no-arrow version. we're probably pushing the limits of the gameboy by doing this, but meh. it looks like they load srites off the cart on an as-needed basis anyhow, so it shouldn't be too bad. in order to get the arrow-sticking visual to work, it might even be easier to have the arrows stored as two 8x8 sprites, and overlap them for the in-flight, then put the tail where the head was when there's a hit and stick it to the target sprite for a limited time.
it probably won't matter if we do the two 8x8 overlapping vs just going with 16x16 sprites for each angle. the gameboy hardware stores all sprites as 8x16 or 8x8 only, there's no mixing.. so it would just be easier to make the rotated 16x16s and just use them. we'll need to have the clip rect set for each one though, but thats just a little extra work for those.
here's a mockup of the above design:
[EDIT: whoops! i messed up! the button needs to be held in, to move the cursor. i'll fix that up soon]
its pretty dirty looking, but thats what you get when you don't do it programmatically. still, it gets the idea across. watch the little controller overlay in the bottom left to see what i'm saying. i didn't show link moving around while the targetting cursor was ready, but it's probably a pretty easy thing to visualise.
what would be next? not sure. gotta think about this for a bit.
[EDIT: we've got..
- item screen
- map generation
- 'thing' interaction
.. still to do, at the very least. the item screen is next on my list.]