Trying to setup scripts/systems without instantly causing technical debt

Help and Feedback Scripting Support
1

Context

For some quick context: this project I’m planning to work on is actually (at the moment) a remake / version 2 of a previous asym game I worked on: LEAD | Play on Roblox

The game was mainly an inside joke that I was planning to briefly work on just for a gag, but kinda grew into a larger project that I did genuinely have fun working on.
The issue is that due to the original unserious nature of the project, pretty much everything was made up as time went along and eventually led to the backend of the game becoming painfully hard to work with

While the game itself is still based on a silly joke, I do want to take the actual development of this new version more seriously and therefore building it without instantly causing technical debt to form.
I kinda don’t know how to do that though. So I’ve kinda been stuck having studio open but doing basically nothing out of fear I would instantly mess something up.
its really not fun. im kinda suffering here and i horribly need help :face_holding_back_tears:

The actual thing I wanted to ask

This is technically more of a design thing than a scripting thing, but I wanted to ask people more experienced with coding the backend to a game how they manage to initially set it up to prevent future technical debt, alongside keeping that debt low when adding new code & systems that interact with existing ones.
I do know various things like module scripts can help a lot with that but I’m still unsure how to fully apply that properly to how a game operates in the background (that isn’t just immediate at the time actions).
Not asking for any direct code or anything like that, this is more just to see how people more experienced in the field like to “format” their code and scripts for a cleaner and overall smoother time scripting games.

TLDR: How do you like to code your games to prevent having to deal with potential future issues with them?

ok thank you for tolerating my god awful long ramble :folded_hands:

3 Likes
2

Keep logic you’ll repeat alot modular, keep things centralized and repeated logic at a central point so when you edit a system you don’t have to copy paste the changes in 22 other scripts (e.g, you don’t create a new script under every single kill brick in your game, you make a central Kill Bricks handler in ServerScriptService and write the logic for every kill brick there, then run it in every tagged killbrick), have CLEAR separation of scripts’ job’s (a main menu script should not also be handling sprinting, NPC dialogue, what not, clearly split them by job)

And when you have to repeat yourself more than once, modularize (make reusable) that code. As a programmer, you should try to almost never repeat yourself. Fourth keep everything consistent. It’s not gonna be fun when every other script uses PascalCase variables and the other script uses camelCase variables, or worse, one script using PascalCase, camelCase, whateverthisisdontuseitcase, interchangeably with no real regard, handling cooldown logic in different ways for the same thing (like player ability cooldown), etc. Keep it consistent basically. Fifth, and this one gets skipped alot, I would personally never use double spacing. It’s ugly and there’s no point. Example I wouldn’t do:

local W = X
-- two
-- spaces
-- or anything more than one, no need
local Y = Z

Makes it feel dirty overall, you don’t need more than one newline in ANYTHING

local W = X
-- This is good
local Y = Z

Sixth, this one’s important keep variables separated by logic. You shouldn’t have 20 variables stacked on each other with no separation like

local X...
local X...
local X...
local X...
local X...
local X...
local X...
local X...
local X...
local X...

Separate by logic instead

-- Services
local X...
local X...

-- Constants
local X...
local X...
local X...

-- UI
local X...
local X...
local X...
local X...

-- Physical
local X...
local X...
local X...
local X...

Also I wouldn’t actually add those comments as the variables are self explanatory, it’s just for illustration here. You can do it if you want, nothing wrong. That said, there are dead comments you should avoid (#7):

-- Checks if the health is above 0
if Health > 0 then...

Yeah of course it’s checking if the health is zero. This is not a complex multi and/or chain condition, that comment is dead and serves zero purpose. Remove it.

if Health > 0...

So:

  1. Keep repeated logic modular (reusable)
  2. Keep logic central (should naturally come with following the first tip)
  3. Clear script job separation (main menu scripts shouldn’t be handling admin commands, sprinting, dialogue, exp bar, etc)
  4. Keep your whole codebase consistent (naming, logic patterns, etc)
  5. Proper spacing
  6. Proper variable separation & spacing
  7. Avoid dead comments and code as well

There’s way more to clean code than this by the way, this is just off the top of my head, these are just general fundamentals, but there’s more.

2 Likes