The title says most of it. I have a “mini games” type game that keeps track of which players are currently in the mini game, which ones are in the lobby, and which ones are eligible for round victory. Currently I use 3 separate modules to tell these apart, but I’m wondering if it’s better or more reliable to use teams instead for checking weather or not a player is in the mini game. I haven’t encountered any issues yet while using modules, but seeing as there is an alternative approach available that I can easily switch to I would like to be using the safest method.
Personally, I would write my own architecture that tracks the player’s state (i.e which minigame they are in) separately, just so I would have more control over the structure of the game and be able to design the systems more to my “needs” rather than the “good for everyone” functionality of the roblox teams service.
Specifically, this would be useful if I had teams WITHIN minigames, i.e red vs blue in paintball, red vs blue in a death run game, etc, happening simultaneously.
Basically, I would categorize:
Player
→ team
→ CurrentGameType
and not
Player → team (which is a game type)
OR
Player → gameType
This way, A player could be in Game A, Team Red, while a player in Game B could also have Team Red but not be associated with Game A.
1 Like
Modules are pretty different from teams. So I’d say they don’t particularly substitute out for one another.
A module script is kind of like a function which runs once and returns one value. That one value is memoized after the first require statement - require(module). It can return basic lua datatypes like numbers and strings, but often times its used to return a table (often populated with method functions for OOP usage).
So it might be more accurate to compare using a table to store which players are playing vs a team folder of which players are playing.
1 Like
Are you sure their values are frozen? They update live as far as I can tell. I mainly just want to make sure there arent any delays or notable downsides to using modules that could make them unreliable for categorizing players
Modules are frozen in the sense that the code only runs once per host process (server/client) and will return whatever it was first able to return. If a module contains a table and you populate that table, those values will indeed be entered into that table; moreover, if you “require” the module from a different script on the same host process, it will have access to those values, because the module script is not re-instantiating anything, only returning what it already knows.
Does your module do anything other than store players’ current status? If the intention is differentiate players without actually exposing a “teams” structure to the players, tables, as GreatGavin mentioned, are a simple, under-the-hood method, but it should also be mentioned that players’ TeamColor property can be set without actually separating players into teams so long as all players’ Neutral property remains true. The TeamColor method is nice because it is part of the DataModel but is not inherently visible to players.
1 Like
Gacha, thanks for elaborating. The main reason I used modules was to have tables that are accessible from other scripts, and since players can only be on one team at a time from what I can tell, I think I’m going to stick with modules.