The Crowley Zone

Genre: Endless action game

Software used: Visual Studio 2013, Maya

Role: Programmer, artist

​

Like with Howl, this was also a solo project -- although I did have some outside assistance. This project came to be during my time learning how to use OpenGL. It started with a base engine that was provided to me, which had allowed me to import .obj model files and apply properties to them, properties such as collision boxes, events on collisions, movement (automatic or through button presses), gravity, etc. Using this base engine I was able to work with it, adding my own models and properties, to create a simple game which showcased how well I understood both OpenGL and C++ in general.

​

Inspired by games like Downwell and Kersploosh!, the game I created is an endless "faller" where you control a character falling down a tunnel, and your objective is to go down as far as you can. As you fall, enemies and obstacles will appear, some of which can be destroyed if you fall on them. Doing so will cause the character to bounce, allowing you to re-position yourself. The further down you go, you'll encounter new enemies and obstacles, and that's in addition to the gradual increase in speed! The speed at which you fall does stop increasing at a certain point, but at that point the game becomes much more difficult due to the constant barrage of things to avoid. The speed at which you can move your character also increases over time as well. The goal of this project wasn't to make something complex gameplay-wise, but the tools I was given allowed me to create something simple and fun, yet also something that would also be a challenge to create.

​

The enemies and obstacles are as follows:

• Blob - Floats harmlessly in the air, landing on this will bounce you upwards.

• Spiky Blob - Floats harmfully in the air, landing on this will restart the game

• Wall - A random section of the well is blocked off, landing on this will also restart the game

• Fan - A spinning obstacle that will also restart the game on collision

• Void Blob - Works similarly to the standard Blob, except not landing on it will cause it to leave a void zone for a brief period. The void zone will block your view, and moving into it will also restart the game. Try to avoid having these stack up!

​

The tunnel itself was the most difficult part of this project. Originally I went into the creation of the tunnel with the mindset of it being made of multiple cylinder pieces, with each piece being a part of an array or list. Each tunnel piece would have a hitbox located at the bottom of it, and landing on it would destroy that tunnel piece, bring the next piece to the top of the array or list, and create a new one at the end. This however wasn't something that worked out too well, as each tunnel piece would disappear while it was in view, and there were complications with using arrays and lists with the hitbox collision property that prevented it from working as intended. The idea was brought to me that perhaps arrays and lists weren't needed at all, and instead just have it so that each tunnel piece would have its associated hitbox placed a tunnel piece-length underneath it, and to have it just create a new tunnel piece from that (again, still destroying the piece in the process). Doing that worked perfectly, and also allowed me to easily test and see how many pieces of the tunnel I wanted to have visible for the player. From there, I put in a gradual color change for each new piece in addition to a slight rotation to give the player a better feeling of progression as they fell.

​

With the engine provided for me, two types of properties were allowed: updaters and interactions. Updaters worked similar to the Update function in Unity, where anything in that function would be applied to the object with that property (or at least checked) every frame. Interactions would trigger whenever a hitbox given to that object would collide with another object's hitbox. To create a property of these two types, I had to create a class inheriting from one of those types, and through polymorphism, alter the virtual function from the inherited class in the new class to have it be applied properly.

 

One of the challenges of this project was to take the concept of an obstacle and think about how they could be implemented into the game using these property types. For instance, each obstacle features a timer property that is set to destroy the object after a brief period of time, as anything the player passes becomes irrelevant. The Void Blob enemy is made up of three different objects, each one having a multiple number of properties. The first part is the blob section. If the player hits this, the obstacle is destroyed. First, it must have a hitbox that is positioned above the hitboxes of the other sections, so it would have priority if the player falls on it. Because the player can bounce off of it, it is given the "static" property. On a collision with another object, the object is also destroyed. The next part is the void section. This is also given a hitbox, but no static property. Instead, it is given a property that will reset the game on a collision, as the player is meant to avoid the area. Lastly, the third part is an "empty" object that has no visible model, but it has a hitbox that is the size greater than the playable area (but lower than the first part's hitbox on the Y plane) that is to trigger effects if the player misses the first part. This object is given a property that passes another object as a parameter (the void zone in this case) that makes it so that on a collision, the object given will have another property added to it: the follower property. This property makes it so that the object will follow another object's Y coordinates, and for this, it is told to follow the player object. Another timer is added to the void zone, with another self-destructor on a much shorter timer (so the void zone will linger for just a few seconds). After the three objects are created but before they are added to the world, the blob part is then given properties that destroy "unrelated" objects upon collision, referencing the two other parts. This is just so the void zone and the miss zone are also removed properly if the player successfully hits the blob section, and the sections must be created before I can tell the game to destroy them.

​

While this project used multiple different pieces of code to set up the base engine that was provided, the majority of my programming work was done here.

​

You can also download the game here.

Screenshots