railkill/the-fat-hand

Game for #minijam88. Born with a fat hand, you solve physics-based puzzles with one cute little punch at a time.

the-fat-hand's Issues

Remove libgitapi.dll from export

This is for the Godot git plugin, which has nothing to do with the game, so it should not be included in the export.

Improve floor button

Currently, the floor button doesn't actually function as a switch and doesn't work with forces. We want the button to be spring-operated and only gets pressed after a certain amount of force is exerted on it (configurable).

Implement on/off lever switch

Gameplay feature for operating certain doors, and even serve as a toggle for certain in-game options. The lever needs to be a physics object interactable with the hand, much like the volume slider already implemented in the game.

Implement character customization

Allow players to grab articles of clothing, bring them into the changing room, and boom, clothing swapped. Existing clothing swapped out will just be flung across the room onto the floor. If there's a lot of clothing, it will get very messy and difficult to find the clothes the player wants. Perhaps the UI element can be restricted to the dresser only, where if the player interacts with the dresser, it will show a UI to spawn clothes. Any clothes not cleaned up will persist, so it is up to the player to grab clothes and shove them back into the dresser. If the player can't find their clothes, they can activate a cleaner bot who will automatically find and return them, though the cleaner bot is slow and will take a little more time.

Fast RigidBody objects phase through walls and floors

Lots of punching stuff in this game which sends objects flying at high speeds. This causes RigidBody objects with small collision boundaries phasing through walls and floors.

I think it is solvable by increasing the update rate of the physics check in the project settings, but exercise caution when trying this out. It's also possible to have invisible areas or out-of-bound checks to just move the object back into place.

Possibly related: https://github.com/godotengine/godot/issues/16505
Workaround: https://github.com/godotengine/godot/issues/9071#issuecomment-529217698
(links surrounded in codeblock to prevent auto-linking)

Implement swimming

A game mechanic where if the player is in the water, moving the hand fast (high power) will paddle the player. To move forward for example, the player must slowly move the hand forward (low power), then quickly move the hand backwards (high power) so that it kind of drags and paddles the player forward.

Power in this case is the velocity of the hand, which should already be recorded in player.gd.

Design and create the first level: "01-alley"

The first proper level for The Fat Hand is for Fat Dino to take the elevator down from his suite and walk down an alley to his company's office building. This level is not timed. It's a short walk down an alleyway, passing through some shops that are on the ground floor of some high-rise buildings.

On the way to work, there's a two-lane main road that the player needs to cross to get to the other side of another alleyway; however, stepping on the road immediately summons a car that will run them over. The player needs to solve this puzzle by either:

• stacking some boxes and climbing onto the fire escape of a nearby building, then jump across
• punch a heavy object onto the road, and let the car crash into it
• tease the car out and then move on safely but this must be hard to accomplish
• the player can look right, left and right again and it will stop the cars from coming because it's "safe to cross"

Before entering the company office lobby, the Fat Dino will have a thought popup saying that he wants coffee or donut, so the player has to go get one from a nearby shop or the lobby doors won't open. It's also possible for Fat Dino to bring the coffee/donut back to his suite, and it will persist. To prevent hoarding too many of them, after the 3rd coffee or donut, the Fat Dino will just consume it (eat the entire thing, cup included) upon entering the suite and die of explosive diarrhea.

Setup automated tests and CI

using WAT plugin and github actions

Add controller support

There is a slight change in the Input API for Godot 3.4 (which is at the time of writing in RC stage but not in stable release) which allows for a more cohesive control of both keyboard and controller under the same method, but since 3.3 is the current version being used, it should be implemented the way it is in 3.3 for now.

Design and create the second level: "02-office"

The Fabbrica office building combines the current 01-toilet and 02-kitchen levels together. It has a space with office cubicles and humans walking around, a pantry/kitchen, social hub lounge, boss' room, conference room, and a single toilet. Use the existing toilet level to gauge how big the office should be - that distance is from Fat Dino's desk to the toilet.

A few events happen in the office, so they should be treated as different levels in the level select, but they all load this same scene at different checkpoints for the following events:

• Level 2: Toilet Rush
• Level 3: Pizza Prep
• Cutscene: Reanimator
• Level 4: Package Inspection (before taking elevator down to building basement warehouse)
• Level 5: Explosion Escape (before jumping out the boss' office window)

Implement multiplayer

Multiplayer should work like A Hat in Time, where players who enter the same numeric ID will be in the same lobby. Connection is P2P. For physics objects, the player who wakes the RigidBody will be the "temporary physics owner" (TPO) and is responsible for sending updates in the object's transform to other players. The transform is sent in intervals, and is linear interpolated. This means the object in other player's machines are moved in the KinematicBody state; only the TPO is simulating the RigidBody. Once the object comes to a stop (back to sleeping), a check is done to make sure the position of the object for all players is synchornized with the TPO's, and only then the ownership is revoked.

As for starting the game or selecting a level, each player can do so on their own. They will automatically see each other in the level if the network ID is the same. Entering a level in-progress (level that has at least one existing player) will sync the positions of all physics objects in the scene.

Complete README.md with attribution of all assets used

All of the assets currently used are CC0 which does not require attribution, but this is not how we do things here. README.md should contain the author, URL of where to obtain the asset, and the filename/filepath of the asset used in this project.

Redesign main menu scene

For this issue, the only things required are the room layout. The individual features such as multiplayer should be implemented separately, as this is just for the design of the main menu scene. Keeping the textless requirement, the main menu should contain rooms/physical controls with the following features in mind:

Main Room

• Play Button
  Button on the ground which continues the game at the currently selected level, default to latest.
• Level Select Album
  When the player walks up to this album, the camera zooms into the album and the player can use the hand to flip the pages or pin a photo to select the level, which will then be displayed on the projector.
• Save Select
  A floppy drive spawner to create new saves, place into reader to select save, and hit button to load save.
• Exit
  Punch open a door and tumble down the fire emergency stairs to quit (this door is locked in the web build).

Options Room

• Sound/Recording/Radio Room
  There needs to be a radio or speaker here that has visible sound waves to show the intensity of the volume.
  • Music Volume Slider
  • SFX Volume Slider
• Graphics TV Room
  • Fullscreen Toggler
    A lever switch, the TV will show a window or fullscreen to reflect the current state.
  • Quality Adjustor
    There's a lamp here that shines on an object to show the shadow quality.
• Key Bindings Room
  Allows changing of certain key bindings.

Changing Room

This is where the player can customize clothes and accessories on their character.

Multiplayer Kitchen Lobby Room

• Online Mode Toggler
  Lever switch connected to an internet cable and router which switches on or off.
• Network ID Selector Machine
  A large combination spinner with a lever that auto-sets to any existing lobby with low ping.
• Max Player Setting
  Adjusts the maximum amount of players to sync at any given scene (any higher will simply be hidden from view).

Mods Menu

When player steps into the balcony, they are greeted with a purple swirl of clouds and stars, like a galaxy. Control is taken away from the player, and shifted onto the presented UI to select or remove mods. Upon exiting the UI, control is returned to the player character.

Implement vertical rock climbing

A game mechanic where on certain walls, the player's camera will change and look at the wall in front of them. The hand controls will also change to vertical instead of horizontal. The player can then move the hand and grab ledges/rocks, then jerk quickly to pull themselves up (similar to Getting Over It by Bennett Foddy).

Hand positioning is twisted when facing horizontal axis

When the player is facing forward or backward, the hand is pointing correctly without being twisted in a weird way. If you try moving left or right, and then control the hand, it will start to roll and twist in a way where it's not as easy to punch things. Although the hand collision is not tied to the hand bone, it doesn't look and feel right.

In addition, perhaps there should be an IK to rotate the spine so that it looks more natural rather than letting the arm just going round and round 360 without any body movement. This could be a separate issue as an enhancement.

Implement grabbing

Gameplay feature where the player can left-click to grab objects nearest to the hand. It should play a sound and have some visual indication that a grab has happened. The player should be able to swing the hand and release the grab to throw objects.

Improve grab-throw

Currently, grabbable objects are switched to RigidBody.MODE_CHARACTER whenever grabbed in order to attach the object to the hand, but this interferes with the normal RigidBody physics of that object. This is alright, but the implementation for the throw() part of the code applies an artificial force to the RigidBody upon release (upon switching back to RigidBody mode), rather than actually letting the RigidBody gain its velocity normally. This causes some throws to look weird and have an unnatural trajectory.

The solution should be to never change the RigidBody mode of the grabbed object, and instead change its transform.origin via _integrate_forces() to modify its position in the PhysicsState. Another possible solution would be to simply perform better calculations on the hand trajectory and factor that into the artificial application of velocity. I prefer the former.

Fix controller's disparity of control

For the controller, it makes perfect sense that the analog stick is moved up, the arm moves forward, and when the analog stick is released, the arm should stay there. Now that the analog stick has been released, it returns to its center. When the analog stick is then moved to the right, the hand maintains its frontal position, so the hand appears 45 degrees to the right, yet the analog stick is 90 degrees to the right, creating this disparity of control.

Retopologize and recolor player character

Currently the fat dino player character is green and reminiscent of many characters such as Yooka from Yooka-Laylee, Yoshi from Mario and even Rex from Toy Story. It also has the sassyness of Gex through the half-opened eyes, which wasn't intended but that's kind of the idea that was created for this character. Also, fat dino doesn't have a name. It would be good to have its own name and color scheme, maybe a suit and tie to go with it to give it more character.

The model was topologized using ReMesh in Blender from the sculpt; this was done in a rush and the topology is unintuitive although deformation is pretty fine. Still, it should be improved. Poly count can be reduced much further.

Implement jumping

Simple gameplay feature to open up more interaction and platforming possibilities.

Reorganize file structure

Scenes are currently scattered across various folders unlike the script folder which consolidate all .gd files in one place. It would be more organized if it followed the following structure:

/models
  /characters
  /props
/scenes
  /characters
  /props
  /levels
  /ui
/sounds
  /characters
  /ui

... and so on

The models folder should contain only the .glb model files and corresponding materials. Basically, each top-level folder should contain only files of a specific type, and only from thereon should it be separated by function or category.