My game content (models, directories, scripts) is all over the place! But is is a mess? Or is it normal?

  1. **What do you want to achieve?
    Clarity about how the core structure of a game should be set up.

  2. What is the issue?
    I have global value objects in workspace for my caves, Global value objects in my serverStorage, and Global value objects in my game controller.

I have scripts in serverStorage that I duplicate into objects in order to copy values from the serverStorage globals to like the “parentdirectory.globalValue1.Value” things. That way I don’t have to do that 8 times for 8 different directories from the 1 file. Just saves repeating code. The copied script will work in any directory it’s put in to and set up that directory.

I have scripts that are like that above, but they are in the control script and they will set up all the values in the P1Upgrades directory with the information saved on the server.

So I like have 3 different ways to do each thing, and they are in like 3 different places.

—MY GAME WORKFLOW EXAMPLE
Like I have a player join, my controller (a big workplace.brick on the map) then sets up the player settings in the “controller.player1directory” for example, ready to play.

When the player does something like an upgrade, it pulls the default values from the default global variables in the serverstorage.globals folder and then pulls other information from the controller player variables, and uses that to set stuff in the sign. Say the cost of their next upgrade.

Other places have multiple sign posts that bring up Guis for the player. So click the sign and a player screengui comes up. So the signs, because there are many, all duplicate the script from the server storage.

Now the NPCs have to pull info from the Workspace.Cave.Globals to get information about where they are. They have to pull info from the Control playerglobals based on who is operating them. And they have to get default globals from the serverstorage. They also get given information from the spawner object. They store much of their information in variable objects inside their model. They use all that information to function.

In some instances, I have the player click a sign. The sign passes the player id to the object it spawns, the object passes the player ID to the object it interacts with, and the interacting object passes that player id to the object it spawns, and the spawned object, when clicked, checks the player ID against who clicked it. Something like that.
—END WORKFLOW EXAMPLE

It’s a bit late now for me and I just have to work out, “which of the numerous places where I have stuff, and the numerous ways I do stuff” in order to work on that part.

  1. What solutions have you tried so far?

I asked on here before about how people set up their game. Where do they put their globals. How do they transfer the information around, but the replay wasn’t clear enough and now I’m getting lost.

I still have no idea what the core structure should be to how to organize the game information to make it easy to navigate and use.

I don’t even know if I’m on the right track or if I do have a complete mess.

1, does that sound like a complete mess or if it fairly normal?

2, How do you organise your stuff so it’s not a complete mess?

As in:
Where do you store your globals? Do you story all your scripts in the same place and duplicate? Or half duplicate? Or not duplicate at all? Do you have like 500 globals in 1 script instead of setting them out into categories and folders? How does the flow of your game work?

All that sort of stuff. Feel free to use something like my WORKFLOW EXAMPLE to explain how your game structure flows.

3 Likes

Ehm… can you send a GIF or a image pls?

Events—>Replicated Storage
Guis----->Starter Gui ofcourse, or in serverstorage, to be cloned into Player.PlayerGui
other stuff, e.g parts and models-------->in different folders , in worskpace,labelled what they contain, for example one folder could be called pet eggs, containing pet containers ,
use _G to share globals, or modules
with all that your game shouldnt look messy, and will look organized.

If the Players GUI’s are in the ServerStorage the client can’t access them and the server can’t clone them into PlayerGui because that’s not replicated to the server.

PlayerGui changes aren’t replicated to the server but remember that it’s the server that replicates StarterGui contents into PlayerGui in the first place. The server is able to add and remove contents but it will never see changes a client makes to PlayerGui.

Therefore yes actually, the server can clone Guis into PlayerGui.

1 Like

Only at startup though? If I added a UI to StarterGui during the game, does it get replicated to all of the clients?

Yep, you can do this!

StarterGui is much like any other storage service you’ve worked with, such as Replicated/ServerStorage. The function of StarterGui is to hold interface assets. Internally, when CharacterAdded is called, the contents of StarterGui are cloned by the server into the player’s PlayerGui.

You can replicate the internal behaviour of StarterGui’s cloning process with a simple iteration across its children. You can also use this if StarterGui encounters issues cloning or if you don’t want to/can’t use it for any reason.

for _, child in ipairs(container:GetChildren()) do
    child:Clone().Parent = playerGui
end

While services provide some kind of functionality for the game, some can also serve as containers also with a specific purpose. Examples to run off:

  • ReplicatedFirst exposes loading screen handling API and can hold children that are the first items replicated to the client upon joining.

  • ReplicatedStorage can hold instances that are replicated to all clients as well as the server.

  • StarterGui exposes functions for working with CoreGuis while also being a container for Guis to be cloned to PlayerGui when CharacterAdded is called

    • There is an exception to ResetOnSpawn false Guis which are taken out of the Gui refresh pipeline (are added only on first join; do not clear on CharacterRemoving).

And so on. :slightly_smiling_face:

1 Like

This is because contents from the StarterGui are cloned when a player joins the game. I believe when a player dies, any GUIs with the ResetOnSpawn will be cleared from the PlayerGui and any in the StarterGui will be copied.

As for the OP, I try to keep everything in ServerScriptService, or the StarterPlayer/StarterGui. All of my game scripts are modules controlled by a main script and each script handles different things in game. For example, I have a script in one of the games I’m working on to handle structure placement. These structures include their own server scripts but those scripts are placed inside of the model which is inside of the StarterGui. These scripts solely talk with the scripts in ServerStorage and don’t do much on their own besides logic and structure specific actions/animations/etc.

So I just took 3 showing some of the basics of what I’m doing.

Really I have all my in world stuff in workspace. So the stuff that belongs to player 1 is in the P1 directory. All the worldly operations. Light say there is a street light for player 1, it will be in the player 1 directory.

I have my background work don’t by my control. Sort of like a CPU handling the operations. Like when players join and leave and when there is information to be saved and stuff. It holds all the main running information for players. It handles the player upgrades too. When the player clicks a Gui, the message is sent here for the control to handle what that message means.

Then there is my server storage which keeps everything I want to clone. But also my main global to make them easy to find.

My globals are IntValues, NumValues, and ObjectValues, so my scripts can just get the values from the script parent to work out where it is and what it has access to there.

I don’t use _G at all because my scripts are complicated enough as it is without losing track of where all my globals are. This way, I fully separate them so that I hand it some IntVariables, and the script then does the work with the IntVariables I supply. Rather than handing a script a script. I like solid tangible stuff to he shared around like letters going from one place to another.

The thing is, I can’t find anything that talks about workflow on the net. I am purely guessing based on my decades of game design in multiple languages and programs.

I just want to know what the basics of how to set out the game components. How to have certain things work together. How to organize things for the most efficient and most user friendly way.

Maybe others could show images of how they set out their games?

I’m just surprised that the studio documentation wouldn’t cover this, with different ways to handle different organizational strategies.

But yeah if I can learn more about how others group their components, and organise their workflow, that would be awesome. I could see if other ideas work for me or not.

2 Likes

Over the years of being on this platform, I’ve seen a lot of things. From people storing their entire codebase in workspace to people swearing that more parts == better.

Personally, in my own games, I love to use two script architecture (some call it one script architecture) where I create things only when they’re absolutely needed and reuse old instances to minimize overkill.

One server script in game.ServerScriptService that controls remote events / functions, game-logic, database interfacing, cache management.

One client script in game.StarterPlayer.StarterPlayerScripts that controls UI / UX, sounds, player input (mouse clicks, keyboard) and visual aesthetics.

Inside each codebase, I have a system of “modules” or “code-blocks” that helps organize my code and determines which methods, variables, etc go in where.

Hope this helps!

1 Like

That does. I tried the ServerScriptService but for some reason it didn’t work. Must have been a newb thing.

I just made a brick in workspace that has my main script. Basically the same thing right? Or am I missing something major?

ServerScriptService is untouchable by clients. Workspace is replicated for each client. Firing remotes or scripts in workspace is inherently bad practice and I’d advise against it. Ultimately, it’s your choice as it’s your game.

Yeah a lot of that stuff is somewhat confusing to me.

As for firing remotes or scripts in workspace, how come? I have a sign in workspace, and they click it, and it fires to the client to open the screen Gui. How is that bad? I’m not sure why it would be a bad practice.

I just have on click in the object, and it does it’s thing. Sort of silly to have the Client register what it clicked, send the message to the server script, and the server script then alters the object based on what the client said. Or alternatively, having the server script constantly checking if the object is currently being clicked. Or alternatively, have the client scripts altering the workspace objects.

Just not sure how else it’s supposed to work. But yeah any info would be super appreciated :smiley:

ReplicatedStorage replicates items to both the client and the server. Meaning that if a client were to change the contents of ReplicatedStorage, it wouldn’t replicate changes to other clients or the server. You can find out more: ReplicatedStorage | Documentation - Roblox Creator Hub .

From what I understand, you have one script that’s parented to a part in Workspace. If this is the case, you’d be at a loss if you needed a multitude of the same part. This particular case is common and is solved by the principle of reusing instances / code. You can do this in a variety of ways from having a ServerScript in ServerScriptService that checks each part that is named under a particular namespace or is under a specific folder to using CollectionService to perform the same action under specific conditions.

I’d consider using/looking into the following resources to help you with your problem:

Hope this helps!

1 Like

I store a lot of my stuff in server script service, even objects. pls no hate I also separate everything into folders. For example, I’ll have a Purchase folder, a core scripts folder and more.

1 Like

I do basically the same thing as collection service and tagging but instead of tagging, I just have a “KillScript:Clone” thing to just copy the script in there.

Every new thing object cloned or NPC etc instantly just clones its script and goes on it’s merry way. I then just have to edit 1 single script. I can also have the 1 script react differently depending on circumstances of it’s parent. So not just tagged “KillBrick” but with that Tag, it will check what brick it is, and how it kills, and if it’s meant to do something else like fling them up in the air before killing etc. Then the 1 script will handle every sort of “KillBrick” that I make.

The 1 script in workspace is in an object that will never be replicated. I’ll make it invisible and not collide when I’m finished. It’s just from my Game maker days where we would have an object that would initialize first and set up the game and control all the core elements of the game. I used to have a Sprite for that controller as a square with the letter C. I’d have it invisible in game but it would control all the core stuff of the game.