With the new release of packages on roblox, I was ecstatic! It was exactly what I needed right when I needed it, but now that I have put these packages into practice on my game, it has become apparent to me that there are some places where packages fall short when they would be super useful! Here is what I’ve gained from my experience using Packages in Midnight Racing: Tokyo (my game):
Link to the game:
At the time I’m writing this, there are only two public levels, but in the near future there will likely be up to five or six, each with huge file sizes (except for the initial menu place)
Group - Owned Packages
As good as packages are for single developers, the vast majority of the games that will be making heavy use of these are likely going to be group owned - especially with a tool so powerful as Team Create in roblox. This is due to the nature of game development, and the necessity of many people with different skill sets.
Midnight Racing is, of course, a racing game. It takes place over different levels in the same universe, each level referencing the same “Vehicles” Package. It is at times very difficult to keep all 126 of our cars up to date, especially considering the fact that most of our vehicle development takes place in a baseplate test track place remote from the actual game universe.
Since only myself and two other devs have access to the team create, we have to coordinate when there will be vehicle “packs” (mass updates). Packages could be used to ease this functionality if they were owned by the group and freely updated by the Vehicle Team themselves. In addition, I myself cannot actually update the vehicles, because the package is owned by the dev who most frequently does it. Had the package been owned by the group, then at the very least all three of us with access to the Team Create could update the Vehicles folder across each of the different levels without having to load three massive game levels to place the new vehicle folder into the game. Our game and the platform are only expanding, so tools like this would be insanely helpful to saving time and easing the dev process.
Nested, Auto - Updating Packages
My next subcategory is to request functionality for nested, auto-updating packages owned by other people. This one might have some issues when it comes to security, so let me address that first. Of course, if someone copy-pastes an auto-updating package from a team create one day and now has access to every iteration of that package, that’s not good for anyone; however if packages work similar to Models in the sense that they can be sold and owned by other players, this would allow roblox to unlock the auto-updater for other people’s packages. It’s like taking a license to auto update the package.
My use case in MRT is not commercial, but rather as a compensation to my staff for helping with the game. Staff for my game get special cars they make themselves, called “slots” that are not actually part of the game, and inserted using the :ins [id] command in Kohl’s admin. Staff, however, cannot update the models on the group themselves (that I might address in another post) so one of the three devs with team create access need to update the slots on the group for the staff. It would be much cleaner if I could make a package folder to insert into each level & have it contain each staff member’s own Package link that they can update - like a window into the team create for that model only - and then have the Package I own update automatically to include the new version of their package.
Variant Packages
Packages are fantastic for reusable code. Tweening modules, objects, server scripts, client scripts - It can all be managed with a package. The tough part comes when certain things need to be slightly different from place to place. You can think of this revision as a player implementation of “overwriting” core scripts. Sort of like how you place a custom camera module in Player Scripts with the same name, and the game won’t load the default camera script because it assumes you’ve forked your own copy.
My implementation of this came when I was working on the teleport script for the taxi near the spawn. Each game has it’s own set of preview / Teleport gui images, but they were nested in the teleport gui module. This kept me from being able to use Packages because the module would not be able to have varied images inside of it. This implementation is easily worked around, but on a larger scale asset, something like this could be very powerful to have.
