Devlog #2 - Tech Demo

Hello!

Welcome to the second development log for Gimme A Hand, a cooperative puzzle game where players control the limbs of an octopus in their quest to escape an aquarium. This log summarizes the progress made for week 3-4 since the pitch presentation.

Game Design Updates - All About Movement

Recap

Last week, we outlined our philosophy: every player gets control of one tentacle, all working together to move the octopus. The journey from idea to execution, however, required a lot of failed experiments where we learned and iterated with improvements.

Our initial attempt let each tentacle pull the octopus’s body simply by applying force in the tentacle’s direction. This was easy to build but made movement too simple, which led to quite boring and stale gameplay. There was no real need for communication or coordination, and the “chaos” just felt like random flailing.

Our second iteration used an inverse-anchoring system. Players could only move by grabbing onto a heavy immovable object or static objects in the scene. It was better, with more room for mischief, but still didn’t force players to communicate much. Any tentacle could grab anywhere, and the octopus would just go in any direction they wanted, no real strategy and little emergent gameplay.

Current Implementation

The current movement mechanic relies on a system that we are calling “Grab-and-Pull”. Each tentacle must anchor in the intended direction of the movement, while anchored, a linear force is exerted from the tentacle’s grab point back towards the body, pulling it towards the direction.

This is where the fun, chaos, and playability really came alive, with emphasis on synchronization, sabotage capabilities, and social gameplay.

From Concept to Code

The biggest leap this week has been from rethinking how tentacle movement should feel and how to ensure it works with the rest of the game’s physics-driven chaos. Previous version used basic non-Rigidbody transforms for movement, which allowed us to quickly test the tentacle controller, but faced some limitations:

• No collision awareness
• Unrealistic feel
• Hard to scale for multiplayer or believable physics interactions

We migrated from transform-based position updates to full physics-based control using Unity’s Rigidbody component. Now, every tentacle hand is moved using actual velocity and force calculations.

Tentacle Hand Control (Prototype):

• Listens for player inut then moves the hand in 3D space, automatically checking for collisions before actually moving
• If the hand runs into another object, it stops or slides along the surface instead of clipping
• Apply boxcasting for grabbing the nearest object and only grabbing one object at a time
• Config kinematics for when the hand is grabbed vs. not grabbed

Player Manager (Initial Prototype; may be subject to change):

• Implemented player input manager and script to handle spawning player tentacle hands on detection of new controller/keyboard input. On join, a new player will be assigned to an open tentacle (maximum 4 tentacles = maximum 4 players). 

Grabbable Interface (Initial Implementation):

• Builds off of our initial item-grabbing mechanic using colliders and interaction zones.
• There are two types of interface scripts: AnchorableObject (surfaces/immovable game objects tentacles can anchor to and pull body towards while anchored) and GrabbableObject (game objects tentacles can pick up, throw, and move around).

Vector Movement Manager and Tentacle Pull (Main movement mechanic) (Initial Prototype):

• Implemented it so that the movement of the octopus body is dictated by the vector direction sum of all the tentacles that are in the IsGrabbing (anchored/grabbing an anchorable object) AND IsPulling (inputting spacebar on Keyboard/pressing the left trigger on Controller). In other words, the vector sum does not include any tentacles that are not in both of these states (i.e. if no tentacles are IsGrabbing and IsPulling, vector direction 0 and thus the octopus body will not move).

Camera & Head Tracking (Modified):

• Made some slight tweaks to our current dynamic octopus head tracking; adjusted angle to be slightly higher and angled downward as per feedback from the pitch presentation. 
• Will continue to tweak and adjust.

Outline and Outline Manager (Initial Implementation):

• Used a stylized outline effect for all grabbable objects to enhance visual clarity and player interaction. This outline highlights interactive elements in the environment using a colored edge glow.
• To optimize performance and control, we developed a centralized Outline Manager that dynamically enables or disables the outline effect based on the player's proximity, ensuring only nearby objects are visually emphasized.

Tech Demo - Proof of Concept

To support all this rapid development, we’ve set up a dedicated playground scene in Unity where we can quickly test and prototype new tentacle interactions. This sandbox environment is filled with a variety of objects and obstacles, such as pipes, planes, movable props, and potential anchor points, so we can easily experiment with how tentacles grab, swing, collide, and interact in different scenarios. This lets us see right away if changes to the movement or grabbing system feel good in practice and helps us discover new ideas and edge cases before rolling them out to the main game levels.

Visual & Level Design Updates

As we mentioned before in our previous devlog, we mentioned that we want the visuals to be overly goofy or wacky to promote the overall theming we’re going for. We will be using a mixture of high poly and low poly 3D assets, along with some painted textures and cel shaders for a 2D animated stylistic approach. If the outlined cel shaded approach is less readable, we will pivot to a more “matte and shiny plastic” look, akin to the references below.

Octopus Visuals & Shader Functionality (Conceptual):

The octopus itself will be a higher poly model to accommodate all of the movement and deformations it will be doing throughout the game. It is the player’s “Hero” object and will always be on screen, so most resources dedicated to the visuals will be put towards making sure the octopus is functional, looks good, and feels good to see on screen. The octopus itself will be cel shaded, and have object outlines to define each tentacle. As of now, we have yet to test this with the octopus object, so it may be subject to slight change.

The cel shader is done by creating an unlit shader graph and creating a material for it. The material holds texture and colour variables that are then placed onto any object. Then, we take the dot product surface normals, and the vector of the directional light (this shader only works with the directional light, not any extra lights in the scene). Based on the dot product, the brightness is set accordingly. This just creates normal smooth lighting, so in order to have that cel shade look, the number of colour bands are restricted using step nodes, adding the textures together, then dividing by the number of step nodes so the texture is the desired brightness.

Octopus Trail (Prototype):

For now, we have a rudimentary implementation of how we might want a wet octopus trail to function. Since the octopus creature is quite slimy and wet looking, we decided to show that with a shader. Next, we will be deciding how to optimize this feature so that it does not tax the system.

Environment/Level Design (Conceptual):

For our level design, we have discussed going with a linear network type of design for our level, heavily inspired by actual aquariums. Given the time limit that we do have for this project, we will more than likely stick to creating only one fully fleshed out level. After testing with the current movement system, we decided that most of the fun comes from trying to have the octopus navigate through an obstacle course-like environment, so we will be heavily relying on this moving forward.

For now, some of the current implementations we have are listed below:

• Implemented a preliminary underwater visual effect and water surface using custom shaders and post-processing; still under development and needs to be tested for visual quality and performance.

• Implemented and created basic assets and shapes in the engine for the design kit and for testing purposes. More of the low poly assets will be dedicated towards the environment to not only save on processing power, but to have a specific aesthetic.

Audio Updates

For the most part on the audio side of things, we have been recording and testing around with different sounds and potential audios we would need for our game. Much of this time has also been spent fully fleshing out our exact references for how we want ambience to sound along with the level design, background music, and other foley art applications.

Miscellaneous Updates

There have been some minor updates to our team charter. We have a better idea of how our workflow functions, and we decided to reflect that in the document itself.

Next Steps

This week was all about getting the movement and core tentacle mechanics ready for our tech demo, with a strong focus on programming and testing how everything feels in action. We’re now confident that our physics-based tentacle hand control forms a solid foundation for the game’s chaotic co-op experience. Next week, our focus will shift towards level design and refining the details of our overall game design