This week in our user feedback post, we have more great requests from ROBLOX players that we want to highlight and discuss.  As a reminder, we asked users for their top three ROBLOX feature requests a few weeks ago. Each week, we will address player feedback, and how we are prioritizing our development pipeline around your responses. Similar to the User Feedback v1 post, John Shedletsky, ROBLOX’s Creative and Content Lead, has provided his insight to the following user requests in italics.

Quenty: Local services. I want a local SoundService, Workspace, Lighting, etc to work with. Sometimes you don’t want to be playing a ‘Cave’ echo for one player when they’re in the open, but most of your game is a cave. Workspace would be local parts, and lighting – well, what if you just want to have a storm for one player, or a mission in which the player has to find an item? A non-hackish way would be great. I know that stuff is replicated client-side and that adding this wouldn’t be entirely hard either.

John: This is a tricky one. There are many aspects to consider here.  While it should definitely be possible to play sound files for specific players, I’m not convinced that the best way to do this is via a local service, which would be a new type of entity in our system. In the cave example, the best design is probably to create custom regions that apply specific sound effects, like an echo, to all sounds played in that region. Having these effects be global and be in the SoundService, like they are now, is not ideal.

As far as local parts are concerned – this is something that we’d like to get away from. Our guiding vision for ROBLOX is that objects in ROBLOX act as you would expect them to in the real world, using physics. There’s no such thing as “local parts” in the real world. They also fight our network architecture – typically ROBLOX scripters don’t need to spend a lot of time thinking about what each client “sees” when they play the game: everyone sees everything. This simplifies a lot of game programming in ROBLOX. Today in ROBLOX, scripters use local parts as a last resort to accomplish some effect that you can’t get any other way. Our challenge is to make it easy to achieve these effects without this hack.

Josh: Re-introduce a functioning InsertService. InsertService allowed so many possibilities in-game, such as what this group “RoGo” did- an updating giver that gives the most current issue by using InsertService. Allow the mouse object to be accessible without a tool or hopperbin.

John: The original InsertService was very powerful – give it an assetId, any assetId, and it will dutifully insert that asset into your game. The problem with that version of the InsertService was that it was actually too powerful – it could be used to insert items into a running game that the creator never intended to be insertable. This is a serious security flaw. In your example, the RoGo authors, at any point, could put a malicious script into their latest issue, and this would infect hundreds of places without the creator’s knowledge.

When fixing it, we tried to preserve most of the power of the InsertService while making it more predictable. Currently, it will allow a place to insert any ROBLOX-authored asset, or any asset the place-creator owns. The current interface for doing this would benefit from some more work. As we add additional access to web services from inside of the ROBLOX client, I think this issue will largely evaporate.

Sircfenner:  Stopping bricks welded to the character from physically interacting with the character’s body parts that are set to CanCollide false. This is a really big issue for making FPS games with welded gun models. Otherwise you start flying, and we don’t want that!

John: This is a great example of ROBLOX scripters being super-creative and really pushing the boundaries of what our game was designed to support. It’s amazing to me that there are games on ROBLOX with custom tools made out of tens or hundreds of tiny little parts. The engine was never designed to support this – scripters have discovered that this just magically works. Making stuff CanCollide = false isn’t a great solution because even if the parts don’t collide, they have mass and inertia, which will affect the character physics in surprising ways.

We do want to make the character easier to model. I think right now anyone who rolls up their sleeves and tries to edit the character model is very brave.

HylianLegend: A way to create and save player animations, and an easier way to move and edit characters. A year or two ago, players could create animation objects using complicated scripts. Those were removed along with user meshes and sounds, but unlike the meshes and sounds, they were harmless. We CAN make animations now using welds and such, but a new system for creating animations would be a nice addition. Characters are rather difficult to play around with. If you want to script in, say, a back flip, you have to accept the fact that it’s not going to be perfect. Characters bounce around too easily and aren’t very fond of being moved about in methods other than the WASD keys. (That’s why animations were so cool!)

John: The main reason we’ve kept animation locked down so far is that our tool for creating animations isn’t fit for human consumption (though we make Sorcus use it anyways). If we were to release it, you would try to use it, and it would make you incredibly angry. You would be blinded with rage, and then you would pound your computer so hard that it would break.

Another benefit of not having any user-created animations to support is that we can change our underlying format without breaking anyone’s code. Basically, animation is a beta feature right now. When we bring it up to version 1.0, we’ll let people play with it.

Nergmada: Merge Brick Option. The merge bricks option would allow you to create an awesome mesh like a person and then merge it into a single mesh/brick – allowing for reduced lag and for more than just your standard Part, Wedge Part and CornerWedge Part. Finally, dynamic lighting is crucial for any RPG you lose the feel of a game if you come out of a barren desert and into an underground bunker and it’s just as light inside as outside.

John: Our design philosophy is that ROBLOX should be: physically intuitive and highly scalable. Builders shouldn’t have to ever think about batching geometry to make it run faster. Instead, we are working on making all parts render ten times faster, which will address any need for a “merge brick” option.

Dynamic lighting is awesome, but if our goal was to build a great RPG in ROBLOX, I would probably start with better NPC/bot support and code management tools. Incidentally, my team does have the goal of building an RPG later this year.

mat852: Rotating Graphic User Interface objects along a 2D axis, 3D isn’t really necessary. Rotating GUI objects really makes a game look neat. With the increase of radars and mini maps, we really can’t have rotating images of a map, to get the direction and distinct location. Today, we have clip descendants, but mix that in a bowl with rotating 2D GUI objects and some milk, you have got a winning game my friend.

John: It seems to me that I would get soggy 2D GUI objects if I mixed them with milk. There’s a slippery slope here. ROBLOX is a 3D game development platform. We’re not a 2D game development platform – there are a lot of those out there already, and we don’t want to fall into the trap of trying to re-implement Flash in 3D. That being said, this does seem like a super handy function to have, and many people have asked for it. We should probably just do it.

While we continue to read each reply, we thank you for your patience and encourage you to send your feedback.  Our goal is to incorporate your ideas into ROBLOX.  Stay posted for more user feedback next week.