Over the past few weeks, we have shown the ROBLOX community various character explorations that include new head, body, arm and hand shapes for both male and female characters. We have a few examples of what these renderings would look like in ROBLOX. Check out the video of some new characters, and let us know what you think.

For previous examples, you can learn more in our first and second character exploration post.

Many scripts want to run little bits of code at frequent intervals. For example, a script might update the behavior of a zombie. It needs to update conditions repeatedly, like checking the location of the nearest player. 

Today, ROBLOX’s Chief Scientist, Erik Cassel, discusses proper use of the wait function.

The Problem

A very common way to do this in ROBLOX is with the handy “wait” statement. Here is an example:

There is one problem with this code. Can you see it? The wait function takes an optional argument, which is the time that the script should sleep. If you don’t supply an argument, then the function will typically return in 0.03 seconds. That means the script is looking for an enemy to attack 30 times a second! The findClosestEnemy function isn’t cheap. It probably needs to iterate over all the players and find the closest one. That might be fine if you have one zombie in your game, but what about a hoard of 50 zombies? Do you really want 50 zombies rethinking who they will attack 30 times a second? That amounts to 1,500 enemy updates per second.

This isn’t a contrived example. I’ve been analyzing laggy games. A large fraction of them are laggy because of scripts that suck up all the compute time.

The Solution

Let’s think about zombies for a minute. Zombies are stupid. Once a zombie finds an enemy, he is unlikely to change his mind and go after a new enemy for a while. Let’s make a tiny change to our script:

We supplied a reasonable wait time of five seconds. Once the zombie spots a player, it will go after him for five seconds before looking to see if anybody else is closer. Now our 50-zombie game does 10 updates per second, rather than 1,500.

I have found games that try to wait for 0.0000001 seconds. That means they try to run complex operations 10 million times per second. We may have fast computers these days, but not that fast! These kinds of games suffer from terrible lag.

If your game is laggy, check your script performance. In ROBLOX Studio, there is a great Script Performance panel. Look down the Activity column. It will tell you what percentage of your overall time that a script is taking up. Anything greater than 3% should set off alarm bells.

Better Resuming from a Wait

Another thing to keep in mind is that wait is not guaranteed to return in precisely the time interval you requested. Let’s say your game fills up with 1,000 zombies. Even our optimized scripts might take up a lot of time in aggregate. In that case, ROBLOX will decide that it can’t run all the scripts fast enough, and it will automatically wait longer than requested. We do this because ROBLOX needs to run other processes, like networking, physics and rendering. By “throttling” the script code, we can try to avoid lag.

Let’s write a script that gradually changes the time of day. If you put this script in a game you will see the sun gradually rising:
The script asks to wait for one quarter of a second. However, let’s say that your game is temporarily running out of CPU time. In that case ROBLOX will decide to make your script wait longer than 0.25 seconds, and the sun will rise slower! Here is the solution to the problem:

As stated in the documentation, the wait function returns the actual elapsed time. With that bit of information, we can adjust the time of day accordingly. If the elapsed time is longer than 0.25 seconds, then we’ll skip the time of day forward proportionally.

Conclusion

Lag is often preventable. I’ve found that many games are laggy because of runaway scripts that spend valuable compute time on unnecessarily frequent computation. If you use wait correctly, you’ll be on the way to lag-free game building.

At the conference, we plan on including various seminars, tech demos, as well as sharing the future of ROBLOX.  During the conference, you will have an opportunity to meet ROBLOX staff, and similar to last year, we will also be giving out ROBLOX awards.  Plus, there will be a Developer Lounge where you can build and hang out with other ROBLOX creators. Some of the tech demos that will be incorporated are topics such as improving ROBLOX physics, water and buoyancy, and ROBLOX Studio 2.0, which is an exclusive, first preview at the next generation content creation tool.  Another session that you won’t want to miss is David Baszucki’s vision of ROBLOX in 2020.

If you are a budding game developer and want to learn how to get a foothold into the video game industry, we will also host discussions with ROBLOX employees about how to whip your portfolio into shape, and how to have a competitive edge.

For more information on the ROBLOX Game Conference, visit the event information page. Several hotels are now offering special RGC room rates.  Be sure to register for the 2012 RGC here.

Getting Dressed Can Be Exciting

This week, we gave you a preview of our not-yet-released in-game wardrobe change feature. Without leaving ROBLOX, you’ll be able to swap hats, heads, faces, shirts, pants and more; we’ll even update your character thumbnail almost instantaneously with your new look. Check out the story and video demo for all the details.

User Feedback, Round Two

Want to know why some things in ROBLOX are the way they are? We’re continuing to comb through your responses to our April blog survey, Your ROBLOX Top-Three List, and providing answers. This time, Creative Director John Shedletsky responds to requests for local services (for sound, light, etc.), expanded Insert Service functionality, canned animations, physics tweaks and more.

This Week in ROBLOX Tech

Software Engineer Navin Lal went in-depth on ROBLOX’s website architecture, and its shift toward MVC (models, views and controllers) and pagelets. While MVC allows faster development and a higher quality web experience, our pagelet infrastructure – akin to Facebook’s BigPipe – will redefine the way ROBLOX serves up webpages and make our website faster and more responsive.

Still not satisfied? You can read an article about ROBLOX, including CFO Matt Finick’s insights into our platform and future direction, at Blistered Thumbs.

If you already follow us on Facebook or Twitter, you might know we reached a milestone this week with our 200,000th Facebook fan. To celebrate, we gave 10 fans 2,000 Robux. Winners: Enjoy your spoils of riches. Just don’t spend it all on one hat.

Of course, we offer more than just free money via Facebook and Twitter. Follow us on either network – or, better yet, both – to have exclusive content and interesting updates fed right to your device of choice. It doesn’t get any easier.

And now, for an abstract collage of deep thoughts, cryptic math and what appears to be a cluster of ROBLOX bricks (or a third of a Rubix cube), straight from the walls of the ROBLOX headquarters:

Can you glean any meaning from a ROBLOX whiteboard?

ROBLOX is working on a new feature that lets players change their character’s clothes and preview their appearance in-game. User Experience Engineer Ben Tkacheff is here today to demonstrate the interface he developed and offer some insider information on how he used ROBLOX’s tools to create it.

Part of the fun of ROBLOX is creating a persistent avatar and making it your own with the finest, most stylish ROBLOX attire. Traditionally, that customization happens on the ROBLOX website – outside the game engine – and requires you to enter a game to see whether the new look suits your fancy. Now, we’re polishing an interface that lets you change and preview your look in-game.

The in-game wardrobe change is a simple, intuitive feature. You’ll just press the tilde (~) key or click the backpack button at the bottom of the screen to open the menu, then click the wardrobe tab to start dragging hats, heads, faces, shirts, pants and more onto your character. You’ll be able to rotate your character so you can see how you look from every, important angle. Once you save your changes, we’ll automatically update your thumbnail image on the ROBLOX website.

Demo: In-game wardrobe change interface. We’ll be adding actual item icons for the official release.

We developed the feature using Lua, the same scripting language game creators use to write new gameplay and interfaces for their games. When approaching the design of the wardrobe interface, we wanted to ensure there were many ways for players to equip various wardrobe pieces to their character. For instance, drag and drop, right-click and left
double-click can all be used to adorn your character with an inventory item, giving all levels of users the best experience possible with the interface.

We also engineered the code as many small functions so we could re-use it for the various interaction methods; plus, it has the added advantage of better readability.

Game creators who don’t want players to change their appearance – for example, in a game where players have team colors or uniforms – can choose not to allow it. The rest of the time, we believe you’ll enjoy the convenience of changing your look on the fly.

At ROBLOX, we believe user experience is of the utmost importance. Today, ROBLOX Software Engineer, Navin Lal, tells us about how ROBLOX is building a faster, more responsive website with the help of MVC and a new pagelet architecture.

The ROBLOX website is built on top of Microsoft’s ASP.NET.  Originally a Web Site project built for ASP.NET 2.0, the site has undergone several upgrades since, most notably an upgrade from ASP.NET 2.0 to 4.0 and a conversion to a Web Application project.  Our next big upgrade will be to add support for ASP.NET MVC. As you may know, MVC is a software design pattern that separates an application into three roles: models, views, and controllers.

Here is a deeper look at MVC:

• Models encapsulate the core logic of the application, such as persisting state and performing actions to alter its state.
• Views make up the user interface.  They present model data and are the entry points for users to interact with the application.
• Controllers are responsible for processing user input and coordinating interactions between models and views.

MVC enforces a clean separation of concerns that makes it easy to develop, test, and maintain each role independently.

For some time, we have been using ASP.NET MVC to develop components apart from the main website. The original services built to support the iPhone app were built with MVC 2. Because it provides a flexible routing system that maps naturally to RESTful services, all of our core data and API services are developed on top of MVC 3.

We knew that we wanted to use MVC for the website, but there was a problem.  At over 3800 files (that’s excluding the majority of our data/business logic code, which are in separate assemblies), the website is big and migrating everything to MVC would be a monumental task.  Like everything we do at ROBLOX, we chose to take an iterative approach.  Since MVC and Web Forms are able to be run side by side in a single project, we decided to build new features in MVC and gradually migrate over older features as we update them.

MVC 3 will help us eliminate a lot of boilerplate code and will make unit testing easier since it has excellent support for dependency injection and inversion of control. This translates to faster development of features and a higher level of quality. The framework is designed to be completely extensible so we will be able to customize the site to our player’s exact needs.  Thus far, the only thing we have added is our own attribute routing system after being convinced by Kevin Montrose of Stack Exchange.

Migrating to an MVC site brings ROBLOX into the modern era of web development, but we’re planning on going beyond this and into cutting edge territory.  We’re building a pagelet infrastructure akin to Facebook’s BigPipe. If you’re unfamiliar with pagelets, the idea is to break up a single web page into small parts that can be served independently.

Here is an example of what this looks like.

Conceptually what is happening is that every red box now loads separately and in parallel. Before, the entire page was essentially one big red box – it loaded all at once in a sequential manner. Processing all the content in parallel should decrease page load time and increase website responsiveness.

The traditional model for serving web pages starts with the browser making a request to the web server. The web server will process the request, gather any necessary data from databases or services, take any actions, and then render the appropriate content before sending a response.  The browser will construct the DOM from the HTML, download and apply any CSS, and then download and execute any JavaScript synchronously.

In a pagelet model, the web server gathers only the bare minimum to serve the request, and then it renders back a page that is mostly static with scaffolding for the pagelets.  Each pagelet is then fetched in parallel.

Despite the cost of extra resources, parallelizing has obvious advantages for speed, and it also isolates each component so they don’t end up blocking one another.  For example, let’s say you have a page that needs to fetch data from several different data sources.  In a traditional model, if one of those sources is slow, the entire response will be blocked, and the whole page will load slowly.  With pagelets, only the components depending on the slow data source would be affected; everything else would load normally.  Pagelets allow for a fast initial page load with additional dynamic content loaded in as it becomes available.

To support pagelets, we’ve built a JavaScript loader capable of lazy-loading resources asynchronously.  This allows us to load and execute scripts at the exact moment they are needed instead of loading everything at the beginning. We’re also adding support for defining re-usable modules, which is loosely based on the Asynchronous Module Definition spec.  Modules have the ability to list their own dependencies and make dependency management for JavaScript files much easier, which is almost a prerequisite for loading scripts asynchronously.

The migration to MVC and pagelets brings ROBLOX to the forefront of web development. This has been a large technical investment for us, but it will pay off greatly in terms of developer productivity, site performance, and most importantly, user experience.

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.

Every week, we’re busy telling the stories behind our platform, our technology, and our place in the gaming and technology industries. For those of you who catch up with ROBLOX over the weekend, the Weekly ROBLOX Roundup collects the best stuff to hit our various avenues of publication in the last week.

ROBLOX Users Love Water

And what world builder or game designer wouldn’t? Early in the week, we took a deep look at our upcoming water simulation and buoyancy physics. Most of the feedback we received was positive, and it sounds like the ROBLOX community is collectively champing at the bit to implement water into their games. We also heard your reaction to the water texture – we’re working on it for the official release.

ROBLOX Users Love Talking About Character Models, Too

We know that when we ask you to discuss our “Version 3.0” ROBLOX character models, you’re going to discuss them. Passionately. Our latest survey was no different. We’re still collecting data from users, so it’s not too late to vote, and we expect to be able to draw some solid conclusions from your feedback.

Emergence and Its Place in ROBLOX

Whether solving physics puzzles in Half-Life 2 or creating your own narrative in Civilization, emergence lets you use a game’s systems in unique and even unexpected ways. This week, we showed how emergence manifests itself in three facets of ROBLOX: building, playing and the social space.

“Aging Up” Your ROBLOX Account

We launched a small feature – with a big impact – to our website this week. ROBLOX users can now change their date of birth or request their parent change it, in some circumstances.

As always, if you still need more words about ROBLOX, check out part one of a comprehensive feature MMOFallout.com is producing about ROBLOX, its community and its creative users. There’s some good, original research happening there.

Your interesting ROBLOX stories continued to pour in via our blog and Facebook page this week. Check out our article about emergence in ROBLOX, as it features some of the best responses.

We’ve also been sharing video reviews of ROBLOX games by Max Benedek. Follow us on Facebook and Twitter to stay in the loop on weekly reviews from Max, and find previous reviews of Bus Driver City, ROBLOX cart-riding games, and Trucking Tycoon.

Need convincing? Here’s his review of Trucking Tycoon:

We’re sharing other content you won’t find anywhere else, too, including videos of our technology, ROBLOX games and places from various eras that are worth playing, and open positions at ROBLOX. So follow along.

Depth of creativity

One of the beauties of ROBLOX is the creative freedom it gives users. Builders start out with a blank canvas and can build anything, from architectural displays to complex vehicle models to competitive, multi-player arenas. While the sophistication of a game or place depends on its creator’s abilities in both construction and scripting, ROBLOX offers users a free-form tool that lends itself to discovery, what-if scenarios and experimentation.

That experimentation emerged early in ROBLOX’s life, when users took advantage of our Lua scripting framework to create airplanes and, in turn, spark the ever-popular and evolving flight-combat genre on ROBLOX. It was emergence in a classic sense; users created totally new gameplay and content using nothing but our standard tool set.

While most builders start simpler than planes, a little persistence and learning open a lot of doors to emergence.

ROBLOX’s Personal Build Servers, too, encourage emergence by allowing up to 30 users to join a single server and collaborate on large-scale building projects. While users can build anything they imagine and even wire up interesting, unique contraptions using customizable triggers, levers and timers, it’s the player interaction occurring in the Personal Build Server that’s especially emergent. For example, ROBLOX users have created sprawling cities, complete with custom houses and towering, decorated buildings, where role-playing and socializing tend to take place during and after the construction.

Real freedom, simulated physics

According to Penny Sweetser, a game designer at 2K Australia and emergence researcher/author, emergent gameplay registers with players because it puts them center-stage. It gives them “the freedom to experiment, greater control over the game, a sense of agency, and less of a feeling of uncovering a path set for them by the designers.” ¹

While some ROBLOX games funnel players through a scripted experience or change ROBLOX into a closed-off, single-player experience, ROBLOX games are usually open spaces where users congregate and play within the game’s mechanics and ROBLOX’s systems – our so-called “magic circle”.

We’ve asked ROBLOX players for their interesting in-game experiences and, for the most part, they involve more than one person, open-world freedom and some aspect of our physics simulation. With a formula like that, emergent gameplay is almost inevitable. One ROBLOX user recounted this memory, in response to our recent call for interesting ROBLOX stories:

“Playing Heli-Wars: Desert Attack, a guest got in my jeep. I drove it half way to the other team’s base and jumped out, but the guest and jeep kept rolling into the base. The guest got out and started shooting, but was killed. The jeep came out of the other side of the base so I jumped in as it was moving and drove it back to my base.”

Another had a similar experience on the battlefield:

“I was in a war group; we were in a helicopter flying to a raider base and our boss said, “deploy parachutes but don’t jump!” When we arrived at the raider base he said, “Jump! Go go go!” We parachuted in but were outnumbered by the raiders and the helicopter was shot down. Our next plan was to get in a heavy jeep. It was white and had no windows except in the front. There was a door in the back, our boss was driving. When we arrived again there were only two raiders. We fought them and left for another fort.”

Then there’s ROBLOX user Lucariobeam, who recently played Natural Disaster Survival and “rode a falling building into the ocean, and somehow, miraculously, survived.”

These are bits of the greater narrative a ROBLOX game can tell, driven almost entirely by the player’s freedom and ROBLOX’s flexible engine.

“I just love how ROBLOX’s physics engine can create different scenarios … It makes the game so much more interesting, not to mention addicting,” said ROBLOX user navysealsnake.

Emergence in ROBLOX’s web services

Many massively multiplayer games have virtual economies and social systems that allow players to purchase and sell items using an in-game currency. ROBLOX’s virtual economy, for example, allows users to earn and spend Tickets and ROBUX.

As noted by Sweetser, “virtual economies are emergent systems that change dynamically with supply and demand, based on the trading patterns of the world’s inhabitants.” ¹ This is what we’ve seen in ROBLOX’s virtual economy with limited-quantity items. ROBLOX users who are vigilant of newly released gear (or just lucky) can snatch up rare items and sell them for a profit to users who didn’t get them during the original sale. There’s only so many to go around, so users can charge a premium. It’s supply and demand at work.

Since ROBLOX uses its website as a distribution channel for users’ games, we’ve even seen emergence in game promotion. Cunning users have learned to market their content not only through effective game design, but also competition: being the most responsive to user feedback, persuasive in use of text descriptions and screenshots, and successful with on-site advertisements.

Emergence manifests itself in all the major facets of ROBLOX, from creation, to sharing and gameplay, to the economy and community running behind the scenes. From a gameplay perspective, it’s not guaranteed, since our users are capable of creating scripted, linear experiences. But there’s no denying that, from front to back, ROBLOX encourages discovery, experimentation, freedom and, with all that said, emergence.

There’s plenty of room to dig deeper, so stay tuned to our blog for detailed explorations of emergence in ROBLOX.

1. Sweetser, Penny. Emergence in Games. Charles River Media, 2008. Web book.

If you haven’t already set your date of birth on your ROBLOX account, we encourage you to do so now. Here’s how it works.

Set Age/Date of Birth

To set your date of birth, simply log into your ROBLOX account and use the interface, shown above, on the Account page. There are some special requirements, however, when you set your age under 13 or “age up” to 13+.

Change Age (Under 13)

ROBLOX users who are under 13 must have their parent(s) change their date of birth. This requires that a parent’s email address be filed on their account so the parent can verify the change. Privacy Mode will be enabled on the account until disabled by a parent.

Users who have not provided their parent’s email address can enter it, along with their account password, when prompted on the Account page.

“Age Up” to 13+

Existing ROBLOX users who have turned 13 since joining ROBLOX can ask their parents to “age up” their accounts and enable the Free Text Experience, which allows users to chat, send private messages, participate in the forums and post comments. They can then select their chat, party, follow and private message preferences on the Account page.

Users who have not provided their parent’s email address can enter it, along with their account password, when prompted on the Account page.

ROBLOX takes the safety of our users seriously and is in compliance with COPPA. More information regarding ROBLOX’s Privacy Mode can be found here.