im a half decent scripter who knows all the basics - modules n stuff, and i wanna know if its possible to learn full scripting from this point on in like a month to a year max, since i have a game thats been in development for a WHILE and i wanna release it as soon as possible
MY MAIN QUESTIONS/PROBLEMS:
How do i go about making (GOOD) asym hitboxes
How do i go about making a util system
HOW DOES OOP WORK
How do datastores work bro
WHY cant i make a simple round system
i just get stuck 99% of the time i try even writing the first lines of code because i dont know where to start (and this happens for quite literally anything too btw)
and like i said i have a game in development that a lot of people have been waiting for and i just feel stressed out because im not that good of a coder and struggle a lot with it
Programming (even on Roblox where stuff can be simpler)/software engineering is a huge field and takes years to get good at, you can’t speedrun noob → expert in 1 year. You go through trial, error, headaches, pain, hours or even days long debugging sessions, experience the pain of your own architecture, refactor it, repeat. The biggest experience gainers are trial and error & repetition. You can’t speedrun it. And even when you’re “advanced”, you still constantly learn new stuff
Sounds like you already know how to script if you understand modules. That’s pretty far.
As far as the rest, those are concepts and/or built-in library commands. You’ll have to learn the techniques and concepts behind them, and for that, you need to do some research. Look for examples and study how they work.
yeah but the problem is, i know what modules and most stuff relating to it does, but when i try actually coding it i just freeze up because i dont know where to start with it (depending on the type of module it is)
Exactly. first learn how the Lua language w*rks, and after you can learn how RĂłblox things like datastores, and etc services.
You don’t need to rush, the gaming industry is obviously a competence but rushing will hurt you in the long way because you aren’t learning correctly if you do it fast. If you learned something, then practice it 50 more times
Learn the basics, start small and then you will grow on specific things.
Karate students with white belts may say learning basics is boring and not important
But karate students with black belts will say learning basics is maybe boring, but it is really important.
You don’t start big from the start or else your “Big” project will rapidly turn into a “small” version of it and will be trashy garbage. You will then lose motivation because your big insane project didn’t w*rk well.
You can watch 1000 scripting videos but if you don’t practice everyday at least some minutes, you’ll never learn. Programming is practicing, just like maths, just like guitar, just like football, just like learning another language. Speaking about language, I know you’ve noticed that you learn a new language better when you talk to native speakers instead of your trashy school classes.
That is similar to programming. You don’t learn it correctly only with theory. You learn it correctly and better with 20% theory and 80% practice.
Everything seems impossible from the start, like making a simple round system. But then 1 month later with enough practice it seems that you have made it, that’s how these things w*rk.
I thought making a game with CCU would be impossible when I was just a kid in 2017. But looks like it wasn’t…
No don’t use it because Luau isn’t designed with OOP in mind. You may use it for other languages though
Instead of asking these questions, which can mostly be answered by watching tutorials or reading documentation, you should start practicing in Roblox Studio by making small things on your own.
Don’t immediately try to build an entire datastore system, round system, or complicated hitbox system. Make something simple. Understand why it works. Break it. Fix it. Then make something slightly more complicated.
You don’t learn development by memorizing how other people built their systems. You learn by trying, failing, understanding why you failed, and trying again.
Eventually, you’ll reach the point where you don’t need a tutorial for every problem, because you’ve developed the ability to figure things out yourself.
There’s nothing wrong with OOP. Use it when it’s better to use it, and don’t use it when it’s better to do say, functional programming. Both have strengths and weaknesses, and your codebase doesn’t need to strictly have one.
Use one or the other when the benefits outweigh the cons. Limiting yourself to one practice is ironically bad practice.
This isn’t good advice. Utility modules are there to reduce repetitive code. Middleware can be used to abstract complicated logic away (e.g., state managers on top of a network layer).
Coding takes time. A year is not remotely enough to be able to code things straight out of your mind.
The only (and likely the best) way to learn coding for anyone is just do something. There’s no perfect first project, you just have to start and stick with something.
--!strict
-- ModuleScript
export type Translator = {
translate: (text: string) -> string;
}
export type Sink = {
onText: (text: string) -> ();
}
export type Args = {
translator: Translator?;
sink: Sink?;
}
const DefaultSink: Sink = {
onText = function(text: string)
print(text)
end,
}
return {
print = function(text: string, args: Args?)
local t = args and args.translator
local s = args and args.sink or DefaultSink
local out = text
if t then
out = t.translate(text)
end
out = s.onText(out)
end,
}
and use it like this
--!strict
local m = require(game.ReplicatedStorage.ModuleScript)
m.print("Hello world!")
The Committee has identified a serious logical irregularity:
“There’s nothing wrong with OOP. Use it when it’s better to use it.”
This constitutes Framework Neutrality™ and is therefore under investigation.
TNLO does not recognize “use it when it’s better” as an acceptable architectural criterion when the proposed architecture itself introduces unnecessary complexity.
You have not demonstrated that OOP is better.
You have merely established that OOP can be used.
These are not equivalent claims.
Likewise:
“Utility modules are there to reduce repetitive code.”
Repetition is not automatically a problem.
If eliminating repetition requires introducing an abstraction layer, the abstraction must justify its own existence.
Do not build machinery merely because machinery can be built.
And finally:
“Middleware can be used to abstract complicated logic away.”
Correct.
It can also bury simple logic underneath:
Interface → Middleware → Manager → State Manager → Network Layer → Factory → Registry → Actual Code
TNLO refers to this phenomenon as The Abstraction Industrial Complex™.
The correct question is not:
“Can this be abstracted?”
The correct question is:
“Does this abstraction provide enough measurable benefit to justify its complexity?”
If the answer is no:
DELETE IT.
TNLO therefore issues the following official directives:
DO NOT USE OOP.
DO NOT INTRODUCE A UTILITY SYSTEM WITHOUT A REAL NEED.
DO NOT INTRODUCE MIDDLEWARE TO SOLVE IMAGINARY PROBLEMS.
WRITE THE LOGIC DIRECTLY.
Do not mistake architectural variety for architectural quality.
Do not mistake abstraction for sophistication.
Do not mistake complexity for capability.
The project serves the requirements.
The requirements do not serve your favorite abstraction.
Better readability (for yourself or collaborators), e.g. fewer models, less abstraction
Better maintainability (easier pattern to extend to add future features)
Easier to debug, less error prone
More logical organization ( not always objective, personal style is a huge factor )
etc… this list could keep going.
Any particular solution might be “better” at some of these metrics, and worse at others. All software engineering involves tradeoffs. Lots of times, when you optimize something fully for one of these metrics, it’s at the expense of one or more of the others. Optimizing for the absolute best runtime performance often comes at the expense of extensibility, for example, because you inevitably end up hardcoding things, precomputing values, removing function overhead by duplicating code or inling helper function code, adding complexity by using caches, memoization, etc.
Performance doesn’t always matter. It’s perfectly reasonable for a developer to use an OOP pattern than is 3 times slower to execute than an equivalent DOD, ECS, functional, etc. architecture, if the runtime performance isn’t a critical factor in the overall operation of the game, and there are benefits like the pattern is more natural way to organize things (again, highly subjective person to person). If it lets you organize things that make sense to your brain and let you work faster, go with it.
At the end of the day, it’s your game, organize it however you want or however works for you today. It’s 100% true that Lua was not designed for OOP architecture, and it’s awkward to use it for that. But it’s also true that flat screwdrivers were not designed to pry things open, yet here we are. If your game works, it works, and everything else can be refined over time as you learn better ways to do things.
TNLO WARNING — ARCHITECTURAL NEUTRALITY VIOLATION