Eye of the Swarm Officially Released

Eye of the Swarm has now been officially published on Desura. I am very proud of the final product and happy with everyone on the team to create this video game during the past school year. Play it, it's free, and let me know what you think. Hopefully, I will get a final retrospective out about my experiences with Eye of the Swarm with all the good and all the bad.

For the moment, I am focused on trying to graduate and get a job in the video game industry. I have a potential job at Hi-Rez as I've interviewed with the company in Atlanta. I really do hope I get the job as I am very excited about what Hi-Rez is doing and what they want to do.

*Note - The gameplay video is from Games That I Play which has also published a review of the game.

Eye of the Swarm is Coming to Desura

Desura has officially accepted Eye of the Swarm for publish. It's offical publish date will be May 19; however, we hope to be able to get it published April 28 when we show off the game at EAE day. This is very exciting being able to get a game I made published, even if it is just Desura. I would like to thank all my teammates for the hard work this year to be able to get a great game out and ready for the world.

Updated Trophy Room

I find it amazing how awesome some art work actually helps me write better code. When I got the new art for the trophy room, each trophy was encased in a treasure chest where it would open when its correlated level/challenge was beaten spawning the trophy. The old trophy room was something I had to get up fast for a presentation of the concept, and as such I stuck the spawning code inside the main menu controller that controlled the transition between the main menu and the trophy room. This obviously had to change if I wanted to have n number of treasure chests that could spawn any number of trophies.

This allowed me to generalize the trophy spawn code in a treasure chest class that would be linked to a challenge and would spawn n number of trophies (the Shorca trophy was each of its armor pieces). When a challenge level is beaten and the player goes to the trophy room, the treasure chest will open up and eject the trophy out of it. I probably would have never gotten around to writing better trophy spawner code had it not been for the updated art. Let this be a lesson to artists that the art they give can influence code and if done right, can actually improve code practices.

Getting Stuck in the Wall

Collision detection, if implemented properly, can take care of many collision issues; however, there are some cases where a collision doesn't happen as it should and an object is now stuck on the other side of the wall. This happens sometimes Eye of the Swarm. All levels are enclosed arenas where the borders are defined by an edge collider in Unity. There are cases when a swarm member gets stuck on the other side of the wall. The swarm member doesn't know that its on the other side of the wall and constantly pressing against the wall trying to get back to the player's position. This problem has plagued us for several months putting it on the back-burner thinking of a solution. There is a good solution to this problem, but the way Unity handles it makes the solution difficult to implement.

The arena border in the game is an organic blob that completely surrounds the area. Using linear algebra, there is an algorithm that is used to see if an object is inside an organic blob or outside. Starting from the position of the minion that is believed to be stuck, a ray will be cast from any direction and counts how many times it collides with the shape. If it intersects an even number of times, then it is outside; otherwise, it is inside. This algorithm works for any shaped blob no matter how concave or convex, so long as the shape is enclosed.

There are some problems with this algorithm depending on the direction the ray goes out. Since this can work with concave shapes as well, there is a chance that an intersection will also be a tangent on the intersecting point (floating point imprecision doesn't help as well). There are ways around this such as running the algorithm 3 times with 3 different directions and take the mode of the intersections. This should not be a problem with our game since there aren't that many points that could also act as a tangent. Also if such a tangent is found, then the next time the algorithm is run on the next frame, a different ray will be used and find the true number of intersections. 

There is also another case where this algorithm may run into problems. The arctic level has icebergs in which the swarm should not get trapped in (the iceberg also uses edge collider). Again this shouldn't be problem because if the swarm member is outside the iceberg, then it will add an even number to the total number intersections and won't affect the final calculation for the number of intersections with the border. If the swarm is stuck inside, then it will add an odd number to the total number of intersections and bring the number to an even number showing that it is stuck. 

This algorithm is all fine and good if the ray tracer is good. Unity has a ray caster which shows how many colliders it has gone through. The edge collider that constitutes the border is one collider. It doesn't matter how many times it has gone through the edge collider, it will only show that it went through the collider. The only object that shows how many times it did collide with a collider is Unity's Collision. This throws off the algorithm since it won't know how many collision point there are. We couldn't use this great solution unless we wanted to make our own ray tracer which we just didn't have the time to do, nor should we since that falls on Unity.

There are several other ways to detect if an object is outside the wall. We found a good way that wasn't fool proof, but ensured that no minion would ever get stuck in the wall. This solution is the bounce back algorithm. The swarm bounces off the wall using the collisions normal and reflection code. Using the normal of the collision, we move the swarm a little in that direction, giving them a bounce-back, that is ensured to keep the swarm on one side of the wall. The normal of the collision is always pointed towards the center of the collider so no matter what side of the wall a minion is on, it will still move in the same direction.

This works for the wall collider since the swarm is enclosed in it and the normal is always pointed towards the center of the arena area. This is not the case with icebergs in the arctic level. The center of the iceberg is not where the swarm should back back from. The code is the same, it's just in this context the trajectory of the bounce back will be inverted sending the swarm away from the iceberg. There is one special case with the arctic with a tight corner between an iceberg and the wall where both send the swarm into each other with the bounce back. A not so good fix for this is to artificially set the center of the collider further to its bottom and weighted towards the tight corner so that the normal is pointed away from the wall. This isn't a fix, but more a band-aid; however, it does relieve the problem so that it isn't so noticeable and even though the swarm still goes through the wall and iceberg, no swarm member will ever get stuck.

Getting ready to publish

Eye of the Swarm is in it's last sprint before we send the build out for publishing. The publishing plans have changed. We originally wanted to go for Xbox, but after talking to the ID@Xbox people at GDC, they felt we didn't have enough content to justify an Xbox release (they wanted at least one more boss with more challenges). After this, we decided to now publish on Desura, which is the indie and small company version of Steam. The sprint will end April 14 in which we will send the build off to Desura. We feel that they will accept the build and publish it later in the week (they are known for fast turn-around). A future post will give the exact details of the publish date when they come.

As such, nothing new will be put in the game. All the programmers are fixing bugs and polishing the mechanics of the game to get it ready. I've been clearing 5 - 10 bugs a week and will go into more detail about the more notable bugs in future blog posts. Because we are going on PC, part of the polishing was a better integration of the keyboard for those who don't have controllers. The way I set up the inputs for the keyboard was a 1:1 mapping of the keyboard to a controller button. This was purely for debugging purposes as we thought that we would be going on Xbox One.

Part of this switch, I've implemented an option to use either keyboard or controller based on user preference. No matter what input is used, the game will recognize both. The option switch will only change the UI that shows what buttons to press to do certain actions. Not only did this require a UI switch in the menu, but a more integrated switch with tutorial panels and win/lose splash screens. This required writing a script that would take in two sprites for each input method.

Showing the keys to use, we needed key art. All the artists were busy with more important art and since I needed placeholder art to use as I implement the switching code I've decided to make my own set. I have some experience with Photoshop and can manipulate images to convey what I want; however, I do not posses the skills to do what our very talented artists do. After creating the keyboard set, they looked rather nice, but I wanted to see what the artist assigned to create these actual keys were at. If the artist was already working on them, then a lot of time was wasted creating non-usable assets and if they didn't start, then we had a good set (according to me at least) and save the artist some time so he could work on more important work. Turns out he and the lead artist liked the set enough that they decided to use it in the menu so they wouldn't have to create the assets. It is nice to have some of my own art assets in the game, even though they don't look as nice as the other artists artwork.

Doing this also allowed me to fix some UI bugs with the tutorial panels. The panels would swipe from one panel to the next, but the animation of swipe was based on frame rate and not a fixed time. This caused different behaviors based on the PC that was being used. The fix was simple to implement, but took too long to get to since there is always a big list of bugs to get through.

The game is going pretty well, and we are excited to publish the game to public. The artists also got some new loading screens into the game depending on if the user is loading a boss or the main menu.

Why is there a goto in my code

As I've explored before, the Unity team has made design decisions that force the programmer to use bad coding practices. As I've spent the past couple of months working with Unity, I've developed a love/hate relationship with it. Mostly what fuels my love is that I can use C# which is my favorite language to program in, though Mono isn't helping. It shocked and surprised me when my programming team was working on a problem for the next build had to put in a goto statement. We had a switch case in which we needed a case to fall through to the next case. This is done easily in C++.

switch(condition)
{
    case 0:
    case 1:
        // do some code
        break;
    case 2:
        // do some code
    default:
        // shared code
        break;
}


C# is different in that the fallthrough from case 0 to case 1 is allowed but the fallthrough from case 2 to default is not allowed. In order to get the fallthrough this is what must be done.

switch(condition)
{
    case 0:
    case 1:
        // do some code
        break;
    case 2:
        // do some code
        goto default;  
    default:
        // shared code
        break;
}


It should be obvious why this looks bad. Goto's have been the boogeyman of software engineering that allows subtle bugs and destroys good control flow. It's hatred is so universal that the first rule at many to all software companies is to never use them. Then why did the people at Microsoft decide to use goto to explicitly declare a fallthrough?

Not explicitly declaring a fallthrough does cause subtle bugs as it is possible to forget to include a break and have the code fall through to the next case. In order to avoid allowing programmers to avoid this subtle bug, they had two choices: declare a new keyword or use an old keyword. Declaring a new keyword, such as fallthrough, would give the programmer one less choice of a variable name and add complexity to their work of implementing it into the compiler. Using an old keyword, they had two choices: continue and goto. Goto isn't used as much, or at all, as continue and is a better choice as a case is a label and switching a condition is basically a goto. So the goto was the best choice given these assumptions.

I believe there is a better solution to this problem. Apple released a new, unfinished, language called swift so that mobile developers don't have to use Objective-C to write iOS apps. In their switch-case, there is no break. Each case breaks by default and in order to fallthrough that keyword has to be explicitly declared. I like this paradigm since it avoids the subtle fallthrough bugs and takes out the work of always writing break. I don't think Microsoft will do this since it does require an overhaul of how the compiler handles switch-case.

Does it suck that there is a goto statement in the codebase, yeah. However, this use of goto is useful because that's the only way to fallthrough to the next case so we don't have to replicate code. It's also not used in a way that breaks codeflow or creates subtle bugs from jumping out of a method from multiple mid-method points.

Embedded Main Menu

As part of the overhaul of the main menu, my team made that decision to add flash and include our mechanic more. When seeing other games use their mechanics or gameplay in other portions that were not the core game, we decided that we should make our main menu embedded and let the swarm be the cursor. This also helped solve a big problem that we were going back and forth on. We need a way to let the user get use to manipulating the swarm and creating a new level was just more work than what we had to make it good. By having the main menu also serve as this room, it would provide a small side-activity to get used to the mechanic before playing a boss. My job was to incorporate the mechanics of an embedded menu system.

The standard way we made a menu system is to use Unity's new UI system. The canvas of this system wouldn't work in this case since the menu had to be embedded in the level and not be centered in screen. I had to rewrite a lot of the UI code to recognize if the player is hovering over it, collide with the swarm so they will bounce off it, and set up delegates so that the right functionality can be triggered.

The second part of the embedded menu is how the level select is set up. The player can hover over any boss and select them. When a boss is selected, then the boss will rise and reveal the main boss level and three additional challenges to the boss. These bosses had to be set up differently since the boss will move out and up. It also required an additional state to the button because the button should still remain active when the player is not over it. 

Setting up the level buttons allowed me to reacquaint myself with Action. As part of the generic button, it had to react to any of the 4 xbox buttons (A, X, Y, B). As part of this delegates were set up for each one, but all of them shared the same functionality if a button was pushed. So when a button was pushed, the delegate was assigned to an action which allowed me to save code.

The next part to get the main menu ready is to set up the trophy room. The trophy room allows the player to play around in a "ball pit" that was similar to the one in Alpha. The ball pit is filled with trophies that the player can unlock such as the Turtle's shell or the Shorca's armor. The trophy room is accessible below the main menu where the user can transfer back and forth.