Debugging Features

This past week I had two main jobs: design an overall architecture for the game and implement basic debugging features in-game. Both should not have been that hard, but the way Unity implements things makes the process much harder than it should.

I implemented two features for debugging: a debug menu and debug attributes. The debug menu allows the programmer to open up a menu and change the state of the game. This is exactly like an in-game console, but with a graphical interface. The simplest thing that the menu should do was to draw debug lines. Debug lines can be almost anything from player trajectory to collision box. The idea for this was when draw debug lines was activated was to draw the collision box for each entity. But Unity being Unity, it made what should be a simple task next to impossible. Unity does not have a built-in function to draw a line. No, in order to draw a line, I could either do Debug.DrawLine() or Gizmos.DrawLine(). Both of these do what I want, but the lines only show up in the scene tab, not the game tab. This is problematic because I need to see these lines when I debug the game in the game tab. I won't have access to the scene tab unless I pause the game. That's why I need a method to do it in the OnGUI event. Even drawing a thin box, proved to be problematic. I could use Unity's built in OpenGL to draw the line, but this would be overkill for what I need to do and defeats the purpose of using an engine in the first place. However, I may need to create a GL Utils static class just to do basic functionality that Unity is too lazy to implement (if there is a reason, I haven't found it).

Example of Debug Menu

The second feature I implemented was a debug attributes. This allows the programmer to cycle through each entity and display the attributes of that entity on the screen for easy debugging without relying on Debug.Log to update each entity each frame for cluster. This was much easier to implement; however, what I hoped to have implemented was if draw debug lines were activated, then the collision box belonging to the selected entity would highlight in a different color so that the programmer could tell which entity was which. 

Benchmarking

One of the most common things that are done in game dev is looping over objects to do repetitive task every frame of the game. It is usually here where the bottle necks of game become evident. This happens to be more the case with Will of the Wisp, a game that's main mechanic is based on controlling swarms. The wrong algorithm for a minion or allocating more memory (increasing the Garbage Collector task) than necessary could lead to huge performance spikes that will devastate playability. In order to help swarm performance, two generic aspects of the swarm were tested, how C# allocates memory when using operators over inline methods to manipulate vectors. The other will be how the for loop vs. for each loop effects overall performance and if the iterator is too much overhead.

C# Memory Allocation

There are two ways to manipulate a vector. The first is to use operators which are static overloads that take in both vectors and return a new vector. It seems with all the use of creating new vectors, that it may allocate more memory in the heap than should be necessary. This will create a performance spike when the garbage collector deallocates the extraneous memory. An alternative would be to use methods to update the vectors that would have been updated with the operators. This would stop the extraneous allocation which should reduce both the overhead of initializing new memory and the cost of the garbage collector. 

Test that uses Vector operators:

var object1Pos = new Vector2(10, 5); 
var object2Pos = new Vector2(-5, 3); 
Vector2 object1Trajectory = (object2Pos - object1Pos).normalized; 
object1Trajectory *= 8; object1Pos += object1Trajectory;

Test that uses Vector methods:

var object1Pos = new Vector2(10, 5); 
var object2Pos = new Vector2(-5, 3); 
var object1Trajectory = new Vector2(object2Pos); 
object1Trajectory.Add(object1Pos * -1); 
object1Trajectory.Normalize(); 
object1Trajectory.Scale(8); 
object1Pos.Add(object1Trajectory);

The code above were used in the benchmarking tests that were able to get the average computational time while eliminating the testing overhead costs and initial performance cost of loading libraries. The benchmarking test also measured how much memory was allocated in the heap and how much would be collected by the garbage collector.

The memory is in kilobytes and the time is in milliseconds. As can be seen from the tests, using methods is 28% more efficient than operators, though the increase isn't that significant. This was to be expected since the methods don't have to deal with the overhead of allocation. What went against my initial hypothesis was that the amount of memory allocated to the heap was the same in both operator and method algorithms. Looking deeper into how C# compiles, the use of 'new' doesn't always allocate the object to the heap and set the variable to that memory address. The compiler will allocate local objects to the stack where deallocation isn't a concern. The take away is that even though using methods to update the vector will provide some increase in performance, the garbage collector will do the same amount of work which is more of a bottle neck than the overhead of allocating stack memory. The operator code above is more readable than the method code below it, so for the meantime it will be better to use vector operators over methods. If the performance of the code dictates that the bottleneck is really vector operators, then the code may be changed to use methods over the operators.

For vs. Foreach

When iterating over lists or array, there are two options: for or for each loop. The for each loop is faster to write and more readable; however, at first look, there is overhead cost of generating and iterating using an iterator which needs an IEnumerable. For each loops also has restrictions on deleting objects or replacing the object in the iterator. That's why it seems that a for loop which is properly optimized to only access memory once each iteration would be a better choice in regards to performance.

There will be five tests that will iterate over a list of vectors and an array of vectors. The simple loop will only call the object once while doing a simple method call. The complex loop will do several calls to the object and more advanced calculations. The for loop will test two different kinds of complex loops. The first kind will be when the object is called, it will grab the object from the array each time. The second time will save the object in a temp variable while the object is manipulated.

Simple For Loop:
for (int index = 0; index < list.Count; index++)
{
    list[index].Normalize();
}

Simple For Each Loop:
foreach (Vector2 vector in list)
{
    vector.Normalize();
}

Complex For Loop (1):
Vector2 position = new Vector2(10, 10);
for (int index = 0; index < list.Count; index++)
{
    list[index].Normalize();
    list[index] *= 10;
    position += list[index];
}

Complex For Loop (2):
Vector2 position = new Vector2(10, 10);
for (int index = 0; index < list.Count; index++)
{
    Vector2 vector = list[index];
    vector.Normalize();
    vector *= 10;
    position += vector;
}

Complex For Each Loop:
Vector2 position = new Vector2(10, 10);
foreach (Vector2 vector in list)
{
    vector.Normalize();
    vector.Scale(10);
    position += vector;
}

Each method was tested twice using a List and an Array. The size of the list grew by a factor of two until the final loop was over an array size of one million.

The time it takes to iterate each test for the list.

The time it takes to iterate each test for the array

As is seen from above, there is no determinable difference between a simple loop for both a for loop and a for each loop; however, there is a slight improvement of the performance of looping over an array over a list. Also the for loop has a slight advantage over the for each loop because the for each loop has an overhead cost that outweighs the cost of the basic operation. These overhead costs are not significant enough to be a bottleneck, so the for each loop for a simple loop will provide clarity and readability.

The surprise is in the complex loop. Unsurprisingly, the second complex for loop did much worse than the second complex for loop because the first for loop has to make more reads from memory which does impact performance. The surprise comes that the for each loop did better than the for loop over the long run. The overhead cost of the for each loop didn't have the loss in performance as my original hypothesis and the observations of other programmers online when talking about performance in Unity. The for each loop does have a slight advantage when iterating over an array than the List. I would have loved to do the performance and calculations on a GameObject to get a more accurate view of how the loop would act in game. 

Based on the calculations, the for each loop would be the better loop to go with for both performance and readability. Where it loses in performance, the loss isn't significant enough to be a bottleneck. 

Prototype Pitch and Shadows of Mordor

 My team pitched the prototype to an industry panel. Since the original inception of the pitch, the game has changed to the point that it is something entirely else. The mechanic still focuses on controlling a swarm, but the twin stick shooter was taken out and instead the player uses the swarm as their primary weapon. It's been definitely hard to keep up with each change that the designers want the swarm to do, and each change they want takes away from the properties of the swarm to the point that it feels more micromanaging. Swarms should never be micromanaged; instead, they needed the player to give out general orders to the swarm under their control, and they execute the algorithm for the swarm state that they are in. Even talking to other people who I trust give a frank evaluation, wanted the swarm to be more macromanaged, than what was presented. They also wanted the twin-stick shooter back, as now the right stick is worthless.

After the pitch from the industry panel, we felt good about the presentation and felt that the game has a good chance of making it through and being selected to be made to production when Spring hits. I'm not stressing much and just planned to relax during the weekend. When I got home after the presentation, I was ecstatic to find that Amazon finally delivered Shadows of Mordor, a game that I was really excited to play. The last game I played was Assassin's Creed 4: Black Flag, which was 2 months ago. Playing through Shadows of Mordor, I definitely could tell what all the comparisons to Assassin's Creed was. For all intents and purposes, Shadows of Mordor is exactly like the Assassin's Creed series: from stealth, to finding viewpoints, the overworld map, even to assassinations. However, despite all its similarities, Shadows of Mordor is a really fun game and I feel that it does stealth better than the Assassin's Creed series. Exploring Udun and Nurnen is really fun and reading the encyclopedia (what Assassin's Creed has for places, events, and people) about the world of Middle Earth was really fascinating. I love Tolkien novels, including the Similarion, and seeing this expanded universe in the game form was something, I've been looking forward to since getting tired of the same old rehash game of the Lord of the Rings trilogy. I haven't finished the game yet, but everything I played makes me excited to finish the game and hope with anticipation what Monolith comes out with next.

Swarming

New Feature: the player has a swarm that acts as a shield and can also be used to attack the enemy. I've been tasked to program this swarm behavior that has two states: protect and attack. In protect, the swarm will move around the player acting as a shield. The swarm is still vunerable to fire from both the enemy and the player, so if the player wished to fire at the enemy they risk the chance of destroying their shield. Attack is where each member of the swarm will latch onto the nearest enemy and attack them.

To implement this, I needed to brush up my boid skills. Boids are the simulation of a group of objects that act as a swarm or flock. They follow three simple rules: seperation, alignment, and cohesion. Seperation assures that each member of the swarm doesn't collide with another. Alignment is that they steer towards their target (which can be a leader or the average heading of the nearest flocks). Cohesion is where they steer to move towards the average position of the swarm. For this algorithm, the swarm doesn't act alone, they base their movements off a target creating a leader-follower paradigm. Boids are incredibly difficult to get right, and require fine-tuning to get right. Each rule produces a vector of where they must move, the sum of the vectors will produce their true trajectory. When creating the boids for this game, I ran into problems getting the boids to act in a fluid manner.

The big problem I ran into is when the swarm gets close to the player, then they should circle around the player acting as a shield. In order to get the trajectory to circle around the player, I figured it would just be the tangent of the cirlce they would make. The tangent is just the perpendicular line of the radius vector. The radius vector is easily obtained by the taking the difference between the two objects position vectors and rotating it 90 degrees to get the tangent. When I ran the code, the swarm would form a circle around the player, but they wouldn't move. Only playing with the degrees of rotation did I find that by rotating the radius vector by 45 degrees, they would move in an elliptical manner around the player which makes sense. This gets me the results I'm after, but I'm still confused why rotating 90 degrees doesn't get me the result I wanted. However, for prototype, its good enough and that's what I'll take. I need to move on to creating enemy classes (which I'll cover next week).

Human Body Defense Prototype

I've been assigned to the team, Human Body Defense, a top-down shooter where you must destroy various diseases to heal the body. Our prototype will focus on the main mechanic, using your enemies abilities to adapt to your environment. This means that when you destroy an enemy, you gain some of their ability such as partial immunity to their attacks as well as their weapon to upgrade your own. Thus far, we've programmed a player and an enemy that can shoot at each other, move around and die. Since A.I. is my favorite thing, I took the responsibility of implementing basic enemy behavior. Mostly stalking behavior and correcting course change every 1/2 second while firing every second. The enemy also stalks the player meaning that it will follow the player up until a min distance plus some epsilon. If it is within that min distance, then the enemy will retreat back while firing at the player. Obviously this isn't very exciting, but it does show the concept of an enemy that will attack the player, and when it dies it will drop its weapon for the player to take and adapt to.

Phone Screen with Naughty Dog

I had the opportunity to interview with Naughty Dog for a Game Programming position, and it was completely different than  what I thought it would be. I had two technical interviews for internships at EA and Amazon, and it consisted of the standard questions: "Tell me about yourself", talking about game projects I made, and technical questions about data structures, algorithms, and c++ technical questions. That's what I was studying for when preparing for this interview, specifically talking points about myself, abilities, and my experiences at EA Tiburon. When the phone interview came up, I did not realize that a technical phone screen was completely different from a technical phone interview. After a quick introduction, he went straight into the technical questions. This threw me off a bit as I was expecting the "tell me about yourself" question first.

Even though being thrown off, I was thinking that I would still be fine by not trying to sell myself and stick to the technical which is my strength. A question about dot product comes up which I knew, then he asked an alternative equation for dot product. That is where I started to freeze up, I didn't know. Then he asked me how to find the angle between two vectors, again I struggled to find an answer until I could say that it included dot product. This is where I started to tense up and stress out. The rest of the linear algebra questions only went down hill. When asked how to find the normal vector given three points, I completely forgotten about cross product and was able to google the answer by given the equation. When pressed what the name the matrix was, I couldn't answer. I'd forgotten cross product, one of the simplest concepts of linear algebra. I was only able to have some relief when he started asking about data structures which I felt good on.

It has been a little less than a year since I last needed to do linear algebra, and it didn't cross my mind to refresh my knowledge of it. Linear Algebra was my favorite subject in math, and I consider myself really good at it. After the interview, I was able to look up the concepts and could then answer the questions. My failure to refresh myself on basic linear algebra concepts cost me the opportunity to prove my knowledge of linear algebra and be able to, possibly, continue on the interview process at Naughty Dog. While I haven't heard anything yet about my application and the next steps, I have little hope that I will continue through. All I can do is continue to put applications in to other game studios and when I get the opportunity to interview again, I know what to expect with a phone screen and to add linear algebra to a list of subjects to study and refresh myself.

German Expressionism

I'm finally taking the capstone class for EAE program, where I have to create a video game with a group that will be published. Right now, I'm coming up with pitches. Part of my problem with this is that the ideas that I have for games are not appropriate for this class because of size and time. While the time is only two semesters, about 8 months, the actual time to work on the game will be closer to 5-6 months. This is due to planning and getting approval for the game to publish will take up a few of those months. I'm very interested in making large scale, RPG games that would take a AAA studio several years to make. Trying to scale down has not been easy.

Starting out thinking of pitches, my ideas have not been very good. I've been coming up with stock platformers and caper games, even going as far to rip ideas straight from movies because I'm so unoriginal. Then I started to think about old German expressionist films from the 1920's. Films like Nosferatu, Metropolis, and The Cabinet of Dr. Caligari. All these films have a distinct style of Chiaroscuro, color scheme, and a very distorted view of reality that ventures into dreamlike.

 Still from The Cabinet of Dr. Caligari (source: http://www.filmsquish.com/guts/files/images/caligari12.jpg)

That me me wonder what video games that might make use of the visual style. Turns out, the style is rarely used in AAA games and seldom in indie games. I would think that the german expressionism would be more used in indie games, or student games, as film students overuse the style to show an imitation of creativity. The closest I could find was Limbo. 

Still from Limbo (source: http://i.telegraph.co.uk/multimedia/archive/01683/limbo-game1_1683129c.jpg)

Limbo certainly shares an artistic style with Dr. Calibari and the other black and white expressionist films due to its lighting and color scheme. While the game certainly has a dreamlike state, it doesn't match Calibari's use of distorted perspectives and shapes. The emphasis on a distorted reality isn't the decisive factor if a film is an expressionist film; Nosferatu relied more heavily on lighting than a distored reality.

Many games are more inspired with film noir, which itself was inspired by German expressionism, which features the use of Chiaroscuro in a more sedated reality. Contrast is a game which seems to be inspired by the early film noir of the '30s and '40s, but when looking at the style, would be more reminiscent of Nosferatu. 

still from Nosferatu (source: http://www.derek-turner.com/wp-content/uploads/2013/10/nosferatu-4.jpeg)

still from Contrast (source: http://4.images.gametrailers.com/image_root/vid_thumbs/2013/11_nov_2013/nov_11/gt_contrast_review_em_11-13_6am.jpg?)

In many respects, Contrast could be considered an expressionist film. The game is set in an alternate reality 1920's where Albert Einstein's theory of relativity is used as justification for an extremely distorted reality where the user can shift into the shadow they project and move around in that plane of existence. 

still from Contrast (source: http://cdn.destructoid.com//ul/265659-C1.jpg)

When playing the game, the game feels more similar to a film noir, like M, than by a German expressionist film, like Nosferatu. This is the problem with art styles; there are so many interpretations that it cannot easily be defined nor categorized. There are films that have elements of the style, but could not be considered that style, just like many film noirs can't be considered German expressionism. 

That is why I want to make a game that is truly based on German expressionism than film noir. I want a game that has heavy use of light and shadow, and has a heavily distorted view of reality. One of the games that I will be pitching will be based on that style. A game of hyperbolic emotion with little to no reality. A game where the player has to go through many points in time to right a lifetime of evil. Each time point will be a heavily distorted view of the reality that actually was, and how the main character saw the world. The hub where the player can traverse to the different time points would be like an M.C. Escher drawing with distorted perspectives. 

source: https://thefalloutgirl.files.wordpress.com/2011/10/escher-big.jpg

It'll probably turn out that I'm the only one passionate about this idea, and it won't make it past the first selection process; however, I do want to make a German expressionist game and I will have both an art style and an idea in my back pocket to when I could potentially make the game. A concrete idea is more than what most people have, even if it does suck.