Frogkey

I worked as a programmer during the development of Frogkey, engineering gameplay alongside technical design elements.

Contributions

• Player Movement

  • Camera

  • Dashing

    • Make the Gradual speed smoother.

• Mechanics

  • Grappling

  • Jumping

• UI/UX Integration and Interaction

• Animations

  • Attacking

  • Jumping

  • Animation State Machine

  • Chest Open Animation

  • implement animations into the project; Animations are in. Need refinement in their timing

• VFX

  • Dashing

  • Healing

  • Unused Damage VFX

  • Projectiles

Collaborating with different disciplines has been an amazing experience, especially when it gives an inside look to see an idea evolve from multiple perspectives.

Frogkey was a passion project from college that was in the brainstorming phase for over a year. My college friend wanted to have the game invoke fun mechanics for full engagement. In turn, he wanted the movement to be polished. I worked on the project for a year. When assigning our roles, we joked that anyone can be anything since we can learn what we need from the Internet, taking specialties and preferences into mind. I was going to be the lead programmer, but I turned it down because I didn't like the name. It held a lot of responsibility and weight I didn't want, but the professor said the name didn't matter. The bottom line is that programmers and lead programmers still have tasks involving the game. If anything, the director/producer/scrum master talks to them for progress notes. I was responsible for creating the game's feel and movement.

One of the tasks made was to create the control scheme for the player

We also had a grapple mechanic it worked when I put it in, but I was confused about what it needed to do. At first, I went through a tutorial to make it and it worked great

During the final playtest, it didn't feel super fun. It was novel but it was too simple to find the fun in it to be brutally honest. I remember some players got stuck in a platform because the jump wasn't high enough. The dash was also weird. It did boost them forward but launched them into the air. One play tester found a glitch where if you angle the camera, it launches you upward. Thankfully you could still go down.

The student group I was in divided elements of the game into tasks, which were given by and appointed to ourselves to increase our accountability, responsibility, proactiveness, and personal integrity. Sometimes we give each other tasks to do as long as we agree and consent to do them. Thankfully none of us had a lot to do for the team, so there wasn't a workload we received that we couldn’t handle.

Some of the tasks appointed for me to do were animations, building metrics for the level design, creating and polishing the player's movement and camera as well as additional visual effects for healing, dashing, damage, and projectiles.

Created Lock movement while in open Chest animation - If I had more time, I looked it up and I may need to split up the animation as a different script and have script disable the movement script until the animation ends.

Redesign the test level with metrics for balancing movement

- Suggested that everyone should play the current build for feedback. Noticed that no one played the actual game yet

Grad Speed is smooth but can’t tell with current model. May require animations to see its flow.

Got the animations in. Gradual speed is being tested now. A little jittery for the transition from walk to run to dash