|
|
Post by chriscrawford on Feb 2, 2016 9:12:51 GMT -8
In dream combat, each adversary gets to deploy one of three auragons. There are nine combinations, six of which are different combinations, and three of which are ties -- both adversaries choose the same auragon. Currently I have the auragons directly overlapping; when they're different, it's obvious, but when they are the same, it looks as if nothing is happening. Therefore I must present the two auragons at different locations on the screen.
This raises all sorts of new problems. How does the player know which auragon is his and which is the adversary's?
I suppose that the best approach is to have vertical separation with the opponent appearing top and the player at the bottom; this makes the opponent seem more threatening. I'll have him swoosh in from low and left or right. Then his auragon will appear at reduced size immediately below him. The player's auragon will appear below that. Then the victorious auragon will expand to fill the view.
|
|
|
|
Post by chriscrawford on Feb 2, 2016 9:27:00 GMT -8
An interesting small problem: the algorithm for the path followed by the eyes as they move from the lower right to the top center. The track must be curved and should initially have low angular velocity, with angular velocity increasing concomitantly with eye size.
Now, the easy way to do this is with trig; just plot a course and calculate the distance and the angle using regular trig. But that's too time-consuming; remember, this is an animation. Besides, I don't need geometric accuracy here. So there are three components to the algorithm:
1. The size algorithm. That's already handled with this algorithm:
displayed size = actual size / (100 - step number), where 0 < step number < 100
2. Angular velocity (amount of movement per step): The angular velocity should increase concomitantly with the displayed size, so I just use the above algorithm.
3. Curvature: Vary the slope so that it starts vertical (deltaX = 0) and ends horizontal (deltaY = 0). I think that by increasing deltaX linearly and decreasing deltaY linearly, I'll get a roughly parabolic curve. I'll just to try it and see.
|
|
|
|
Post by chriscrawford on Feb 2, 2016 9:38:55 GMT -8
I just realized a tiny error in my algorithm: I am thinking in terms of the delta-values, that is, the change in position from one frame to the next, but I don't calculate deltas, I calculate positions. When delta increases or decreases linearly, the result increases as the square; this is a lesson I figured out in 8th grade. This little table should help show that. It has the integer, its square, and the difference between the squares:
1 1 -
2 4 3
3 9 5
4 16 7
5 25 9
So I'll modify the algorithm to use squares.
|
|
|
|
Post by chriscrawford on Feb 2, 2016 10:48:16 GMT -8
I overlooked a simple problem. Here is my original line of code:
float magnifier = (float)(1.0f/(float)(startOpponentAuragon - longCounter));
The top of the range for longCounter is startOpponentAuragon-1, so this value starts off very low, but grows rapidly as longCounter approaches startOpponent Auragon. Here's a table of the values of longCounter and Magnifier:
71 0.03448276
72 0.035714287
73 0.037037037
74 0.03846154
75 0.04
76 0.041666668
77 0.04347826 0.30434784
78 0.045454547 0.36363637
79 0.04761905 0.42857143
80 0.05
81 0.05263158
82 0.055555556
83 0.05882353
84 0.0625
85 0.06666667
86 0.071428575
87 0.07692308
88 0.083333336
89 0.09090909
90 0.1
91 0.11111111
92 0.125
93 0.14285715
94 0.16666667
95 0.2
96 0.25
97 0.33333334
98 0.5
99 1.0
As you can see, this grows too slowly at first, then jumps up too suddenly. Here's the correction:
float magnifier = (float)(4.0f/(float)(startOpponentAuragon + 4 - longCounter));
|
|
|
|
Post by chriscrawford on Feb 2, 2016 11:54:54 GMT -8
More difficulties: I'm having trouble calibrating both the size and the speed of motion; it turns out that there are too many variables to tweak simultaneously. Currently it's set as a parabola starting at the lower right corner, and I have to tweak the various control constants to get it to the appropriate destination at the right time. I suspect that I need to redesign the algorithm to include both ends of the motion. This will probably just take some mathematical calculations, but these kinds of things don't come easily to my semi-senile brain.
|
|
|
|
Post by chriscrawford on Feb 2, 2016 16:09:24 GMT -8
I decided to explore the question more thoroughly, expending too much time on a mathematical analysis of power series, Fibonacci series, and other interesting approximations of the problem. I decided, after much exploration, that the fastest approach will be a table-driven one, but that still requires me to develop the mathematics. At one point I had a fascinating diagram using a mess of diminishing nested circles connecting line segments along a curve, but I could not devise a suitable algorithm. I'm going back to the Fibonacci series, as it generates excellent spirals, which numerically are appropriate to my needs here.
|
|
|
|
Post by chriscrawford on Feb 3, 2016 7:18:09 GMT -8
Well, at least I have solved the problem of the approach of the opponent's eyes towards the top. Here's the final algorithm:
float magnifier = (float)(5.0f/(float)(startOpponentAuragon + 5 - longCounter));
float z = (float)(longCounter-startEyes);
int x = (int)(WindowSize - 50 - z*z*z/96.4f);
int y = (int)(WindowSize - 20 - z*z/2.2f);
int x1 = (int)(magnifier*(float)eyes[iOpponent].getWidth());
int y1 = (int)(magnifier*(float)eyes[iOpponent].getHeight());
netG2.drawImage(eyes[iOpponent], x, y, x1, y1, this);
Sheesh, I wasted far too much time getting that right. Now I must shrink and re-center the opponent's auragon.
|
|
|
|
Post by chriscrawford on Feb 3, 2016 7:38:41 GMT -8
I've now gotten the opponent's auragon displaying properly at half-size and top-center. That was easy. It's odd how some things are ridiculously easy and some things are horribly difficult. In any case, now I must decide on the protocol for where the opponent appears. The simplest approach is to have the opponent always appear at the top, regardless of whether attacking or defending. But would it be useful to the player to have attackers always at top and defenders always at bottom? There's no ambiguity to the situation: when the player is defending, the action stops while the player chooses a defensive auragon.
I think I'll go the easy way for now. Opponent always at top, player's auragon always starts at the bottom.
|
|
|
|
Post by chriscrawford on Feb 3, 2016 13:10:49 GMT -8
I wonder if I should have something on-screen representing the player? Otherwise his auragon simply appears without any direct association. But how do you show the back of somebody's eyes?
If the player is the attacker, then his own auragon should appear immediately after the opponent's eyes have appeared, after which the opponent's auragon appears and they clash.
However, if the player is the defender, then the opponent should appear, followed by a break for the player to enter his choice of auragon with which to defend. This implies that the main window must remain active for the player to use, which in turn implies that the combat window must be integrated into the main window, and somehow slid over. Time for some graphic layout issues.
|
|
|
|
Post by chriscrawford on Feb 3, 2016 14:10:08 GMT -8
For now, I have set aside the problem raised in the previous comment and plunged ahead with getting the basic animation running. I now have both auragons appearing and animating properly in their assigned places. The next step is to animate the combat. I'd like something good here, something better than them merely moving on top of each other. I will need different animations for ties. I'll begin with the non-tie situations. What I'd like is some sort of AlphaComposite that really highlights their clash, perhaps an exclusive-Or composite.
|
|
|
|
Post by Chris Conley on Feb 8, 2016 9:01:57 GMT -8
I wonder if I should have something on-screen representing the player? Otherwise his auragon simply appears without any direct association. But how do you show the back of somebody's eyes? If the player is the attacker, then his own auragon should appear immediately after the opponent's eyes have appeared, after which the opponent's auragon appears and they clash. However, if the player is the defender, then the opponent should appear, followed by a break for the player to enter his choice of auragon with which to defend. This implies that the main window must remain active for the player to use, which in turn implies that the combat window must be integrated into the main window, and somehow slid over. Time for some graphic layout issues. My instinct is to treat the dream combat screen as if it's first-person. Thus the auragon begins entirely off-screen bottom, at 1600% or so scale, and then moves up to the center as it scales linearly down to 100%. |
|
|
|
Post by chriscrawford on Feb 10, 2016 6:57:24 GMT -8
I did have the scaling idea in place initially, but it had a bunch of problems of its own, so I set it aside. Perhaps I'll bring it back later. In the meantime, it occurs to me that I could make some sort of "ghost image" of the back of the player's head. But I don't have much screen space to work with.
|
|
