Pumpkin Paladin

'Pumpkin Paladin' was a project built by a team of five programmers. This project had its fair share of ups and downs as it was the first long-term game project that the majority of those involved had worked on. The concept itself came from a lovely brainstorming session and eventually developed to be a sort of middle ground between what everyone on the team wanted to work on.

This project is where I gained my confidence as a programmer in a team and got my first taste of what it means to be a producer.

PROGRAMMING ACCOMPLISHMENTS

Entity and Asset Management

To ensure that all of our assets and entities were handled properly from both a memory and accessibility perspective, I created and helped my other teammates create managers.

The managers that I created are as follows:

• Sprite Source Manager: made all textures read in from their associated metafiles and stored within the manager to be accessed from anywhere within the engine from load in to load out)

• Game Object Manager: read in all of the prefabs from their associative metafiles and stored them within an archetype list so new entities could be cloned and handled in an active list

• Mesh Manager: provided an interface for creating meshes and made sure that all meshes were stored and properly freed at engine load out

The managers I helped with are as follows:

• Sound Manager: made all the game sounds to be accessed from the global space and be initialized at engine load in so that the sound could be called multiple times from anywhere within the engine

• Bullet Manager: gave a lifetime timer to all bullets that were determined by the weapon to which the bullet corresponded to

Enemy Behaviors

Since our game was a randomly generated dungeon crawler, it was necessary that our enemies operated similarly regardless of which "arena" they were placed in. As such, we decided to structure our enemies to have an idle behavior (patrol the location around them using A-Star pathing) and active behavior (attack the determined target). I wrote the initial logic for all of these behaviors and the switching thereof, but one of my teammates refined my A-Star pathing algorithm to be a little more efficient. Outside of that, I gave the following behaviors to the enemies:

• Patrolling behavior: if the player is not within the aggressor's range the enemy would continue its patrol pattern - once a patrol point was met, pause momentarily before finding a random location nearby and continue patrolling.

• Alerting behavior: if the player was in aggressor range, abandon pathing protocol and head towards the player on a vector (changing visual to provide feedback to the player)

• Attacking behavior: once the player was within weapon range, utilize the weapon, making sure not to apply damage as the cooldown was active (providing visual feedback for the player)

• Drop protocol: upon death, randomly determine which item the enemy would drop (nothing, health packet, ammo, weapon, key). This logic ensured that the key (what progressed to the next stage of the dungeon) would only drop once and that it always dropped within the level.

• Friendly fire: if an enemy was hit by another enemy, the two enemies would engage in combat - ignoring the player until one of them had died.

Outside of the enemy behaviors, I also created the enemy generation protocol which determined how many enemies would spawn within a room, where the enemies would spawn, and what kind of enemies would spawn. This also allowed for random weapon generation (same visually but different statistics) which I was also put in charge of.

Player Controller and Feedback

I created the player controller which enabled the player to move the character around the screen, attack with the current weapon, switch between weapons, and interact with objects within the arena. Additional feedback was added to give the player as much information as possible. The feedbacks that I included are as follows:

• Damage difference between weapons: if a weapon had higher damage, when the player walked over it a green + followed by the difference in damage would hover over the weapon; otherwise, a red - and the difference in damage would appear.

• Hurt pumpkin icon: in the top left of the screen is a pumpkin head icon. Depending on the health, the pumpkin head would change between its three states (fine - hurt - beaten) as another visual for the player's health.

• Object Interaction: When over a "pickable" object, I added a floating SPACE to indicate to the player what key press was necessary to interact with the item.

• Ammo counter: since our player could equip ranged weapons an ammo counter was necessary and was placed in the lower left-hand corner of the screen.

• Key icon: To let the player know that they could continue to the next level, a key icon was added underneath the health bar and would change from grayed out to full color once the player had found the key.

Level Progression and Scaling

To allow the player to experience multiple levels, it was necessary for a visual transition from one level to another as well as a scaling of both the player and the enemies. In order to satisfy this requirement, I implemented the following:

• Player statistics: the necessary variables for the player (i.e. health) were stored after each level and reinstated from level to level to "carry over" the player's state.

• Player spawning: had the player randomly spawn within the first chunk of the map so that they wouldn't spawn outside of the map.

• Level progression area: made the staircase (the object that the player could interact with to progress the level) randomly spawn within the player's spawn chunk to make sure it didn't spawn outside of the map.

• Level progression locking/unlocking: at the beginning of each level, the next staircase would be locked, forcing the player to go kill the enemy with the key. Once the key was retrieved, the staircase icon would switch to be opened, providing visual feedback to the player.

• Level progression action: once the player returned to the stairway with the key, they could interact with the staircase which triggered the level progression protocol. As an added visual for the player, the character would start at the top of the staircase icon and go down, decreasing its scale; this made it appear that the pumpkin was going down the staircase.

• Level scaling: between each level, the player's health would increase and the enemies' weapons would have a damage increase, scaling the difficulty of the dungeon.

ARTISTIC ACCOMPLISHMENTS

Since our team was composed of all programmers, we needed to also create the visual assets for the game. With my prior experience with pixel art and animation, I was tasked with creating the in-game assets in order to keep a consistent style.

Entity Animations

All "live" entities were given a series of animations.

The player and three enemies (apple, blueberry, and pineapple) received eight animations in total with 12 frames each and each frame being 32x32 pixels. These animations dealt with their movement and covered both cardinal and secondary directions.

The torches along the walls were given a five-frame animation with each frame being 16x16 pixels. These animations made it seem that the fire on the torch was actually moving, adding more life to the game itself.

Map Chunk Layouts and Tileset

To support the procedural generation of the game, we opted to have different pieces that could be sewn together to create the large maps seen in-game. For this, I created a tileset that had a variety of floor, wall, and ceiling tiles. Using the tileset and a program called Tiled, I created 42 different chunk layouts of varying entrances/exits / dead-ins that were used to create the dungeons in the game.

Static Textures

Unlike the animation sprite sheets or the tileset, the static textures that I created were separate from one another and loaded separately to help in the creation of weapons and general gameplay. These static textures are as follows: items dropped by enemies (health packets, key, ammo), all weapons/projectiles, and pixel-art HUD elements.

PRODUCTION ACCOMPLISHMENTS

Given the size of the team and the relatively small scope of the project, the production tasks were smaller in comparison to my other contributions. However, they were as follows:

• Organized and lead team meetings to go over action plans, outline deliverables, and set deadlines.

• Compiled all necessary documentation needed for shipping and encouraged teammates to complete them early.

• Ensure all milestone requirements were met (and generally exceeded).

• Completed shipping needs and ensured everyone met passing requirements (i.e. code count).