How do scripters organise their scripts?

Help and Feedback Scripting Support
,
1

Hey there scripters, I’ve come to ask some questions about how you guys keep your code organised and the best ways you would suggest to minimise bugs being caused by future additions/changes. I’m working on a game completely by myself and that’s put me in unfamiliar territory as my strong suit is building and I’m determined to keep the game a solo project, problem is I’ve never had to write code fully myself so I don’t actually know what techniques people use to keep things organised and from causing problems.

I’ve wondered about a few things such as:

  • When I should seperate pieces of code (i.e making a new server/local/module script)
  • Why I should seperate said pieces of code
  • Ways of making these pieces of code not so dependant on each other, as to not bring down my whole game with one bug

I think a big thing that has actually worried me about coming to the coding side of my game is being a player of Deepwoken, who have been having a whole slew of bugs when trying to rework their systems, and I don’t want my potential playerbase however small to suffer because of my inexperience.

Anyway, any techniques and advice are welcomed and will be taken on, thanks in advance!

6 Likes
2

I often comment everything. Not always though, it depends on how well I know the type of script I’m about to write. For example a physics script is getting a comment on every single line to help me code it.

Other than comments, I use spacing between lines, and I often make return, continue and break a 1-liner to signal that the code may not run further.

--Normal code
while true do
   if 1 == 1 then 
      continue
   end
end

--My code
while true do

   if 1 == 1 then continue end

end
2 Likes
3

When I should separate pieces of code:
Try and keep code of a similar purpose together, but balance this against keeping your script length of a manageable size. For example, perhaps you have written some car controller functions and you find they fit together nicely in one car controller module, that’s good. Perhaps you have written a very intricate car physics module, then it probably makes more sense to break your big module down into more manageable modules, e.g. powertrain, suspension, steering and brakes and then manage the data flow from a controller script. Remember you can use folders to logically structure your files. Avoid circular references between modules.

On the same note, when you write a function give it one simple job to do, there is no shame in defining something in a separate function that is initially only called from one other function. This keeps you focused on what is happening in that piece of code without polluting it with additional jobs.

Why:
It is much easier to maintain small, well defined code chunks.

Dependency:
Games programming by its nature often has high levels of dependency, the trick is how you manage this. Small, well managed scripts make this far easier to do.

General advice:
Keep things simple and easy to read. It’s amazing how complex conditional statements can be compacted into short lines of almost unreadable code, this is not going to help anyone.

If your statements are becoming deeply nested, have a re-think about your strategy because it can be very hard to follow the flow through such structures.

Use comments only where they really add value, remember to update comments when you change the code or they will just make things worse in the future. If you use concise, specific functions with good names and well named variables it’s much better than a bunch of outdated comments that repeat the function name.

Events are incredibly useful and you will use them, but they can also make it almost impossible to understand your data flow if many different modules are reacting to the same signals, so think carefully about how you manage them and how you track them.

1 Like
4

we dont

17 Likes
5

You’ll know when you get there. You’ll be writing code that does X, Y, A, Z, then you need to add X, Y, B, Z, then another part does X, Y, C, Z, and you’ll say… “hey, why not make X, Y, and Z their own thing?” For a more concrete example, think about X being “getting the player’s data from a datastore”, “Y” being “getting the player’s money”, “Z” being “setting the player’s money”, and “A”, “B”, and “C” being something that manipulates money (like buying or selling). (For the record, the recommended way to use datastores is not like this, but bear with me.)

The general formula is to take something specific and make it applicable to a wide variety of situations. You’ll know what that something is when you start designing your project. If you’re not sure, then you should take a moment to consider what you want to accomplish in code.

1 Like
6

How do I organize my script instances?

First, you have to understand the best way to place Script instances in general:

  • ServerScriptService: Code that runs on the Server
  • StarterPlayerScripts: Code that runs on the Client (Yes, even UI!)
  • ReplicatedStorage: Modules
  • ServerStorage: Modules only accessible by the server

Having understood this, the next thing is Folders. Lots of them. Oragnize related systems and Scripts that affect the same stuff in the same folder.

image
image210×163 4.92 KB

image
image179×199 4.69 KB

Your other questions

When 2 things are distinct and complex enough (do different things), you should separate them.

If the 2 systems are distinct and complex enough, as I answered in the first question, it will save you time. Consider that if you make 2 complex systems in the same place, there may be unintended consequences when changing something from one to the other.

An example of this is back when I made my game get a drink at 3 am, I originally handled everything in one giant script called DialogScript (over 2,000 lines). It didn’t just control dialogue, but also events, endings, and all the game logic, which is about 30 different endings in total. Any small change risked breaking something else, which quickly became a nightmare to manage.

What would I do differently now? I’d have each “ending” in its own “handler” Script inside a Folder with all the different “endings”, with all the handler scripts calling back common Module functions that would be easy to change globally without breaking anything.

Hopefully this example and my experience can help you identify similar situations you can break up into multiple, smaller Scripts.

5 Likes
7

interesting question. i have a few tips.

  1. try to limit nesting - me personally, im a “NeverNester.” this means just limiting the amount of code you have in if statements, e.g.,
if a and b  then
   c = a*b
   if c and not d or b > a and math.min(x, y, z) == x then
      if nesting and tryingToKeepLinesNotTooLong then
          print("Hello World")
      end
   end
end

VS.

if not (a and b)  then return end
c = a*b
if not (c and not d or b > a and math.min(x, y, z) == x) then return end -- ideally ig you would alter the conditions instead of just adding not to it all
if not (nesting and tryingToKeepLinesNotTooLong) then return end

print("Hello World")

now this wasnt a too great example but imagine being like 5 if statements in and your entire view is constantly shifted.

  1. naming conventions. i already have the most important ones in a list i made some time ago
# Naming Conventions
`Please follow these naming rules for variables that I have established over my years of scripting`

## 1. Services
- Include game instances such as TweenService, ReplicatedStorage, etc., anything parented to game
- The first letter of every distinct word must be capitalized. Ex. `local ServerScriptService = game.ServerScriptService` or you can do `game:GetService("ServerScriptService")` either is fine

## 2. Variables
- Include the generic variables such as references to object, like gui, and any other general variables that are subject to change throughout the script ex. currentSpeed
- First letter should be lowercase but the first letter of all other distinct words must be capitalized ex. `currentSpeed = 0` and `lastPosition`

## 3. Constants
- Include variables that are like settings and usually are static, meaning they will not be changed. Ex. `SENSITIVITY` or `DEBUG_MODE`
- All letter must bu capitalized and words are to be seperated by underscores. Ex. `CURSOR_THRESHOLD`

## 4. No Abbreviations
- Please, please, PLEASE  make an  attempt to limit abbreviations used in variable names (or instance names, or any names at all). Abbreviations can be confusing and it's just so much more readable and clean when you don't use them
- There may be a few (very few) exceptions to this, but use your own discretion to decide if your situation is an exception
- When in doubt, don't use abbreviations
  1. modules and functions. i love module scripts. they are just so useful for organizing code and avoiding redundancy across numerous scripts. they are also great for and creating reusable, customizable code or systems that can simply be copy and pasted across games. however, know when to use modules and when to use functions. functions are equally great, providing similar uses but within a singular script. im not gonna say much more because this is just my preference, but i would say i use module scripts a LOT - like almost every chance i get. it just eliminates repetition and i can use it in all of my other games.

bonus mention: stop misusing waitforchild

thats about all i have to say, honestly, ive gone through so many different styles of scripting, but ive found that the most important thing is consistency. if you pick up one style and stick with it, you can save so much time opposed to wasting it on finding the “best” style (spoiler: there is none). so yeah, its all up to you. but still like its good to follow general practices but other than that, you choose your destiny lol

1 Like
8

how many module scripts would you say is a normal number for a game? i’m having trouble sorting and organizing my own.

9

Finally, someone I can relate to.

1 Like
10

depends on the size and type. for something like a battlegrounds game. i would say maybe at least 20, but i think thats on the lower side (for these games like tsb). and honestly, it REALLY depends on your needs. ill show you an example of how a battleground game’s modules might look like:

ServerStorage modules (for the server)

image
image260×472 20.7 KB

ReplicatedStorage modules (for client and server)

image
image246×442 18.6 KB

As you can see, it really depends on the game - if you have an incredibly complex combat system, youre gonna have far more modules.

its a bit hard to answer this question cuz it really varies (a lot) from game to game. perhaps i might be able to help you - what troubles are you having in organizing your modules? like what are the mechanics that you want to modularize?

1 Like
11

i dont really know, i guess i just think i’m making it hard for myself to add things to my existing code/modules because there are multiple scripts requiring them and whatnot. it’s hard to explain, but i’ll figure it out. thanks!

12

nevernesting makes my code even worse :broken_heart:
(also no offense but the never nesting example looks worse at least imo)

1 Like
13

I feel like this would be a pretty good fit for Development Discussion considering it isn’t really asking for support with a certain piece of code itself and is more of a general discussion on organization technique.

14

Are you using a module loader or manually requiring these?

15

yeah ok that wasnt a great example but it really can be better. ok maybe this is better.

image
image842×437 26.7 KB

this is a part of a script in a project im working on. it would have been like 4 indents if i nested it all in if statements instead of returning

3 Likes
16

Just write the code.
If organization can’t be “compiled” into your code writing without affecting bytecode/logic/performance, then you should not even bother about this “organization :tm:” in the first place.
Integrate the optimization technique if it passes these 3 simple questions:

“Does it affect performance for the worse?”

Y - ditch it.
N - passes this step.

“Can it be seamlessly integrated into my code writing RIGHT NOW?”

Y - passes this step.
N - up to your consideration.

“Does it really bring any reading and/or performance benefit in the long run?”

Y - passes the test.
N - ditch it.

17

there’s infinite ways to structure and organize scripts, everyone has their own style to scripting aswell

some people use folders module scripts instances,

just research ways people organize theirs and find one that suits both you and teams you’ll work with in the future

18

Manually requiring. Require IS the module loader - module loaders are nearly completely useless except for a few use cases.

1 Like
19

I would say find one style that you like and stick with it. Consistency is key - don’t spend time trying to find the perfect organization method. Just follow general practices and take inspiration from people and choose the style you like most.

20

What a great explanation! Thank you!