how could i improve my code

[glacial fox]

https://github.com/kilpyfr/Roblox/tree/main/Combat Stuff i want to know how i could scale this and just overall make it better

[livid escarp]

Renaming your variables better , having constants

capitalize global variables

[glacial fox]

wdym having constants

[rain prism]

make more things

[glacial fox]

I need to perfect one before I move on

[rain prism]

no you dont

physically impossible to perfect it before moving on because later on you might need it to do things you didn't originally plan on needing it to do; meaning you may need to throw it out and start again to get it to do what you wanted. meaning all that time you spent perfecting and optimizing it? wasted.

s1 is expected to know this

Technical Ranking Guidelines

[Scripter 1 - Beginner] Key Expectation: Novel problem solving with intent

What this looks like in a script:

• The script is not prematurely optimized: https://www.youtube.com/watch?v=tKbV6BpH-C8

[rain prism]

what really matters here is that whenever you need to do this, re-write modules to add behavior, you have originally made it so that you don't need to change anything else that depended on the module, only the module itself. this is what decoupling and abstraction is supposed to be for. s2's are expected to know this

[Scripter 2 - Intermediate] Key Expectation: Novel problem solving at scale with intent

Meaning:

In addition to the scaling problem, you, or another scripter, often may need to go back to your scripts at a later time to fix a problem ("Maintainability"), change or add new behavior ("Robustness"), or produce new content with it ("Versatility"), so it is a major priority for marketplace employers that their codebase stays clean, organized, and manageable as its scale increases so that any person or team working with your scripts, yourself a year from now included, are able to look upon your work and understand what it is doing in order to build upon it with minimal time and effort; this is the problem of collaboration.

What this looks like in a script:

• The script shows decoupling and independence, separating implementation details away from its inputs and outputs, also known as Abstraction: https://www.youtube.com/watch?v=L1-zCdrx8Lk

[rain prism]

you won't be s1 until you learn that optimization and performance don't matter as much as you, and so so many other s0's think it does. learning this is the best way to improve your code.

coz if i can look at your code and say "this section sucks but all i have to do is change the body of the function and nothing else" it is excellent code 👌

[nova basin]

So that's decoupling?

[rain prism]

pretty much

the inputs and outputs are 'decoupled' from the implementation

[glacial fox]

idc abt s1 bro

[glacial fox]

whennnn did i mention optimization gng

i asked how i could improve my code

and youre edgiiing it

[glacial fox]

i already watched this smh

trust me i did my research

[glacial fox]

im already above s1 wdym

im like high s1

im tryna get low-mid s2

[rain prism]

that was your first question

[rain prism]

which I answered

[rain prism]

right here

[rain prism]

what else would "perfect one before I move on" mean?

[rain prism]

y'know, the second question you asked right here

[glacial fox]

organization, abstraction, just general format of the code

[rain prism]

Which I also answered

[rain prism]

right here

[rain prism]

and here

[rain prism]

and here

[glacial fox]

im already abstracting though

at least i think so

[rain prism]

but really the best thing you can do is what i suggested the first time

[rain prism]

gaslighting is not necessary when i've already answered your question

[glacial fox]

how am i gaslighting???

[rain prism]

atp just make more stuff.

that's the best way to improve.

it's really not that deep.

it really, really is that simple.

[glacial fox]

i just want to know if my general format is fine

i dont think im asking for much

[rain prism]

it's fine

[rain prism]

ya you didn't ask for much and i gave you a lot, perhaps too much

[glacial fox]

sure but you still didnt give me what i wanted

which is mainly what i care about

[glacial fox]

i dont think im prematurely optimizing cuz im asking for organization advice, not optimization advice

[rain prism]

you're trying to optimize your organization

and i'm saying dont bother; just roll with what you have

[rain prism]

it may not be the answer you wanted, but it is the correct answer

[glacial fox]

so everywhere i turn is a dead end

[rain prism]

wat

[glacial fox]

im trying to scale so its easier to add more stuff

cuz i plan on adding more to this system

[rain prism]

yeah, you're doing it backwards

add more stuff first and then scale it

not the other way around, that is premature optimization

[glacial fox]

oh so i add something, see what made it difficult, and then fix it?

[rain prism]

now you're getting it!

[glacial fox]

https://cdn.discordapp.com/attachments/1363682223538049077/1398287079070236802/copy_B6078E9E-C0F7-4E60-B04E-0DEF62B02E97.gif

[rain prism]

it's impossible to know in advance how flexible you need your systems to be .. until you actually use your system to do those flexible things

[glacial fox]

what if im just trying to makle it more readable though

[rain prism]

coz you can plan all you like, it won't matter when it comes to actually making the things you want to make

9 times out of 10 you'll hit something that you weren't expecting. you simply cannot account for that short of just making stuff, finding all those boundaries, scale up, and keep going. rinse repeat

[rain prism]

that's just practice over time

[glacial fox]

abstraction helps though right

[rain prism]

the more stuff you create, the more accustomed to making stuff you'll be, and the more consistent your code will become because you simply know the patterns you're using better, which will in turn make it more readable because your code is more consistent

[rain prism]

abstraction is a tool

you need it to make systems flexible

and do more stuff

[glacial fox]

isnt that the job of decoupling

[rain prism]

same same

they're roughly the same thing

[glacial fox]

isnt abstraction hiding functionality and decoupling making it more usable to more situations

or is abstraction more than that

[rain prism]

how to put it simply

"do more with less"

i.e every time you go to use an animation you usually don't care how it is loaded or anything, so you abstract away those responsibilities to some abstraction layer that handles loading and playing back animations

then wherever you need an animation you call into that abstraction since you only care about actually playing an animation at that point, how it gets loaded or where the id comes from is irrelevant

coupling is the specific functions and interfaces you depend on

the specific kinds of inputs the abstraction needs

there is always some coupling

i.e animationsystem:PlayAnimation(name_or_id)

your system could take a named animation, or it could take a flat id, or maybe it can take both!

[glacial fox]

could it take an object?

[rain prism]

but the :PlayAnimation() function is a dependency now - the function must always have that name and do exactly that job, you can't change it because anything that depends on it must also change. this is coupling.

[rain prism]

and this is why abstraction so good. if you later decide you want to pass in animation objects directly, you can do that without changing anything else coupled to it

[glacial fox]

but wouldnt you have to go to all scriptss using it and change the id to an object?

[rain prism]

make your abstraction support both

[glacial fox]

wait thats a good idea

[rain prism]

if you want to remove capability such as removing the ability to pass in a pure id, then yes you would need to change all the scripts that use a pure id to use the new technique instead

naturally, doing that without making those changes first is going to break a lot of things

this is the purpose of Deprecation.

[glacial fox]

so my inout handling system is tightly coupled since it only supports 3 parameters?

[rain prism]

so your system might still be capable of taking a pure id - but you would consider it "deprecated" and slowly phase out anywhere you still use a pure id, and never use it for future works. this is why you should absolutely care when roblox deprecates something because it is exactly the same as this

[glacial fox]

so changing parameters in a module should be handled like how roblox deprecates objects

or even a function in general

[rain prism]

only if you remove functionality or change it in a way that older methods are no longer supported

the goal is backwards compatability; code that hasn't been updated to use new methods still need to function

otherwise your game breaks

this stuff isn't hard to research btw

[glacial fox]

i see

[rain prism]

and should be glaringly obvious

like well duh if you remove something that other parts of your game relies on, it's going to break your game

I didn't need to tell you that, you already knew that

[glacial fox]

yeah bt i didnt think about the backwards compatability part

[rain prism]

the only part you probably didn't realize is yes code really is that stupid

most beginners tend to overthink it

[glacial fox]

i mean yeah code isnt sentient

[rain prism]

like omg deprecated big word such complex

no.. it just means you don't break your game when you go to remove something

everything in scripting is like this

all of it

in fact the more ooga booga caveman smallbrain you are about it, the better.

in fact, you may find me asking really stupid questions, or posting really dumb or obvious answers to people's questions

[plucky cove]

** You are now Level 56! **

[glacial fox]

i mean i already know what deprecated means

[rain prism]

i don't do it just because, it's actually a very specific technique

[glacial fox]

you dont make more things?

[rain prism]

i make more things all the time

last week i made gui particles

this week i made a bytenet replacement

[glacial fox]

so you dont do what

[rain prism]

today and tomorrow i'll be working on the player session sync thing, basically networking/remotes wrapper so i can share data

[glacial fox]

i thought you hated buffers and optimization

[rain prism]

you're overthinking it

[rain prism]

what is the simplest, dumbest reason you can think of for why i would tell beginners not to use bytenet, but then go and make my own even better one for myself?

[glacial fox]

cuz youre a hypocrite

[rain prism]

that's simple but not very dumb

kinda dumb tho

it's actually because beginners don't know how to use that stuff whereas i do

[glacial fox]

i already figured it out

[rain prism]

a beginner, who does not understand remotes in the first place, does not need something that makes their remotes harder to use

[glacial fox]

i now know when and how to use buffers

praise me

[rain prism]

it really is that dumb and simple

the skill level of the person i am speaking to matters a lot

[glacial fox]

if thats your idea of a beginner then i guess iim not a beginner

[rain prism]

you're still in the range where adding it is just more work you don't need to care about right now

it's only worth using when you have good reason to use it

and know why you would use it instead of not use it

[glacial fox]

buffers or remote events?

cuz remote events are unavoidable in most cases

[rain prism]

you should be using something more like knit instead which gives more meaningful networking communications

bytenet is pure compression into buffers (and tbh doesn't do a very good job of it)

[glacial fox]

so you were talking abot buffers

[glacial fox]

i learned that but i frogot to remove them

im pretty sure buffers should be used for very very frequent calls with many parameters

[rain prism]

no, you're overthinking it again

[glacial fox]

how is that overthinking it

[rain prism]

buffers are only useful if you can beat roblox

[glacial fox]

are buffers not meant to be used in expensive situations

[glacial fox]

???

[rain prism]

do you really think roblox doesn't already compress a lot of its network traffic?

if you can't do better than that, there's no point to using buffers with remotes

[glacial fox]

i knwo roblox does that but buffers do it better in most cases. usually not by much, but still more

[rain prism]

yeah it's usually not by much. people post benchmarks where they send 2gb of data in 1kb and you might think how? in reality it's the same data duplicated a billion times

it doesn't show meaningful compression because real data is much more random and unsorted

most of the time, people are not going to be sending so much data that any of this actually matters

I am in a position where i do expect to be sending a lot of data

hence i need proper networking systems

-- i also know how to build them

[glacial fox]

so what would be some uses of buffers in an actual game

or are they just not useful

[rain prism]

and i only know that coz i've already made so much stuff. when I say make more things, i'm not suggesting you do anything I have not already done myself.

I have already done all that work. you have not

[rain prism]

i know the answer to this because i've made so much stuff. you don't because you've never properly hit resource limits

like as in without doing something dum like an infinite loop or insane memory leak - in the normal course of operation the game maxes out servers. i've hit limits like that before

[rain prism]

generally they're not that useful. main use is to reduce memory usage

[glacial fox]

so theoretically if i had an ability that fires 10-15 times a second would buffers be useful or is that still too far under the threshold

i would benchmark but i cant realy simulate a real game

[rain prism]

so what you'd be sending a number or a boolean - the buffer isn't going to change anything

you'd get better gains by sending a number instead of a string

coz i see that a lot

:FireServer("SomeAbility")

[glacial fox]

the entity id is a number from 1-256

[rain prism]

and then they go ermagherd bytenet uber compress ByteNet:FireServer("SomeAbility")

..... send a number not a string would've been better in both cases, bytenet didn't help

[rain prism]

most games need more than 255 entities

in fact with roblox the definition of an entity isn't as clear-cut as it is in other games

but i'm not going to go into that right now

[glacial fox]

entity meaning a humanoid

[plucky cove]

** You are now Level 20! **

[glacial fox]

what the hell is ermagherd bytenet uber

[rain prism]

anyway, bottom line is that i'm not kidding, exaggerating, gatekeeping, or "edgiiing" when i say, just make more things. I genuinely mean it.

coz while you're still trying to perfect one little tiny piece of code, someone else, such as myself, has made leaps and bounds of progress in making systems and content - they aren't perfect, but the job absolutely gets done to a reasonable degree, and in substantially larger volumes.

it's like

you can spend a year making one thing that doesn't end up doing what you want after a week of adding content to it

or you can spend a year making and releasing a thousand things that may not be perfect but they function and people can play with what you make.

it's really up to you, i'm not your mom

[glacial fox]

the self glaze 💔 😭

[glacial fox]

im tryna make stuff that looks good on my port so thats the main reason im making this

[rain prism]

well yeah i've just spent an hour explaining to you that you should be focusing on making stuff not perfecting it when i could've spent that time making my own stuff

we've both lost productivity in your pursuit of unnecessary perfection.

[glacial fox]

well theoretically you could spend any time doing that so thats not saying much

its the principle

[rain prism]

just make stuff that's fun to play with

but

well

[glacial fox]

commisioners dont care about that sadly

[rain prism]

you can forge your own path and i won't stop you if you really want to do that, at least you are now informed that it is a bad idea and why it is a bad idea.

is about all i can give you - can lead a horse to water but can't make it drink.

[glacial fox]

How would I balance it though

Cuz at the end of the day commissioners barely care about back end

Only how it looks

And if it works

[rain prism]

you only need to improve code when it needs improving

you will know when it needs improving when your code doesnt do what you need it to do or is lagging your game

[glacial fox]

I should also balance this with making it readable right?

[rain prism]

i think you're overthinking what readability is

readability is just dont make it confusing to read or follow on a later read

aka use descriptive variable and function names, don't nest too heavily

don't using confusing weird ass logic where it doesn't belong

"bEcAuSe OpTiMiZaTiOn" is not a good excuse to make your code impossible to follow

and your datastore code shouldn't have any animations in it

that is - keep related stuff together

don't put unrelated stuff together

avoid globals and magic variables etc

[glacial fox]

I’m not

I meant just making my code readable

[nova basin]

Hmm

[glacial fox]

I did my research and around 200 entities is the max for oop before noticeable hits in performance

So I think your hatred for dod is unjustified