So I have a function that tracks the controllers in VR and I don’t know if it should be in a modular script or a function as it’s just 3 lines of code(yes i have read To what extent is modular scripting “too much”).
AnaglyphPositionalInput.TrackVRCFrameRelativeToCFrame = function(VRDevice, WorldCFrame)
local VRDeviceRealCFrame = VRService:GetUserCFrame(VRDevice)
local VRDeviceWorldCFrame = WorldCFrame:ToWorldSpace(VRDeviceRealCFrame)
return VRDeviceWorldCFrame
end
I’m reading this as you have a module, AnaglyphPositionalInput
, which has several utility functions for just that. Realistically, what you’re doing isn’t absurd. In my mind, this is actually a good practice. How many people are working on this project?
In reality, you do want to aim for a very modular structure with just about anything. Modular designs are a trend these days, mostly in the physical aspect, such as:
- Mac Pro Internals
- iPhone Internals
- Car Assembly(such as Tesla)
But that doesn’t mean you can’t do the same with your code, in fact it is something you really really would like to have. If you plan on expanding your systems further in the future, modular systems offer a great opportunity of expandability.
I had several reasons in mind when I created the post you linked above, mainly because
- I was working on a system that you can just easily take out a “module” of code (not necessarily module scripts) and swap it for something else without breaking anything. Or easily add another module without having to re-implement anything.
- It was so modular to the point it looked ridiculous.
When going for a modular system, I try to make sure that function A is only written once, meaning there’s only one in the entire system. This allows me to make changes easily all in one place.
Looking at your code, there’s nothing really to worry about it. If it makes your code look cleaner and doesn’t give you a hard time, then it’s perfectly fine.
2 Likes
Just me. However, I am thinking about making this a public framework for VR/Physics/Input stuff.
Anything public like this should be very modular to make it both maintainable and easy to interact with for the end-user. I recommend you do the following, though:
-
Use the normalized pattern of function statements as opposed to a function expression.
-
Document functions with any consistent style that gives information of the parameters, what the function returns, and a summary.
For instance, if I were to write that function for use in a distributed module, I would probably write it as so (this is using my subjective, personal style guide; do not take this snippet as a definition of an absolute solution):
local VRService = game:GetService("VRService");
-- Aw yeah, the best module with a single helper function.
-- TODO: Actually write the rest of the module.
local VRify = {};
--[[
Retrieves the given CFrame, `cFrame` relative to the supplied VR Device,
`vrDeviceKind`.
@param {UserCFrame} vrDeviceKind - The kind of VR device to be used.
@param {CFrame} cFrame - The CFrame to transform.
@returns {CFrame}
]]
function VRify.getCFrameRelativeToVrDevice(vrDeviceKind, cFrame)
local vrDeviceCFrame = VRService:GetUserCFrame(vrDeviceKind);
local relativeCFrame = cFrame:ToWorldSpace(vrDeviceCFrame);
return relativeCFrame;
end
return VRify;
If you have any other questions or would like the rationale behind some decisions, feel free to ask!
1 Like