How PRO Devs Set Up Roblox Games — Transcript

Full transcript

1. 0:00Roblox projects fall apart as they grow,
2. 0:02not because of bad code, but because of
3. 0:03that structure. This video breaks down
4. 0:05how professional developers set up their
5. 0:07games with organized folders, modular
6. 0:09services, scalable UI, and essential
7. 0:11packages. This isn't just for big teams.
8. 0:13This is the exact structure that I use,
9. 0:15and I'm going to walk you through it
10. 0:16step by step. Advanced tooling like VS
11. 0:18Code and Rojo aren't required, but if
12. 0:20you want to dive deeper into tooling,
13. 0:22you should check out my previous
14. 0:23tutorial video.
15. 0:25Let's break down the structure behind
16. 0:26the professional-grade Roblox game. Game
17. 0:29logic should be broken into services.
18. 0:32Each service owns a slice of your game
19. 0:33and manages related data and systems.
20. 0:36For example, build service would handle
21. 0:38placement of parts, while enemy service
22. 0:40controls enemy spawning and tracking.
23. 0:43Although not always required, each
24. 0:45service is typically split into client
25. 0:46and server versions with shared
26. 0:48functionality or data placed in a
27. 0:50utility module.
28. 0:52This keeps your logic organized, makes
29. 0:54debugging easier, and helps your game
30. 0:56scale cleanly as it grows.
31. 1:00So, what does this actually look like in
32. 1:02Studio? First, we're going to create a
33. 1:04shared folder. This will house our
34. 1:06shared and client game logic. Inside of
35. 1:08shared, create a services folder. Each
36. 1:11service will have a dedicated folder
37. 1:13assigned to it for easy scalability. In
38. 1:15this example, I will create a build
39. 1:17service. The client version of each
40. 1:19service will live here along with any
41. 1:20needed shared utility scripts. We must
42. 1:23place the server versions of each
43. 1:25service under server script service in
44. 1:27order to prevent exploiters from
45. 1:29downloading sensitive server code.
46. 1:33Our build services hierarchy setup is
47. 1:36now complete.
48. 1:38Here's an example with multiple
49. 1:39services. Like I mentioned earlier, some
50. 1:42services don't need client and server
51. 1:44versions as you can see with part
52. 1:45service here.
53. 1:48Ideally, all related code would live
54. 1:50together for easy access and navigation.
55. 1:52However, the server code must stay
56. 1:54within non-replicated containers as
57. 1:56mentioned earlier. To remedy this, I
58. 1:58created a VS Code tool that
59. 2:00automatically maps scripts to their
60. 2:01correct container while allowing
61. 2:03everything to live together. This tool
62. 2:04is available on my GitHub link in the
63. 2:06description.
64. 2:11Each service is a singleton. We only
65. 2:13ever have one build service, one
66. 2:15inventory service and so on. That means
67. 2:17no new constructor. The module itself is
68. 2:20the instance. Most services have an
69. 2:22initialize function in it. Here any
70. 2:25needed objects can be created or
71. 2:27non-yielding startup code can be
72. 2:28executed.
73. 2:30In this example, we're inside build
74. 2:32service client. So the singleton table
75. 2:34is named exactly that. Always keep
76. 2:37service names explicit to maintain
77. 2:38readability.
78. 2:40in it creates a model called parts and
79. 2:43stores it on the service.
80. 2:46The service then exposes the build
81. 2:48function. It spawns a part, sets it
82. 2:50frame to the pass in parameter and
83. 2:52parents it under self.parts.
84. 2:57By default, the current Luau type
85. 2:59checker struggles to understand the true
86. 3:00type of self. In order to fix this, we
87. 3:03need to ditch the colon operator and
88. 3:05pass self in as the first parameter with
89. 3:07our defined type.
90. 3:18Member variables can be defined by
91. 3:20unionuning a table of our defined
92. 3:22variables to the type.
93. 3:25Additionally, type cast the return
94. 3:27service for proper IntelliSense when
95. 3:29used in another script.
96. 3:33Now let's use the service we just
97. 3:35created. Create a client script inside
98. 3:38of starter player scripts and name it
99. 3:39client.
100. 3:41This contains basic startup logic for
101. 3:44our client sided services.
102. 3:47For demonstration purposes, I'll use the
103. 3:49build function here.
104. 3:54Typically, startup scripts will simply
105. 3:56initialize all of our services. If order
106. 3:59matters or the init function takes any
107. 4:01parameters, you can initialize each
108. 4:03service manually. Otherwise create a
109. 4:06simple loop that calls in it on a
110. 4:08recognized services.
111. 4:12In order for client and server
112. 4:14communication to be possible, we must
113. 4:15use remote events and functions.
114. 4:18Remote instances should not be created
115. 4:20manually. Manual creation leads to messy
116. 4:23hierarchy trees, dependency on names,
117. 4:25and hard to manage version diffs.
118. 4:28Instead, create remotes through code. A
119. 4:30simple remote event wrapper can be
120. 4:32created in less than 50 lines of code
121. 4:33and solves all of these issues. There
122. 4:36are plenty of open source solutions such
123. 4:37as Biteet, Blink, or Zap. I personally
124. 4:40created my own networking solution that
125. 4:41I use in all of my games, and I'll be
126. 4:43using it for the example shown. Whatever
127. 4:46networking library you use or create
128. 4:48should be placed into a new folder
129. 4:50called packages. Packages are reusable
130. 4:52scripts that are not reliant on any
131. 4:54specific game logic, meaning they can
132. 4:56easily be dropped into any project. If
133. 4:58you are using VS Code, I recommend using
134. 5:00the Wall-E package manager as I
135. 5:02mentioned in my previous tutorial video.
136. 5:08Start by mirroring the service setup on
137. 5:10the server.
138. 5:17Inside of the initialize function,
139. 5:18create any needed networking solutions.
140. 5:22My networker library is designed for
141. 5:24easy communication between either side
142. 5:25of the network. Simply create the client
143. 5:28and server versions of the networker,
144. 5:30define any functions the client has
145. 5:31access to call, and use the built-in
146. 5:33methods to communicate.
147. 5:39I'm not going to go in depth into my
148. 5:41specific networking solution as it could
149. 5:43vary from yours. If you're interested in
150. 5:45mine, there are docs on the GitHub
151. 5:46repository in the description.
152. 5:50Instead of clients telling the server
153. 5:52directly, I built a part here, it should
154. 5:54ask, can I build here? The server would
155. 5:56then validate the request and
156. 5:58potentially send some response if
157. 6:00needed.
158. 6:01In this example, the client calls the
159. 6:03serverowned attempt build function
160. 6:05within its build method. In this case,
161. 6:08the attempt build validates by creating
162. 6:10a 5-second cool down between builds.
163. 6:14Don't forget the server startup script
164. 6:16inside of server script service.
165. 6:22In order to modulize reusable game
166. 6:24logic, most professional developers
167. 6:26utilize object-oriented programming to
168. 6:28create classes. Similarly to the service
169. 6:31structure, create dedicated class
170. 6:33folders under shared and server script
171. 6:35service. This video will not be teaching
172. 6:38object-oriented programming. So if
173. 6:39you're unfamiliar with this paradigm, I
174. 6:41recommend doing some research on your
175. 6:42own.
176. 6:44Leave a comment if you'd be interested
177. 6:45in a separate video covering
178. 6:47object-oriented programming in depth.
179. 6:50In this example, I will create a spike
180. 6:52class.
181. 6:53Now, instead of build service creating a
182. 6:55new part, it will create a new spike
183. 6:57object instead.
184. 7:03When a player touches a spike, they'll
185. 7:05now be damaged.
186. 7:07Custom models, VFX, and other instances
187. 7:10should be placed inside of an assets
188. 7:11folder under replicated storage. For
189. 7:14example, my spike class will now use
190. 7:16this custom spike mesh instead of a
191. 7:17basic part.
192. 7:24For the sake of example and to make
193. 7:26things more interesting, I've hooked up
194. 7:28the clients build function to call
195. 7:30attempt build whenever the mouse is
196. 7:31clicked. I initialize this behavior
197. 7:33within the init function.
198. 7:38Modules provide shared functionality,
199. 7:41data or utilities that other scripts can
200. 7:43depend on. Follow the same shared versus
201. 7:45server rules from before, creating their
202. 7:47respective folders.
203. 7:50I take module organization a step
204. 7:52further by grouping them into clear
205. 7:53categories like core, game, math, and
206. 7:56platform. This way, it's immediately
207. 7:58obvious where any script belongs and
208. 8:00where someone should look to find it.
209. 8:02Keep modules small and focused. Math
210. 8:04helpers, reusable functions, pure data
211. 8:06tables, and so on.
212. 8:10User interface is one of the easiest
213. 8:12places for projects to get messy.
214. 8:14Professional teams prevent this by
215. 8:15keeping UI modular and scalable.
216. 8:18Many developers use declarative UI
217. 8:20frameworks for this. React, Fusion, and
218. 8:22VID are the main options. I currently
219. 8:25use React and I've shipped production
220. 8:26games with Fusion as well. With that
221. 8:29said, I know many Roblox developers
222. 8:31aren't ready to dive into declarative
223. 8:32workflow, but here's a middle ground
224. 8:34that I recommend. Place all interface
225. 8:36code under a tople UI module in
226. 8:39replicated storage. This module acts as
227. 8:41the UI initializer. Inside, create
228. 8:44folders for interface types such as
229. 8:45menus or HUD.
230. 8:48In this example, I have a left sidebar
231. 8:50HUD element and an inventory menu.
232. 8:54Each feature gets its own module script
233. 8:56that exposes its functionality and an
234. 8:58init function if needed.
235. 9:06Just like services, the top level UI
236. 9:08script should initialize these features.
237. 9:15Finally, make sure the UI initializer is
238. 9:18called inside your client startup
239. 9:19script.
240. 9:23This approach keeps the familiar Roblox
241. 9:25workflow while still giving you scalable
242. 9:27modular UI design.
243. 9:32As mentioned earlier, packages are
244. 9:33reusable scripts that aren't tied to any
245. 9:35specific game logic, which means they
246. 9:37can be dropped into any project.
247. 9:40Professional developers rely on them to
248. 9:41avoid reinventing the wheel and to keep
249. 9:43their code base clean. Here are a few
250. 9:45core packages that I personally use
251. 9:47across all of my projects. Signal, a
252. 9:50pure code replacement for bindable
253. 9:51events, more efficient, easier to work
254. 9:53with, and hands down the one package I
255. 9:55wouldn't want to develop without. Charm,
256. 9:58an atomic state manager that pairs
257. 10:00perfectly with declarative UI
258. 10:01frameworks.
259. 10:04Sift, a comprehensive table utility
260. 10:07library packed with useful functions.
261. 10:13Data service, a full persistent data
262. 10:16solution with automatic client
263. 10:17replication and observable values.
264. 10:23Janitor, a lightweight cleanup module
265. 10:26that makes managing connections and
266. 10:27instances painless.
267. 10:32These packages keep your projects
268. 10:34modular, predictable, and ready to
269. 10:36scale. Like I mentioned earlier, I
270. 10:38manage all of these through Wall-E for
271. 10:39versioning and easy updates.
272. 10:43This is how professionals structure
273. 10:44Roblox projects. Services for game
274. 10:47logic, clear modules, scalable UI, and
275. 10:49reusable packages. Together, they keep
276. 10:52projects clean and scalable. Your exact
277. 10:54setup may differ slightly, but the
278. 10:56principle is the same. Organize early to
279. 10:58avoid chaos later. Check the description
280. 11:00for relevant links, and drop a comment
281. 11:02below the like button if you'd like a
282. 11:04deep dive on topics like object-oriented
283. 11:06programming or networking.