Every so often, we ask our users to let us know what they’d like to see in ROBLOX, then respond to some of the most insightful comments and pertinent questions. This time, John Shedletsky, ROBLOX’s Creative Director, talks about a variety of ROBLOX topics, including expanded terrain dimensions, enhancements to ROBLOX GUI creation, vehicle seat functions, server-based data persistence, script protection, group moderation and 13+ groups, dedicated image hosting and a feed for updates to items in the ROBLOX catalog. You can read previous entries in this ongoing series here.

Building

Unknown: Larger terrain maps. Currently, you can make terrain a maximum 526 by 526 voxels. I wish this would be expanded so I could make more with my friends! I also would like to see terrain strength, or the ability for it to withstand “X” damage before being destroyed (e.g., grass is 100 strong and cement is 500 strong).

In light of the radical performance improvements we’ve made with featherweight parts, the ROBLOX team has been rethinking the role of voxels in our system. Our current thinking is that voxels are great for making deformable terrain, but that they are ultimately disappointing when used to construct buildings and other models. This is because voxels are chunky (4x4x4) and don’t respect physics (they’re always anchored in space). We anticipate a future where we streamline our existing voxel system, focusing it entirely on use as terrain. This is the point at which we’d consider possibly paging terrain chunks in and out of memory to essentially create terrain that is unlimited in all directions.

Your suggestion with regards to material strength is also something that we’ve thought about for a long time – there’s actually a design doc I wrote a year ago that is a giant spreadsheet of 100 materials we want in ROBLOX, along with physical constants (like hardness and melting point) for each of them. Of course, if we were to add intrinsic material properties to our game, we’d do so for both our rigid body and voxel primitives.

Valanax: Upgrade your GUI system. When I use Text Boxes, my script clears the value, and then when the player clicks it again it goes back to what they had typed rather than being empty. I also wish there was an instant-update when people type in them, so I could have my script run a check on what they are typing (while they are typing) and validate it.

Visually, you are limited on the use of GUIs, I want to be able to flip them around and do effects like I can in CSS (gradient, border-radius). The border width doesn’t even work on GUIs; it’s either no border or a set-border.

While I absolutely agree that all the GUI features you mention are desirable, overhauling our GUI system to the point where it is as flexible as Flash or HTML/CSS is a huge project. The current GUI system is functional and users have managed to do some really great things with it. I think the whole team here would rather spend the next six months improving the networking (lag), graphics, and quality of building tools (you know, core game stuff) rather upgrade the GUI system significantly. We have limited engineering resources and building in 3D physics-based virtual environments is what gets us excited, not GUI systems.

That being said, you can still expect a constant stream of minor improvements to the GUI system. But a major overhaul isn’t in the cards at the moment.

Tenal: Custom fonts (or more fonts). I consider myself a great GUI creator, designing advanced art tactics such as gradients, bevels, etc. without images. However, I always fall short due to the lack of font selection. I use Arial Bold the most because I think of it as the prettiest font out of the three, but it really isn’t that great in certain cases.

To follow up on my response to the previous request, adding more fonts is an area where we’ll definitely be making improvements to the GUI system in the next six months.

Technical

Spectrial: Add “Misc” keys to vehicle seats, allowing for extra functions on cars. “Misc” keys would add an extra layer of complexity to vehicles, allowing you to turn on and off headlights and/or suspension with the touch of any “X” key.

Vehicles and vehicle controls (especially on iOS) are an area of the product that we want to radically improve in 2013. The specific issue you touch on is an important one – there needs to be a layer of indirection between the input device (be it a keyboard or touch interface) and the vehicle control system. It would be much preferable for scripts to be able to write: “When user does VEHICLE_MISC_ACTION_1 then turn on lights” as opposed to “When user presses ‘X’ then turn on lights” – because the latter will never work on touch interfaces whereas the former is easy to make work. This type of functionality would also enable users the freedom to specify their own key bindings – something most games allow.

RyanDolan123: Data persistence on servers. We should have the ability to have persistence through just servers. Instead of storing data in a player, you could store it in the cloud. It would have more uses than anyone can imagine. Examples: A live counter showing the total number of KOs/Wipeouts, the ability to display a message across all the game’s servers, and more!

I just had a very productive meeting about Data Persistence improvements with one of our web engineers, Navin Lal, earlier this week. We are targeting a rich feature set, including: allowing multiple places to read/write from the same data store, the ability to render a leaderboard with high scores for your game on the site, and the ability for place creators to browse/edit information saved in data stores (which will make development and debugging much nicer). Nothing has been finalized, but I have high hopes for Data Persistence in 2013.

Scripting

I have a comment and two thoughts about this. First, my comment is that at this point we’re pretty sure we’ve solved the issue of copy protection on scripts. When you join my online game, *none* of my server-side script code replicates to the client. That means no matter how good you are at reverse engineering and digging through the Roblox process memory, you will never find my code because it isn’t there. It’s unstealable. So for published games, your source code is safe.

If I understand correctly, however, you’re not talking about a published level. You’re talking about a published *script*. Of course, if you publish a script, it’s out there and anyone can take it and do whatever they want with it.

So my two thoughts about publishing are this:

First, it’s an important part of the ROBLOX ecosystem. Almost no one on ROBLOX is building everything they use from scratch. To use a buzzword from 2006, ROBLOX is all about “mash-ups” – taking previously published works, improving them, and re-releasing them. This is the main mechanism that allows ROBLOX levels to evolve over time. For example, almost every plane script in the ROBLOX catalog descends from Stealth Pilot’s original plane script that he published in 2007 (you can tell because they all use the same wacky control scheme). The original script was very basic. I’ve since seen versions where people have added stunts, and bombs, and hyperspace drive, and all this other stuff. It would be nice if more people gave Stealth Pilot credit, but most of them honestly don’t even know who the original creator of this script is. However, on the whole, it’s good for the game that this content gets free.

My second thought about publishing goes to your concerns about attribution and copyright. We can’t solve these problems technically. The music industry has tried and failed, and they have way more resources than we do. We would like to solve this problem, however, because then we could allow users to sell models – something that we think would be very exciting to many players. We have been kicking around the idea of a ROBLOX “copyright court” for years – basically a copy protection system run by players (as jury members) for the express purpose of determining if X is a copy of Y. This system would make it possible for users with a good reputation to sell models. If someone steals your model, sells it, and you “sue” them in copyright court, the system would award you royalties on those sales and the miscreant would lose reputation and would not be able to sell models for a while. This is obviously a very complicated system to get right, which is the reason why it doesn’t exist already.

Coolkingrobo: mechanical arms tools. Make more mechanical arms tools so your arms follow your mouse.hit position on the Z-axis. These features are already found on Blockland and Minecraft. Examples of these arms on tools are very hard to script but have been done on some places, such as Call of ROBLOXia 6.

You’re talking about improving our character animation. Rather than publishing tools to create this effect, we would rather make it the default across all of ROBLOX. That would be the most elegant solution.

Social

Leperdy: Group moderation. Let groups do all their own moderation, or let them choose a tolerance setting. That way, groups are free to do as they please. Or maybe some kind of 13+ group button that only lets older users in on groups. I think this would get older players back on ROBLOX, without putting the younger ones in any danger of seeing swear words or inappropriate topics.

One feature that has a lot of support among the Web Team is adding group forums to the site. We would allow groups to run and moderate their own forums. It’s possible that we would liberalize the global ROBLOX moderation standard for 13+ group forums. So yes, I think we’re thinking the same thing.

epiksoda11: ROBLOX should have its own image-hosting site. Moderators would be able to review images before they are published for all to see. This would be helpful to anyone making a high-quality image or logo for someone else’s group. I think that most people agree that they want to show others high-quality images or logos that are not the square images know as decals. Anyone would be able to send links to these uploaded photos on group walls, messages, forum, etc.

I agree. We need to overhaul image support for builders, all the way down to how you upload images to the site (it should be through ROBLOX Studio, not a webpage). The current system has remained untouched since the very early days of ROBLOX – it feels primitive because it is. Personally, the biggest issue for me is having control over the ultimate dimensions of the images I’m uploading – this would unlock all sorts of potential in Studio for creating nice splash screens, and custom GUI elements that aren’t fuzzy because they’ve been internally rescaled (as decals currently are).

As far as posting images to the forums and in private messages, we’d probably use the same interface for this as the rest of the web. Nothing to invent there.

Economy

horridian6: Catalog notifications. There should be a feed feature that works with your favorites and tells you whether an item’s price has changed, has gone off sale, etc. It’d really help limited collectors or people who favorite stuff to watch the price so they can save up for it.

Great idea. In general I think a “wish list” for items would be a useful feature to have. When items on your wish list are updated, we could send you updates like “Item X is now 30 R$, down from 60 R$ (50% off).” Wish lists would also make it easier to trade with other users, because if they had a wish list, you’d know what to offer them in a trade. We could even match up trading partners based on wish lists. If you have a lot of stuff someone else wants and they have a lot of stuff you want, it’s very likely that you’d be able to work out a good trade.