1 min
The cameras were too hard coded before, as all the variables were set in the camera header and were magic numbers. This had to be changed in order the cameras to be more usable. The data that was shared between all the cameras were taken out of the camera class and stored in a Json file. This enabled the user to change the configurations in the Json without having to go into the code base. It was helped with Matt’s tool which had a nice GUI, in which the user could adjust values without having to see the Json file (example shown below).
"FOLLOW": {
"fov": 60,
"rotation_lerp": 0.1,
"position_lerp": 0.50,
"look_at_position": [ 0.0, 0.0, 1.0 ],
"target_position": [ 0.0, 0.0, 0.0 ],
"camera_offset": [ 0.0, 2.0, 5.0 ],
"look_at_offset": [ 0.0, 2.0, 0.0 ]
},
Any data that shared across multiple camera instances such as how fast the orbit cam span or what positions the cinematic camera went to were put into the CameraData struct. This was called by the service locator and it stored all the data shared across multiple cameras. This meant now, every instantiation of camera didn’t hold a vector of its possible cinematic positions which never changed so multiple vectors were not created unnecessarily.
Subscribe to this blog via RSS.
Low level programming dev diary 28
Text based adventure dev diary 6
Level design developer diary 3
Game engine programming dev diary 14
Audio-visual production dev diary 7
Audio-Visual Production: Particle System Mesh Spawning Issues
Posted on 20 Feb 2020Low level programming dev diary (28) Text based adventure dev diary (6) Level design developer diary (3) Post mortem (4) Ex-machina dev diary (11) Game engine programming dev diary (14) Network game dev diary (11) Audio-visual production dev diary (7)