Dev Team for Zelda

[ACagliano]

Ok, I had a few people helping me out on certain aspects of Zelda, but that was months ago and I have since lost those records. If you were working on something, please let me know. I am going to put together a dev team to help me with aspects of Zelda that I cannot program myself. The entire dev team will be credited for the release of this project.

Below is a list of things that need to be done:

1. Artificial Intelligence
2. Collision*
3. Bullet-like shooting system for hook/longshot and bow
4. Smooth scrolling rendering of greyscale graphics

*Collision: The collision with enemies I'm assuming is part of the AI. As for collision with tiles, I just need a way to convert the pixel by pixel Player movement into a way to check if collision with a tile has occurred. To clarify, the variables PlayerX and PlayerY are in pixels. If someone can tell me how to convert that number into a tile value, I can handle checking for movement onto illegal tiles myself.

Beyond that, there are a few other things that need to be done.

1. Compress map data (I can provide the data here, but the utilities will not run on Mac. Someone may need to run the data and post the compressed here).
2. In game-dialogue. I can handle this.

[Hot_Dog]

I don't fully remember if I offered to #4.  If not, I can do it, but it may take some time if you want the grayscale as flickerless as possible.

I can also compress data that you put on the website.

[shmibs]

for collisions, just use (<pixel position>+<amount of pixels the screen has scrolled since the last tile change>)/<tile size>+<tile offset to the top/left most tile being displayed on the screen> to find the tile a specific pixel is inside. that means that, in order to find the tile above/to the left of your character you would make pixel position the player's position minus one, and to find below/to the right of it would be player position+player size+1

you can do enemy collisions the same way, storing the player's position somewhere and then checking the enemy position against it. it would use their absolute pixel positions (x,y on the screen+tile offset*tile size), though, and would have to use regions, though, so the check for a contact between the player and an enemy would be:
(player position < enemy position < player position + player size) or (player position < enemy position + enemy size < player position +player size), where the positions are the top/leftmost pixel in the sprite. you don't need to worry about having any <= in there unless you make enemies that move in increments larger than enemy increment+player increment, because link gets knocked back by enemies, so they will never be exactly on top of him.

zelda AI should be simple, as they're mostly just moving in straight lines and turning at random intervals or moving towards the player. bosses may be more difficult, though.

just make bullets a special type of enemy that moves faster and deal with them the same way.

[Xeda112358]

For pixel-by-pixel collision detection, a gave a few mini tutorials not too long ago that show how to make really detailed hitboxes and whatnot and it is fast. The only issue is that it can eat up RAM, fast Pretty much what you do is draw all the collision areas on another buffer and pixel test that buffer for collision. Then, on another buffer, you draw any damage areas (areas that you get hurt). This could include moving enemies and whatnot. When you pixel test, if there are any pixels in the damaging buffer that overlap (can be tested with XOR), then you get hurt. So at this point, you will need at least four, 768 byte buffers. 1 for the collision layer, 1 for the damage layer, and 2 for the cover layer (since you are doing grayscale).

This means that you need another tileset for collision and damage masks and that you will need to draw 4 sprites per enemy, but that is still a fast process. What size sprites are you using? I have a pixel-test routine that pixel tests a region of a buffer.

[shmibs]

/\that works, too, but means that you would have to draw everything to three buffers instead of two, or even more if you want to have insta-kill tiles, like holes, which could really slow things down.

EDIT: it might be faster to check for enemies that way, though, because all that math can slow things down.

[Xeda112358]

It seems like the best approach will depend on how many objects are around. For collision detection of static objects, my method will be faster, but for moving enemies, probably shmibs'.

[ACagliano]

Well, the method I use to determine if you have moved onto an illegal sprite is this...

I have two separate sets of position variables, Player X and Player Y, both 1-byte large, and PriorPosition, 2-bytes large but contains the Prior X and Y.

1. The movement is performed, so for all intents and purposes, your character has actually moved over one tile, regardless of legality.
2. I test the current position against the value of the tile.
3. If the tile value is illegal (one that you can't move on to), I write PriorPosition over PlayerX and Player Y.
4. If the tile value is one that causes damage, then the correct damage flag is set and the damage counter initiated.

Is the method you guys are proposing more efficient, if so, then we should do that, but it is beyond my coding ability. So is AI of any sort

[aeTIos]

For the AI you should ask Kerm or Ashbad.

[Xeda112358]

For Zelda AI, it is rather simple.
Player 1 has coordinates (x,y)
Enemy has coordinates (r,s)
Make (r,s) try to occupy the same space as (x,y). In pseudocode:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10

If X>R R+1→R If X<R R-1→R If Y>S S+1→S If Y<S S-1→S

I've made games using a similar algorithm. (In TI-BASIC, I used lists to have multiple enemies chasing you).

[Hayleia]

The problem in that algorithm is that the enemy will not walk straight.
See the attached image, assuming that "you" don't move.
The enemy will follow the black line, not the bridged blue one.

[Xeda112358]

Ah, good point >.>
Are you familiar with the bresenham line drawing algorithm? If so, you can follow the same algorithm, except instead of drawing pixels, draw the enemy

[DJ Omnimaga]

Do old Zelda games allow enemies to even more in more than 8 directions, though?

[Xeda112358]

I don't think so, but if they are moving pixel by pixel, they can make it look like it is moving in more directions.

[ACagliano]

And so this is how my head explodes.

Technically, when moving pixel by pixel, the only legal directions are horizontal and vertical.

[shmibs]

if you are basing your enemies on those of the first zelda game, there doesn't have to be any diagonal motion at all except for zora projectiles, which can move in 16 directions and can't change direction once they start. other games are a bit more complicated, though. here are a few quick examples of how enemies move:
<a href="http://www.youtube.com/watch?v=aektG-xZzDU" target="_blank">http://www.youtube.com/watch?v=aektG-xZzDU</a>