Hey everyone! I wanted to ask a question that’s been on my mind for a while: How do you script?
Let me clarify—I don’t mean how to learn scripting or write code, but how do you handle the actual process of scripting? Do you work on one thing at a time and test as you go? Or do you, like me, sometimes end up coding everything at once and then testing later?
I’ve noticed that coding everything at once has become a habit for me, and it makes debugging a nightmare. I want to break out of this habit, and I’m curious how others approach their scripting workflow.
The Problem I’m Facing
I often find myself:
Coding multiple features or functions at once.
Not testing anything until I’ve written a huge chunk of code.
Struggling to debug because I don’t know where the issues are coming from.
It’s overwhelming and slows me down, especially when I can’t pinpoint what’s causing the problem.
How Do You Handle Scripting Progress?
I’d love to hear how you approach your scripting process:
Do you write one feature or function at a time and test it before moving on?
Do you work on multiple parts of the script simultaneously?
How do you avoid getting stuck in the debugging stage?
My Goals
I’m trying to:
Learn to break my work into smaller, testable steps.
Make debugging easier by catching issues early.
Develop better habits for managing my scripting progress.
If you’ve had a similar struggle and found ways to improve, please share your tips and workflows!
Conclusion
Let’s discuss! How do you script, and what advice do you have for someone like me who’s trying to improve their workflow?
My habit is when the code is functional, i test it (sometimes multiple), when i add another functional chunk of code, i test again (sometimes multiple)
I test my scripts at sporadic intervals (whenever I feel that the script needs testing), so I would most probably write huge chunks of code before testing, like you.
Honestly, I would find it a hassle having to test every single function I script to ensure it doesn’t bug out.
What I try (and you can try too) doing to speed up the debugging would be to add comments (yes, really, comments). It helps me narrow down which possible areas my script might be erroring at just at a glance. I feel this is often overlooked by most people (including me at one point), but it helps as your script grows more messier and the need to save time identifying where the bug may be located at becomes more important.
In a way, organising scripts play an important role in speeding up my workflow. I need to make sure to name scripts properly, use folders and comment what part of my script does what. Hopefully this means I could still write bigger chunks of code while having an easier time debugging.
What usually happens when I start a new game file is that at first, it starts going super smoothly. Then, the code starts getting messy, so I rewrite everything. After I’m satisfied, I then continue but I don’t know why but I just don’t know where to continue. Do you plan before scripting or just take a stab at it? I have some kind of fear of bugs like I try to think of how to stop the bug before it happens, then I get stressed and lose motivation. That’s one of the reason why most of my game don’t get completed. AND I HATE IT.
A mix of both to be honest. If I decide to plan things out, I would plan out the general outline of what should happen, what events happen in the server and client etc. through flowcharts. If you have multiple big systems in place in your game, I’d suggest making separate sheets of rough planning.
Hm, I already have so much on my plate for planning out the system, I hardly think about bugs. Honestly, debugging albeit time consuming, would help you understand how these bugs form in the first place, and learn some good practices you can carry over to other systems.
It’s perfectly normal to have bugs in your scripts regardless of your experience! If you were to plan, maybe force yourself to stick to planning the main outline of your system and start thinking about bugs when they surface, if it makes you feel slightly better.
I usually start small, make a function that do one thing and test it. if it work as intended just then you start adding more and more stuff, eventually you’ll have a script that you understand every part of it make it easy to add more thing later or debugging
I create pseudocode as an outline then I work on one thing at a time and test as I go. It’s hard to say if something is wrong if you don’t know if everything before it is right. Once I have everything working I’ll go back and start refining. Parts that are weaker than others get researched and re-wrote. When you first start programming your scope isn’t as large as It will become. You end up becoming “Punch Drunk”. The more you work your way out of that the larger your scope becomes.
I also save snips of things that work well in a “program library”, a folder with scripts with titles of the task it’s doing. Over time this is invaluable to me. As I’m not re-making the wheel over and over. I’m using time tested routines I know work well for what they do.
I have a big picture plan of what I want, then focus it down one task at a time, testing frequently. I use --!strict. I try to keep single script files to less than 150 lines. I keep my functions short and specific to a task. I use modules both as a resource, and as an organisation strategy. I use folders. So I might have many files, but they are all relatively short and specific.