This might sound like a beginner question, but I’m honestly stuck.
I don’t struggle with basic scripting itself. I understand Lua, I can write functions, connect events, make systems work. But when it comes to building actual game mechanics, I feel completely lost.
For example:
How would you properly structure a battleground system (skills, abilities, combos, cooldowns, damage handling)?
Or something like a building system with blocks?
Or basically any bigger mechanic that isn’t just one script doing one thing?
My main problem isn’t syntax. It’s architecture.
I don’t know:
How to organize scripts.
When to use ModuleScripts vs normal Scripts.
How to separate client and server logic properly.
How to know what architecture is “correct” for a specific type of game.
Every time I try to start something bigger, it turns into spaghetti really fast. Everything starts referencing everything, and I don’t know if I’m overcomplicating it or doing it completely wrong.
How do experienced developers approach this?
Do you design systems on paper first?
Do you follow specific patterns?
Is there some general rule for structuring mechanics in larger games?
I’d really appreciate advice, examples, or even just mindset tips on how to think about architecture when creating systems like battlegrounds or building mechanics.
Everyone will have a different style, but it’s best to have a plan for anything you do!
I haven’t really done much with complex game mechanics. I do use a single disabled script that starts out as a comment ( --[[ ) for notes or plans. That way if I’m building or scripting I can just open it to add or change notes in Studio rather than use a separate program or paper. Here’s an idea of how I’d plan out something like an inventory system using notes:
Write down the inventory systems main points so when planning it other items work upstream and downstream.
Make sure to leave room for other modifications you may want to add in the future so you can be prepared for them instead of having to rewrite your entire code.
Store it on the server so player’s can’t modify their inventory locally and affect the game.
Will it be driven by an economy system, or have trading or crafting type mechanics? Notes on how the mechanics will be set up.
How will the player’s GUI be organized to work out the tasks needed? Factor in things like submenus or other GUIs to make it easy to use without cramming everything into one window.
and so on…
It gives you a list of things you can always reference to.
Also modify it or use notes on the fly to keep it updated, or to remind you of things you want to do. Believe me, there’s lots of times I would think “Oh, I should make this model” or “I need this script to take this variable into effect later on” and then forget about the details of what I had in mind.
Start with smallest possible things you can think of in system. (like most basic action)
Clearly separate the responsibilities of the system between modules. (think of different aspects of the system and how we can separate them into modular structure)
Define datastructure. Basic objects/classes (e.g. Block in a building system)
Work your way upwards the “hierarchy”, to create more complex layers/modules, that perform more complex tasks (e.g. BlockManager).
Here is an example of what “thought process” I have when designing systems:
Example
Lets take building with blocks as an example. Here are most basic parts of the system that come to my mind:
spawn a block at specific position
snap to grid
check surrounding blocks / validate surroundings
As you can see, we are performing most of operations/actions on something that we call Block. In such cases we need a convenient way to manage such reappearing things. For that we create objects:
In block building system we create object Block with properties (like color, health, etc.) and basic function for handling it (like SetPosition(), GetNeighbours(), etc.)
If we want a combat system, we might want to create Action object to conveniently access properties like range, damage, cooldowns, etc.
Now when we have convenient data structure, we can start implementing basic building actions that we defined before in some kind of Utility/Manager module, if sticking with our block building example I would make something like BlockManager, which will handle things like positioning, spawning, destroying, grid snapping, etc.
And if needed, we can add more layers (that is called abstraction), for example, we can make BuildingClientManager which handles Player specific states (e.g. controls and validation, remove events) and uses our BlockManager to handle building for players.
But we have to make sure that responsibilities are distributed correctly between the modules. For example Block must not handle grid snapping or Player data. Its responsibility is to exist, provide information needed and perhaps change color or any other properties.
Then we can comfortably implement UI/Controls or whatever interface for player to interact with the system.
Make sure to have a list of requirements and goals of the system somewhere. And separate server and client logic. Never trust a client, always validate and execute important actions on server. I hope my response was helpful
