DevLog: Week 2 Call to Adventure

The "Call to Adventure" in game development isn't just a narrative trope; it is the technical moment where a static environment becomes a playable world. This week in the Skills Bootcamp, we shifted our focus to the protagonist of any experience: the Player Character, and more importantly, how that character interacts with the world through reusable mechanics.

While my university background gave me a solid foundation in moving a character from point A to point B, this week was about architecting systems that allow for scalable, professional-grade gameplay.

1. Defining the "Actor": The Player Controller

A character is more than just a 3D model with a script. It’s a complex intersection of physics, input handling, and state management.

This week, I focused on:

• Input Decoupling: Moving away from hard-coded keybinds. I am prioritizing a system that separates Input (the button press) from Logic (the resulting action). This ensures that if we swap from keyboard to gamepad, the core movement code remains untouched.

• Kinematic vs. Dynamic Movement: Refined my understanding of when to use the CharacterController component versus Rigidbody physics. For the precision required in modern action-adventures, I leaned into the CharacterController to ensure snappy, predictable player feedback.

2. Building Reusable Interaction Systems

The core goal this week was to create reusable game mechanics. In a professional pipeline, you never want to write the same code twice. If I build a "lever," that logic should be abstract enough to also power a "button" or a "pressure plate."

To achieve this, I implemented an Interaction Interface (IInteractable):

• The Problem: Traditional "If-Else" chains check if a player is looking at a "Door," then a "Chest," then an "NPC." This is inefficient and prone to bugs.

• The Solution: By using a C# Interface, I created a contract. Any object in the game world, whether it’s a sliding door or a pickup item, simply needs to have an "Interact" function. The player doesn't need to know what it’s hitting; it just calls .Interact() and the object handles its own logic.

Professional Impact: This modular approach drastically reduces technical debt. It allows a level designer to drop an interactable object into a scene and have it work instantly without the programmer needing to touch the Player Script again.

3. Creating "Game Feel" through Iteration

Interaction isn't just about logic; it’s about feedback. Using the Custom Unity Events I mastered in Week 2, I’ve started layering feedback into my mechanics:

• Visual Cues: Objects highlighting when within range.

• State Changes: Ensuring the world remembers if a switch is "On" or "Off."

• Scalability: Testing these mechanics across different environmental layouts to ensure the code remains robust regardless of the level design.

Reflection: The Shift to "Systems Thinking"

Coming from a university degree, it’s easy to fall into the habit of "prototype coding"—writing code that works for one specific level. The Bootcamp is successfully pushing me toward Systems Thinking. Every script I write now is designed with the "Next Developer" in mind. Is it readable? Is it modular? Can it be reused in a different project?

Technical Milestone: I have developed a foundational "Interaction Framework" that I can now carry forward into any Unity project, allowing for rapid prototyping of complex environmental puzzles.