My goal for this project was to keep things fairly simple when it came to the actions the player could perform. However, most of the map is vertically focused, so I gave the player several ways to move vertically (often through the environment):

• Jumping
  • I implemented variable height calculation to give the player more control over where they land based on their input.
  • This includes special gravity calculations based on how high or low the player is.
• Climbing Vines
  • The player can jump to attach onto vines, allowing them to move up or down. From there, they can jump off to reach platforms they couldn't access before.
• Bouncy Mushrooms
  • When the player lands on these, they bounce much higher, enabling them to clear obstacles that would otherwise be too high.
  • Initially, I allowed the player to control the bounce force by jumping directly on the mushrooms, but it was too inconsistent. To make the game easier, I made every bounce the same force, requiring the player to focus more on timing when to move over obstacles.
• Tree Entrances
  • Similar to the green pipes in Mario, these simply “teleport” the player to its corresponding location.
  • There are only a couple of these spread throughout the level, but serve to act as another form of “movement” for the player.
• Moving Platform (Flying Bird) -> Scrapped Idea
  • A bird that flew from one side of the screen to the other on a timer, and the player could jump on to ride.
  • I encountered problems with allowing the player to jump and ride on the bird at varying speeds while still allowing full player movement.
  • The horizontal movement was interesting and added some variety, however, the vines fit the vertical map better.

I started this project by brainstorming ideas for my overall main theme of a squirrel in a tree. This led to a large scope, as projects often do, so I then created a list of "Must Haves," "Should Haves," and "Would Be Nice to Haves." While some of these ideas were realized in the end, many were cut or heavily modified due to scope and time constraints.

1. Initially, I planned for the player to have multiple attacks, starting with a throwable item that would return, like a yo-yo. However, after prototyping it, the mechanic didn't feel smooth or fun.
2. Another experiment I tried was a throwable stick that would stun enemies (see below), but I could not get the throw to feel right.
3. I also realized that developing a solid combat system would take too much time and shift focus away from the platforming and movement.
4. As a result, I scrapped all combat ideas and focused entirely on refining player movement and creating interesting puzzles.

Even without a combat system, there still needed to be hazards and enemies to make the platforming more challenging. Since these enemies can't be defeated, I designed these based on my original ideas:

• Dynamic Enemies (Spiders)
  • One variant drops down when the player triggers a specific spot on the map, creating a surprise element.
  • The more common variant moves up and down its thread at different speeds.
  • Both variants cause the player to take damage and respawn.
• Static Hazards (Wooden Spikes)
  • A simple hazard placed throughout the map, with varying heights.
  • If the player makes contact, they take damage and respawn.
• Squirrel Guard (Scrapped Idea)
  • An enemy that would "guard" an acorn (health item).
  • When the player is in range, it would follow the player.
  • With no combat, this was hard to balance between too difficult and too easy

For many actions in my game, I needed a way to trigger specific events when the player reached certain locations. Although it may not be the most efficient method, I developed a singleton class to handle these "trigger points." For each trigger point, I:

1. Created an empty GameObject with a box collider at the desired location and set it as a trigger.
2. Attached a trigger point script with booleans to determine the type of trigger.
3. Assigned an index to the trigger point if needed, allowing it to be referenced in a list. For example, a checkpoint trigger would be added to the respawn triggers list to be used by the respawn system later.

The first major use of these trigger points was for player checkpoints. Since there's no combat in my game, I had to decide whether enemies and hazards would:

• Cause a player respawn, or
• Simply knock the player back, giving them a chance to react.

Testing Knockback:

• I initially tested giving the player invincibility frames with knockback.
• The knockback was inconsistent and didn't work well with my player controller's physics.
• It also made it difficult to tell when the player was taking damage, which wasn't ideal.

Final Decision:

• Rather than adding special FX and animations, which I wasn't skilled in, I opted to have the player respawn every time they took damage.
• This made each platforming section a consistent challenge the player had to pass before reaching the next checkpoint, which fit better.

Checkpoint Setup:

• I added numerous checkpoints to reward players for overcoming each challenge.
• These were set up using my trigger points, with a list of respawn points stored inside a manager object.
• Each checkpoint had an ID to track the player's current respawn point.

As a fan of video game puzzles, I was especially excited about creating this part of my game. I enjoy puzzles that are challenging but not impossible, so I aimed to bring that balance into my design. I focused on:

• One Main Mechanic
  • In Portal you solve every puzzle with the portal gun
  • I designed every puzzle around controlling two squirrels at once
• Familiar Platforming & Hazards
  • Same hazards and platforming objects the player is already used to
  • Controlling the second squirrel adds the complexity, or second layer to gameplay
• Puzzle Areas
  • When entering past a blue flag, the second squirrel starts following your inputs
  • It stops following when you exit again
• Interconnected Puzzles
  • Lever and door system, where certain areas are locked until other sections are solved
  • Ties the puzzles together, making each section feel like an important piece of a larger goal
• Puzzle Progression
  • One simple puzzle introduces players to the system
  • Four interconnected puzzles follow, and solving all of them unlocks the final doors

This project was a valuable learning experience for me, especially in terms of planning. I believe my biggest mistake was not establishing design pillars from the beginning, which made it challenging to navigate changes or problems, as I wasn't clear on the game's core identity. Around halfway through, I finally decided that my game should focus on movement, platforming, and puzzles. This clarity made it significantly easier to make subsequent changes.

During this project, I tried a new method of documentation: I wrote down design thoughts and solutions for each major problem encountered (excluding minor bugs). I also captured screenshots, videos, and documented decisions for future reference and comparison. All of these practices helped me make more informed decisions by allowing me to take the time to think through and document my ideas first.

Overall, I consider the project a success. However, I would have liked to include audio, more levels for players to explore, and additional puzzles. I believe the game achieved its goal of gradually introducing players to various mechanics and combining them into diverse puzzles of increasing difficulty. It serves as a tutorial for users, and I think several more levels would provide ample opportunity to explore different combinations of mechanics and challenge players in new ways.