Cave Destruction Simulator
REPOSITORY AND DEMO
This project will be used to do some additional work on my Master thesis.
In my master thesis I am creating a simulation for real-time 3D cave destruction calculation using Voronoi's diagram. User starts in an initial cave room. There the user can start mining in any direction he/she can reach. With each "hit" corresponding pieces are calculated and dropped out as rubble from the wall leaving a hole.
During the project a way for the user to interact with the simulator world is added (character). Some visual cues are created to visualize the process of mining/destroying the cave.
The plan is to:
- Research different FPS controllers in Unity
- Implement most suitable one for the simulator
- Add some basic UI (crosshair, etc)
- Create some visual cues to show the user what is currently happening (pickaxe, simplistic arms, swing animation)
Fine tuning the FPS controller, so that it would feel good will probably become the biggest issue along the way.
End result will be a cave generated by Voronoi's diagram. User's character is placed in the cave. User can move around and mine the walls of the cave. In real-time new smaller Voronoi cells are created and used to calculate and create the pieces that should fall from the wall.
Milestone 1 (02.03)
- Research about FPS controller implementation in Unity
- Create a scene where to test different first-person character controls
Result: There are two main kinds of FPS controllers that people make. One is based on CharacterController and the other is based on RigidBody. Camera controls are implemented similarly, since there is no physics and movement only rotation.
Camera is added as a child to the "Player" object and moved up where the head is supposed to be. For looking up and down the camera is rotated on the X axis and is clamped between 90 and -90 degrees. For left and right rotation the "Player" is rotated along the Y axis.
Movement is handled differently. For RigidBody controller Movement vector is calculated and the transform is translated with this vector. RigidBody is there only for the gravitational effect, and rotation along the X and Z axis are locked so that it would not topple over. For jumping upward velocity is set and the gravity takes care of the rest.
With CharacterControllel forward and sideways speed vectors are calculated and then given to method SimpleMove. SimpleMove differs from normal Move by the fact that, it ignores the y component of the vectors and it applies gravity to the movement. To make it jump, Move method is used to move up and SimpleMove is blocked off. During jump the entire physics needs to be calculated by hand. If the SimpleMove is not blocked of, you get a bouncing ball.
A simple scene was created to test the controllers on. It has movement up, some rugged parts and jumping parts and a fall off.
Milestone 2 (16.03)
- Add more behavior to the FPS controllers
- Test which controller is better with the added behaviors
- Improve FPS test scene to test different behaviors(jumping, crouching, etc)
Result: Both controllers types were made into state machines and both got a new state, crouching. Crouching on both controllers works very well and has no issues. To make the character crouch collider height was halved and the camera was moved lower. Currently model is not changed.
Additionally a god mode was added. God mode is a special state where no collisions work and gravity does not apply. Character can move through walls and floors, and also can fly around. This is useful when testing the cave simulator later, when the controller placed in the simulator.
Biggest problem came with jumping. While jumping in empty space, it works well and has no issues. Issues come when trying to jump into walls. For rigidbody the wall collision initially didn't work at all, so i had to change the way i move around. Instead of using translate on transform i use velocity value on the rigidbody. This solved the issue of walking into walls, but jumping into walls is still broken. When rigidbody jumps into wall it gets stuck there. Wont slide down against the wall. Similarly for character controller. Character controller wont jump properly when colliding with wall, instead the jumps are very shallow and end very fast.
Both controllers have their issues. Character controller is easier to make into state machine and for rigidbody the state machine is smaller since horizontal movement can be separated from the state machine.
Milestone 3 (30.03)
- Try to fix the jumping on the controllers
- Some initial "tool" to use for mining
Results: The issues with the jumping comes from the fact that RigidBody and Character controller implementation cannot handle the collision and weird positions and angles. I was not able to fix my jumping with the rigidbody fully. Now when i walk then jump it works and wont get stuck in wall, but when walking against the wall and then trying to jump there is no jump. While in air the code is doing a bodycast to the front to see if it will collide or not. If yes then it stops forward movement. But the same logic wont work when walking and then trying to jump.
With character controller the issue was with the slope angle parameter. This parameter determine on how steep of a floor you can walk on. While walking it is set to 45 and while jumping it is 90 to fix the problem. SO what was happening is that when walking forward and jumping, it detected a collision and since the slope was not enough it slid down from it. But changing the slope angle to 90 allow it to keep on jumping.
If some special movement or really good controller for character is needed, then according to people who have been using Unity proffesionaly the best way is to create your own controller from scratch using the Unity physics API. Blog about creating custom controller For the model a simple mining laser was made in blender and added a laser beam when fired.
Milestone 4 (13.04)
- Clean the code from the rigidbody controller(code cleanup)
- Try to tweak the character controller to get a better feeling
- Make mining laser able to mine
All the states and controller part that worked with rigidbody is removed as it is not needed any more. Mouse speed and movement speed adjusted to feel bit better.
Imported character to the cave system and made the laser able to mine the rocks. Added in the FPS gun camera based on this answer FPS gun clipping solution.
Milestone 5 (27.04)
- Add in basic menu screen and in-game menu for user convenience
- Research about how to make a lighting for dynamically changing dungeon
A basic menu with simple buttons were added. Start game button will always generate a new dungeon, exit game will close the simulation. In game, continue button can be used to unpause.
For lighting a flashlight was created, some testing with different skyboxes was made to get more atmospheric look, but no good result was gotten.
Milestone 6 (11.05)
- Test different skyboxes to find the best suiting for the cave
- Try to implement laser system that requires few moments to initiate the mining process
No good skybox for the cave was found. Skyboxes were either too dark or light. So in the end the default skybox without directional lighting was taken, since it gives the most decent results.
Lazer won't mine instantly, instead there is a visual indicator on the HUD that will let user know how far the mining is. If the indicator is full then mining happens. Additional modifications were made, to remove the lag when mining happens calculations were moved to separate thread and coroutine. Controls window was added to the menu, so that the player can look up the keys whenever they wish. Profiler was used to remove some of the performance hot spots, small performance boost was gained.