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.

Tutorial Panels

For the current sprint, I am in charge of overhauling the main menu. Part of the overhaul is that the player needs to know how to play the game. Since the time we have left is so small, a new tutorial level was too expensive for us to make, so instead we opted for the cheap and faster version of tutorial panels. When the player plays either the Turtle or Shorca boss for the first time, it will force them through the panel tutorial. If they have beaten the boss but still want to see the tutorial again, then when they hover over the boss level, selecting "Y" will bring up the panels.

I created a generic panels object that would be given a set of images to swipe through. The image would take up almost all the screen given about 10 pixels of buffer. When the player would want to get to the next panel, then the panels would animate by rotating the image across a pivot offscreen given the effect that it is being swiped off. It also fades out as it is swiping off. The user also has the option to go back to a previous panel. When this happen, then the swipe animation is done in reverse where it will fade in and rotate back to its original position.

This provides a basic way to convey info to the user in a fast and cheap way with a little flair. Obviously, we would like to teach the player to play in a better way, without a tutorial would be awesome; however, time restraints left us to be fast and cheap. I still love the final results and feel that it is a great resource for Eye of the Swarm as it can be used in other contexts if panel information has to be given to the player in other contents. 

Updated Turtle Movement

When analyzing the turtle, its movement is kinda boring. First off, it will always look to the right in which ever direction it goes and it will always move in a random direction. I had to update the movement of the turtle to provide some interesting behavior. For now, two new behaviors were introduced. When the turtle hangs around a corner for too long, it should return to the center. Determining that the turtle is in the center is easy enough. Having the turtle keep reference to each position for each corner and if the turtle is close enough, it will return to center. It won't go towards the direct center, It will pick a position at a random distance around the origin and go in that direction.

When the turtle health get low, it will forcefully go towards a volcano for protection. When a turtle goes towards a center will always be probabilistic in which the lower the turtle's health, the higher chance it will go towards a volcano. The probability is calculated as 1 - (curHealth / totalHealth) and if a random number from 0 to 1 is below the probability, it will go towards the closest volcano; otherwise, it go in a random direction. These three behaviors of either going towards the center, the corner, or a random direction allows for more interesting movement from the turtle.

Another behavior that I modifies is which volcano the turtle will send a charge towards. Before the change, it will always send the charge at a random volcano. This gave the chance that the same volcano will always be bombarded by charges and have the same volcano always be active. The new behavior wanted a weighted probability to favor the farthest volcano with decreasing probability favoring each subsequent volcano closer to the turtle. This randomness allowed for the same volcano to not be bombarded all the time, but if one does, then it will be the one that is farthest away and won't kill the player in one stroke.

New Gameplay Trailer

We've got a new gameplay trailer for Eye of the Swarm that now features the Shorca boss.

Redoing a Volcano

Part of my last sprint was focused on redesigning and polishing the Turtle Boss while completing the full gameplay of the Shorca boss. I was assigned to the Turtle boss and part of my responsibility was to rework the volcano. The old volcano worked when a charge hit the base of the volcano and ignite an eruption which was just a red rectangle that would go up and then descend. The volcano was also a volcano and cannon in one in which it could either erupt or shoot out fireballs. We decided to split the two into their own in which a volcano could only either erupt or shoot fireballs. Since my responsibility was redoing the volcano, this gave me a chance to recreate the volcano from scratch to get a better feel. Many of the behaviors of the volcano needed to chance such as the fact that there was no warning that a volcano would erupt or that if a charge hit a volcano while it was in the middle of an eruption, a new volcano would be generate and rise as the old one fell.

I also received some new art which allowed me to do more with the design. I created a new volcano spout (the lava that spews) that had three states: rising, neutral, and falling. It was beneficial to do this way since when a charge hit the volcano if it was in any of these states, it would add time onto the spout and send it back to the neutral state in which it would remain up until the time elapsed again. Another factor that made the volcano looked better was the addition of a particle effect that would spew from the base making it look like fire is erupting. Also when a charge hits the volcano base, the volcano would shake side to side using sin.