Open hertz30 opened 5 months ago
An idea for Volumetric fog found by Bridget: https://github.com/sinnwrig/URP-Fog-Volumes
Custom input controls were mapped for the player, including left and right inputs to in the future move the player right and left. The wheel crank is being simulated by scrolling the mouse wheel.
The code to determine the amount of scrolling done over time is not calculating scrolls per second properly.
The scroll will take the inputs per second to determine how much up or down to boost the player. The left and right will also make the player bank side to side.
The tunnel segments will be moved in the negative Z direction and deleted once they are out of view of the player
New segments will be instantiated at the positive Z end of the tunnel every time the last segment moves out of range
Current plan is to track the movement with a variable based on the velocity and instantiate tunnels once the last one is 5 units away (the prefabs should be 5 units wide)
Created script to move and delete tunnel,
Added nebula space clouds/fog to obscure segment instantiation,
Created basic tunnel segment prefab (William is working on creating tunnel segment variants)
Created tunnel segment instantiation script but segments are not being instantiated properly, plan to troubleshoot on Wednesday
Custom animations were developed for the player to exaggerate movement. A blend tree was created so the player animation will flow smoothly based on motion.
The player can bounce off walls and start sliding uncontrollably.
I will try and use a move function instead of a force apply function to move the ship to prevent bouncing.
Beginning UI code and score tracking mechanics. Score will be accumulated based on "distance." Began process of developing game manager script.
Unity is refusing to work on my hope computer setup again.
Will implement scaling obstacle speed as a variable in game manager, making it easily usable in the UI scripting. I will find time to use RH2055 in lieu of my home setup.
The player movement was swapped to a move position system instead of a physics and forces system. However, this caused the player to be able to slide between corners of colliders. Player movement was clamped to stop the player from sliding between the corner edges of the collider.
Photos of the aesthetics for the game have been uploaded in TEAMS for the Toy design team to provide style references for their prototype.
The parts have been ordered by the toy design team and now we must do research on how to interface the mechanical sensors into a language unity can read.
Added new obstacle variants: 2 asteroids (spherical and irregular), asteroid field, spaceship
Added generation rotation variety RNG
High speed interactions are revealing issues
Not sure what caused problem 1 but seems to be resolved
Added logic so obstacles don't spawn more obstacles when deleted
Changed instantiation logic to dynamically calculate the offset distance based on velocity instead of being set to a static value of 5
The tunnel movement system has ben moved from each individual object to an overarching manager. The tunnel manager now tracks the last tunnel and the arrays that store the prefabs. To create multi planet functionality a 2D array of game objects has been created to store all the asset pallets of each planet separately. The first dimension of the array tracks the arrays of each planet, the second tracks the prefabs in each planet. The same has been done for obstacles.
Each planets array can be edited in the Inspector.
Unity does not currently support viewing of 2D arrays in the inspector. Arrays must be instantiated and loaded into the 2D array manually in script.
With a game manager and tunnel manager we can now create transition effects once a certain score threshold is met. We could create an index 0 of prefabs in the tunnel manager of invisible tunnels to create the illusion of the player warping in space. Then some particle effects and lights to obscure the players view as the new planet loads in, then swap array indexes and have the new planet spawn in.
Completed basic score management and UI, as well as a framework for game manager (as mentioned above). Work has begun on the player's lose conditions, namely collision with obstacles.
Obstacle collision is bugged beyond belief. The player ship flies straight through solid collision objects, and the detection of collisions is inconsistent at best, regardless of collision detection type (discrete vs. continuous, rigidbody vs. no rigidbody). Issues exacerbated by higher speeds.
Will continue to debug and experiment with collision detection. I suspect the issues have something to do with the interaction between objects using non-physics-based motion.
Added obstacles for planet 3, updated obstacles generation to new version (was rolled back in a previous merge)
Scheduled meeting with toy design team for Friday May 3rd
Starting work on game music and sound
A script was uploaded to the Arduino, reading the input values of pedals and a proximity sensor. A breadboard was used to distribute 5V power to all components and have a ground back to the board. The pedals are registered to Analog ports A5 and A4. The proximity sensor is routed to the digital input returning 1 if nothing is detected and 0 if there is a signal. The LED on the board is set to flash at regular intervals to read status of the board.
We discussed how we would potentially track direction of movement, and the agreed upon idea is to have a second proximity sensor and track the order of inputs being registered to determine spin direction. We need to look at the process of translating from the board into unity inputs. Once the two applications talk, the game will be fully interfaced with our controller.
Work continues on debugging the health system and object collisions. Some insights have been gained about the nature of the bug, but it remains unsolved.
Obstacle collision still in an unacceptable state. I am running out of ideas for how to fix it.
Will continue to debug and experiment with collision detection regardless. This log doubles as a request for help, should an opportunity to assist come up.
Progress
Work continues on debugging the health system and object collisions. Some insights have been gained about the nature of the bug, but it remains unsolved.
Setbacks
Obstacle collision still in an unacceptable state. I am running out of ideas for how to fix it.
Planning
Will continue to debug and experiment with collision detection regardless. This log doubles as a request for help, should an opportunity to assist come up.
The rigidbody froze the ship in the z axis, but the player controller moved the triggers to z=0 (even though this wasn't shown in the inspector) so it looked like the ship was hitting objects before they got to the ship. When objects would hit z=0, even though it looked like the ship was at z = -34, it would hit the ships triggers at z=0.
Composed music. Added start scene with a button to start game scene (starts the scene in build settings' scene position 1),
Added FMOD integration and music. Changed timescale to 0 on death and reset upon restarting scene. Updated game death UI and added hearts at the bottom of the game scene plus sound effects to indicate health.
Met with toy design team on 4/10
Goal: Prototype greybox prototype by 4/17
Ryan will be developing controls Haiying will be developing obstacle Generation: Obstacles move, character stays in place