Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: ACagliano on April 24, 2012, 09:42:39 pm
-
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.
-
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.
-
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.
-
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.
-
/\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.
-
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'.
-
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 :(
-
For the AI you should ask Kerm or Ashbad.
-
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:
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).
-
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.
-
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 :)
-
Do old Zelda games allow enemies to even more in more than 8 directions, though?
-
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.
-
And so this is how my head explodes.
Technically, when moving pixel by pixel, the only legal directions are horizontal and vertical. ;)
-
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:
-
Yes, do that ^ Make life easier XD It will still bring nostalgic feelings :3
-
Ok. I need an AI programmer to do the enemy AI and someone experienced with bullet code. Just two things left. Yay!
It doesn't matter to me what method or system the AI uses, as long as it is moderately challenging.
-
Hmm, is this going to be an app? If so, I can try to program the AI as long as I know what scrap RAM will be available and whatnot. Also, what is the time frame looking like for this? Finally, I will be gone by the first week of May (next week) without internet for a few months.
-
It is an APP. I'll post up the RAM available asap.
-
Cool, that would be helpful :D And if you guys know exactly what arguments will be passed to the code, I have a novel idea for what to do :) All I have to do is make it chase the main character around, right? (that is what I had in mind for being able to do or help with). I could also potentially return collision detection info, as well.
What I know I will need as arguments passed are:
Size of the Enemy
Coordinates of the enemy
Size of the player
coordinates of the player
As for bullet code, I have no experience with that, really, but if it is only in 16 directions, I think I can handle that. What I would ideally like is:
A buffer for bullets (no clue what size)
A 768 byte scrap buffer
-
Bullets for hookshot and bow would only be 4 direction, Xeda.
-
Ah, there was an earlier post that said 16 D: (It was for bullets from certain enemies). I think for the general bullet code, I would prefer 8 directions as that is easy to handle.
-
Cool, that would be helpful :D And if you guys know exactly what arguments will be passed to the code, I have a novel idea for what to do :) All I have to do is make it chase the main character around, right? (that is what I had in mind for being able to do or help with). I could also potentially return collision detection info, as well.
What I know I will need as arguments passed are:
Size of the Enemy
Coordinates of the enemy
Size of the player
coordinates of the player
As for bullet code, I have no experience with that, really, but if it is only in 16 directions, I think I can handle that. What I would ideally like is:
A buffer for bullets (no clue what size)
A 768 byte scrap buffer
ACagliano, it's quite common for special Ti-83+ games to require user RAM. Both Xeda and I need scrap RAM for our code, so maybe you should plan on Zelda requiring 2-3 KB of user RAM. (B_CALL _InsertMem is perfect for this)
-
Yes, this would be a great idea and I am sure people would not mind at all having to have a few KB of RAM free for a game like this :)
-
in original zelda, zora shots are the only things (i remember) that move in more than 4 directions. they can't turn once they've been fired, so all you'd have to do is determine which of those 16 is the closest to facing towards link (which the original game did somewhat poorly :P) set the values to increment x and y accordingly, and then add those amounts every time. it could even just be whole pixel amounts to make it easier, so down is +4y, 0x, down down right is +3y, +1x, down right is +2x, +2y, and so on. you can tell, from playing the game, that it doesn't do anything more complex than that.
-
Well what about the AI? It is certainly more complex than just constantly moving toward the player. Sure, some enemies do that, but there are certainly more complex actions as well.
What enemies are going to be included in the game? That will help to figure out what needs to be done for the AI.
-
apart from bosses, the ai really isn't complex. enemies wander around, turning at random, and shoot/attack at random iff you are in front of them.
-
I just want to put this out there: I won't have internet this summer, so other people can claim the spot for writing the AI ^_^
-
apart from bosses, the ai really isn't complex. enemies wander around, turning at random, and shoot/attack at random iff you are in front of them.
Exactly...but the bosses are gonna be a pain...
-
Well, we have ground enemies...
Forest - collision attack
Water - collision attack
Ice - ranged freezing attack/collision attack
Fire - ranged fire attack/collision attack
Spirit - collision attack (enemy class invisible without Lens of Truth)
Shadow - ranged poison attack/collision attack (invisible as well)
Ganon's Castle - collision attack
As well as Regular, Ice, and Fire Keese.
Bosses are a separate enemy class.
-
ACaglino, I just thought of something...with screen-by-screen rendering, do we want the side-to-side scrolling method? It's a fun idea, but I wonder if it will get annoying on calculators