How should organization and placement be for making a well-functional game?
Sorry if this is a question that's not for this site! Remove it if so.
I have had a question in my mind of how "Popular" scripters have their game laid out. Is it actually Okay to have multiple scripts in your Workspace or other places for a game and not have a lag problem? For example, large games with heavy coding such as Apocalypse Rising or maybes games made by OnlineAdventure or Rukiryo, their games, I would imagine, have many scripts doing many things? Is their a way to make this at a lower extent of scripts doing just one thing and in many cases, one script only being 10 lines to do a simple function? I don't know if I'm wording this right but I'm a little confused on this matter. If more information is needed, please just comment!
I'd love a well detailed and informative answer which could have other sources to view!
1 answer
Short Answer: Divide your code into as many (or as few) scripts as you want; it won't affect lag (lag will increase the more you have your scripts do, regardless of how many scripts you use to achieve your goals). Let organization/maintainability trump efficiency/lag considerations.
My understanding is that the quantity of scripts does not have a significant impact on lag, but rather what those scripts are doing.
For instance, a single script that contains 1000 coroutines each executing 1 instruction per second will lag about the same amount as 1000 scripts each executing 1 instruction per second (since each script starts on its own coroutine). (I wouldn't be surprised if the 1000 scripts lag Roblox in other ways, since it'd have to store and transmit 1000 sets of script properties (and possibly content as well?) to clients, unless the scripts are in the ServerScriptService, in which case the clients never receive a copy. Even then, I doubt it'd be a significant drain on resources.)
In general, making your code maintainable is much more important than making it efficient. Code that can be easily changed can often be easily improved (if you need to improve its efficiency), or if you want to change your game, maintainable code can be easily modified.
I'm not an expert on what maintainable code looks like, and by briefly reading some programmers.stackexchange threads, I'd say it's not an easy thing to specify. Nonetheless, I highly recommend looking into the topic of "code maintainability". One post recommended SOLID and DRY. DRY ("Don't Repeat Yourself"), for instance, suggests that you shouldn't have the same information in multiple places. I believe this refers to data (ex don't have multiple variables that all contain the same value) and code (use loops, functions, and/or (classes)[http://lua-users.org/wiki/SimpleLuaClasses]. Also see a definition of ("good code")[http://programmers.stackexchange.com/a/17455]
Note: I'm most familiar with Object Oriented Programming, which has a huge set of recommendations on how to program "properly". You may wish to investigate alternatives here.
Back to the distribution of scripts in your place.
You have the decision between having a bunch of small scripts that do distinct things and putting all of those things in the same script. I'd say that if two components need to communicate with each other (ie use each other's variables), they should probably be in the same script (exception is LocalScripts communicating with server Scripts, of course). However, using BindableFunctions and/or the global table, you could separate them if you felt it would improve your organization.
If two separate scripts end up needing the same classes/functions, put that code into a ModuleScript so that the function is defined once throughout your entire place.
I recommend against having multiple scripts that do the same thing, as this violates the DRY principle. In practice, if you wanted to modify the functionality, instead of making the change once, you'd have to do it multiple times. For instance, imagine a series of "lava" bricks that kill the player on contact. A simple approach would be to put a script into each lava brick and the script would say "script.Parent.Touched:connect(--[[function to kill the player here]])". If a bug was found, or the desired behaviour needed to change (ex hurt the player instead of kill, or teleport instead of kill), the change would have to be made to numerous instances of the same script. A "master" script that held a list of the lava bricks would be superior in this respect, as you'd only have to change a single function. (An interesting note is that the "master" script will require more processing power - at least to start up - since it'll have to create and manage its list of lava bricks. Nonetheless, I'd say it's always worth following the DRY principle over saving a small bit of processing.) That said, a 3rd option is to store the lava script in ServerStorage (so it won't run the script) and to have a second script that distributes copies of the lava script to the lava bricks.
So long as it's organized so that you can figure out how to change it if you come back to it after months of inactivity, it's probably a reasonable solution.