New builds are up on the Downloads page. Go get it and don't forget to leave feedback!
If you don't care about the story behind squashing the bug that kept us from a Mac build – read no further. Go to Downloads and get the build.
Pretty much since we started on the game, there as been this bug that was exclusive to the Mac. It was in a line of code that I didn't write and it was an IndexOutOfBounds Exception. Upon quick glance, there was nothing clear about the error, so I brushed it under the rug and just developed in Windows all last semester. But being a Mac user, this was beginning eating me alive from the inside out. I thought, "we'll just get through Alpha and I'll figure it out then." Well, Alpha came and went and I didn't do anything about it over the break. We did a big code clean up and file reorganization at the beginning of the semester and suddenly the next time I tested things out in Mac OS...the bug was magically gone! Hooray, my many fellow Mac users can become play testers!
I obviously didn't want to just make a build for the Mac in the middle of a sprint, so I was holding out until the end of a good sprint to make a build for Mac. Today was the end of said sprint and I went into Unity to do some quick tweaks on a health bar thing. I started the game up and....the damn bug was back! IndexOutOfBounds Exception at the same line of code! I decided I was going to get to the bottom of this since I had promised a build for so many Mac users.
Really quick, the bug happens during an effect that takes place while the player squeezes the right trigger on the controller, or presses return on the keyboard. The controller's trigger provides a high precision range between 0 and 1 depending on how far down the trigger is squeezed. 0 if fully released, 1 if fully squeezed. The return key is just 1 if return key is down and 0 if return key is untouched.
The line of code that was getting the error had to instance where it was doing array indexing, so I had to figure out which array it was. One of the arrays was the materials of a trailRenderer and the other was an array of ColorKeys in a Unity Gradient. I set excessive null and OutOfBounds checkers prior to the index accessing and nothing seemed to fix it. It was simply a very bizarre bug that I assumed came down to some kind of Unity Compiler error.
However, in my numerous tests trying to debug this thing, I discovered the only time this error occurred was when I was using the controller (as opposed to the keyboard) for the particular effect. I thought that was strange. I use a wireless Xbox 360 controller with an Xbox 360 wireless USB adapter and the TattieBogle driver on Mac OS X 10.10 Yosemite. Perhaps this was unique to the controller or the driver. So I tried my teammates PS4 controller (which amazingly works natively with Mac OS X - just plug n' play). That wasn't it.
I went into our code for our InputManager that will return the correct input based on OS since the Joystick controller Axes vary between OSes. Where the code gets the Right Trigger for the Mac joystick controller, I had it print the value of the Right Trigger (typically a number between 0 and 1 as mentioned earlier). I launched the game, the initial value was 0, as expected. But as I squeezed the trigger the values that were printed ranged from -0.99 to 0.99. Ah ha! The Mac right trigger has some goofy range from -1 to 1. This does matter because the amount our swarm units move around depends on the value returned from the right trigger which was assumed to be a number between 0 and 1 but on Mac was returning negative numbers.
The fix was simple. If the right trigger value is less than 0, add 1. This will guarantee it to stay positive and be a number between 0 and 1. This bug was the devil, and I conquered it.
If you have a Mac running...probably any 64-bit version of OS X which I think is everything 10.6 and up, there is now a build for you. Head on over to the Downloads page to grab the latest copy.
Remember that it's recommended to use a joystick controller. We have tested it with Wired Xbox 360 controllers, Wireless Xbox 360 controllers with a wireless USB adapter, and PS4 via MicroUSB. PS4 via bluetooth should also work if you know how to pair your controller with your Mac (hint...System Preferences > Bluetooth...make sure Bluetooth is on and set your PS4 controller to pairing mode).
We're back at it for another semester. I have been overseeing UI elements for the game with Remington. We have been coming up with ideas for communicating with the player organically as opposed to HUD (heads-up display) elements. For example, I removed the swarm unit counter that was displayed as HUD in the top corner in favor of having the full collection of the swarm glow red upon swarm loss, glow green upon swarm addition, pulse red when the swarm count is dangerously low, and pulse gold when the swarm has reached max capacity. I have opened the variables up for the Unity inspector such that the designers can select the colors of the glow effect, set the fade out time of the glow, and set the time between pulses for states that pulse. Unity has a built in glow effect, however you're required to upgrade to Unity Pro for that. So I implemented my own glow effect. It's a little bit of a hack, but it does the job.
The steps for the glow effect were to first create a sprite for the glow. This was done in Photoshop by just using the sprite that I want to have glow and adding the "Outer Glow" blending option to the layer. I gave it a pretty large spread and make the color white. The white color is the important part, everything else can be done to taste. What the white color does is allow you to set a color overlay in Unity such that when it comes down to setting custom glow colors, we can allow our designers to pick a color in the Unity Inspector. Back in Photoshop, once the glow looks good, save the blend options. You can right click on the layer effects and select "Create Layer". From there, I had to create a mask of the sprite upon the glow layer so there was a shape of my sprite cut out of the center of the glow layer. I had to do this because, in Unity, I couldn't figure out how to get the glow sprite to be behind its parent's sprite. If I could, then this glow could be applied to any sprite.
I added the glow sprite to a child object of the prefab of the GameObject I wanted to add the effect to and by default had the Sprite Renderer disabled. The script was pretty complicated and required using Unity's Coroutines to run the animation of fading the glow from full to off. The coroutines had to be stoppable so that recurring events could interrupt any animations currently in play; i.e. losing minions which would cause a red glow that animates for 2 seconds, losing more minions 1 second later could then stop the previous animation and start a new one to last 2 seconds, then adding some minions 0.72 seconds later could interrupt the previous animation to start a new green glow that fades out over 2 seconds, etc. But in the case of the pulse effect, I didn't want the pulse to interrupt itself because the pulse would start and stop so quickly that you could barely see it. But I did want a fade effect to interrupt a pulse, so I just had to include these checkers in the Update() function.
Here's what it looks like the inspector. Again, I take pride in making sure it's easily customizable for the designers sake. I want to give the designer the freedom to tweak it to the desired effect in as many ways as possible.
There is one more tweak I'd like to add for one more nice detail of customization and that is allowing the designer to select which effect they want to utilize for each state. That is, if they wanted to have there be a pulse effect instead of a glow effect when minions are lost, or they don't want a fade/pulse, but a constant glow, they could make those selections in the inspector for each state. So...there will be another post on this in the near future.