I’m working on my game Universe Vastness. It’s sandbox game about space. Players can build many different constructions out of parts. They can build factories, spaceships, space stations, etc.
Currently I’m using Rojo and Git for game development. Each part type is described in ModuleScript, which are stored in ServerStorage. Those ModuleScripts describing part types can also contain information about scripts that will be included into part instance. When new part instance is created, it’s created according to rules in ModuleScript. Parts may have properties and scripts. Part types can also inherit from other type. Currently, no scripts are duplicated in game code.
But I heard about CollectionService. I’m thinking if I should use this, instead of having many copies of script (those copies are made in runtime).
I heard many people say it’s good to use CollectionService. However, I think my case is quite specific, because in my game there are no prebuilt maps, and players build constructions out of parts. Those constructions save.
I’d like to know your opinion. Should I switch to CollectionService in this game? If yes, then should I have one script per part type? Or one script for all parts? Should this script do something for each part instance in loop, or maybe make new thread for each part instance?
Currently, parts in that game don’t any unique ID. But it would be easy to add it. And if I would decide to use CollectionService, then I’ll make such unique part ID.
This is the main reason that I personally recommend people a tag based approach instead of manually spamming identical scripts into lots of things. It’s really just about how easy it is to make changes to the scripts, which is much easier if each script is only present in one place before run time. So if you don’t have copies of scripts, you’re pretty much fine IMO. Creating a package for each script theoretically solves this issue, but I haven’t touched packages since they launched.
Nope, AFAICT your type of game doesn’t have any special considerations that should affect the question at hand.
In the end I think both approaches could work perfectly fine, with no real performance or maintainability problems with either. I’d just continue with your current approach if it suits you instead of doing a huge rewrite of your entire project.
Regardless of which approach you use, you should probably handle things in an event based manner instead of using too many polling loops.
As you mentioned, switching to CollectionService would take some time, because it would require to rewrite all parts scripts.
I think I’ll do some performance tests in my game soon. They’ll show how many parts do I need to place to have noticeable performance impact. And which parts are most resource-heavy.
Part’s UID would ease identifying parts, especially when region saving. Because in this game there are many regions, and each region’s content is saved. Each region has its own server (more specifically reserved server). For example, when I use hyperdrive to travel to other region, it would allow game to know which seat is player sitting on.