After managing to deliver on my project management priorities, iteration ) of TGM47 is complete.
Iteration #0 is a series of prefabs that address basic interactions and movement.
The main purpose of this iteration was to create prefabs that would make future iterations a bit more efficient as I can draw and iterate from these general principles to create environment/level specific instances.
Of course, with the explicit approach to development being organic there have been more than a few bits of fiddling and going off on tangents that are perhaps fundamentally opposed to some of the original concepts – specifically eleveators!
Iteration #0 – Features
- Movement that is inertia based
- Boost (accelerate on Y) – jump
- Dash (accelerate on Z)
- Power consumption
- Raycasting to recognise and retrieve information from other GameObjects
- RigidBody Interactions
- Transform based audio for all movement elements
- Display and update power consumption
- Methods to allow messages from other objects to be displayed linked from CamSpace to WorldSpace
- A button controlled door opened/closed using the Player Raycast to distinguish between and activate individual doors
- A door controlled via a collision trigger
- Parameters include options for how many objects (and of which type) are required to activate the door
- Based on the door prefab this elevator is activated in the same way as the Door(PP)() but has other customisable options:
- A button that can call the elevator to this floor
- Elevator ‘knows’ which floor it is on and responds accordingly – going up/down/already on this floor
Some conclusions and thoughts
Why do I need elevators anyway???? Seeing as how the main player is the TGM camera complete with a boost (fly) function/hover it seems a bit unnecessary.
Having said that it was more the challenge of trying to develop a universal/catch all prefab that could solve what is (at least for me) a quite complicated logical problem. In this example there are only 2 floors so the logic isn’t particularly head scratching but (for the sake of it), I’ll try and develop a more universal script that I’ll then put on the Unity store…..
One of the fundamental lessons learned in this iteration is the need to have some idea of how the logic will work in a given scenario and what objects need access to what data. Rule of thumb (based on research) seems to be to allow parent objects to control and access data in children and try and push scene/level wide data into an overall manager that injects data into the objects in the scene as requires.
Thats an ongoing learning process at the mo but as scenes become more complex this approach will help keep the logic and the code clean, accessible, easy to debug and easy to read.
A future iteration of this needs to include some experimentation with the player itself. The next iteration is focussed on developing a way to ‘shoot’ video textures onto world object, although after having started to experiment with animations in Unity and Blender I want to develop a TPS with Cinemachine option for this project.
(GIFs created with https://ezgif.com/video-to-gif)