Final Blog

The final exam is tomorrow, so this will be my final post. Just in case some of my blogs don't get full marks, I want to have this one here to help reach the full 20/20. I wanted to take this last blog to critique this course as a whole. Talk abut what was good and what was bad and how it could improve for the next game dev students taking it. This is just a follow up or more in depth look of the course to go along with the end of the year course evaluations.

Why not start with the good. In my honest opinion I thought most of the homework questions were fair. Not too difficult, just take time to research and fully implement. I liked this year that the questions didn't expire pass a date similar to passed years when if X amount of students did a question it became worthless. I do however think having a date in order to get more points would have been helpful. What I mean by this is similar to Lennart Nacke's GDP2. You could do as many questions as you wanted when you wanted but if you did more early you were rewarded with a "midterm" you wouldn't lose any grades for not taking the midterm but you would actually get a small bonus depending on how well you did.

The times of each class were good not too early not too late. I don't really like the split up time periods (1.5 hours twice instead of 3) but I know these were the universities decisions and not the FBIT faculties'.

Another good thing that was enjoyable with the class was the use of class participation. An example would be when we had to get into groups to draw scene graphs of our game on the board. It helped get through the class material much better.

Now to focus on some of the things that needed much improvement. Sadly, I think this whole blog work was flawed. I don't mind making a few blogs now and then to keep people updated on work, or to help keep me up to date with learning course material, but when it is mandatory and assigned as work, there should definitely be marks involved. It's not very fair to have work assigned to do but not receive any marks for it. Instead, we just get penalized for not doing them and the penalization is unrelated to the blogs. We lose marks on our GDW and most of our blogs are unrelated to the GDW anyway. If we had a separate blog one worth individual marks, and another worth GDW marks.

Another thing to change would be how the homework questions are graded.They are worth 20% of our final grade. I am totally fine with that. If I don't do half of them I deserve to only get the 10%. To lose an additional "up to 40%" on my final exam (which is worth 40% of my total grade) is kind of unfair. I don't think these should be directly related at all. It's a really negative way to try and force us to do more homework questions.

This course has been good and has also been an improvement over other Hogue courses in the passed. I truly think that these classes would be the best if they were structured like any other University level course. It should simply be structured like this:
20% homework questions
10% blogs
35% GDW
35% Exam

Maybe lower the final and add a midterm? I just feel like there shouldn't be extra penalties for not doing a certain part of the work.

Thanks for reading and please do not take any of this personally, it is just my opinion.

Disney's Material Point Method

 Controlling the elements is a really hard feat in computer graphics. Whether its fog, rain, or snow, the particles and algorithms involved are hard to fully pull off and make look natural. When it comes to animating snow dynamics, I have not come across any sure ways of creating such a realistic effect before. This is because it is hard to simulate all the different kinds of snow like the density, wetness, solidity, liquidity, etc. This has all suddenly changed now thanks to Disney. This video isn't too new, but I came across it just recently. It's a very intriguing video that Disney put out addressing how they simulate snow in their animations. Take a look here

Now, after watching the video, you can see that Disney animators created something new to achieve the cool snow materials an effects. The technology they use is technically called material point method (MPM). MPM works great to simulate snow dynamics, addresses particle volumes, grid forces and collision response to help the animators create shockingly realistic snowball throws, drops and collisions. 

 The picture above is just an overview of the material point method (MPM). The top and the bottom rows are steps that operate on particles while the middle depicts grid-based operations. In the video, they present a unique snow simulation method utilizing a user-controllable elasto-plastic constitutive model integrated with both a Eulerian and Lagrangian Material Point Method as you can see from the picture above, which is taken from the video. The method is continuum based and its hybrid nature allows their animators to use a regular Cartesian grid to automate the self-collision and fracture between each particle. It also naturally allows them to derive a grid-based semi-implicit integration scheme that has conditioning independent of the number of Lagrangian particles. They can show how it all works by having the snow interact with each other and having it interact with characters as well.

 

This picture shows some of the physics calculations they use to create the specific properties they want. If they want a more powdery effect, they use the middle reference. If the snow is more liquid and wet they will use numbers according to the bottom image.

In conclusion, the basic idea behind the material point method is to use particles (material points) to track mass, momentum and deformation gradient. This causes a really cool effect. The math behind this method is extremely intense though. If you are interested in nature particles I suggest looking into this method a lot more intently because this can be applied to a lot of practices. It's great that Disney shares their up to date methods of work with the public similar to devs at GDC.

GDC Presentation: Scripting

When professor Hogue  first mentioned scripting to the class I assumed this was some new kind of new and complex way to code. I thought it would be another technical thing to learn about game engines, that would make me, as a designer, much more inclined to ignore it, or let it pass me by strictly due to its complex nature. I was surprised that I was actually completely wrong and the truth about scripting is the complete opposite of my initial thoughts.

Scripting use a programming language like C# but it allows your engine to execute code that is not part of the game code itself. The scripts run independently of the game code and are parsed through different programs like notepad which allows the parsed material to be changed without having to recompile code. In layman's terms, programmers can create a script in C++ or a language that can take in data that is parsed and it can appear to designers to be easier to interpret. For example; a programmer could make it so the program reads a text file to determine how many enemies would be created in a level and their stats. The programmer would make it so the compiler knows to read in the digits of the parsed .txt file but to the designer it would look something like:

#of enemies = 2
power of enemies = 3
speed of enemies = 5
That is just a very simple example but scripts are generally used to make some of the code more user friendly and easier to decipher.

Just an example of a basic .txt script

Getting a little more in depth with scripts, there are many different types of scripts. From watching the GDC video on scripts I am aware of a few. They are component, system, and data scripts.


Component scripts are kind of like a container for features that you can make work together. They can hold code or scripts. System scripts are grouped together in a system which helps allow them to be accessed much easier. The final script is a data script. Data scripts create a save state of the script, drive the system forward with data, and help determine structures for both.

Pic from GDC presentation of scripts

In Bullet Devil: Attack of the Elements we use scripts. They are used to load in particles. I posted previously on our enemy manager. Our enemy manager also used a script would load in values like velocity, spawn point, the power up they were going to drop, etc. Here is a bit of code taken from our particle manager.

emitter Point
    {
        name                    Ice
        angle                   180
        emission_rate           1
        time_to_live            1
        direction               1 1 0
        velocity                1
        duration                0.1
        repeat_delay_min        1
        repeat_delay_max        1
    }

This piece of code just shows a test of the ice particle effect that surrounds our main characters weapons. We plan to add more attributes like colour, so we can manipulate this script to create other effects like fire, water, earth, etc.

In conclusion, scripts are a really useful tool for programmers to make their code much easier for other members developing the game to understand. Scripts can cut development times by a lot since so many more people can design and implement stuff using scripts other than programmers dealing with their own messy code. There are also some disadvantages to using scripts like making too many so remember to use them sparingly.

Bullet Devil: Attack of the Elements' Enemies

I wanted to take a small break for this blog and talk about my groups game instead of lecture content. Specifically, I wanted to talk about our enemies and a lot of the cool stuff we do with them. 

We control everything our enemies to with a singleton class that has several data members. We call it the enemy manager. We also have a main array in it that is used to represent each wave of enemies. We also include the state of each enemy, whether hey are alive or not alive, the number of enemies currently in the "game world" and a timer to delay certain actions.

The main point of our enemy manager is to keep track of the enemies, spawning, despawning, and the overall management of our games' enemies. It also deals with the ammo and powerups that our enemies drop when they die.

We have a really unique way of dealing with enemies when they die in our game. Instead of deleting them we put them in a space we call "the graveyard". The graveyard is a box underneath the main game world. We didn't want to flat out delete our enemies because we were afraid it could cause memory leaks that could cause the game to crash after X amount of enemies had been killed. The main purpose of the graveyard is so we can reuse the enemies instead of constantly respawning them. We also copy the powerups they would have originally had as well. When an enemy is killed it is sent to the graveyard out of the players sight. When our game requires an enemy with the same attributes as a graveyard enemy it will bring it back to the main game world with all its properties. When in the graveyard, our enemies lose their physics, collisions, etc. in order to save on memory.

*

A pic of the graveyard underneath our level

Our original idea was to stop drawing them and remove their rigid body functionality completely, but Havok's rigid body functionality caused problems when we tried to disable it, like causing the game to crash. To work around this, we simply made the dead enemy box deep enough so that the enemies could not pop back out of it, and the level big enough so that the dead enemy box could not be seen during normal gameplay. Thus, the graveyard was created.

Here's a picture of our enemy manager and what causes our enemies to despawn

When the enemies health drop to 0 their living variable is set to false. This means they are dead and sent to the middle of the graveyard with no velocity. The despawn function also handles what to do with the copied powerup or ammo that I mentioned above. 

          The despawn function also handles the point at which a new copy of the original powerup is created, with the powerup being spawned directly where the enemy died. The variable which keeps track of the number of enemies is being decreased by 1, so that it can be used to more easily determine when all the enemies have died without having to iterate through a loop to check whether all of the elements in the array that keeps track of whether an enemy is alive or not are set to the "dead" value. This is used to automatically respawn the enemies based on their original positions, or their spawn points, which are being loaded in from locators placed within a model of the level in Maya

So essentially, our enemies have all of their variables reset to the state they would be in after initially loading them and have their position set back to the position that we defined as an enemy's initial spawn point. When the function is called, all our enemies get respawned regardless of whether they are dead or not. This allows them to be respawned via a trigger that would force the player to restart their current wave.

I hope this sheds some light on some of the cool things we use in our engine when dealing with our enemies. For a more in depth rundown, check out or Game Engines report.

Navigation Mesh and Insomniac Games

I posted previously about artificial intelligence in games and now I want to do it again. This post talks more about AI path finding. The method used is a navigation mesh or navmesh which is an abstract data structure used for collision and is a tool to help agents path find through large spaces.

I first heard about navmeshes in class when professor Hogue showed us a video of Resistance 2, created by Insomniac games, and how the developers used navmeshses in the game. So what is a navigation mesh or navmesh? A navmesh is a path that is defined as a series of nodes. The path is used for characters and objects to travel through without running into problems or obstacles. Here is an example. Say the game you are building takes place in a forest. You want the AI to intercept the player somewhere in the level. So the AI's destination is the player. If it is told to just walk from point A to B it will clip through obstacles and look unrealistic. It would pretty much look like the AI is a ghost walking through walls directly to reach the player. A navmesh can be used for the AI to walk intelligently throughout the forest and still reach its destination (the player). This can be achieved by placing nodes throughout the level that the AI can go to. Another interesting way to look at it is through tiling on the ground. Treat each tile as a node that you can travel to. If there is something on top of the tile you clearly can't step onto it.

In the picture above, you can see two path. They both start and end at the same point. In the green line you can see that AI unrealistically clips through the wall, its trying to find a short path so it cuts corner. The yellow line depicts the AI following the path more realistically using the nodes from the navmesh. The AI object also travels the shortest distance to get to the end node and doesn't take unintelligent routes.

Insomniac Games have created many popular AAA games. Resistance: Fall of Man, Resistance 2, Ratchet and Clank, and even some of the Spyro games. After doing some research, I was able to find some of the ways they used navmeshes through these games, how they worked, and some of the problems they faced.

 

 

 

Ratchet and Clank

Lets start with their work in Ratchet and Clank. The navmeshes were very basic at first and were hand made by the designers of the game. They would create the mesh and set the nodes for a specific destination they wanted the AI to travel on. They used the A* algorithm to make them travel from point A to point B. Using a handmade navmesh helped the game by making less run-time calcualtions because they didn't use the geometry from the level, they just set specific nodes.

 

Resistance

For Resistance, Insomoniac decided to keep the same method. They created the navmeshes again by themselves in Maya and used that data to build a convex poly mesh at run-time. They wanted to again use A* path finding but they ran into some problems. Only 8 objects could run on the mesh at any given time. The cause of this was because of bottle necking on the physics processing unit.

 

Resistance 2

In Resistance 2, Insomniac had to improve on their bottle necking problems on the PPU. They didn't just fix the problem though, they revolutionized the way they use their navmeshes. they created multiple navmeshes in the level. They placed them in clusters and in different heights of the level. They accounted for the size of particular enemy AI units (some were big, some were small) and were also parametrized to account for the characters jumping to higher and lower places on the map. How they did all of this was by using a 3-sided poly mesh instead of a 8-sided poly mesh. This prevented any overlapping within the polygons of the mesh to not cause any problems with the A* navigation used. They then combined path caching with A* to improve their path finding. 

 

In conclusion, navigation meshes create immerse experiences for players by adding intelligent and fun non playable characters in the games they play. Insomniac has done a great job of showing how they incorporate such great methods of path finding in their games and they keep on improving how they do it.

Scene Graphs

 Only nine more days until the final examination for Game Engines so I decided to review some things that might be on the final exam. Why not start with scene graphs? Scene graphs are very useful when designing games because they keep everything really organized. They show the relationships between different objects in game. Scene graphs are a very helpful tool when design games. They are used to show the relationships between objects in the game. They form a hierarchy to display how nodes are parented to each other either as a parent or a child.

The picture above shows a basic scene graph similar to how the homework question "solar system" works. The root node is that "star" at the top. The picture depicts how the planets are children of the sun. The moons are not parents at all since there is nothing below any of them. The planets on the other hand are parents to the moons and children of the star. Again, this is just a basic diagram but it shows exactly how the base homework question number four works.

Scene graphs aren't just a great tool to keep organization and to visually show how everything is connected. They are also great for transformation and inheritance. When a game uses animation it requires for the children to follow suit with the parent. If  transformations or movement is done by a parent a child will react accordingly but not the other way a round. If you move your finger does your forearm move? No it doesn't, but on the other hand if you move your forearm your finger will move positions as well.

This picture above helps add to my example stated above. From the graph you can see if you move the body, which is the root node, of the character forward five steps, every child i.e. head, lower arm, right hand, etc. will move five steps as well. If the lower right arm moves up five centimeters the parents above it wont be affected by this transformation, and neither will the left hand or lower left arm. The right hand will move as well though simply because it is the child node  of the lower right arm. This is due to the hierarchy stated above.

Scene graphs are also great for applying certain effects and elements in game to more than one subject. Say you have a  fire that starts in the living room of a house. The fire won't just immediately jump to the upstairs bathroom on the opposite side of the house. The fire would be rendered in the living room at first. It would find the children to the room. The children would be adjacent rooms and objects inside the room. This helps the game understand how the fire should appropriately and realistically act. It also helps systems graphically as it knows to only engulf the house it is in. Realistically the fire would spread, but in many video games you see  fire just staying attached to a car that's about to explode (like in grand theft auto) but the fire doesn't catch onto a tree if it is nearby. Also, the documentation would be shorter and cleaner since the programmers working on this piece of the game wouldn't need to write a bunch of if statements saying if fire catches here move here etc.

 

Check out the shrubbery in the bottom left corner. The game knew to make the wheels of the car catch fire and explode but to save the GPU some constraints it doesn't catch onto the bush.

In conclusion, scene graphs are really useful tools that help structure and format a game engine. They are great for transformations, animations, shader effects and are a great way to use and depict hierarchy.