May 29, 2022: Prototype Thought Process

Submitting the Greenlight Jam Prototype

At the start of the prototype sprint, I originally aimed to create a level and focus on designing enemies and combat situations. One week and one prototype submission later, I'm documenting some of my decisions and thought process throughout the sprint.

Evolution of a bouncy ball

In Sunchaser, an orb of light bounces through the level. The main mechanic of the game is using that orb to deal damage to enemies, and the player can redirect the orb with an ability. Originally, I thought that the orb would hurt an enemy any time it passed through them. In my early builds, it felt like this encouraged passive play where the player would perfectly angle one shot and then stay out of harm's way.

Sunchaser's combat was intended to be more about adapting and thinking on the spot. So, I opted for the orb only being able to hurt enemies for a short period of time: immediately after a redirect but not after the first bounce. This would force the player to have to move closer to the orb multiple times in combat and navigate the battlefield carefully while planning how to redirect it.

In the design doc that I submitted for the Greenlight Jam Ideation phase, I also had a different idea for how the orb would be redirected. I thought it would be based on how the mouse was positioned relative to the player when they clicked. But, some more thinking made me realize how unwieldy this would be. Plus, the player is already tracking their character, the enemies they're fighting, and the orb's position during a fight. Adding in the mouse position to this list could feel overwhelming.

Instead, I chose to have the orb be redirected based on the player character's position to the orb. So the player would push the orb away from them on a key press. This means the player wouldn't have to track the position of an additional object, but now the player's plan in approaching the orb (and direction) is more important.

Rethinking abilities

When I playtested the game with the orb push, it felt like it might be difficult to manipulate the orb and respond to how it'll bounce especially if it went offscreen. As a result, I added in an ability to stop the orb which would give the player a chance to get the orb in the right spot, reposition for a good angle, and/or stop the orb from moving too far away.

Also, the sunchase ability in the design doc wasn't going to work well with the levels. When activating sunchase, the player would automatically and quickly move to the position of the orb. This doesn't work though if there's a wall between the player and the orb. This could easily happen if the player pushes the orb into another room or behind a wall. To avoid this problem, I changed it to teleport the player to the orb after a short delay (using the delay as a cheap way to differentiate it from the dash). In the end, I coupled this with the orb stop to combine into one ability.

Communicating with visual and audio feedback

With the mechanics of the game implemented and a simple level laid out, I had to sort out my priorities in the remaining time before the submission deadline for the prototype. I decided to focus on visual player feedback. This would make it easier for players to get into the game and understand how the mechanics worked.

I wanted to show the direction that the orb would go in before pushing it, so I added a directional arrow near the orb. This would improve aim and help prevent the feeling of being cheated if it didn't go in the direction the player thought. Additionally, I colored the orb orange when it could hurt enemies and white when it couldn't. Then, I made the directional arrow orange (to further reinforce the connection) when the player was in range to push the orb. This demonstrated the push range rather than the player always having to guess the range while dealing with a moving orb.

Since the player could try to activate abilities and fail (not enough stamina or out of range of orb), there needed to be additional feedback to confirm that the player did press the button. I'll still need to revisit this again in the future to communicate stamina exhaustion. But, I added some placeholder visual and sound effects for abilities when they are activated. 

Conclusion

Developing the prototype definitely caused me to confront some of the ideas in my original design and problem solve how to improve it. The prototype doesn't really delve that deep into the combat since the enemy and level design feels basic, but I'm glad I was able to flesh out the mechanics a bit. I also tackled lighting to give the prototype a better feel of how the game might take place in a dark cave with the orb as one of the few sources of light. In the coming weeks, I'm planning on refining the visuals and the combat.