Improvements to Packages

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.

2 Likes

Hey, this is pretty awesome and thank you for taking the time write this out. Hopefully, I can give you the answers you are looking for.

I think about Packages almost every day and where they are going to go next.

First, you’ll be excited to know that group-owned Packages are coming this year. The feature is coupled with permissions which will allow you to give users and rolesets the ability to use or edit a Package. More on this later :slightly_smiling_face:

Nested, Auto-Updating Packages is definitely something I want to get done. This right now is not possible because of the way that the modification of Packages works. I hope to resolve this next year so we can make this year even more powerful.

Variant Packages are definitely an interesting topic. Something like this is on the roadmap for next year, but comes with a lot of product implications so it will need be thoroughly investigated. My desire is to solve this use case somewhere down the line. So trust us that we are thinking about it!

Once again, thank you for posting this. Please don’t be shy about poking me later down the line and holding me to my word.

7 Likes

Great to hear! I appreciate the feedback. I did want to point out another thing that has recently crossed my mind. I think Data type packages would be a nice addition to the Packages functionality. It’s like Packages, but instead of instances from the game, there are primitive data types stored as the package. Think LinkedSources, but instead of just a string for Script sources, it could contain Primitive data such as numbers, tables, Strings, etc.

This would be extremely useful in my game since I have textboxes in different places of the menu, each with their own formatting, but the Text property needs to be linked between them (for the version number). At the moment, I use a ModuleScript model published to my group that is accessed by a script inside the text box to set the text property of the TextBox to the value returned by the module. As you might imagine, this is quite convoluded at times and hard to explain to my less-code-savvy developers how to use. Having a Primitive data type Package which links the Text property of the TextBox to a game asset would be super useful since my game makes use of the Universes feature.

Another good use case this would help with is tables of names, such as admins or values that need to be accessed by each game place. The first example that comes to mind for me is using it to store place ID’s for the teleport service to use - that way when I publish the game to my test universe, I don’t have to manually change the ID’s in every script from every place, I just change it in that one table “Package”.

Honestly, Linked Sources would probably work just as well for something like this, but seeing roblox wants to get rid of those to provide ground for newer updates it would be nice to have the same functionality under packages :smile:

1 Like