Week 3 Objectives

HELLO!

I know what you are thinking, where the hell is week 1 and 2 objectives.  Well I skipped the first week because I really didn’t do any graphics work we (Scorching South Studios) mostly went over our future deliverables and requirements and our game vision.  As the team leader I was fairly swamped trying to set up meeting dates for the coming weeks.

This week (week 2) I was also swamped with other course work and readings so I did not get a chance to start looking into SHADER programming.

Aside

I know a lot of people are complaining about how much work we have to do in our course, while I am not one to complain, my classmates are not entirely false.  We do have quite a lot of work in terms of outside class work and preparation for the next class.  Lastly, the game we have to build outside of class is essentially the biggest workload.

While I love the fact we get to build a game with a group of your good friends, it is no easy task.  What would be really beneficial to our program would be a student run game development workshop.  The current workshop is fairly useless in my opinion.  I find that sometimes the proctor wastes a bit of our time with project management lectures that I personally do not find helpful.

What I think we should do is:

  • Sign up for separate smaller workshops taking place in the game lab
  • Rather have an official proctor, have one of the very helpful TA’s our program has the pleasure of  having manage the session
  • The time is essentially a 3 hour work session having all the game lab tools near you to work with (3D screens, motion capture, sound and audio recording software, projector screen, etc.)
  • Rather then standing in long line-ups asking the proctor for help then getting shot down because he says “figure it out” , your peers and the TA can help you
  • The original proctor can stop by for the milestones to check and see how we are doing similar to the current workshop

I feel if our workshops were in smaller compartmentalised sections, it would allow for better peer-to-peer collaboration rather then having 80 people in one room working in their own group.

If we had smaller sessions, people would be able to go up to the front and ask for help, while peers who have run into the same problem could help them.  Also during the testing and debugging period, teams can place their game at the front and other members can play the game and help the team collect data as needed.

Week 3: Objectives

That was a pretty massive aside.

Nonetheless, this week I hope to begin doing some CG tutorials and try to get some experience by doing some homework questions.  Aside from the team leader, I am one of the 3 programmers in my team, and will most likely be doing a large chunk of the shader programming and the report that will be handed in at the end of the semester

I plan on figuring out how use the cell shading algorithm so that we can use it to make our game look a lot better.

Cel-Shading or Cell shading or Toon shading?

As you may or may not know, we are using a lego theme for our game, and as a group we thought that rendering our game with a toon shader would really make it look a lot better.

Aside from figuring out how to do that, my other objectives are trying to implement a skeletal animation system in our game.  We are currently able to load and play BVH files, the next step is to get mesh skinning done.

The reason why we need to have the skeletal animation system is because we have several models we would like to incorporate in the game, and doing a keyframe animation for all of them would be very brutal to our artists and animators.  This would also cause them to deter time from making the models and in game assets look better to animate everything while exporting 100’s of obj’s.  With a skeletal animation system we can use BVH files found on the interwebs and use that for many of our idle animations to add polish to our game.

The only problem is that I theoretically understand how to do mesh skinning, but converting that to code is proving to be difficult.  I am having trouble figuring out how to add weights to the mesh from the joints.  I can visually see it done in Maya (heat map), and I need to figure out how to export that skeleton with all the weights with respect to the mesh and convert that to code so that the joint will move with the mesh.

Once I get that done, my next step is using inverse kinematics to bind the feet of the character to the floor.  But that is optional… for now.

Summary

  • Start CG programming and tutorials to finish homework questions
  • Learn how to do cel-shading/toon shading
  • Figure out how to properly do mesh skinning
  • See if I can export the weighting of the joint structure from maya to our game engine
  • Work on inverse kinematics to reduce foot skating

 

That is all for this week,
Thank you for reading

– Moose

 

Game Construction: Assassin’s Creed

Happy Saturday dear reader,

Today I will be going over the wall climbing technique used in the first Assassin’s Creed.

Overview

Assassin’s Creed is an open world stealth adventure game that takes place during the Third Crusade (1189-1192) with the main player character being Altaïr Ibn-La’Ahad or Atlair.  I wont go into to much detail about what the game is and other gritty details because it is a fairy popular game (over 5 million units sold) and part of a popular franchise.

One of the core gameplay elements of the Assassin’s Creed franchise, is the ability to parkour across any in-game surface and climb any building.

Goal

My goal is to figure out how they created the wall climbing system for Altair, both his locomotion and animation.

Breakdown

Starting of with the gamplay trailer breakdown:

  • From 0:15-0:20 – Here we can see that Altair is in fact floating above the ground showing us that they are not using Inverse Kinematics to bind the feet to the floor.  This is also known as foot skating.
  • 0:34-0:37 and 0:43-0:51 – Altair does not seem to be walking up the stairs like a normal person would rather it seems like he is diagonally interpolating  to give the illusion that he is actually climbing the staircase. Altair is not walking up every step, he seems to be playing an animation and another force is slowly increasing Altair’s elevation making it seem that he is walking up a staircase.
  • 0:53-3:00 – Wall climbing

Locomotion

First let’s begin with user input.  Assuming the player is playing on the Xbox 360, he will be holding the ‘RT’ and ‘A’ button in order to run up a wall and begin to climb it.  After this point they use the analog stick to pick a direction to climb in.

Now the only way to climb a wall is to look for different ledges to point to and then Altair will climb to that direction.  Most the most part he is limited to horizontal (X axis) and vertical (Y axis) movement.  For the most part there is no diagonal movement (X and Y axis) unless there are special landmark buildings where they have certain designs that can be climbed differently.  For the most part there is just X and Y movement on a building.

For the normal movement locomotion, they are not doing anything special other then basic physics across the world.  Altair’s movements are segregated into 2 categories

  • Low Profile – Basic walking movement, the ability to blend and steal
  • High Profile – The player must hold down the Right Trigger and the low profile buttons change.  Atlair can now run, jump and start a wall climb as well as assassinate others and pull out his weapon.  Altair can also tackle and shove people while he is running.
This makes the locomotion for the wall climbing a lot easier.  In the normal default stage (low profile) Altair is grounded on the floor and cannot scale buildings.  However as soon as he begins his wall traversal (0:50 – 1:00) Altair is in another “mode”.  In this mode all his other actions are unavailable.  All Altair can do is traverse the building, drop and let go of the building or jump away.  Essentially Altair is bound to that face of the building.  He switches one axis of freedom.  While on the ground Altair can move on the X and Z direction, as soon as the wall climb starts, he looses either the X or Z axis and gains a Y axis to move upwards in.

In this first image, we can see Altair hanging down on a ledge.  To prove that they used a similar system for almost all the buildings you can see his right arm is going inside the mesh.  This means that the ledges are essentially small bump mapped graphics separate from the locomotion system.  If the locomotion system was parented to the mesh of the building that Altair was climbing, then he would not be going through that ledge in the picture.

The hardest part to figuring out how Ubisoft managed to code the wall climbing system is the “ledges” system.  Did they use nodes that were hand placed on the buildings that indicated the ledge type? Did they physically make ledges in the mesh and had Altiar read in the the triangles to determine if it was a ledge? Was each ledge manually stuck on and treated as another object?

It took me a while to decide on one, but with a little helpful discussion with Kevin a.k.a. @Iceninja77 we were able to agree it was a mixture of nodes and separate objects. We believe that the basic buildings are plain rectangular texture mapped objects and the landmarks are just several polygons in one mesh. The level designer might have manually placed nodes on the building using their game engine to indicate where he wanted ledges.  Those nodes would have different type depending on what type of ledge they wanted and what animation Altair would play to reach it.

Figure 2: Ledge Types

Here we can see some of the basic types of ledges there are.  There are the Purple ledges that are just pieces of geometry that pop outwards and are not connected to other ledges.  The purple edges are only used as stepping stones.  Then we have the Blue type of ledges that wrap around the whole building that Altair can shimmy toward the left or right on.

Figure 3: Ledge Highlights

Each colour seen in Figure 3 is a ledge that Altair can climb on.  The window pane (Blue, Green, Pink, Red) would be a special node that has sub-nodes (Sub-Ledges) in it so that it can be traversed. The normal ledge (Purple) would be another example of a ledge Altair can shimmy around.

So far we have learned:

  • The only inputs are a direction given as a degree from the X-inputfrom the Xbox 360 controller. For example:
    • Left = -X axis
    • Right = +X axis
    • Up = +Y axis
    • Down = -Y axis
  • Once Altair enters a wall climb he is only limited to three options and the other walking actions are locked from use
    1. Move in a direction – Analog Stick
    2. Drop – ‘B’ button
    3. Jump in a direction (upwards or away from the building) – ‘A’ button
  • There are several basic ledge types:
    • Stepping stones – Used for Altair to from to other ledges
    • Shimmy Ledges – Altair can move left or right on these ledges until he finds a stepping stone to climb up, or another Shimmy Ledge.  Shimmy ledges can also wrap around the whole building
    • Sub-Ledge Objects – Special objects like window panes and steel grates that are a mix of Shimmy Ledges and Stepping stones.

Animation

We have a choice to pick between a key-frame animation system or a skeletal animation system.  Assuming that Ubisoft has lots of motion capture data for Altair climbing from and to different ledges, a Skeletal animation system would be the better pick.  Using a keyframe animation system would involve a lot more coding and a much larger animation blend tree.

Lets say that the wall climb is done in a doubly linked list, tree data structure.  The root would be the the top of the tower and the children would be the start of the building.  The way to traverse the tree is to give a direction from the analog stick.  For example, if you initiate a wall climb by walking up to the building and grabbing the closest ledge you would start of at one of the youngest children in that tree.  If you initiate a wall climb by running up the wall you would pass one child node and go to its parent.

Figure 4: Ledge Climbing Tree
  • White is the Root node for the top of the building.  This can be either a point or another flat surface like a roof where Altair is no longer locked in wall climbing mode and is free to roam in the X and Z axis
  • Red/Pink are the Stepping stone ledge types
  • Blue are the Shimmy ledge types
The colours of the line are the types of movements Altair can make.  Altair can go from Stepping stone to Stepping stone provided they are on the same level.  If Altair would want to move up a level he would have to use either a single Stepping Stone or a Shimmy ledge to move upwards.

Now the basic idea here is that you would start at the bottom and work your way up.  This is NOT a BST (Binary Standard Tree) so some rules of tree’s do not apply to us.  So if you start at the bottom on a Stepping Stone ledge type you can traverse the tree by going upward and increasing your level to a Shimmy ledge type and Altair would play the animation from Stepping Stone to Shimmy.  If Altair does not move then he would play the animation for idle on Stepping.

So the best idea is to store the animation to be played in the nodes themselves.  A boolean would be changed and then that animation would play while also moving Altair to that new position.

The reason I would use a tree like this for the wall climbing is that it makes it easier for combining user input and traversing the tree.  If the user inputs a negative X value and if Altair was on a Shimmy ledge he would move left until he reaches the end of that ledge or forever if the ledge wraps around the building.  If the Shimmy edge has a Stepping Stone to the left of it and the user is still inputting a negative X value then Altair would climb to the stepping stone.  If the user wants to climb upwards, the just input a positive Y on the analog stick and Altair will keep climbing upwards until he reaches a dead end and has to move left to right to find another ledge to climb upwards with.

Closing Statements

This was a fairly quick overview of how the climbing system would be done.  I didn’t go into detail about the linked list aspect of it because that would be more complicated.  We would have to factor in several items to choose which animation to be played.  Since sometimes Altair is grabbing the ledge and hanging freely, and other times where Altair is grabbing a Stepping Stone and two level’s under him there is a Shimmy ledge and his feet are held up on that ledge.

I think that having a logic tree for each building would be easier to program rather then giving the player unlimited freedom thinking that each ledge is special and there are unlimited ways of climbing each building.  In reality they are just picking a random point in the matrix and depending on their inputs they are just following a predetermined path.

Thank you for reading 😀

You have just been Moose’d

– Moose