CAGD 370: Sprint 4
ePorfolio
Blog Post 4: Clarity Is Key
Publication - 11/22/25
The Goal
My team, Treasure Hunters, has been developing a game prototype dubbed Vinebound. Our goal is to produce a functional prototype of Vinebound for our peers to experience by the end of the semester. The creation of this prototype has tested our collective knowledge on the iterative design process and agile development.
Lead Designer
The idea that is encapsulated in the prototype is of my devising. Throughout each sprint, I have made my best attempts to clearly and consistently explain my vision for this prototype. If my team members don't have a clear vision of the prototype, then the work they complete may not align with the design requested. Leading to an avoidable revision. Building on our previous sprints, I have taken additional steps to ensure that my critiques and ideas are thoroughly explained and conveyed. Each critique and idea is explicitly discussed and written down with verification that each person on the team has seen it. The communication pipeline established as of the last sprint has proved itself useful, as each member has been able to accomplish tasks with minimal confusion, resulting in fewer revisions, accelerating our development velocity this sprint.
The Sprint
Sprint 4 was dedicated to preparing for the system playtest. This playtest would be more comprehensive as it would mix all our aspects together, testing to see how it worked as a cohesive system instead of isolated testing. The feedback of this playtest was crucial, as it would determine if our game was truly viable. On the list to do before the playtest was making levels with the mechanics intertwined within them. My team members handled levels 1 and 2. For me, I was to make a tutorial level and ensure that aspects of the game were clear and concise to prevent any form of confusion.
Combination Puzzle Iteration
The first thing I did this sprint was iterate on my Combination Puzzle from last sprint. What I was able to improve was the selection of the pieces. I used a sphere collider in the previous iteration, which functioned in the direction the character was facing. This led to some confusion in internal playtesting. To fix this, I changed the selection from a sphere collider to a line trace from the reticle. Having two different ways to select something was redundant and only complicated interactions; thus, it was iterated on. During playtesting, the selection change was complemented; however, the shapes gave people the impression they would be picked up. I will use the next sprint to combat this confusion.
Control Scheme Clarity + ADS Limitations
Controls are essential to any game. If these controls are not logically placed, they will need a learning curve and not feel natural to the player. We had multiple abilities that were selected using "1" or "2," meaning they would not be used at the same time, so they could share the same controls for simplicity. Allowing the weapon and grapple to use the same buttons means the player doesn't need to adjust their hand placement during gameplay, giving them a smoother experience. Creating this simplicity was difficult for me as I had to tinker with code that I was unfamiliar with; however, I found a solution that can be simplified down to: if there is a weapon mesh, don't fire the grapple. During the playtest, I received positive feedback regarding this change.
Using similar code, I was able to lock the Aim Down Sight ability to only the weapon, because nif ADS was enabled, regardless of what was equipped, it could be accidentally actuated, distorting the player and possibly killing them.
Pressure Plate Puzzle + Key Revision
This sprint, I was able to create my third and final puzzle for this prototype. The basis is pretty simple, with it involving a pressure plate that is connected to a moving door. This is modular and will be used in our level 3. This was implemented in our tutorial level with a positive reception.
Behind the door are the revamped Keys I made for a puzzle last sprint. The revisions were a change of material and a custom animation script, both of them being visual changes to the keys. Ensuring the keys looked enticing was important, as the player needed to collect them to finish each level.
Tutorial Level
Creating a Tutorial Level is crucial; if it isn't properly created, it will fail to properly prepare the player for the levels. At its worst, it could even confuse the player instead of helping. Using this thought process, I built this tutorial section, which encapsulated simple platforming, a single grapple jump, and a "museum". To help players in the level, I placed floating words to explain things. I tried to be concise and clear. This worked pretty well, but could use some improvement on the wording. The "museum" is something I'm proud of, as it visually introduced the mechanics to the players so they would understand what each thing was in the levels. Doing it this way allowed them to know the mechanics, but let the levels introduce them still. In playtesting, it performed very well as all players were able to understand the level and gain knowledge on our mechanics, leading to a more understanding play session.
.gif)
.gif)
.gif)

Comments
Post a Comment