Amazon GameDev Blog

Join the Amazon Lumberyard team during Gamescom 2016 and CEDEC 2016, where we’ll showcase our engine and you’ll have an opportunity to meet our developers!

gamescom 2016
Cologne, Germany
Wednesday, August 17th — Friday, August 19th

Gamescom, a must-attend trade fair for games and entertainment, will be held at Cologne’s Koelnmess exhibition center.  You can find the Lumberyard team at the business hall (hall 02.2) at booth D-017:

Wednesday, August 17th: 9:00 AM – 7:00 PM CEST
Thursday, August 18th: 9:00 AM – 8:00 PM CEST
Friday, August 19th: 9:00 AM – 8:00 PM CEST

We’ll be providing Lumberyard content workflow and editor overview demos, and will have a meeting space for business inquiries.  We’re excited to meet potential customers wanting to make great games using the power of the AWS cloud and Twitch! For more information on Gamescom 2016 and everything that will be shown there, please visit the official site.

CEDEC 2016
Yokohama, Japan
Wednesday, August 24th — Friday, August 26h

The Computer Entertainment Developers Conference (CEDEC), will be held at the Pacifico Yokohama convention center, also known as the Pacific Convention Plaza Yokohama. You can find us in the expo area next to the Amazon Web Services booth, where we’ll be showcasing our VR technology and editor demos. Our Business Development teams will be on hand to field customer questions. Read more about CEDEC 2016 here.

For Lumberyard business inquiries, please give us your contact information here. Follow @AmazonGameDev on Twitter for updates on our presence at both gamescom and CEDEC. We hope to meet you there!

We are excited to announce the release of Lumberyard Beta 1.4, which you can now download here. Lumberyard Beta 1.4 contains over 230 improvements, fixes, and new features.

With each release of Lumberyard we get closer to our vision of an ideal game engine – a collection of tools and services, deeply integrated with the AWS Cloud and Twitch, which enable the creation of the highest quality, community-driven games.  We want to enable designers and developers to spend more time creating games and connecting with fans, and less time thinking about the tools they use.

Beta 1.4 focuses on two areas: First, you’ll find new improvements to help you build more cost-effective multiplayer games – we help you make more efficient use of cloud resources than was previously possible, and take more control over your network traffic. Second, we’ve focused on continuing to reduce your team’s iteration times, so you can build high-quality gameplay with faster workflows.

Build More Cost-Efficient Multiplayer Games

Amazon GameLift now allows you to run more than one instance of your game’s server code, or one or more instances of multiple game servers, on a single EC2 instance. This flexibility lets you optimize cost and performance when deciding how to structure your multiplayer game’s servers. So if you’re building a game that doesn’t require much computational horsepower, like a Kart Racer, you might be able to run ten instances of your game server on one machine, potentially saving you 90% of the cost.

The design and structure of network data is a key consideration when building a multiplayer game. The size of the data and the frequency with which it is sent has a direct impact on the game’s scalability – more data sent more often means a game server’s capacity will decrease, thereby hosting fewer clients. Some games, especially large community games like e-sports titles, may also require you to encrypt sensitive data so that it can be sent securely.

To this end, we’ve added native encryption support (OpenSSL) and a network traffic profiler that enables you to measure the amount of CPU time and replica bandwidth your game’s network layer is using.

These features let you quickly see the impact of your changes, so you can balance performance and security while staying within the processing time and bandwidth limits allotted to your game’s network layer. For example, using encrypted data can increase bandwidth and CPU usage, so being able to measure the result of such decisions is an important element of data design for games.

The Network traffic profiler

Reduced Iteration Times

To speed iteration times, we’ve added an in-Editor Lua editor and debugger and a new scripting API.  If you’ve ever watched a game designer at work, you’ve seen that putting the “fun” into a feature is oftentimes a razor-edged balance of tweaking values – whether they’re timing a combat animation, tuning the amount of force on a springboard, or adjusting the height of an obstacle. Designers enter an almost Zen-like state of interaction with the editor – “the zone,” if you will – whereby they change values and examine the result, then iterate until the feature feels right. Every time the designer has to stop and wait, or switch to another application to make a change, it takes them out of the zone.

So how do we keep designers in the zone? We “hot load” both assets and code so that changes are reflected automatically and immediately with zero interaction required on the part of the designer. Our tools work together with a consistent interaction model, so that designers don’t have to think about how to use a given tool.

Lua can bind to C++ functions at a much higher than environments such as C#, meaning it is lighter-weight and thus more performant. Lua provides what we believe is a great balance of functionality and performance for a scripting system, whether you’re building a mini-game or a AAA extravaganza. Lua scripts no longer require you to switch to an external editor – you can edit them directly within Lumberyard. You can also debug Lua scripts during live gameplay. The ability to edit and debug scripts within the Lumberyard Editor lets game developers focus on designing without the distraction of switching between different applications.

Lumberyard’s Lua editor and Debugger

We’ve also provided a new API that lets designers and animators control an animated character’s Mannequin controller using Lua, making it possible for a developer to write complex animation behaviors that would previously have required an experienced C++ developer. We also streamlined the character animation pipeline, so your animators can do more in fewer steps. We added the ability to hot-load SKIN files, meaning that if you change a SKIN file on disk, the changes will be automatically reloaded into Lumberyard. To define how much of an improvement this is, we measured it. This used to be a four-step process that—depending on the speed of the machine—took roughly 40 seconds; we timed it ourselves to get a good idea of how much effort is saved.

You can also now add physics proxy rules when importing a character model from an FBX file, which saves time by eliminating the need to create and import a collision mesh using external tools. The streamlining of features related to character animation greatly reduces iteration time on what can be a long and arduous set of tasks.

I’ve called out a few of the features in our latest release, but we’ve made many other improvements as well. I encourage you to read the release notes for a comprehensive list of features and improvements. I also want to reiterate that the Lumberyard team always welcomes your feedback and suggestions —visit us on our forums, in our blog comment threads, or email us at lumberyard-feedback@amazon.com.

You can download Lumberyard Beta 1.4 here. For full details on the Lumberyard Beta 1.4 release, check out the full release notes here.

About the Author

Todd Gilbertsen has been building game engines, video games, and other software professionally since the late 1980’s. He is passionate about creating intuitive tools and technologies that enable game developers to focus on being creative. Todd is a Senior Technical Product Manager on Lumberyard.

As part of the Lumberyard team I’ve recently had the unique opportunity to partner with Girls Who Code, a non-profit organization that focuses on the importance of inspiring, educating, and equipping young women for futures in computer-related fields. But, like most things, it didn’t start out so simply.

Let me tell you my story.

I wasn’t planning to enter the tech field. I didn’t go to a traditional college, own a computer, or receive mentoring. I was a fine artist working for a company that needed a website. It was difficult, but I muscled through learning HTML and CSS to produce a bare minimum website with a few images and text. Impressive, right? After that job, learning to employ a bias for action and ownership over art and code challenges led me to where I am today – a 30-something Senior User Experience Designer working for Amazon’s Lumberyard team.

When I walked through the doors of the Lumberyard team in 2014, I noticed that I was the only woman in the room. Women make up 29.1% of the tech industry, but only 16.6% of technical jobs. Women make up 22% of game developers. Where are all the women? The issue goes back to before we step through workplace doors. The majority of U.S. K-12 schools do not offer a Computer Science curriculum. “Too often girls don’t pursue computer science because they’ve never been exposed to it, or they don’t see the impact it can make on the world,” said Girls Who Code Founder and CEO, Reshma Saujani. “By actually embedding classrooms in today’s leading companies that create products girls use every day, we show them, ‘Look, you can do this. You can code this. This is a world that is open to you, and once you learn this skill set, the possibilities are endless.’”

How does Girls Who Code do it? They began a 7-week summer immersion computer science program that embeds classrooms in major media and tech companies and universities. Students learn the fundamentals of computer science, and in week three the girls learn Video Game Programming.

This is where we come in; we invited 20 high school girls ranging from sophomore to seniors to a dedicated Lumberyard segment so they could learn what is possible with our engine.

Lumberyard offers a visual scripting interface called Flow Graph that helps developers string together game logic through signals, inputs, and outputs, and uses nodes and connectors, without needing to know C++ or a more formal scripting language, like Lua. Lumberyard’s Flow Graph is even connected to AWS, so you can build connected gameplay without much backend experience.

We asked the girls to use Flow Graph to create marble maze game. Led by Chris Corliss—one of our Software Development Engineers—they learned Flow Graph, designed a maze, pieced together art assets, and wrote the core game logic to create a game level.

For some of the girls, this was the first game they ever worked on. I could feel the excitement in the room as they learned about Lumberyard and used it to create fun gameplay. They broke down the logic of the inputs and variables by talking with teammates and asking questions to our team of Lumberyard helpers. They gasped as their marbles flew off the edges of the maze board due to a rotation speed setting being tuned too high, but they quickly figured out how to adjust it. It was inspiring to watch the girls learn our visual scripting interface and how to problem solve the game design in real-time, right in the Lumberyard Editor. “It was a little hard getting used to where everything was, but once it got familiar it was really fun to use, it makes sense,” said Zoe Alise, one of the eager girls.

Once the girls successfully seized control of their marble board, they tried adding different materials to the game pieces. They used the selection and move modes to customize the board and express their personalities. One team used the board pieces to spell out their name. Another team laughed hysterically because they made the marble so big that it crushed the entire board. Soon all the girls were laughing with each other and sharing what they created. In just a couple of hours, I think they discovered why game development is such a blast, and how great editor tools can help developers iterate fast, and surprise and delight each other.

A favorite moment for us was when our engineer Chris told the girls that the Lumberyard segment was over and it was time to start a new activity; there was a collective, “Awww!”. They wanted to keep playing with Lumberyard! We reassured them that they could keep playing by downloading Lumberyard for free at home, and diving right into our Getting Started material.

The girls weren’t the only ones to walk away learning something new. “The girls helped us track down a few hard-to-find bugs in one of our newer systems,” said Engineer Eric Borts. “We thus welcomed them warmly into the Lumberyard team!”

I walked away from the day feeling fulfilled and overjoyed that I had been a part of this experience. If I had this opportunity growing up, I may have had more time to explore the work I love earlier on and better understand my school and career options. I realized the best development for curious girls comes from opening their minds and letting them be creative and explore technology. The best development for our children comes from opening their minds, trying new things, and playing a few games. The possibilities ARE endless.

About the Author

Courtney Artuso has been working on User Centered Design since the early 2000’s. She has been with Amazon for over 2 years as the lead Senior User Experience Designer for Amazon Lumberyard Engine and Amazon GameLift.

Join Lumberyard at the Anaheim Convention Center in California for SIGGRAPH 2016;  five days full of events, computer graphics, interactive techniques, demos, screenings, and hands-on sessions with various building tools!

Visit us at Booth #655, found on the Expo Hall – Hall D, during the following times:

• Tuesday July 26th – 9:30 AM to 6:00 PM PDT

• Wednesday July 27th – 9:30 AM to 6:00 PM PDT

• Thursday July 28th – 9:30 AM to 3:30 PM PDT

We’ll be featuring VR and HDR demos as well as interactive in-engine building experiences. Additionally, the Lumberyard team will be there to answer your questions about the event, Lumberyard, and your own game-building adventures. Amazon recruiters will be present at the booth – more than willing to answer your questions about our team, product, and company. If you can’t make it to Anaheim for SIGGRAPH 2016, we’ll be streaming a series of interviews and a demo session with Lumberyard developers on our Twitch Channel. Be sure not to miss our live streams:

• Tuesday July 26th – 2:00 PM PDT – Hao Chen and David Chiapperino will discuss graphics, VR, HDR, animation, and the current state of these technologies in the games industry.

• Wednesday July 27th – 2:00 PM PDT – Eric Schenk and Patrick Wyatt will talk about building multiplayer games, GameLift, and the various disciplines that go into game development. For those who can’t make it to the event, we’ll also be streaming the demos available on our booth.

Follow @AmazonGameDev on Twitter for updates surrounding the event. We’ll see you there!

One of the ways Lumberyard is deeply integrated with AWS is through Cloud Canvas, a set of tools designed to help your engineers and technical designers—even with little to no backend experience—build online game features. Last month, we released Lumberyard Beta 1.3, which includes a new tool for Cloud Canvas – the Cloud Canvas Resource Manager. The Resource Manager, which relies on the AWS CloudFormation service, is an in-editor interface that makes it easier for you to manage and configure the cloud resources that implement connected game features such as player statistics, high scores, and real-time events. In this post, we’ll explore why we built the Cloud Canvas Resource Manager and how you can use it to deploy and manage AWS resources for your game.

The main Resource Manager window

Why did we build it?

Game development is an inherently local activity. You have a local copy of game code, assets, etc. You build, you test, and you tweak… over and over on a local computer, or console.

Because it’s an external environment, working in the cloud is different. The resources your game depends on no longer live on your computer. The process of using and modifying these resources in the cloud isn’t the same as for local elements. Cloud Canvas Resource Manager bridges this gap. It lets you have local descriptions of the AWS resources (for example a database table, an S3 file storage bucket, or code that executes in response to an event) your game needs to exist in the cloud and provides ways to create and interact with actual instances of those resources.

For projects where many users are implementing changes frequently, the Resource Manager helps you deal with that additional complexity. In this case, the source code and assets you’re using likely come from a source control system. With the Resource Manager, the changes you make are shared with other people working on the project through that system. Different people on your team can even be working with different branches of the code and assets at the same time, without interfering with each other.

Once the game is launched, you’ll need another copy of the required resources for your players to use while your team works on bug fixes and new content. You want to be sure that players cannot access the development versions of the resources. You want to protect your players’ information—such as account data—from unauthorized access, while also preventing your development team from accidentally making changes that would break the released game.

The Cloud Canvas Resource Manager provides the tools you need to maintain descriptions of the AWS resources that your game depends on; and creates as many copies of those resources as needed for your development teams and releases, while also helping you secure access to those resources.

How did we build it?

Cloud Canvas Resource Manager is built on AWS CloudFormation, which allows you to maintain a description of the AWS resources you need in a text file that can be checked into your source control system. These descriptions can be branched and merged along with the rest of the game code and assets. When actual instances of the resources are needed, the descriptions are passed to AWS CloudFormation and it goes about creating, updating, or deleting AWS resources so that they match the descriptions.

The description files are stored in your game project’s AWS subdirectory. Resource Manager lets you organize the descriptions into any number of “resource groups.” Each group can describe all the resources needed by a game feature, such as a high score tracking system. These groups are known as Resource Definitions.

Resource Manager lets you create as many “deployments” of the resources as you need. You could have a deployment for the dev team, another for the QA team, and another for the released game; or any other arrangement that matches your development and release processes. Each deployment contains a complete and independent instance of all the resources defined by all the project’s resource groups. Deployments are implemented using CloudFormation “stack” resources which contain a nested stack resource for each of the resource groups.

You can choose your active deployment in the Lumberyard Editor. When testing the game, the Editor will use the active deployment you selected to map references to resources in game code and Flow Graphs to the instance of that resource for the deployment you select. You can also specify what deployment is used for release builds of the game. More on that here.

Each deployment comes with an AWS Managed Policy and an AWS Role that can be used to grant access to that deployment to selected AWS Users and Groups. The player is granted access to specific resources within a deployment. Details can be found here.

The Cloud Canvas Resource Manager’s use of AWS CloudFormation is an interesting case study for anyone who needs to add similar functionality to their (game and non-game) applications. Resource Manager makes use of CloudFormation features such as custom resources implemented using AWS Lambda and demonstrates how AWS Identity and Access Management (IAM) can be used with CloudFormation to secure your AWS resources. All the source code for the Resource Manager is included in the Lumberyard download. Most of it is implemented in Python using the Boto3 AWS SDK. It can be used from the command line and from inside the Lumberyard Editor.

See For Yourself

You can see the Resource Manager in action using the “Don’t Die” level of the sample project that comes with Lumberyard. “Don’t Die” uses AWS to store player high scores, and your AWS account must be prepared for that before the example is fully functional. For more info on configuring your AWS account for Cloud Canvas in Lumberyard, check out our tutorial.  Your AWS usage running the “Don’t Die” sample should be well within the free tier.

We’ll be providing a lot more examples, and more ways to leverage AWS, as we continue our work on Lumberyard Cloud Canvas.

About the Author

Mike Deem has been building distributed systems since the early 1990s. He has been at Amazon for over six years, where he built scalable and reliable backend systems for the catalog and Kindle teams. He now applies that experience and his long time passion for online virtual environments to the Lumberyard project where he is the lead engineer on the Cloud Canvas team.

One of the perks of building a multiplayer game in Lumberyard is using Amazon GameLift to manage the backend. Amazon GameLift is our managed service for deploying, operating, and scaling session-based multiplayer game servers in the cloud. Teams making multiplayer games must have a backend strong enough to handle sudden player population spikes, and GameLift takes the work and uncertainty out of building and managing those systems.

As a GameLift engineer working with our internal development teams at Amazon Game Studios (AGS), I’m all about automation. I want every commit to produce a new build, pass a set of automated tests, and be staged for QA testing, all without manual intervention. I also want this level of automation extended to cover backend game servers, particularly for AGS multiplayer games being hosted on GameLift.

While Amazon GameLift does make it easy for developers to host their servers in the cloud, the task of deploying a new build of a game requires several manual steps. I wanted to fully automate the build update process by extending the AGS continuous build system to include deployment of updated server code into Amazon GameLift.

This post walks through my approach to automating Amazon GameLift deployments and includes a Python script that you can plug directly into your build system to do the same. By following these steps, GameLift users can create new server stacks in about 30 minutes.

Approaching Automation

We’ll start by recapping the Amazon GameLift deployment model, which involves three key resources:

• Build: The bits representing everything needed to run the game server.
• Fleet: A set of EC2 instances running a particular build.
• Alias: A friendly name for a fleet, which clients use to connect to the fleet. While build and fleet IDs change with each deployment, the alias ID that clients connect to remains static. For example, a client might be coded to always connect to the fleet with the alias “latest-mainline-build.”

The tasks of deploying new game builds and deploying build updates involve a similar set of steps:

1. Upload the latest game server build to Amazon GameLift.
2. Create a new fleet from that build and configure it.
3. Create a new alias or update an existing alias to point to the new fleet.
4. (build updates only) Terminate the fleet hosting the previous build, so we’re not accumulating unused resources.

AWS CloudFormation allows you to manage sets of AWS resources (including Amazon GameLift resources) together as single logical unit referred to as a stack. A stack is instantiated from a template, which is a JSON document describing a set of AWS resources. In my approach, the three Amazon GameLift resources (build, fleet, and alias) compose a logical stack, and we’ll leverage CloudFormation to create and update these stacks for us.

To simplify the process, I created a small Python command-line script that uploads the build to GameLift, then executes a Create Stack or Update Stack command in CloudFormation. CloudFormation automates all the steps required by GameLift to deploy a new game build or update. Specifically, it creates a new fleet with our newly uploaded build, configures the new fleet, and either creates a new alias or updates an existing alias that points to the new fleet. For build updates, it also scales down and terminates the old fleet. Since the update command is repeatable and cleans up old resources, it’s perfect for plugging into automated processes like a continuous build system.

The Python command-line script works in conjunction with a locally available CloudFormation template. The template defines all the properties of a fleet that generally don’t change between updates, such as launch parameters and port settings. CloudFormation uses this template when configuring a new fleet. Following the DevOps spirit of “infrastructure as code,” wherein all infrastructure is created and configured via repeatable automated processes, I suggest checking these templates into source control so you can track and review changes as needed over time.

A nice side effect of leveraging CloudFormation for updates is that it gives you an audit log of all updates made to a stack over time (shown below). You can view your current stacks in the CloudFormation section of the AWS Console.

Script Walkthrough

The Python script interacts with the AWS CLI, automating the same commands you would normally type manually, making it easy to follow along. Use the same script to either create a new stack or update an existing stack, providing parameters at the command line. The full set of options can be viewed by passing the --help option, as shown below.

> python manage-gamelift-stack.py --help

Create new or update existing Amazon GameLift stacks via AWS CloudFormation

optional arguments:
-h, --help show this help message and exit
--action {create,update}
Choose to create a new stack or update an existing one
--stack-name STACK_NAME
Name of the CloudFormation stack to create or update.
(Must contain only letters, numbers, dashes and start
with an alpha character)
--build-root BUILD_ROOT
Directory containing everything required to run your
game server per the Amazon GameLift upload-build command
--build-name BUILD_NAME
Friendly name for build
--build-version BUILD_VERSION
(Optional) Friendly version string for build
--alias-name ALIAS_NAME
Friendly name for alias
--from-template FROM_TEMPLATE
File containing a CloudFormation template defining a
stack of Amazon GameLift resources

Deploy a New Game Build

To start off, we’ll create a new stack and give it the friendly name “QA-Stack”. The process of creating a new stack will create a new GameLift alias, which our game clients will use to connect to the new fleet.

python manage-gamelift-stack.py –-action create –-stack-name “QA-Stack” –-alias-name “QA-Alias” –-build-root “./dev/Project_Dedicated” –-build-name “mainline@12456” –-from-template “./gamelift-sample-template.json”

Creating a new stack can take up to 30 minutes to run, as it is also uploading a build to GameLift and setting up a new fleet and alias. Once finished, the script will output the ID of the newly created alias (see example output below). This alias ID is what game clients must use when connecting to the fleet. As the software in the stack is updated, the underlying build and fleet IDs will change, but the alias ID will remain static.

Stack creation completed with newly created alias id: alias-0dbc24ac-2e24-4dad-91e1-0341e594fdd7

Deploy a Game Build Update

Now that we have a stack up and running, let’s examine how to update its software. We’ll leverage the same script, this time using the update action and the name of the stack we created earlier (“QA-Stack”). Specify the path to the updated build files and a new build name, as well as the CloudFormation template, to use with this deployment. Notice we don’t specify an alias name when updating, as the alias name and ID won’t change as part of the update. While GameLift does allow multiple builds to have the same name and version (the system will assign a unique build ID), I suggest tagging the build name or version with a unique identifier tying it back to your source control or build systems to aid in debugging.

python manage-gamelift-stack.py –-action update –-stack-name “QA-Stack” –-build-root “./dev/Project_Dedicated” –-build-name “mainline@98765” –-from-template “./gamelift-sample-template.json”

The update command doesn’t create a new alias, but it does clean up by terminating the previous fleet. You can expect the update process to take the same amount of time as creating a new stack. The final line output to the console will reflect this.

Stack update and clean up complete

Download Automation Components

Use these resources to create your own automation solution:

• Python script: This script requires that the AWS CLI be installed on your path. Python, which is also required, is included in the AWS CLI install.

Download this Python script

• CloudFormation template: Use this sample template (.json file) to create a template for your game build. If you have multiple game builds requiring more than one fleet configuration, simply copy and adjust the template for each required variation. The sample template has the correct properties filled out for the multiplayer sample project that ships with Lumberyard.

Download this sample template

Recap

With the provided Python script and leveraging CloudFormation stacks under the covers, we’ve effectively automated the process of deploying new builds to Amazon GameLift in half an hour. This process begins in one step, either manually from the command line or plugged directly into an automated build system. We’ve also reduced the risk of manual mistakes by defining our infrastructure configuration in source-controlled templates.

For more information on GameLift, watch our presentation from GDC 2016. In this talk, Chris Byskal and I explain how GameLift can help multiplayer games scale their server loads to respond to sudden changes in player populations.

Geoff Pare is a principal engineer on the Lumberyard team and has spent the last 10 years at Amazon building and operating distributed systems. He specializes in infrastructure management at scale, and GameLift combines his love of gaming with cloud computing. He’s currently playing Offworld Trading Company.

In his post, Hao Chen covered HDR, VR, and other graphics improvements in Lumberyard Beta 1.3, available for download here. I wanted to tell you a bit more about some of the other 130 improvements, fixes, and features this update includes.

Our character team has updated the FBX Importer with the ability to import multiple objects to a single mesh, so you can import a complex scene all at once. We’ve also introduced a new interface that displays the hierarchy of an FBX file, and allows you to toggle the importation of individual meshes. If, for example, you have a single FBX file with a helmet, sword, and shield in it, and you just want the sword, you can simply uncheck the helmet and shield without going back to your 3D content tool. We’ve added support for vertex colors and the option to use any transform object in a scene as the focus for a translation or rotation offset. We’ve listened to your usability UX suggestions and have made it easier to select nodes and improved messaging on progress reporting. Animators will notice that Lumberyard now supports full live reloading of CAF animations in Geppetto, which allows you to instantly view your animations from the Lumberyard Editor and while running your game from the Editor.

For 2D and UI artists, Lumberyard Beta 1.3 includes over a dozen improvements to the Lumberyard UI Editor. We’ve added new Flow Graph nodes so you can enable or disable a UI canvas: you could, for example, load a canvas but not display it to the user for faster switching between menus. We’ve made it easier to edit UI canvases with many elements, including support for pivoting, offsetting, and anchoring multiple elements all at once. We’ve added more presets to the anchor and pivot widgets for faster iteration, allowed new objects to be created on the exact position you click the mouse button, and added functionality to enable you to paste objects as siblings and children, so you can create more complex menu functionality more efficiently than before.

In addition to giving you tools to better create impressive artistry, the Lumberyard team strives to help you build online, multiplayer, and live games so you can better reach a vast audience of fans. For the developers on your team building connected experiences, the Cloud Canvas Resource Manager is now generally available in Lumberyard Beta 1.3. With the Cloud Canvas Resource Manager, your project managers, engineers, and technical designers now have new tools to create and manage AWS resources for your connected game. You can manage AWS building blocks, such as DynamoDB databases and EC2 compute-on-demand, without leaving the Lumberyard Editor, enabling you to iterate faster on connected gameplay.

The Cloud Canvas Resource Manager GUI configures independent AWS deployments to support the needs of multiple development and test teams. For example, you could have one deployment your QA team is using, one for your internal development team, and another for a beta test. AWS resources are secured to prevent unauthorized player access, as well as to prevent accidental changes to production resources by members of your own team.

Our team always welcomes your feedback and suggestions. Visit us on our forums, in our blog comment threads, or email us at lumberyard-feedback@amazon.com.

You can download Lumberyard Beta 1.3 here. For full details on the Lumberyard Beta 1.3 release, check out the full release notes here.

As a graphics programmer, the most satisfying part of my job is to put a piece of cool technology in the hands of content creators and see them make magic with it. Throughout my career, I have had the fortune to work with some of the most talented artists in the industry, and they always surpass my wildest imagination. From time to time, I had to ask myself: Is this really coming out of our engine? Our tech did that? That’s amazing! This is one of the biggest motivators for us to keep innovating.

Today, we are excited to announce the release of Lumberyard Beta 1.3, available for immediate download here. This update includes over 130 improvements, fixes, and features, and is the first significant update on graphics tech since we launched in February. There are big features we added that I’m super excited about, but this is just one installment of what will be a constant stream of graphical innovations in Lumberyard. I can’t wait to see what you can do with them. Make us something amazing!

The first thing I want to highlight is HDR. I have been a long-time advocate for doing lighting and material in HDR space, starting with Halo 3. (I talked about this in my Siggraph talk in 2008.)  Ultimately, all those beautifully preserved HDR pixels get crushed by the terrible consumer TVs we have. How do you make the sun look real when your TV is only capable of pushing out 100 nits? When they showed us these Frankenstein sets of prototype HDR TVs at Siggraph about 10 years ago, everybody went nuts. Then we waited, and waited, and finally, this year, HDR TVs hit the shelves, for real. We immediately jumped on enabling HDR in Lumberyard.

There are two flavors of HDR: HDR 10 and Dolby Vision. Both use the same EOTF curve, called PQ, which is closer to human perception and is way better at utilizing the bit precision for brighter TVs. HDR 10 is going to be supported in most console hardware and Windows, so from an engine perspective, it’s about doing all of the math in the right space and authoring content for HDR, which Lumberyard excels at already. With Dolby Vision, we have additional ability to pass per-frame meta-data to the TV, and allow the display to adapt to your scene smartly. We don’t know which technology will be favored by consumers yet, but it doesn’t matter because Lumberyard supports both.

With Lumberyard, we make it easy for you to enable HDR. You just have to turn on a couple flags in the configuration file. No code or shaders need to change on your side. Knowing that an art director will want to have tight control over how a game looks, we have exposed all of the tweakable parameters in the debug console so they can be adjusted as you play the game live. We also exposed a target for an HDR reference monitor, like the excellent Dolby Maui, for art directors and color grading artists to see an accurate rendering of the scene on a calibrated setup. We recommend that you author all of your content in HDR with a reference monitor, and cross-check how they look on a number of consumer TVs, both HDR and LDR. One thing you want to be aware of is that some of the LDR tricks, like filmic tone mapping and bloom, don’t quite make sense anymore, as they try to simulate HDR on LDR TVs. You will need to experiment on your end to see if you want to preserve any of those operators, or just get rid of them entirely.

The second feature I want to highlight is VR. We showed a preview of Lumberyard VR at GDC and a couple of VR demos. After GDC, we concentrated on bringing you the cleanest possible way of integrating VR into Lumberyard. We want you to be able to plug in a headset, enable a couple of check boxes, make a scene in the Lumberyard Editor, hit a button, and be in your own virtual world. I think with Beta 1.3, we delivered exactly that. Oculus and Vive are supported right out of the box, and we provided a framework to support other and future devices, or even a new device you’re building yourself. You can find further details in Cody White’s blog. VR is one of the areas that we are investing in heavily, and you will see more supported devices, many more features, and more performance optimizations in upcoming releases.

In addition to these big features, with each release we continue to improve the quality and performance of the existing feature set and add a few new “graphics goodies.” Here are a few callouts in this release:

• Volumetric Fog: We increased the temporal stability of volumetric fog, reduced the presence of flickering artifacts, and improved fog’s overall performance.
• Motion Blur: To give a higher degree of control over the motion blur effect, we added a weighting algorithm to improve the visual quality of silhouettes and added a shutter speed control like those you find in a real-world camera.
• Height Mapped Ambient Occlusion: This new feature generates ambient occlusion per pixel from a terrain height map, which brings out subtle details and depth cues in terrain that would have been previously unseen.
• Depth of Field: We implemented a new depth of field technique that reduces edge-bleeding artifacts and utilizes fewer GPU resources.
• Emittance: We have replaced glow with a physical-based model of emittance. This allows you to model glowing objects as proper citizens of a physically accurate world of lighting and materials. We have changed lighting calculations to properly account for emittance, and we provided a way to automatically convert older content to use the new emittance property.

On the mobile graphics side, we have improved iOS rendering performance by an average of 15%, which is a significant jump considering our mobile renderer is already leveraging Metal and GMEM to maximize performance. We also added adaptive and scalable texture compression (ATSC), which is useful for managing bandwidth, memory footprint, and power, all of which are important for low-power, mobile devices.

Finally, if you are a graphics programmer like me, then you are just as concerned about profiling and performance as pretty pixels. So one last thing I want to highlight is the integrated graphics profiler. You can now display all sorts of mission-critical performance stats in real-time, including detailed CPU and GPU timings per frame, per pipeline stage, per sub-system. You will also find many useful graphics counters like to draw call counts, shader counts, triangle, and vertices count. These run-time stats nicely complement capture-based analysis tools like RenderDoc and Lumberyard’s Driller logging system.

We’re excited to continue to receive your suggestions and feedback—join us on our forums, in our blog comment threads, and email us at lumberyard-feedback@amazon.com. For details on everything new in the Lumberyard Beta 1.3 release, check out the full release notes here.

That’s enough from me until next time. Now it’s your turn: download Lumberyard and make something great!

The gaming industry is always evolving, and one of the most exciting new technologies to capture the imagination of our customers is VR. Lumberyard is already a powerful graphics engine, which makes it ideal for VR content creation. Lumberyard Beta 1.3, which we’re releasing in a few weeks, includes support for VR game development and new VR devices. Our VR implementation uses Lumberyard’s Gems, which are self-contained packages of assets and features that you can drop into your game. Lumberyard Beta 1.3 includes Gems for both the Oculus Rift and the HTC Vive. Moreover, these Gems serve as templates for customers to build their own Gems and support any VR devices they want.

Gems make adding support for new VR devices easy, with no engine code editing required. Developers won’t have to wait for an official patch or a new plug-in to start using commercial devices (or prototype devkits) as they hit the market. In this post, I’ll take a look at how Lumberyard supports new devices and speeds up VR development with the new VR Preview function.

We’ve been working on VR support for a while, and gave our first preview at this year’s Game Developer’s Conference (GDC). In fact, our approach for VR device support crystalized at the conference. Our VR demo at the show included elevator rides, deep space, and an attack by giant robot squids. It was also integrated with Twitch using ChatPlay, allowing the audience, both at GDC and online, to cast a vote to determine whether the player lived or died.

Our GDC demo was built by Climax Studios using Lumberyard.

Once the demo was over and the adrenaline wore off, people asked the same question over and over: “What VR devices does Lumberyard support?” Rift and HTC Vive support were top requests (our demo was presented on the Rift), but many developers were just as interested in other devices, like the Samsung GearVR, PSVR, and OSVR. Rift support in our demo had been written into the engine code itself. However, with customers asking to use so many different VR devices—and with new devices being announced all the time—it would be cumbersome and code-intensive for an engine to have hard-wired support for all of them. We knew that we had to find a way for customers to add support to any VR device they liked. We found our solution in Lumberyard’s Gems system.

How’s it Work?

Utilizing Gems, small chunks of code can be created that interact with the engine but don’t require editing the engine code itself. This means that developers can add support for any VR device without having to delve into the engine source. As long as a new VR device conforms to the public interfaces that Lumberyard has defined, the engine will automatically use it. Developers can create their own integrations for additional devices without having to wait for an official Lumberyard update, as they would in other engines. With so many new VR devices coming out soon, we wanted to provide a way for customers to make their own support decisions. Additionally, developers can easily override existing device support to add any experimental features that may be important for their gameplay. Below is a high-level diagram of the way this works inside the engine.

The HMDManager contains an IHMDDevice, which is then implemented by a device-specific Gem. The manager takes care of device initialization and device-abstracted head-mounted display (HMDs) interaction with the rest of the system. On the rendering side, Lumberyard’s stereo renderer makes use of the D3DHMDRender object, which takes care of creating graphics-API-specific render targets, social screen rendering, and frame submission to the VR device. To add support for any new VR devices, you simply wrap the vendor-specific SDK in a Gem as defined by IHMDDevice. That’s it! There’s no need to edit Lumberyard’s underlying HMD code, which is represented by the Lumberyard Engine section of the diagram.

On engine startup, the selected HMDs are scanned for connectivity and selected for use. If you want to support both the Rift and the Vive, for example, simply go into the Project Configurator, enable both Gems, and the engine will pick which one to use at runtime based on which device is plugged in.

Device-Specific Functionality

A good example of device-specific functionality is in the differences between the Rift and the Vive controllers. To handle VR device variations, Gems allow the user to supply custom Flow Graph nodes to the engine, meaning that each device-specific Gem can create its own nodes that appear when a specific Gem is enabled. These nodes can expose device-specific functionality for the end user, such as different controller schemes, tracking information, and room states. Because VR is so new, a lot of experimentation is taking place.  VR devices are often quite different from one another. It’s likely that, over time, devices will all start to share popular features that used to belong to only one device. When that happens, features that used to be device-specific will then be put into Lumberyard’s device abstraction and shared across all devices.

Enabling VR

Any Lumberyard project can easily add VR support by enabling one or more of the supported Gems when configuring the game project. However, even though a Gem is enabled, that doesn’t mean that any connected HMD will actually get used until the proper cvar (output_to_hmd) is set. The reasoning behind this choice is so that games can ship with VR support enabled in the game’s executable, but support will only turn on if the end user actually wants to use it. The current state of VR rendering can be queried in Flow Graph, so game designers can make different choices based on if the game has entered VR mode or not.

Developing in VR

Game developers need to be able to see what they’re doing in the editor at all times. Without a way to see VR in the editor, developers would have to export a level, load it into the launcher, enable VR, and take a look around. This is obviously inefficient. The Lumberyard Beta 1.3 editor will have full VR Preview support built in. VR Preview utilizes the same Gems system as the engine runtime, and it works in a similar fashion. We’ve added the “VR Preview” button to the editor, which you can click to see in VR right away. This allows developers to make VR-specific adjustments to their level designs right in the editor, which reduces iteration time. Flow Graph nodes are an important part of developing in Lumberyard, but they can only be debugged in the editor. With VR Preview, users can debug their VR Flow Graph nodes and see what they’re doing.

To use VR preview support, just click the new “VR Preview” button.

Performance

Enabling these Gems has zero (yes, literally) performance impact on a finished game. Performance will only be impacted when the VR code is actually running. Developers don’t have to worry about having this feature always on, so a game can ship with support for multiple VR devices without sacrificing performance.

What’s Next?

We’re just getting started with VR in Lumberyard, and will be continuing to reduce iteration times, improve rendering performance, and enable new features to take VR to the next level. When Lumberyard Beta 1.3 arrives in a few weeks, try it out and tell us what you think!

Cody White is a graphics and VR engineer who has a background in both feature film and real-time rendering. He’s responsible for Lumberyard’s VR system and spends most days in alternate realities.

Understanding how human perception differs between observing the real world and viewing game worlds helps us build great visual tools. The real world is a beautiful place, and our eyes excel at taking it all in. Until recently, though, there has been a gap between the fidelity of the real-world and what we’ve been able to recreate and display in games. This gap will narrow with HDR (High Dynamic Range) display technology, which can reproduce a wider range of colors and contrast. Lumberyard’s HDR pipeline—rendering, lighting, and visual processing—can help developers take advantage of this new technology. In this post, we’ll explain the importance of an HDR pipeline for creating games with color and contrast that can match the real world, and how Lumberyard can help unlock the potential of HDR.

The human eye has a wide visual range across different intensities of brightness. Our eyes can adjust to lighting situations ranging from a starry night or full moon, to a well-lit office room or sunny day. The Luminance chart on the left of Figure 1, the Chromatic Diagram at center, and the Eye Sensitivity chart on the right, show the full range of real-life colors and contrast the human eye can observe.

(Figure 1)

There are two significant technical hurdles that prevent game developers from making game worlds look as good as real life: the game engine graphics pipeline and LDR displays. Every stage of the graphics pipeline in a game engine reduces contrast and color. The degradation in quality, as illustrated in Figure 2 below, starts with modeling: a digital camera takes source photos of the real world, and part of the visual range gets lost in the photograph. That source photo is sent to an artist, and the artist’s recreation of the object loses fidelity. Once in a game engine, the textures are applied to a model, rendered, and finally displayed to the player. If a level is looking too dark or enemies are too hard to see, game designers might ask for colors to be changed or the brightness to be increased, and this change reduces the dynamic range further. After the real world is interpreted through all of these layers, the losses to contrast and color can be substantially different than the source material.

(Figure 2)

Lumberyard’s HDR mode improves this pipeline, preserving a full-value range and passing it through to next-generation HDR displays. This overcomes many of the limitations shown in Figure 2 and results in a much brighter, full-color image that is more pleasing to the eye. Lumberyard’s upcoming Beta 1.3 release will ship with an HDR pipeline in place, and your project will automatically begin to benefit from this technology.

Lumberyard’s HDR graphics pipeline solves part of the problem, but the biggest bottleneck is the common LDR display. LDR displays impose contrast and brightness limitations on their outputs, so even high-quality HDR data won’t look much better on most monitors. In Figure 2, the black triangle overlay on the Chromaticity Diagram shows the color limits of traditional game engines outputting to LDR displays. Sending HDR-ready graphics from Lumberyard to an LDR display is akin to drinking fine wine out of a Styrofoam cup.

Don’t make the mistake, however, of thinking that HDR still belongs in the far-future. An LDR pipeline is fine for the PS4 or Xbox One, which don’t support HDR, but it won’t be sufficient for very long. HDR displays are already shipping, and all major manufacturers will offer consumer HDR devices at affordable prices by the end of 2016. Research from market analysis company IHS predicts that HDR display sales will rise from 2.9 million in 2016 to 32.6 million in 2019. With HDR, artists will have more space to explore and express themselves, with a greater variety of colors and environmental rendering tools. The best time to fully master your HDR game is before HDR displays are ubiquitous. For artists and developers, Lumberyard’s HDR tools make working in the full color range intuitive and responsive.

Graphics research has been the focus of my entire career. I have been impressed at how much our team has been able to achieve with Lumberyard and how quickly we continue to advance the technology. We’re just getting started. With Lumberyard Beta 1.3, not only will the engine deliver on the promise of HDR, our toolset will allow you to take your scenes to this new era of display technology. Lumberyard makes HDR easy.

This post is based in part on Hao Chen’s presentation at GDC 2016. In this talk, Hao and Jonathan Oakes explain what HDR is, how it works, and how artists can take advantage of it in Lumberyard. Their presentation also explores the physics and math behind light, color, and human perception. You can download the slides from this talk here.

For nearly two decades, Hao Chen has led graphics R&D and game engine development at a number of game companies, including SingleTrac, Microsoft, and Bungie. Hao helped shape the core technology for some of the most innovative and influential games in history, including the Halo series and Destiny. He is also a frequent contributor to graphics and game conferences. Hao recently joined Amazon’s games technology group as a senior principal engineer. In his spare time, Hao enjoys photography, making music and films, and piloting airplanes.