Alien invaders
I designed this Space Shooter with heavy nods to the classic space arcade games like Galaga and Space Invaders. Players must fend off wave after wave of attacking ships by utilizing multiple weapon systems, a recharging shield, and various power-ups dropped from killing select enemies. Each wave increases in intensity as the player must scramble to survive ever increasing numbers of invading ships.
I found the shield mechanics to be an especially interesting problem. For it to work the way I had envisioned it, I had to find a way to track the charge/recharge time, the activated time, and notify the player in a simple yet understandable way that their shield was about to run out. Here is a code snippet of my shield mechanics.
I found the shield mechanics to be an especially interesting problem. For it to work the way I had envisioned it, I had to find a way to track the charge/recharge time, the activated time, and notify the player in a simple yet understandable way that their shield was about to run out. Here is a code snippet of my shield mechanics.
This allowed me to track all the required elements as well as keep the standard shield and the power-up drop shield separate. I also solved the graphic element telling the player when the shield was set to run out by toggling the shield's rendered effect off and on for the final 1.5 seconds of the active time. This achieved the desired effect simply and effectively.
Another issue I had was with the player ship's left and right boosters. My brother (who did all the art for the game) designed the player's ship to have side facing thrusters that were intended to fire when the player moved left or right. Since the animations we used had multiple elements to them, I could not simply turn on and off the renderer for the thruster. I wrote this method to turn all the child renderers on or off. This small method inadvertently was far more useful than I had initially anticipated. Here is the code for the RendererOff method. I wrote a companion method to turn renderers on.
Another issue I had was with the player ship's left and right boosters. My brother (who did all the art for the game) designed the player's ship to have side facing thrusters that were intended to fire when the player moved left or right. Since the animations we used had multiple elements to them, I could not simply turn on and off the renderer for the thruster. I wrote this method to turn all the child renderers on or off. This small method inadvertently was far more useful than I had initially anticipated. Here is the code for the RendererOff method. I wrote a companion method to turn renderers on.
Project: Ladybug
For Shadowfall Studio, I worked on several projects for their portfolio. The main project I was associated with, and the one of which I am most proud, was Project: Ladybug. Project: Ladybug was a children's app that was to be sold along side an award winning children's book. The author had hired us to create an app that had multiple game modes and would be suitable for her target audience. When i was hired on, the majority of the had been roughed in and everyone was hard at work cleaning it up and adding features.
One section the desperately needed help was the Maze Game. The idea was that the kids would be able to drag their player icon through the maze collecting ladybugs. I was assigned this task. The maze code had been purchased and generated a random maze within given dimensions. The issue was that everything that had been tried to control the player failed to detect and respond to collisions correctly. When I first got the code, you could drag the player straight through any wall and it wouldn't register that a ladybug had been touched. The gameplay mode was on the verge of being axed as the studio had spent far too much time on it with nothing to show for it.
I had been playing around with raycasting not too long before that and i thought this would be a great opportunity to try it out. Below is the code which I settled on and it worked like a charm. The player responded quickly and accurately to all collisions and this made the maze workable. With in a matter of weeks, I had the maze fully functional with collectible ladybugs, score tracking, increasing maze difficulty, and a timer to increase the challenge and scale back the maze if the challenge was too great.
We later introduced a 3D mode to the game which was a great challenge and forced me to devise another control system to cope with the new limitations and dimensions. It also exposed that the maze reset and transitions were jarring and needed a little delay so the player could have time to adjust to the change and approach the new maze ready rather than already behind.
One section the desperately needed help was the Maze Game. The idea was that the kids would be able to drag their player icon through the maze collecting ladybugs. I was assigned this task. The maze code had been purchased and generated a random maze within given dimensions. The issue was that everything that had been tried to control the player failed to detect and respond to collisions correctly. When I first got the code, you could drag the player straight through any wall and it wouldn't register that a ladybug had been touched. The gameplay mode was on the verge of being axed as the studio had spent far too much time on it with nothing to show for it.
I had been playing around with raycasting not too long before that and i thought this would be a great opportunity to try it out. Below is the code which I settled on and it worked like a charm. The player responded quickly and accurately to all collisions and this made the maze workable. With in a matter of weeks, I had the maze fully functional with collectible ladybugs, score tracking, increasing maze difficulty, and a timer to increase the challenge and scale back the maze if the challenge was too great.
We later introduced a 3D mode to the game which was a great challenge and forced me to devise another control system to cope with the new limitations and dimensions. It also exposed that the maze reset and transitions were jarring and needed a little delay so the player could have time to adjust to the change and approach the new maze ready rather than already behind.
Ullamaliztli
My latest project is 2D platformer style game in which the object is to throw a ball throw a horizontal hoop to score points. This will be my first AI project as I intend to have a AI controller opponent who will attempt to steal the ball from you as you move through the maze of platforms so that it can take the ball to it's side of the goal and throw it through. This project has already become fascinating for me as I have decided to forgo the Rigidbody component in Unity and detect collisions with raycasting instead. This is a bit of a challenge as I have only used raycasting once before. I am also really looking forward to implementing AI functionality into a game.
My intention is to implement the following:
-Ability to charge the power of your throws
-Moving platforms
-Multiple ball spawn locations
-Changing level design that reorders itself when a team scores
-A.I. Opponents
So far, I have implemented a ray-based collision system and got the basic game play elements such as the jumping physics, the ball physics, throwing the ball, and scoring working. I ran into an issue where the majority of my maze like level was ignored as the players could simply score and then run along the top most layer to pick up the ball and score again. I have been brain-storming ways to encourage or require that the players use the whole level. A few of the ways I have come up with is a barrier separating on side of the goal from the other that prevents the players from running to the other side of the goal without using the lower layers. Also, minimizing the upper layer to just a few moving platforms would encourage the ball to bounce down into the lower layers thus forcing the players to chase after it.
Here is a bit of my current code handling the throwing of the ball...
My intention is to implement the following:
-Ability to charge the power of your throws
-Moving platforms
-Multiple ball spawn locations
-Changing level design that reorders itself when a team scores
-A.I. Opponents
So far, I have implemented a ray-based collision system and got the basic game play elements such as the jumping physics, the ball physics, throwing the ball, and scoring working. I ran into an issue where the majority of my maze like level was ignored as the players could simply score and then run along the top most layer to pick up the ball and score again. I have been brain-storming ways to encourage or require that the players use the whole level. A few of the ways I have come up with is a barrier separating on side of the goal from the other that prevents the players from running to the other side of the goal without using the lower layers. Also, minimizing the upper layer to just a few moving platforms would encourage the ball to bounce down into the lower layers thus forcing the players to chase after it.
Here is a bit of my current code handling the throwing of the ball...