Yeah, just a table or something...dysfunction wrote:
Yes, but those differences are just numbers, and (I would assume) would be easy to implement.
Project Discussion
Moderator: tr1p1ea
- tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
Yeah, lets say we get those out of the way ... then we can talk about other features .
The MAIN problem here is that i am not very experienced with Smash Bros. games. Sure i have played them, but i have never gone very in-depth. Im going to have to get my hands on a copy of Melee so i can better my understanding .
The MAIN problem here is that i am not very experienced with Smash Bros. games. Sure i have played them, but i have never gone very in-depth. Im going to have to get my hands on a copy of Melee so i can better my understanding .
- thegamefreak0134
- Extreme Poster
- Posts: 455
- Joined: Mon 23 Jan, 2006 10:09 pm
- Location: In front of a Computer, coding
- Contact:
A lot of the complexity of melee comes from a couple of glitches in the engine allowing you to pull off very advanced tactical moves. The actual fighting system and engine are very straightforward. I've looked into the debug menu and seen developer stuff, so I can help you out.
The way fighting works, every character is actually composed of a few "hit bubbles" that represent areas that things come in contact with them. (this rather than using a sprite or something every time.) When you generste hits with a move, they have bubbles. You also create grab bubbles, and your collision bubbles will sometimes become shield/invincible bubbles depending both on the character and the state. (For instance, link's shield's bubble is green, I believe.)
This all looks very advanced, but is infact very simple to implement. You know Pyth. theorum right? (a^2 + b^2 = c^2)? Well, every "bubble" can be represented by a single point in the center and a radius. Then you determine the x and y differences for two "bubbles" you want to check and determine the distance between them using a^2 + b^2 = c^2. If this distance is less than the sum of their respective radii (is that the right word?) then it's a hit, otherwise a miss.
Using this system and a simplified bubble set for the characters, I think the calc should be able to pull it off without much difficulty.
-gamefreak
The way fighting works, every character is actually composed of a few "hit bubbles" that represent areas that things come in contact with them. (this rather than using a sprite or something every time.) When you generste hits with a move, they have bubbles. You also create grab bubbles, and your collision bubbles will sometimes become shield/invincible bubbles depending both on the character and the state. (For instance, link's shield's bubble is green, I believe.)
This all looks very advanced, but is infact very simple to implement. You know Pyth. theorum right? (a^2 + b^2 = c^2)? Well, every "bubble" can be represented by a single point in the center and a radius. Then you determine the x and y differences for two "bubbles" you want to check and determine the distance between them using a^2 + b^2 = c^2. If this distance is less than the sum of their respective radii (is that the right word?) then it's a hit, otherwise a miss.
Using this system and a simplified bubble set for the characters, I think the calc should be able to pull it off without much difficulty.
-gamefreak
I would suggest link cable support for this. That, 2 players on one calculator, and player vs. cpu modes would make a great game. But if you want to add more, go for it.
Hey, how about making it so that if you have 84 series calculators, you can connect more calculators up(usb and normal link) and get 3-4 player games going?
Hey, how about making it so that if you have 84 series calculators, you can connect more calculators up(usb and normal link) and get 3-4 player games going?
In Memory of the Maxcoderz Trophy