13/03/13 - Evaluation and Link to all Animation Files

I feel a slight sadness that this module has come to an end, it has certainly been the highlight of my year so far. I've been introduced to many new aspects of game design throughout, though this can mostly be narrowed down to the corporate side of things such as management structures, and  the pitching process, as well as all the knowledge I gained on animation for games. However, I do also feel a slight sense of relief from the modules end. The formation of our group saw the coming together of various sub-groups in the class that normally didn't have anything to do with eachother, this led to the surfacing of some apparent 'clashing of personalities', as well as a slight rift occurring in the group at large as everyone basically kept to the sub-groups they were used to, and I fully admit I did this too, but even so I was left wondering whether we'd actually be able to work together successfully, thankfully as you may know this was not the case.

Still, I feel this brings me to the biggest problem our group suffered, and I think that was a general lack of communication. For example, throughout the project no one really seemed to have a definitive idea of what our game was and wasn't going to be/be about/do, I certainly didn't but I know why that was. A lack of effort to closely follow the development of our game outside of my own role. Yes we had an easily accessible Facebook page where certain people posted important info about their own progress but it was all nothing I really paid particular attention to, and I didn't delve into the group drop box to find out everything I could, I was quite happy working on the stuff I needed to work on rather than passionately watching over the project as a whole. Perhaps that wasn't really my job though, and to be fair if our team was using the Agile management structure then I guess no one needed to really do anything more than what was required of them, but I still feel like I should have invested myself more into this project. I generally blame my social anxiety for these types of things. I can normally deal with the ones that require talking to people I don't normally speak to if I have to, but I’m sure everyone would agree they'd feel far more comfortable working in a group with people they're good friends with on the whole, and in some respects I feel that everything would have turned out better if this had been the case. Still it's a given that the ability to work comfortably within a group of unfamiliar people is essential to anyone wanting to go into the industry or hell work comfortably in any job for that matter. Even so, I still feel like there's some area for improvement there on my part.

Speaking of myself however, I should discuss how I think I personally fared in this module. I feel I coped well with my role, I made sure I met my deadlines, as well as making sure I discussed ideas thoroughly with my co-animator Tim before using them. I was really surprised and impressed by just how well my animations turned out, and though it was incredibly frustrating at times I would gladly do it again as I believe I could do them even better. From research through to production I really enjoyed the animator experience and have come out of the module feeling that I may well have found my profession at last. Though even with all the knowledge I have gained on animating in Maya and the animation process, I realise I have only scratched the surface.

Overall I greatly enjoyed this module, it has been at times fascinating and my anticipation for gaining a place in the industry has never been higher. If I were to be given the chance to do this module again, as mentioned before I would try and invest more of my time and interest in the project and generally try to be more sociable within my group, even if that just meant posting on the group Facebook page more. As for my work within the project I feel I could have saved the Small Character from its importing problems by making sure the model was consistent in all the files, so being a little more thorough would be where I would improve things in my work, I also believe that the knowledge I’m currently gaining in our Animation for Games module would see some improvements to my animations were I to do it again, though thankfully the course was running parallel to my work so it did see some benefits.

Finally, though I may gripe about how things were a little tense and divided in the group, this did seem to fall away as time went on, especially when everything started coming together (though it was definitely still there under the surface!) Its incredibly gratifying to see your own and everyone else’s work coming together in a playable prototype, and I really thought this created more of a team spirit towards the end of the project. 

I am now greatly looking forward to the next time I get to experience another group project, be it in my final year, an internship or in my first paid job in the industry.

Finally, here is a link to all my animation files.

13/03/13 - Importing Issues

Having completed all my animations i let myself believe that all my work was done, but this week some issues presented themselves, confirming some fears i'd had whilst creating them.

Our Coder Dean informed myself and Tim that he was having some issues importing the animations themselves into Unity, everything else seemed to have imported fine but that animations refused to play. We attempted exporting our files to fbx format without success, as well as trying to use the mb files that Maya saves to by Default. Again this didn't work. Thankfully after some intense panicking Dean managed to get them working in-game without having to make any changes to our animations or models beyond conforming them to a new naming system. Phew.

Another problem arose shortly after, one that did require some modifications to the animations themselves. Thankfully the adjustments were relatively minor, but i'll explain how this came about. Simply, the way that Dean has implemented character movement in the game, using a cube that traverses horizontally along the screen, meant that the vertical movement from the Jump animation had to be removed. This is because when the jump button is pressed in game, the cube representing the character physically moves upwards, therefore if there was still vertical movement in the jump animation the character would move upward, and this movement would stack with the vertical movement of the cube. So rather than messing with the game itself we decided it would be easier to remove the vertical movement from the animations then import them back in.

The last issue was one that i personally created, and that was due to my decision to split the fail animations. Bugger bugger bugger. When i realised after watching a demo that all the animations were playing from one file i knew i would have a problem, and given the difficulty i had moving a single pose from one file to another i thought i was in for a mountain of extra work...

Luckily however, i found a solution that would have helped me in the situations where i found myself copying from a pose across from one file to the other, and possibly saved me some time too. I discovered that if i simply imported the file for the second part of the animation into the first, despite this creating a second character model, this meant i could simply copy the keyframes across from one model to the other, simple!

And with that, i was certain my work was done. I handed over the files, and Dean imported the character into the game, once tweak had been made the character came to life, or at least, everything except his right arm did.

Frustratingly, we just didn't have enough time to figure out what the problem was, but everything about my character was fine except for the arm, which refused to move from its tock pose. The rig and animation that myself and Tim had made for the Large character all worked fine but for some reason something went wrong with my Small Character, and i have a sneaking suspicion it had something to do with the inconsistencies between models for each of the animation files, though it still leaves me baffles a to why only one of the arm was affected, i am sure however that given enough time this bug would have been fixed.

06/03/13 - Large Character Animations

As mentioned in the last post, i was to be creating a couple of the animations for the Large character rig i had created to make things easier for my co-animator, Tim.

Given the size and appearance of the character he obviously suited the big thuggish tank stereotype and so i tried to make his animations reflect this.

Idle

For his idle animation i wanted him to look imposing and bulky, i took inspiration from the hulk as he is shown in the avengers, a slow rising and falling of the shoulders and a slight bend at the knees, as well as some subtle head movements convey the bulkiness of this character quite well, i think.

Running

For the running animation i simply opted for a slightly slower animation than i used for the small character, to clarify, the small character takes 3 strides as opposed to the larger characters 2. This leads me to believe that the run animation for the small character may have been too slow for the character he portrays, though sadly its too late to change that now.

I enjoyed working with my Large Character rig, it proved to me that the extra effort i had put into it to make sure it didn't misbehave really payed off. There were no issues with IK's at all. I also enjoyed how greatly this character contrasted with the animations i made for the Small Character. Whereas the animations i made for the small character were quick and jumpy, those of the large character had to be slow and lethargic. A great test of my ability to adapt to different animation styles, and a great way to finish off my work for the module.

27/02/13 - Modelling and Rigging for Third Character - Large

Despite assuming the majority of my work had been completed for this module, the fact that Tim and i had accounted for three different body types in the game had been looming over us both, so given that we had both finished the animations for our characters, we decided to split the workload and get all three characters done. I would be creating the model and rig for the large character, as well as two of his animations; idle and running. Tim would be creating the rest. I went into this one feeling a lot more confident that I could do a really good job of it, i also hoped it would be easier to do as i had effectively done it before. I was also hoping that i may be able to avoid some of the IK issues i had such as twisting along unwanted axis when keyframed if i made and rigged the model correctly. But enough about what i was hoping to achieve, here's how i went about it.

When creating the model i used exactly the same process as i used for the model for my small character, though of course the whole process was sped up by avoiding the mistakes i made first time around, this is also why i have summarised what i did into bullet points.

- Obtained assets from Lewis
     o Addition of liquid effect to model for drinking animation
- Used PSD to create square, flipped images of each body part
     o Made sure to name all images that would have sequences appropriately
- Started Maya
- Created Materials for all body parts
     o Named all materials appropriately
     o Created two hand materials to allow for food and drink animations
- Used same technique as small character to create planes for each body part
     o Used image size to create Maya planes that would be the correct size for body parts
- Arranged body parts onto a background picture of the asset sheet that was given to me by Lewis
- Rearranged planes along the depth axis so that body parts wont intersect and the model looks exactly as it does in the imag

Above you will see the final model, created with no problems whatsoever, and with all images and planes scaled appropriately to allow for various extra sequence images. Going well so far!

Next thing was to create the initial rig, which you can see below.:

I decided to be more thorough with my rigging (and modelling) this time around, making sure to name all the bones and planes appropriately. I even added 'Left' and 'Right' labels to the bones though these can only really be seen in wireframe mode. This was part of the increased discipline i wanted to exert when creating this rig, partly for professionalism, but mostly because the rig would be being shared with another person and would hence need to be as clear and easy to use as possible.

The next thing i did after finishing the above rig, was to test out the creation of the IK's for the arms and legs, unfortunately i managed to run into my first problem: The IK's were rigid and had no flexibility just as had been a problem with my test rig, and that time i'd ended up having to redo them. I tried binding the bones to the model before attempting to create the IK's again with exactly the same outcome. Then the license server connection was lost and given i could only work from my college at the time, i may have had a moment of slight raginess. Especially as the server didn't come back up for several hours afterwards...

But anyway, when i finally managed to get back on i tried out a solution i had been reading about in the meantime: right clicking a bone in Maya brings up a menu system of contextual options, one of these is to 'Set preferred angle'. Meaning the angle from which the IK's should be being solved.

Again this proved unsuccessful.

Again i got rather... frustrated. This is most likely due to the fact i had hoped that i wouldn't have any major setbacks during the creation of this model. I believe this was a useful lesson to learn for the future!

So, after this i decided to start over, just as i did with my test rig, this time however i wanted to pay very close attention to the bones i was placing as i noticed that they did not always use the same axis for rotation for some bizarre reason. So i went about recreating the skeleton, paying close attention to the angles of the bones i was placing, finding that alot of the time the bones would be offset by 90 degrees in unnecessary angles. Paying attention to this, and although it took far longer than it normally would to create the rig, i managed to make sure all bones used the same axis for rotation, and also that they all had positive rotation values as i believe this was the culprit for some of the unnexessary twisting between keyframes in my previous rigs.

I tried locking the y and z rotation values at 0 for the joints in another attempt to clamp down on any undesired rotation by right clicking their respective 'Joint Orientation' value boxes and clicking 'Lock Attribute'.

An ominous crash from Maya followed shortly after... would it be better for me to create the bones then manoeuvre them using the transform tool rather than rotating them?

Before i had a chance to test this idea i made a discovery that blew everything i had just tried into irrelevancy, and it was so simple!

Upon looking at the joint tools options window (by pressing the little square next to the option in the drop-down menu) i discovered that you could have all the joints you create be orientated to the World axis automatically!! Not only this but you could limit the degrees of freedom each bone had before you'd even created them!!!!

A breakthrough, just what i needed.

Once again, i scrapped my rig and started over, but using the joint tool this way solved the axial inconsistencies and the bizarre rotation problems i'd been having COMPLETELY. Leaving me with a consistent, clean rig to use with the model.

Sadly even with my incredible mastery of the joint tool, it wasn't enough to stop the problems i was having with the IK's... rigid as ever.

So given i still hadn't found a solution i decided it was time to actually post my problem online, and after waiting a couple of hours i was provided with what would lead to my solution:

It seemed that all the effort i was making to lock down the rotation to the x axis only was causing problems for the IK solver, and all it took to change this was to unrestrict the limits on the degrees of freedom from the bones that were at the top of my IK chains (Upper Arms, Upper Legs)

So from here i went on to test this solution with all my other IK's and did so successfully! After this i went on to bind the bones to the model with the IK's still there (I believed this may have cause some problems but was proven wrong.) Next i created the point constraints just as i had done for my test model and the small character to stop the feet from going through the floor, I also made sure i named all the IK's and Constraints appropriately using the Outliner window.

And finally, i put the character into a nice silly pose for some screenshots/rendering and that was the large character rig finished!

Despite a major setback during the creation of the IK handles and despite looking no different to it (at least on the surface), i believe that this model is of a far higher quality than the model i created for the small character. It shows better discipline through the clear naming of all assets within the model and rig, and the rig itself shows a much better understanding of the process required to create a 2D animation skeleton. Overall it shows how my skills have improved in such a short space of time and serves as a fitting testament to the standard of work i have submitted for this module. I was very pleased with how it turned out and was confident that the issues i had had with my smaller rig would not be a problem when creating animations with this one.

06/02/13 - Creating Animations for the Small Character

In this post i will be documenting my progress on the creation of the animations i need to create using the small character rig. Below is a quick list of those animations, read on to see how i got on!

• Idle + Variations

• Idle-to-Running

• Running

• Jump

• Duck

• Jump Fail

• Duck Fail

• Eat Item

• Drink Item

Idle + Variations

Starting nice and easy, i created the idle animations. The small character is known to be slightly mad so i wanted him to appear twitchy and excitable. So for all the idle animations he bounces up and down on his feet abnormally quickly and in the variations his foot twitches or his head jerks down to his shoulder spontaneously.

As i said these were the easiest animations to create so i didn't have any problems making them, especially as they involve no significant movement of the limbs.

Running

For the running animation i originally wanted the characters sleeves to be flailing behind him but after finding out there would be a 'speed-boost drink' in the final game i decided he needed a standard running animation and that i would create my original idea if it was necessary.

The first problem i ran into here was fitting the animation into the 60 frames (2 seconds) we had allotted to each animation, it took a little time and some experimentation to create a run animation that fit the two second slot as well as the character i was trying to portray, that of a zippy madman in an unbound straitjacket.

I also ran into more IK problems during the creation of this animation, i found that although the joints wouldn't warp or rotate in undesired directions when i was moving it about manually, the joints tended to do just that when moving between keyframed positions. I found no obvious solution to this so i ended up having to add extra keyframes to stop the joints misbehaving in this manner.

At this point i assumed the animation was finished, but while acting out a jump as a reference for my jump animation i realised that i had my characters body lowering and rising at the wrong times. Moving the key frames forward solved the issue and gave a profound improvement to the final result.

Before:

After:

Idle to Running

This animation is simply (and obviously) the transition from the idle state to running, in my case with a 'warm-up' animation prior to assuming the running pose at the end. It is intended to be played right at the start of a race.

Given that i wanted to show the character raising his arms and shouting some unintelligible war cry before moving off, this was the first animation i created that made use of the extra faces that Lewis made. Thankfully i was saved the time spent searching for a method to achieve this as my fellow animator had already encountered and overcome this problem, and all it involved was changing the file names for each of the Head images. Adding .00x to each of them (with x being the image number) whilst making sure the main image name is the same (so Head.001.png, Head.002.png, etc.) helps the image sequence option detect the different states for the image. Through right clicking the box into which you set the image number, you can set a key and from this to create animation sequences that play along with the rest of the animation. This was everything i needed to gain the animated screaming face that i desired for this animation.

After creating this initial part of the animation i ran into the difficult situation of transferring the starting pose of my running animation into the idle-to-running animation which had been created from one of the idle animations, i needed this so the animation would transfer smoothly into the running animation. This was the part i was dreading the most and the very long time that i spent searching for a solution without success seemed to confirm my suspicions. In the end i simply tried my own idea of opening the two files in two separate instances of Maya and copying the coordinates for each separate limb that was affected by the pose, the results were such that i had transferred the pose exactly into my idle-to-running, though i had to do everything more than once as i forgot to keyframe all the joints when moving between frames!

And here you can see the final result:

Jump

A jump animation is required, as well as a duck animation, as there will be obstacles that require player input to leap over or duck under during the race. Below you can see the jump animation i created, i feel it may be a tiny bit floaty but this game is a bit of a zany cartoony affair so it fits with the style. I believe this was one of the most straight-forward aniamtions i created, that's not to say it didnt take plenty of time and a lot of tweaking to get it to a satisfying standard, i just encountered no significant problems. The jump animation takes place across a 30 fram segment i 'cut' out of the running animation.

Jump Fail

As well as having animations for jumping and ducking animations we also needed to have animations for when the player fails to provide the input needed to successfully traverse the obstacles. Hence the creation of 'Fail' animations.

I decided that given these animations are failures they would need to incur a penalty, i took this penalty idea and used it as an excuse to make the fail animations twice as long as all the other animations. So 4 seconds each. Even so, i stuck to the '2 second rule' and split the fail animations in two, this meant i would have another chance to employ the copied coordinates technique i used for the idle-to-running animation.

Creating the first part of the animation was another straightforward affair, i simply manipulated the finished jump animation so that he didnt make it. With tweaks and quality checks on my part before continuing. Simple!

My original plan for the second animation, given that it starts with the running pose and ends with the character floored, was to swap these poses over. This didn't go to plan due to an error on my part which meant i lost the 'floored' pose (I basically managed to overwrite the keyframes for it by accident), so i ended up using the copied co-ordinates technique.

Thankfully the rest of the animations creation went smoothly, giving the result you see here.

Duck

To create the ducking animation i used the same method i used for the creation of the Jump animation. There were no issues with this one, though i found that to fit my planned animation in i had to allow a devote a larger segment of the run animation to it. I was happy with how it turned out:

Duck Fail

Again no issues creating this animation which, like the jump fail, was split into two parts. I was however, very happy with the results. This is certainly my favourite animation.

Eating/Drinking

These are the animations i made for the eating and drinking actions made by the characters when using different items during a race. Similar to the jump and duck animations, and given that using items only takes place during the race, i created these animations by manipulating the running animation.

After altering the hand images so that i could switch between the regular hand and the food or drink hands (to do this i had to create a duplicate hand image and material in maya for the Left and Right hands), i encountered a problem. Simply put i hadn't factored the food/drink hands in while i was creating the square images for Maya so the planes I modelled for the hands weren't big enough. As such when i switched to the image they appeared slightly squashed on the model.

Thankfully the solution, though slightly inelegant, meant that i didn't have to de-skin and remodel the hands. All i had to do was create a scale keyframe before the switch to the item-in-hand image that would stretch the plane in such a way that it became indistinguishable in size from the reggular hand, then rescale it once the character had eaten/drank the item. By doing this in the space of one keyframe the change in scale is instantaneous and completely unnoticeable.

As a final note i will add that i think particle effect such as crumbs for the eating animation would greatly improve the overall look of these animations. Though such a thing is currently beyond my ability.

And with that one done, my animations for our small character are DONE! All i have to do now is hand them over to Dean Stone our Coder who will put them into the prototype. The next step is to see what else i can add to the game to help finish it off, but in the mean time i have found something that despite being incredibly frustrating at times, was very enjoyable to do. This is a very big step for me as it has given me an area of game development i can truly say i enjoy working in, and a potential focus for the future.

I decided as a final addition i would do a very brief write-up of the technique i emplyed when creating the majority of my animations (aka once i had gotten the hang of it):

1. To start with i would take the main 'back/spine' bone that acts as the central point of the rig and moves all the bones therein, and keyframe some basic rotations and transformations to get the basic movement down.
2. I would then move on to keyframing in the movement of the limbs, often starting with the legs first and, once happy with them, moving on to the keyframes for the arms.
3. Next i would adjust the heads position and rotation as its movement is in direct correlation with the spine's, this would involve keeping the character looking ahead or bending in to emphasise the anticipation for the jump, etc. After this i went through a similar routine with the feet as having the IKs for the legs based at the ankle joints meant that the feet would bend in undesired ways at times.
4. Finally i would create the facial animation keyframes (if they were required of course) before going back and making any more tweaks or adjustments i felt were necessary.
5. At this point i would simply sit back and let the finished animation play over and over whilst feeling very proud of myself.

30/01/13 - Character Rig Creation, Rigging

This week, as i mentioned in the presentation i gave last week, i felt confident enough to move onto creating the model and rig for the Small, Speedy, Straitjacketed game character.

Concept art created by our Artist Lewis Coleman

I was given the Photoshop document you see below, it contains an arrangement of all the body parts in separate layers as well as different facial expressions and alternate hands holding either food or drink items.

I took each of these layers and saved them as separate images, then booted up Maya. I set about creating the planes that i would be using for each of the body parts first, but before doing anything else i created one plane and imported its texture as this was something i hadn't practiced, though it was something we had done in our first year Maya sessions. Whilst my technique was fine, i immediately i ran into a problem: Image stretching.

My hope was that the images would simply appear on the plane scaled normally but cropped by the edges if the plane wasnt big enough to fit it, and that it would simply be a case of making each plane fit the image it was displaying. Sadly i instead found that Maya would stretch or squash the image to fit in the plane on to which it was being applied, and there was no way (as far as i found) to change this. Luckily it didn't take me long to invent a solution to this problem.

This solution was to take each of the body-part images and save them in a square resolution so that i could then create a plane that had a matching size (e.g. image with 450x450 pixel resolution would be applied to a 4.5x4.5 default Maya unit plane) allowing for a consistent scale to the model, hopefully giving a result that looked imperceptible from the Photoshop image i had been given. The results were exactly that, i used a template image to make sure the scale was correct and to match the pose, giving the result shown below.

The template image (left) looks a little strange and that's because i had to go back to the Photoshop document and make the hidden body parts visible so i could pose them properly.

Skinning the model was a simple enough process, i used the same technique as i used with my Test Rig, though i had to use the Outliner to make some selections as the overlapping planes made it difficult or impossible to select the body parts i was trying to bind the model to.

When creating the IK handles for the rig i encountered a problem i hadn't faced with my test rig. I found that both of the arms on my model would only bend in the wrong direction. To solve this i basically had to unbind the bones from the rig entirely, after which i arranged the arm parts in a concave shape before binding them to the bones again. Due to the way IK handles are created, they must have some indication of the direction in which they are supposed to bend before being created, hence bending the limbs slightly before creating them.

After this my rig was finished and ready to be animated!

So in celebration i whipped something up to test it out (apologies for the horrific video quality but you get the idea):

23/01/13 - Progress Presentations

At the end of the last session our lecturer informed us that we would each be presenting our progress in the form of a powerpoint presentation, and that it must consist of what we had done so far, what we were currently doing, and what we would be doing next. Below you can see a summary of what i presented to the class.

What have i done?:

- Pre - production:
Reference Vids

Selection of animation software
- Took a very long time
- Program we eventually chose was practically staring us in the face the whole time
- Decision based on video ofa 2D animation rig created using Maya

What am i doing?:

- Creating a test model and animation rig as a proof of concept

What i will be doing?:

- Creating rigs for the characters in the playable version of our game
- Creating animations for said rig
- Animate various other assets for the game if needed

16/01/13 - Rigging: Test

Rigging, in animation, is the process of taking a 3D model and creating a 'skeleton' of 'bones' that allow for the manipulation of designated parts of its geometry, allowing for the creation of animations for said model.

Myself and Tim, having decided how we would create animations for our game, immediately jumped into Autodesk's Maya to see what we could create. Having previously dabbled in 3D Modelling and Animation in Blender a few years ago, as well as using Maya in the first year of this course, i felt fairly confident that i could create something without using the internet to find out what i needed. I managed to create a test model, which consisted of a series of re-sized and carefully arranged planes, for a human character. I also found out how to create the bones for this test model; either by having 'Animation' selected in the drop down box at the top-left of the UI (Animation Mode), then finding the 'Skeleton' list at the top of the screen and selecting 'Joint Tool', or by selecting the 'Animation' tab from above the 3D workspace then clicking the 'Joint Tool' button, which looks like this:

Once i had the bones in place i realised i didn't actually know how to make the bones interact with the model, luckily Tim had encountered this same problem and already found a solution so he showed me how; to attach a bone to geometry you must have the bone and the part of the model you wish to assign to it selected. Then, in Animation Mode, you must select 'Skin', followed by 'Bind Skin', then selecting one of the options from the list. What i found was that using 'Smooth Bind' as Tim suggested, caused the bones to interact with more than the desired geometry, as well as warping it, which is not what we wanted to do.

Through some experimentation I discovered that selecting 'Rigid Bind' and in its 'settings' window changing the 'Bind to:' drop-down to 'Selected Joints' gave the desired result, which was to have each individual plane attached to a specific bone in the rig.

Next came the task of making the rig easier to animate. It would be perfectly reasonable to create the animations by moving each of the bones individually, but the time this would take is enormous when compared with the time saved by using IK solvers.

IK Solvers or Inverse Kinematic Solvers as i understand them, allow you to manipulate a chain of bones through a single IK handle that is placed at the end of the chain. Moving this handle causes the bones in the chain to bend and rotate so that they are still linked but not overlapping, and that the end bone is still in contact with the handle. It is commonly used to allow for easier and more convincing animation of limbs in human character models.

When setting these up for my test model, which consists simply of selecting the 'IK Handle' tool from the 'Skeleton' list and clicking the top and bottom joints of the chain you wish to create a handle for, i ran into a problem.

Simply put instead of being all bendy and flexible my joints were becoming completely rigid when i set up my IKs, the chain was achored at the shoulder or hip as it should have been, but would stay completely rigid when i moved the handle around and did not flex at all. I was utterly stumped as Tim had managed to create a test rig himself with joints that flexed just as they should have done. In the end i resorted to recreating the rig and found that if i set up the limbs separately before linking them all together i achieved the flexible bendy IK's that i desired, though it was not an ideal solution.

The final part of the creation of our test rigs was to create constraints that would anchor the feet to the floor, as we saw had been done for the rig in the video that led us to use Maya. Having this constraint would mean that the legs of our character would not be able to go past a certain point on a desired axis, for us this was the vertical axis as we wanted define a 'floor' point that would cause the feet to stop and the legs to bend if the rest of the model was moved below it. Such a thing proved very hard to do, or at least to find out how to do...

Initially we just tried out the different options from the 'Constraints' menu in the hope that one would give us the results we wanted. I spent a very long time searching the internet for a solution without success,while Tim continued experimenting with the different options, and while he did manage to achieve what we were trying to do he did it by accident and couldn't see how he had managed it. So we continued looking and eventually found the solution was to use the 'Point' constraint but to make sure the vertical axis was the only thing being constrained.

Words cannot express the relief that was felt after finally solving this problem, but we at least felt that we had reached a point where we could comfortably start on our actual work for the game, the modelling and rigging of the 3 in game characters, Large medium and small. I chose to create the small rig.

09/01/13 - Eureka Moment

Today Tim and I continued our struggle to find a suitable program to use to animate our game characters. After trying so long to find a 2D animation program that would allow for easy implementation with Unity, unsuccessfully, we decided to go back to one of our original ideas which was to use Maya, and create our 2D animations using a 3D workspace. Realising this method may have slight disadvantages such as a slightly unrefined look due to separated limbs, we went in search for examples and stumbled across THIS VIDEO. After watching this glorious video that depicted exactly what we wanted to do to create our animations we decided that Maya would be perfect.

Having finally found a suitable program to create our animations with, and given the need for separate limbs, we asked Lewis to create the assets we would need, and provided him with this list, which includes another list of extra animation points that would be useful for attaching accessories to the characters without having to completely redo animations.

- Head
- Neck
- Torso
- Upper Arm (Left and Right)
- Forearms (Left and Right)
- Hands (Left and Right)
- Hip Region
- Upper Leg (Left and Right)
- Lower Leg (Left and Right)
- Foot (Left and Right)

Potential Assets (Item/Accessory Slots)
Idea: Create ‘points’/placeholders in animation templates where DLC/Customisation items can be attached to a character.

- Headwear
- Facial Accessories
- Neck Accessories
- Chest Accessories
- Arm Accessories (Upper/Lower/Hand)
- Hip
- Leg Accessories (Upper/Lower/Foot)

I believe using this technique will prove far more efficient for creating our animations than anything else, and if the rig can be loaded into unity, it would allow for greater variety of animations through the ability to play two different sequences simultaneously. This would also decrease the workload and file size used by saved animation sequences.

With this new revelation Tim and i were able to write up our section of the GDD:

"Animation for this game will be implemented through the Unity Engine and created through Autodesk Maya.  The animation for this game will be using a 2D Skeletal  System on 3D Models because of the camera angle doesn’t require the use of a 3D Skeletal System. The animation for the game will encapsulate the style found in games like Plants vs. Zombies with the animation being very loose and comical."