The Crowley Zone

Genre: 3D puzzle/platformer

Software used: Unity

Role: Programmer

​

When I joined this project, it already had a few months of work behind it. The group needed an extra programmer, and I had worked with two of the other project members in the past, so they brought me on board. The project itself was appealing to me, as the game's primary inspiration was Rare's Nintendo 64 classic Banjo-Kazooie, which is a game that I really enjoy. My work consisted of implementing animations for the player character, enemies, and objects, introducing animation events to said animations (allowing code to enable at specific frames of animation), part of the combat mechanics for the player, pausing the game, the demo level's boss mechanics, adding directional influence while the player was midair, checkpoints, moving between scenes, currency collection (in a way so that you could only collect a coin once in a level, which was made of multiple scenes), and general bug fixing. This project was also shown at PAX East 2016 as part of the Becker College showcase, alongside 3 other games. Of all the projects I worked on, this one was one of the more completed ones.

​

As this was the first and only project I worked on that I had no part in the original creation, it was a task to get me up to speed in regards to the general code structure of the lead programmer. That didn't take much time, however. Other than that, there were systems and elements that I hadn't worked with before, namely Unity's mecanim system (allowing transitions between animations, as well as animation blending), animation events, and figuring out a method to move the player character between scenes, placing them at the correct entrances and exits.

​

For this movement system, each scene (level) is given its own ID, and in each scene is a multiple number of checkpoint objects. Whenever a player triggers the event that causes them to move to another area, the destination ID is saved to a variable that is accessed when the scene loads. From there, the player is then moved to the appropriate checkpoint. This is accomplished by a script that is placed on the player (which can be seen here), a script that is placed on an empty object located at the area of the checkpoint (which can be seen here), and with an optional script that is placed on a trigger box placed as a child of the empty checkpoint object (which can be seen here). This system also allowed the option to have checkpoints for when the player accomplishes a goal, returning them to that point if they run out of health. A similar method was used for the currency collection as mentioned above, with it loading saved variables when a scene is loaded to see if each coin had already been collected previously. If a coin was, then the coin object associated to the loaded variable is removed.