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.

Level Select and Saving

The semester begins again and we only have 2 months before we hit beta and a little over a month after that to get the game to release. In the two months til Beta, the game has to be in a shippable state in which all art and animation is finalized and all levels are complete. After Beta, we take the time to test, fine-tune, and fix bugs. After the good reception we got at EAE Open House, we are invigorated to release the best damn game we can. We decided to only have 3 bosses/levels in which the turtle boss will be simplified to create a good learning environment for the player to get accustomed to the controls and style of play. For this sprint, we are currently creating the Shorca boss which is an Orca that can electrify its armor and release electroballs when an armor piece is destroyed. I've been focusing on two aspects: swarm generation (more to come later) and level progression and saving.

When a player first starts the game, they shouldn't be able to skip to the last level. They need to unlock each level sequentially and be able to go back to previous levels on future replays. This requires the game to save its state so that it can be persistent when the player closes and reloads the game. The data for a saved game needs to be stored in a text file in a location that unity provides. Storing in a text requires a protocol to write in a certain format so that when it reads the save file, it can upload the correct information. Instead of dealing with parsing and protocols, I decided to use my knowledge when I interned at Amazon.

At Amazon, I was working on a cloud computing service that required the service to constantly read and write from a NoSQL database. A queue needed to be stored in the database, so the queue had to be transformed into a format that could be easily sent across a network in packages and stored. The obvious solution was to serialize the queue. This allowed the queue to be easily stored and when I needed to read a queue from the database, I would get the data and be able to deserialize it into a queue data structure. No parsing or anything fancy on my end (except for some encrypting).

By having the save data be a struct with the most important items to be able to load a game state and save it, I could easily store which level had been beaten and which level was still locked. Since we only had 3 levels and weren't going to create any more, I made the decision to hard code levels as bools for speed sake. If given time to go back and redo the system (or my assumption on the levels are wrong), then in the struct, I would have a level dictionary that would store the level name as a key and if it had been unlocked as the value. The level name can be provided from outside the class so there is no hard-coding. Also more elements can be added to struct if there are other game states that we want to save. The game would save whenever a level was beaten without the player ever knowing or having to explicitly save or load a game.

After creating the saving system, I needed to revamp the level select menu. At Alpha, the level select menu was just a sub-menu that would display a list of level names that the player could choose. I got rid of the sub-menu and replaced the play button to go to the new level select menu instead of the first level. The level select now features 3 images, one for each level. The levels that are locked will have a lock symbol on it and the player can only choose unlocked levels. The system works well, but there is one flaw. Since the level menu is in its own .unity file (new level), the music stops when the player goes to the level select, and when the player goes back the music starts up again. This is considered part of the main menu, so the inconsistency is jarring. I either need to make the music persistent between the two scenes, finds a way to make the level menu interact with the regular menu system, or new music can be playing when selecting a level which may be fine. These are design decisions that can be addressed at a later time.

I am very interested to see how the semester goes and am excited to release what should be a great game.

Alpha Trailer

Now that Eye of the Swarm has entered Alpha, we have a trailer to show off and get excitement for the final product. Eye of the Swarm will be released Spring 2015, hopefully on Xbox One.

EAE Open House

Today was the EAE Open House, among the other capstone projects and the master studio thesis games we displayed the alpha build of Eye of the Swarm to students, professors and industry professionals. We were all excited to see how our game would perform among fresh eyes that have not played the game in its earlier stages. We felt the game would do well, but were quite surprised at how well the game would be praised. Not only did the game receive universal praise, but the industry professionals went to the main professors, Robert Kessler and Roger Altizer, to praise our game to them. We received much feedback for ways to improve our game, and as we go into the alpha stage we will implement the feedback that we feel will improve our game for Beta. Overall, I am very happy at the stage our game is in and the positive feedback has relieved the many months of stress and heartache to get our game to fun state.