Organizing your game

Resources Community Resources
#1

Hello!
Many developers are very annoyed by the process of organizing a game. For this reason, they don’t do it and abandon the project. I’ve done it myself.

image
image315×766 30.3 KB

Now I will describe what is used for what, because some things like the advice not to use StarterGui may seem strange.
First, I advise you to put the UI in ReplicatedFirst and nowhere else and clone them on the client for each player.

Memory Leak: When using the StarterGui interface,
roblox copies the UI from StarterGui directly on the server. This leads to the fact that in large projects, the server can receive gigabytes of unnecessary information. The solution is to simply clone the UI on the client. To do this, it is most logical to use ReplicatedFirst or ReplicatedStorage.

dividing Workspace into two large subgroups - GameArt and gameplay. GameArt may contain scripts, however, these scripts should be secondary, if you can say so. Flashing lights, shaking the object. In general, this is about ambient scripting. gamePlay, on the contrary, should contain entirely scratched objects that the player can interact with.

-What is a Utility?
this is an overused feature. In the case of the server, these are validators, read about them. In the case of the client, these are simple functions. Type of formatTime and so on

-the difference between Storage and template library:
the first should store what you need during the game only on the server (in fact, it’s hard to even imagine such a thing, lol), and the second should be a kind of tool box, but only for your game. Keep there what you may need during game editing, but definitely not at the moment after the server is turned on.

-Packages? Why not just libraries and so on?
because I think that Packages is the most correct name in the context of roblox. I divided it into classes, with which everything is clear, managers, with which everything is not so smooth anymore, but I think it’s clear that they work for all objects (ZoneManager, RaceManager, &c.)
as well as libraries. They are needed to store global modules, which, if they are classes, are singletons. For example, ProfileStore is definitely a library, not a class or a manager.

What else are Core and Server/Client Loaders? The kernel performs a light function - calling the loader module. The loader module, in turn, calls all the other modules that the client or server needs. The difference between the ReplicatedStorage client side and StarterPlayerScripts is that you should put those scripts in ReplicatedStorage… Which are more important, so to speak

so, module for auto download and structure you can load here:

folderStructure.rbxm (9.1 KB)

2 Likes
Tips/tutorials on project organization with OOP/module scripts
#2

There is no “good” or “bad” organization, as long as the game is organized into folders in one way or another, it’s fine. Choosing a particular organization mostly depends on the developer’s preferences. You should opt for the one that you (and your teammates) feel most comfortable with or are most familiar with. Don’t use an organization you dislike just because someone told you it’s better.

3 Likes
#3

I will correct your statement, ‘there is no best or worst organization.’. Of course, there is a good and a bad organization, and they are easy to distinguish.
I think anyone can tell that the garbage from the toolbox is less organized than a project that dozens of good programmers are working on.

2 Likes
#4

Instructions unclear, think I done it right tho.

image
image357×544 13.9 KB

(I’m joking and I’m obviously organizing this mess as you can see lol)

I strongly recommend organizing your projects, easier to maintain, modify & update.
Maybe a “too well” structured organisation might not be your thing but it’s just… better to try to.

(and before someone think I really keep things unorganized… I try to keep it as organised as I like it !)
image

#6

I didn’t read too much but would you consider this organized? It’s the usual structure for most my games.
image
image

#7

Too many people come for pranks. >:(
You can storing scripts in the Workspace, but you should not store client scripts in the folder for lightning

#8

It’s not a joke I fr do this

Why

#9

Maybe because they don’t work there?

#10

scripts with a client RunContext work anywhere

3 Likes
#11

you’re right, my mistake is that I assumed it had LocalScript.

#12

Wait how did i not know this bro :open_mouth:

#13
1 Like
#14

Storing objects in Lighting is so retro

#15

There is no “Right” or “Wrong” way to organize your experience because in the end it’s just really a preference or an opinion. I do recommend optimizing it so it fits you and your team at the same time if you’re doing a studio collab so just keep you and your team comfortable! I do think this is a good idea for beginner developers as you said some just abandon projects that they have something that organizes their studio untill they learn how to organize it themselves.

4 Likes
#16

anywhere except (ironically) starter containers themselves and server (duh) containers

1 Like
#17

real (send help)
image
image
image

1 Like
#18

Isn’t the knit outdated?

Summary

This text will be hidden

#19

I run a forked version of Knit with tons of custom features and whatnot, to the point that it’s essentially entirely rewritten. I prefer using it, and it works for me; therefore, I don’t plan to move away from it anytime soon.

While I don’t recommend it for people anymore, it is still a resource I will continue to use my version across new projects.

Knit encourages bad behavior from developers who don’t understand how to use it, and people tend to create circular dependencies. Plus, it lacks intellisense.

Here is what Stephen said on the GitHub archival reason:

Due to the nature of Knit’s design, these changes put Knit at a significant disadvantage in regard to developer experience. Knit cannot fully benefit from types, and thus does not have good intellisense. While there are workarounds, it forces developers to nearly reinvent Knit altogether.