• Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About Epilef

  • Rank
  1. cRPG Combat - Tactics or not?

    Hi, I've been thinking about this stuff for the last few days, ever since a game idea started to sprout in my head. What i'm thinking of is this: -Strategic "free movement" combat system (like in FF Tactics and Fire Emblem). -Active battles with "energy" bars: different attacks take up different amounts of energy, but unlinke the "mana points" type thing, the energy bar recharges quickly. (I think I'll also have the mana points-type thing, however.) -No distinction between "the world" and battles; when enemies are encountered, you can avoid them or attack them at will, and other enemies can come along and join in the battle if they so desire. -I've always thought special environment conditions are nice because they add variety to battles, such as different terrain features (cliffs, trees, rocks...), or conditions that affect certain types of attacks like someone mentioned before about fire not working underwater but electricity being very damaging. So my idea is kind of a hybrid between tactical and real-time systems (sort of like Chrono Trigger, except your team members are able to move around). The main thing I'm unsure about is the movement system; to make the world and battles "in the same realm" I would have to make the movement system the same, and that means allowing team members to pretty much move at will during battles, which would make it less tactical and more like a real-time type of thing. Sorry if I'm kind of vague-sounding, it's just that I decided to try to design and make a small rpg a few days ago, so I'm still thinking of new ideas and changing old ones...
  2. Thanks, I've been looking for this for a long time :D
  3. No I mean when the balls are pushed out of collision do they move backwards along their movement vectors (so that they are accurately moved back from where they came from instead of to the side). Also, this would make the collision response more accurate since the collision vector would be calculated from the balls' "real" positions. For example, if a ball moved into another ball after a time step, could bounce sideways (depending on how far into the other ball it moved) instead of having a nearly head-on collision.
  4. Thanks a lot, this works great now. Does this push the particles back along their velocity vectors? From my observations it doesn't, but I don't trust my observations very much since I don't know much about vectors.
  5. Hi again, I'm working on this problem again after a long time of putting it aside. I hadn't gotten it to work before, and now I've tried a lot more and I still can't figure it out. Why is the Pythagorean theorem used, if that's only for right angles? It seems like that's the problem, because 'd' is almost always larger than it should be. Also, in this line: A.position -= V*d Doesn't V*d come out to be a very large vector? It seems like i'm doing this all wrong, but i've checked over it and tried lots of other things, but it just doesn't work...
  6. converting degrees to vector normals

    Just one more question... to convert vector normals to degrees i figured I would just have to do the inverse sine function on the x value or the inv. cosine on the y value. I tried this, but it doesn't work. It seems like the orientation of the normal messes things up. How am i supposed to do this?
  7. converting degrees to vector normals

    Ok, ViperG's method seems simple, but it's still not working. Do I still need to make the degree value below 90? I tried it with and without that, but neither works. The angles are always wrong, and the vectors go beyond the radius for some reason. I'd post some code, but i tried so many different ways of doing it that i don't know what to post :P *edit* nevermind it's working fine after i fixed a dumb mistake i made. It works perfectly now, thank you thank you thank you thank you thank you!!! :P
  8. converting degrees to vector normals

    This is in 2D. I tried to implement my method, but it doesn't seem to be working... This code might not be perfect because I don't use C++, but here it is: // calculates the arc start and end points, given the two degree values // 'a' and 'b' are two class members (vectors) void calcPoints(float aDeg, float bDeg) { Vector an = degToVector(aDeg); Vector bn = degToVector(bDeg); a = an * radius; b = bn * radius; } // calculates and returns a normal of direction based on a degree value // 0 degrees is a left-to-right horizontal line Vector degToVector(deg#) { Vector startNormal; //make the degrees less than 90, storing the rest of the degrees (to the closest multiple of 90) as a normal If(deg >= 0 && deg < 90) { startNormal = New Vector(1,0); } ElseIf(deg >= 90 && deg < 180) { startNormal = New Vector(0,-1); deg -= 90; } ElseIf(deg >= 180 && deg < 270) { startNormal = New Vector(-1,0); deg -= 180; } ElseIf(deg >= 270 && deg < 360) { startNormal = New Vector(0,1); deg -= 270; } //find the side of the triangle formed by a horizontal line (0 degrees) and the remaining degrees float triSide = tan(deg)*radius; Vector normal = New Vector(radius, triSide); normal.normalize(); //return the normal of the sum of the bulk and remainder normals Return (startNormal + normal).normalize(); }
  9. Hi everybody, is there a formula for converting degrees to vector normals? What i'm trying to do is this: to create an arc from a circle with a center point and radius, and start degrees and end degrees. I can already do this, but it's a long and complicated method and i don't think it's the best way to do it. Thanks for anyone's help.
  10. Is there any way of doing this using position-based velocity? I'm working on a verlet engine, which needs to have position-based velocity (i think). When i try to implement it anyways, the circles go all over the place unpredictably.
  11. ok i think i figured it out. The only thing i had to change to make it work was to only change the current position when an intersection was found. I don't have the slightest idea why this is so, but oh well it works :P
  12. ah, thanks, now i understand. I'm still trying to integrate it into my current ball collision algorithm though...
  13. But i can test if a ball has passed through a line by testing if its previous-current positions are on different sides of the line, and that can be done by testing line segment collisions. Then i thought i could just move the ball back to the closest point on the line (or a little bit further) along the backwards velocity vector and the collision checking would find a collision and it would be handled normally. I guess it's just some minor error i made.
  14. cool, the friction and elasticity are working, but now other questions (sorry, i don't know how to handle vectors very well :P ). how do i make code boxes? i edited this post like 10 times trying to put code boxes in :P My first problem is that i'm trying to make it so that balls can't pass through the the lines. I'm doing that by checking if the line segment formed by the ball's current and previous position touches the line segment (the one the ball might have passed through). If so, the ball is moved back to the closest point on the line (the collision point). But i'm doing something wrong and i don't know what it is. Here's my code: // this is inside the CircleSegmentIntersect function //bool SegmentsIntersect(Vector start1, Vector end1,Vector start2, Vector end2) checks returns true if the two specified segments touch; false otherwise // Vector prev: the previous position of the ball // closest point on the line to the ball Vector point = A + AB * t; //check for break-thru If (SegmentsIntersect(A, B, C, prev)) { Vector change = C - point; C -= change; prev -= change; } ... You'll notice that i changed 'prev' also instead of just setting C to 'point'. That's because i'm using the verlet method (ball's velocity = current - previous position), so i have to change both of them to properly move the ball. When i run my demo program ALL of the balls just disappear after a second or two. I tried adding 'change' to C and prev instead of subtracting, but then when i ran the demo the balls didn't disappear, but they still whent through lines. My second question is this: how do i calculate the closest point on a line if the line has a 'radius'? The point has to be on the edge of the radius. This what i came up with: // this part would come before the break-thru checking // 'point' will be the final result Vector point = new Vector; // closest point on the line to the ball Vector linePoint = A + AB * t; If (radius == 0) point = linePoint; Else { // the normal along which to extend the collision point Vector normal = (linePoint-C).normalize(); // extend the collision point outwards to the edge of the radius point = linePoint - normal*radius; } ... I'm not exactly sure what i'm doing, it's probably all wrong. When I run the demo, the balls collide with the lines, but i think for some reason the collision point is extended too far or something, because when the balls hit the lines they are moved back a little further than they should. Yeah... as you can see i'm not that good with vectors...only being in 9th grade and all... [Edited by - Epilef on January 31, 2007 10:25:54 AM]
  15. Is there any way to do 2d ball vs. ball collisions that uses a collision angle that is calculated from the positions of the balls AND their velocities? i'm thinking of something like this: When two balls are calculated to be colliding, each is projected out of collision along their previous movement vector INSTEAD of along the collision vector (the vector of the line between the ball centers), so that their collision angles are not calculated wrong, such as when a ball is halfway into another ball and it is projected out sideways instead of the way it came. The problem is that i don't know how to calculate how far the balls have to move backwards along their movement vectors. Maybe this isn't why my ball collision system isn't very stable, so if any of you have any examples of ball-ball collision algorithms that would be great. [Edited by - Epilef on January 30, 2007 6:58:27 AM]