Remotes:
A folder in replicatedstorage named Remotes
Occasionally with subfolders
Modules:
A folder in either server or replicatedstorage named Modules
I also never use the default character spawning system as my own system gives me more control over how characters spawn, what goes into their playergui when they spawn, etc.
When it comes down it it, the Workspace should be organised based on what you need particular things for. For example, projectiles should have a Folder called Projectiles, that the server can parent projectiles to (this would include canons, bullets, arrows, lasers, etc). You would have a folder also for any map elements that don’t need interaction, or health, things like that. I usually call this StaticModels or Map it’s entirely up to personal preference. Folder for other more important things, like perhaps item drops should also have their own folder. I think it’s really important to keep the workspace as minimal as possible on the upper hierarchy, otherwise you’re going to have a huge list of miscellaneous items that you don’t need to see.
Similarly, ReplicatedStorage and ServerStorage should follow this rule. You don’t want to put everything directly as a child and hope for the best. If you have multiple assets, then why not create a folder called Assets that would parent sub-folders like Models, Sounds and Items to help better organise. This will also help when it comes to accessing these via Scripts and LocalScripts, because you know immediately where things are.
ServerScriptService might be a little different, but it essentially follows the same rules. Say you have a Script called ChatService then create a script inside of ServerScriptService, name it, and if you are using ModuleScript’s, put them as a child of it.
Overall, I think it’s basically providing yourself with the most sensible layout, where things are properly named, properly stored and you know where to find things easily.
Lua is a whole different story. There’s no right or wrong answer, as far as writing code goes. People have various different preferences on how to write, name and structure code. This isn’t to say there are recommended practices though, I personally think that when writing code you should always know what something does. When you’re reading it, it should make sense. If you have one function to turn on a light, then name it appropriately.
local function TurnOnLight()
-- Light turns on
end
And as I said earlier, you should always keep up-to-date with ROBLOX Lua/API so you’re not doing things like
Part:remove()to permenantly get rid of something.
ReplicatedStorage
I put all of my RemoteEvents/RemoteFunctions in organized folders within a folder called “Network”.
I also use ReplicatedStorage for any assets I need to store for the client. (mostly ModuleScripts)
ServerScriptService
I have one script in ServerScriptService – everything uses ModuleScripts. I try to organize things neatly, by category. As a rule of thumb (and this is the same for any of my organization strategies), I try not to have more than 10 objects in a single folder.
ServerStorage
I have few uses for ServerStorage, albeit the uses I have make ServerStorage tremendously useful. I use the same organization structure here as aforementioned.
It’s almost always good practice to keep client-only instances under the camera, regardless of whether filtering is being used. It maintains compatibility between FE and non-FE, even if only for debugging purposes.
Apart from that, here’s my two cents:
There’s no reason to make your FE game compatible with filtering disabled… 
Sometimes it’s the best practice though, proper client-server communication and all that jazz. When I made the train system for Paper Mario RP, it was FE-compatible without any modifications because that was the right way to do it, I didn’t even try nor realize I was making it FE-compatible.
My best practices:
cmdutl
cmdutl
cmdutl
The tool is not prone to large rounding errors like the studio tools, it is extremely precise because you can put in your increments of adjustment, and the best feature is that it will accept equations as inputs. My favorite part of the tool is that I can make angled pieces line up by putting in deg(atan2(a,b)) into the edge rotate field, and sqrt(a^2+b^2)-0.2 in the length field. cmdutl is the reason why my most recent locomotive works so well in the old solver despite its mechanical complexity, and the same for PSGSolver, which doesn’t allow slop in joints like the old solver does.
[quote] I’ve been a vivid ‘console’ gamer for a long time (years now) so I’m use to a lot of controllers and controller layouts. I thought I’d share some guidelines after what I’ve seen and what I know. I’ve seen a lot of games fail because the controller layout was stupid as heck. Sure you can add controller support but if you make ridiculous bindings…you aren’t going to be popular.
[center]
External Media
[/center]
Don’t ever;
[ol]
[li]Use DPAD as steering or movement controls (If you do this, don’t even bother adding controller support. What is this? PS1) [Please see exception 1][/li]
[li]Use X,Y,B,A as movement/steering [/li]
[li]Use Start, Back, Select controls as main parts of the game (e.g. having the start button fire a bullet. I’ve seen it and you should not do this, please for the love of god)
[li]Use thumbstick presses as a means of pausing (My thumbs hurt, stop) [/li]
[/li]
[left]Just please, never do any of these.[/left]
Acceptable; however, not the best
[ol]
[li]Use Thumbstick 2 (bottom right) as movement/steering (Some people actually prefer this, it’s called ‘Southpawing’)[/li]
[li]Use the ‘A’ button as a means of accelerating a car (seriously, you have triggers. Why?) [/li]
[li]Use Thumbstick 2 as a accelerator (What about camera controls? Camera controls generally use Thumbstick2) [/li]
[li]Use the Left trigger as a means of accelerating/braking (This should be on the right, it’s very common practice) [/li]
[/ol]
Good controller layout practices
[ol]
[li]Using the right trigger (R2) as a means of accelerating/shooting (It’s becoming common practice in a lot of layouts)[/li]
[li]Using the R1 button as a handbrake (Better feel than using X for example, also closer to accelerator)[/li]
[li]Using the L2 button as a brake (More precise braking and/or reversing)[/li]
[li]Using Thumbstick 1 as movement or steering (This is a ‘Northpaw’ layout)[/li]
[li]Using Thumbstick 2 as camera control (This is a ‘Northpaw’ layout)[/li]
[li]Using Start as a means of starting the game or pause it (This should be self explanatory)[/li]
[li]Using A to navigate/select in addition to the DPAD controls (More precise selection)[/li]
[li]Using X, R1 or B to reload a weapon (A lot of people associate ‘X’ with reloading and this is becoming common in new games, X/B is preferred)[/li]
[li]Using B as a melee attack button (it’s close to the edge, shortest travel time of your thumb for quickness)[/li]
[li]Using Y to interact with something (Walk through the door Niko!)[/li]
[li]Reminding players what button does what (e.g. GTA 'Press Y to get in the car. You’ll notice these die down after awhile and there’s not as many or in some cases, at all)[/li]
Generally X,B,Y,A buttons can be used for anything 
[/ol]
Exceptions
[ol]
[li]If your character only moves in four ways or an isometric format, DPAD can be acceptable. Although you should use thumbsticks for better comfort [/li]
[/ol] [/quote]
Some rough practices for good controller support without driving your players crazy because you’ve binded the fire bullet button to select or the thumbstick to pause.
[ Original Thread ]
[quote=“Quenty, post:7, topic:18642, full:true”]
I write testable code, using this guide …[/quote]
Bravo Quenty! I personally would love to see an article authored by Quenty on how to bring testing practices to the ROBLOX environment. I like to test my code as well, but the ROBLOX environment is not ideal for it and I haven’t yet settled on a good strategy to accomplish it.
My best practices include using source control. I believe it to be an indispensable practice. Because the ROBLOX place file format makes it especially difficult to practice, I’ve been petitioning for change. (Please don’t mention ROBLOX’s version history as an implementation of source control - it has almost none of the features of a decent version control system.) In order to practice source control with a ROBLOX place file, I save it in the old rbxlx xml file format. Before committing any changes, I examine the differences made to the file to ensure I am not committing any changes that were not deliberate. This has saved my bacon numerous times. I also use descriptive comments when committing code to make finding past revisions easier. The shifting sands of the file format keep me on my toes and make this practice a challenge, but it is certainly worth it. It is particularly important when working in teams.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
