The Problem
At RDC 2017, I recall that we were asked to stop forking Roblox’s Camera code during one of the presentations. The reason was something along the lines of: “It prevents new features and fixes from being introduced, and theres no source control system in place to know when these changes happen if you fork the code.”
I’ve looked into some of the recent changes, and I’ve found that there are a lot of bad practices in the CameraScript:
- Spaghetti code ｅｖｅｒｙｗｈｅｒｅ.
- Input handling is hard-coded directly into the RootCamera.
- The CameraScript requires very specific modules instead of having some generic module package system.
- Not possible to externally communicate with the active RootCamera instance, or anything else really.
Thus, I think they should create a new system, which splits up the camera into an extendable framework.
The framework would have three phases:
Pre-Update
The Pre-Update phase provides an entry point to a folder of ModuleScripts that each provides a feed of input into the Camera’s panning.
This could be divided up into several individual input handlers:
- Keyboard
- Mouse
- Touch
- Gamepad
- VR
Update
The Update phase runs the update function of the active camera behavior module, and that module applies the base camera transformation through the RootCamera using the provided input feed.
Post-Update
The Post-Update phase is used to apply some post-processing to the camera after it applies the base transformation.
This can include stuff like:
- Transforming the camera when in shift-lock mode.
- Auto-rotating the camera while in a vehicle.
- Handling camera occlusion (PopperCam, Invisicam).
- Updating the transparency of the character.
Rationale for this proposal
With a system like this, Roblox could just introduce new module packages whenever they want to introduce new input behaviors, and as long as they established a strong foundation framework, they wouldn’t need to worry so much about people forking their code. Developers could simply write extensions upon the framework instead of having to fork and edit the base code itself. The in-game chat system does a pretty good job at providing support for custom behaviors, and I think the Camera code could do it just as nicely with a proper redesign.
Ideally there would be access points where developers could register their own handlers in separate LocalScripts. These access points could also provide access to other behavior handlers, so that developers could adjust settings pertaining to these behaviors.
Some examples could include:
- Adjusting the offset applied by the Shift Lock.
- Tweaking the behavior of the vehicle camera, so that it can be disabled entirely, or certain aspects can be tuned like the rotation speed and the idle time it takes for it to start rotating on its own.
- Changing the mode of the Invisicam, as well as the transparency it applies, the speed that things fade out, etc.
In Conclusion
This is a large undertaking, of course, but Roblox should really consider doing something like this if they want us to stop forking the camera code. I think it would really pay off in the long run.
(cc @Rototally, @darthskrill, @AllYourBlox, @0xBAADF00D)
