I worked as a programmer during the development of Frogkey, responsible for engineering gameplay and proactively helping with technical design elements.

Contributions

• Player Movement and Mechanics

• Camera

• Jumping

• Grappling

• UI/UX Integration and Interaction

• Animations

• Attacking

• Chest Open Animation

• VFX

• Dashing

• Healing

• Unused Damage VFX

• Projectiles

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

Frogkey was a passion project from one of my friends in college that was in the brainstorming phase for over a year. He really wanted to have the game invoke fun mechanics for full engagement. In turn, he really wanted the movement to be polished. Evidently, I worked on the project for a year. When we were assigning our roles, we joked that anyone can be anything since we can learn what we need from the Internet, taking specialties and preferences in mind. It was planned for me to be the lead programmer but turned it down because I didn't like the name. It held a lot of responsibility and weight I didn't want to hold, but the professor basically said that the name didn't matter. The bottom line, programmers and lead programmers still have tasks to do involving the game. If anything, the director/producer/scrum master talks to them more in terms of progress or whatever.

Anyway, I was responsible for creating the game feel and movement of the game. I needed to make sure the jump was good, and the speed was great too. I created the player movement script, and it held a lot of variables to modify. One time the jump felt way too floaty, and I had to increase the jump strength. The same can go for gravity but it felt inconsistent when changed. It was fine where it was. Another time the jump button can be repeatedly used in succession. It made the character hop, but the director didn't want it to hop, so the delay in pressing the jump button was increased.

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

(sidebar: I think working in the dark works because I can't see any distractions, but taking my glasses off does about the same thing too)

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.

- Naikym - Lock movement while in open Chest animation

    - 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.

- naikym - start redesigning 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

- Naikym - implement animations into the project; Animations are in. Need refinement to their timing

- Make Gradual speed smoother. Sometimes delegated tasks to other programmers because that’s what they said helps.

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