Fight Automation Journal

Randomized Fight - History

Date: 3/13/06

Worked on keyframing my final credit. I am now completely finished with the animation and am working on some documentation.

Documentation

Date: 3/9/06

Help with creating some scenes. And rendering things.

Date: 3/5/06

Fixed some blending problems with guys not blending well after they had killed someone and are going back into the flocking system.

Date:3/2/06

Kevin, Tim, and myself worked out the final bugs with the combat system and I believe it is ready to go. Also guys actually walk now to and from battles. Just found a bug. it seems that sometimes the character disapear when there are 40 v 40 in the battle. (it seems to have just been the computer we were working on)!

CODE: The Entire Scene , Flocking Code (added some walking stuff here) , Combat Code

CLIP: 10 on 10a, 10 on 10b, 10 on 10c, 20 on 20

Date:2/28/06

Kevin and I worked out some major bugs with the combat system. the delay with the death scenes. The next major thing is to make sure everthing is woring properly and to make the guys actually walk.

Date:2/26/06

Over the weekend we (myself, Tim, and Kevin) descovered a few errors with adding the death scenes. The first of these errors was the after a death the characters would get up and continue to fight. This bug was fix easily. The second bug is there needs to be a delay after the deathswhich we plan to work out on the 28th.

Date:2/23/06

Integeration! I met with Tim and Kevin who are responsible for the flocking system and we attempted to integrate our code. The main problem we ran into is that I created all of my variables on the Characters and the flocking system used all of their variables on the groups which were associated with the characters. The main problem was the Target value which specifies the name of the opponent so that we could tell who is fighting who and also the Status value which was named (ib for some dumb reason -- Tim came up with it). The Status value is used to tell if the character is in combat, flocking, or dead. To solve this problem we made two new variables that linked the character to the group and v.s. Since Kevin and Tim and lazy, and because there are two of them, they made me to the run around. So I was responsible for the zig zag lookup to solve our problem, and their code would go unchanged. At the end of the night we were able to create a working integration of our code. And to my surprise with the exception of the variable problem everything went smoothly.
CODE
MOVIE

Date:2/14/06 through 2/19/06

Durning this week through much headache I was able to create some code the actually works. Solving the copying problem was a simple matter of understanding how mel works and also finding a command that allows me to coy the entire character rather than having the recreate it. I ran into some problems later when I noticed the second character model (the SquareGuy) was not the same as the first and it could not be moved in the same way. However after the copying code had been worked out, I Started looking at why the clips had been changing their names and I was able to solve the problem by changing the way I duplicated the clip. However I still do not understand why the pervious method did not work. After the duplicator and the clips started working everything fell into place I was able to once again piece together scene similar to the scene created on the 6th of February. However this scene was able to use our character models and also generated the information much quicker. Blending became a real pain to add be after a bit of experimenting I was able to blend the last 6 frames (which is changeable) to make the motion seem more fluid.
CODE
MOVIE

Date:2/11/06 through 2/13/06

I was able to create some simple code to give me an understand how I could used mel and the trax editor together. I was also able to create a simple procedure to duplicate the CircleGuy Character to that I could test my code. My code worked great on a single character however once more than one character was put into the scene for some reason the source clips I was using to add to the trax editor changed their name, creating some serious problems. Also I noticed that my copy algorithm would copy the nodes out of order which in turn distorted the animation. So needless to say it looks like I have some things to work out.
CODE
Also during this horrifying week Cara mentioned that it would be nice if we could use blending (another trax editor feature).

Date:2/6/06 through 2/10/06

After showing the group this film I talked with Cara about making things a little more efficient. She mentioned she was working with The trax editor a little and perhaps we could uses that to do a similar thing as my code does now. Naturally I was devastated knowing we would be using nothing of my current code and I would have to start all over on a new method.
During the week I attempted to learn some things about the trax editor and figure out how it works. I was able to add simple clips but found it very difficult to find documentation on how to use it.

Date:2/3/06 through 2/5/06

Over the weekend I put my ideas into code. The general idea of this method is to start by keyframing several different animations for a single model. Once this is complete I will save every keyframe on a single animation inside an array. Once all the animations are saved into arrays the object which the animations are created for is duplicated n number of times. Then for every object a random number is generated and for that model the animation array is copied onto the model. This continues for a set number of cycles. And the result is every copy of the model displays a random sequence of the original animations.
CODE
MOVIE
This method although it could have worked takes a very long time to render for the simple models that are seen in the movie clip. I believe the render time for this movie on my home computer was 17 minutes. Granted this would be greatly increased in the accad lab, however since the number of frames on our models is significantly greater and the complexity of our characters are much greater than the two object models that the scene in the movie shows. This method is not very practical but was a great start in learning what mel is capable of.

Date: 1/30/06

Since the first idea wasn?t going to be practical I planned a new idea to at least get me started. The key framed animations will be mapped out together, allowing for a simpler solution. Again three sets of attacks and three sets of defenses will be created. Then I will create a random procedure that will be able to link the animations together until a termination step is randomly chosen. This will allow for random lengths of fight scenes. Also it will simplify the point of contact so that the clashing procedure will be easier to create.

Problems
-    I am currently having trouble with getting more then one character set to control different animations of the same object.
-    I have not quite figured out how to add clips with the script editor yet.

Date: unknown

My first idea for the creation of a randomized fight is to create three separate attacks for each side (rock guys and sword guys). The attacks would be fully animated as if they were swing in the air. Then I would have a defense for every attack, which would also be fully animated. Then I would produce a collision detection system to find the exact points of contact. This would allow me to not only randomize the attacks but also allow me to change the timing of the attacks.

Drawbacks
-    The collision detection system would not only be very difficult to produce being as the objects for which the collision detection would be used for are not basic shapes.
-    Since we are planning to have a huge army, making all the calculations would be very cost inefficient.
-    This would require more key frame work then would be required for other methods.