Last week we started getting into interpolation and splines and the math behind it, so this weekend I decided to apply the knowledge immediately and complete at least two of the interpolation assignments.
First I added a linear interpolation function to an existing 3D vector class I had already created. The next step was setting up the SFML input so that it converted mouse coordinates to OpenGL coordinates. I drew a 2D sprite and tested the interpolation function with a few points and a simple algorithm to step through all the points and it worked.
Next I set up a vector of positions and when the user clicked a point was added to the vector. Everything worked fine in the first assignment, and I had very little trouble cycling through the keyframes and the sprite seemed to be interpolating just fine. Then I noticed some smaller movements that weren't supposed to be in there. After setting up a few output messages I discovered that because my implementation of SFML uses real-time input as opposed to event based input, several keyframes are being duplicated and keyframes the are very close to each other are also being added, so occasionally it looks like nothing is happening, but the sprite is in fact interpolating. Those little movements drove me crazy for the longest time, even though they usually lasted 2 seconds or less.
I added a reset for the keyframes vector and finished the assignment.
I moved on to the second question in the easy level assignments. This one took me a little longer to fully grasp the math. I couldn't seem to understand how the algorithm actually worked. I read through the slides from class, then I read from the text book, then I researched a little online. What I didn't understand, and most likely missed during class, was whether or not the catmull-rom spline would result in interpolation through all four points or just two.
I eventually discovered that to get it to go through all 4 points, all I needed to do was repeat the first and last keyframes and step through 4 points at a time. I did that and the code ran for any number of points and passed through all of them as long as the first and last were repeated. Next I tried to add input so that a user could click at least four points and then the sprite would start to interpolate.
When I started testing with input the sprite would sometimes go right past a point and continue infinitely, even though a simple output statement showed it had indeed reached that point. Turns out when doing my comparisons, there would be a difference of say 0.000000001 that wasn't being output to the console. I added a condition that should a point come within that range, it should move on to interpolating to the next point. It worked for some points but eventually I reduced the difference down to 0.00001 and that yielded much better results that were still accurate.
All in all, I have grasped and I understand both interpolation methods and hopefully when I move on to the next assignments I have the same success that I did on these ones.
Computer Animation
Monday, 1 October 2012
Sunday, 30 September 2012
Aerial Combat Game Development - Update 1
Over the last 3 weeks our studio, Phoenix Development Studios, has met at least once per week.
In our first meeting the discussion was mostly which game type should we choose; action, adventure, aerial combat, racing, or run'n'jump. We talked about how we might go about making each one, how much creative control we had, and whether or not we believed we'd meet the criteria for each game type. We eventually found ourselves gravitating towards the aerial combat game because we felt we could do a lot with the game in terms of design and adding our own features to it while still meeting all the requirements asked of us. Our group only has four people and a contractor, meaning planning and managing our time will be more important for us since we don't want to spread ourselves thin.
After deciding to do an aerial combat game we brainstormed different themes and styles of play. We started throwing ideas out randomly and as fast as we could so as to make sure the ideas kept flowing. In terms of themes we had:
- World Wars I, II and III
- Aliens
- Technology
- Bio-mechanical
- Dragons
- Greek Mythology
- Superheroes
- Birds
- Pegasus
- My Little Pony
We weeded out ideas we didn't like and ended up with aliens, technology, and bio-mechanical as themes. We also decided that each level will be like a sandbox and will be played more like Geometry Wars as opposed to Phoenix HD (iOS and Android).
Love how the game looks and how the shapes stretch and compress. We want our game to mostly control in the same way, and we're going with sandbox style gameplay.
Love how this game looks too. It's fun to play, but the player can't really escape from enemies, they're always in his face; I'd like to allow a little more freedom so that a player can move around and be chased, move in one direction and shoot in another.
At this point we were far enough along to start designing the game at a high level and we created a story that suited our themes.
Since then we have finalized the high-level design, determined what art assets we will need and when they need to be done by, and using the Game class from last year's BaseSpriteLib, we have a project using SFML, OpenGL, as well as full Vector, Matrix and Quaternion classes.
I also want to note that in terms of performance there is a considerable difference between SFML and GLUT; the SFML version seems to be running much faster and smoother, I'm not sure why though. The input is also much easier to set up for multiple keys than GLUT because there is no keyboard callback function needed, input is all real-time and SFML has classes setup in its library to make use of it.
I'm really excited to be working on this game, and can't wait to start programming and testing.
Monday, 17 September 2012
Week 1: Diablo 3 Animation Components & Concepts
As of late, I have been playing quite a bit of Diablo III. So I decided that since I am yet to even finish the game that I'd play through it and record some footage and note down what I see. Multitasking at its finest.
Here's a few things I managed to capture.
Apparently once you get to a certain point in the game you can't return to the more open areas,
so I was unable to record the environmental destruction or any more organic animations.
Locomotion System
To move the character you simply have to click to where you want the character to move to, or you can hold down the left mouse button and he will constantly move towards the mouse. Key frame animations are used for most of the character animations in game. The animations appear to adjust smoothly when walking from a flat surface onto an elevated surface such as stairs and hills. Each character also has its own speed, and this can be adjusted at any time and the animation will play accordingly without the "moon-walk effect" that you see in some games.
Animation Blending
For the most part all animations blend well into each other and have a seemingly natural transition between each one. I am certain that blending trees are being used based on the fact that the majority of the transitions I've seen have been virtually perfect (and that this is a big budget triple A game and it is more efficient to use blending trees in large scale games). From walk animations transitioning back to rest animations and vice versa everything is quite smooth. Attack animations blending into other attack animations. AI characters reacting more naturally when being hit rather than cutting out of one animation and into another.
I am also certain that skeletal animation is being used due to the fact that characters share many similar animations and in turn inverse and forward kinematics as well as skinning.
Paths and Splines
In terms of the locomotion system in the game, the player character moves towards where the player clicked on screen. When the player clicks, their character quickly orients itself towards that point and interpolates (linear interpolation) to this point with minimal adjustment for obstacles (almost none). Every character in game follows a similar linear interpolation, except with different targets. For example, enemies will interpolate towards the player and orient themselves accordingly towards the player.
In terms of splines, I could only find one example demonstrated in the video above. There is an attack, activated on a key press, such that when it is pressed, the player character orients towards this point, jumps in the air whilst moving towards the mouse pointers position when the key was pressed. I noticed that whether the mouse was very close to the character, or as far as possible, the character went just as high and stayed in the air for just as long. There was also no noticeable breaks in the animation, and it is always a smooth asymptotic path. Therefore by observation I concluded that this must be a spline interpolation. There are several other examples of spline interpolation in the game, such as projectiles being thrown and such.
Physics Based/Environmental Animations
Diablo III also features a fully destructible environment and ragdoll physics. Most of the destructible objects are furniture, although you do get the occasional body splitting into five pieces and heads rolling around (dynamically I might add). A lot of the dead characters and destroyed objects disappear over time, but the bigger objects and characters tend to linger for a while and so you can just keep hitting them and watch them roll around. Ragdoll physics is always fun to watch.
There are also many small environmental animations I never noticed before. Such as cloth, hair, and grass/leaf animations. The grass and leaf animations are extremely spring-like to the point where its funny to look at. The hair and cloth animations are done well but are easier to see when larger characters appear since their attire flows around a lot more. There are particle systems in place and are used widely throughout the game.
Conclusion
Before this assignment, I never really noticed the simple things such as interpolation, or animation blending, because I was so immersed in the game, I only noticed if something went wrong. This assignment has proven to me just how important these features are in games. They heighten the level of immersion and improve my overall experience even if I'm not in awe every time the character goes up the stairs and his feet actually touch the ground.
Labels:
Animation,
Diablo,
Diablo 3,
Diablo III,
i2310,
infr2310,
UOIT,
UOIT Game Dev
Subscribe to:
Posts (Atom)