Amazon GameDev Blog

December is a busy month for teams at Amazon, and the Lumberyard group is no exception. There’s lots of bustle in our four offices as we wrap up features for the next release, look deep into the data from our last user test to see areas we can improve, review animatics for the GDC surprises we have in store, and leap into action when one of our customers gives us a call with an idea or an issue to solve. While our team will get some time off to relax and get caught up on the latest video game releases (Titanfall 2 and Planet Coaster are on my list), we’ve much to do before that happens.

As important as it is to look forward, it’s also important to look back. Lumberyard was launched into Beta on February 9 this year, and a lot has happened since:

February – Lumberyard 1.0 launched as a free, AAA game engine deeply integrated with AWS and Twitch… and the world got another tool to battle zombie outbreaks, thanks to our diligent (and creative) legal team.

March – Lumberyard 1.1 launched with 208 new improvements, new features, and fixes, including a preview of our new Component Entity system, designed to make it easier for engineers and content creators alike to create gameplay in Lumberyard. Mobile support for iOS and Android launched, along with integration with Allegorithmic’s Substance, and a new FBX importer. March was also the first time many of you got to meet our team in person, at the 2016 Game Developers Conference in San Francisco. Thousands of people traversed our booth, and we introduced you to Rin, in beautiful high-dynamic range:

April – Lumberyard 1.2 launched with over 218 improvements, new features, and fixes. We called this release a “kaizen” release – Japanese for “continuous improvement” – as we believe it’s important at times for our team to relentlessly improve what is already in the engine, based on our customer feedback. We’ve learned in our experience making games that many times it isn’t the big new feature that accelerates teams, but the nuts and bolts quality of life improvements – interface tweaks, performance increases, cutting a task down from five steps to three steps, etc.

June – Lumberyard 1.3 launched with over 130 improvements, and became one of the first game engines with support for HDR displays. This release also included modular VR support, so you can more easily build games for any of the dozens of VR devices that are launching in the next year. Our own artists were especially excited for the other features in this release, including volumetric fog, improved motion blur, height mapped ambient occlusion to bring out subtle details and depth cues in terrain, and more performant depth of field effects. We also improved iOS performance by 15% in this release.

July – Several of our team’s veterans stormed Siggraph, broadcasted live on Twitch, and talked about the future of Lumberyard. Hao Chen, who leads our graphics vision and has many, many Halo games on his resume, talked about the explosion of display complexity happening today and tomorrow. Eric Schenk talked about leading technology teams, from his days at Radical and EA-Frostbite and, now, here at Amazon. And Pat Wyatt, who was one of the leaders of Blizzard’s Battle.net and ArenaNet, talked about the importance of connectivity and community in today’s games.

August – Lumberyard 1.4 launched, with 230 improvements, new features, and fixes. Whereas the previous release made artists smile, this one was for gameplay engineers, with a new Lua editor and profiling tools to help them iterate more quickly on complex gameplay. This release also let you build more cost-efficient multiplayer games, as GameLift announced support for hosting more than one instance of your game’s server code, or one or more instances of multiple game servers, on a single EC2 instance.

September – Lumberyard 1.5 launched with 210 improvements and a brand new feature — the Lumberyard Asset Builder SDK, which lets you add custom asset types to Lumberyard’s Asset Processor, which itself automatically processes game assets behind the scenes as you work. This release also included support for OSVR and dozens of improvements to the Component Entity system based on the feedback we’ve been hearing from our customers.

TwitchCon 2016 blasted off this month, with over 41,000 attendees, and Amazon Game Studios revealed three new games, built on Lumberyard, including an in-depth look at Breakaway, a 4v4 team battle sport. Our networking and GameLift teams were excited to finally be able to talk about Breakaway, since it so heavily utilized GridMate, Lumberyard’s robust, flexible, and low-latency networking subsystem, as well as GameLift to automatically scale its multiplayer sessions on AWS. Breakaway also demonstrated Twitch Metastream, a new Lumberyard feature that lets Twitch streamers look like the pros, letting them deeply customize broadcasts of your game. Streamers can use any HTML tool to create and display dynamic real-time graphics based on the data you provide.

October – This month, the Lumberyard team opened a new location in Austin, Texas, one of the long-standing centers of gravity for great game development talent and innovation in community-driven games. Although it’s only been a handful of weeks since they joined, our Austin team is already moving fast. We have new staff members joining us not only in Austin before the end of the year, but at all of our locations (and if you’re interested in joining us, we’re still rapidly hiring for next year).

November – Lumberyard 1.6 launches, with 337 improvements, new features, and fixes, a new record for our team’s velocity. This release included Twitch Metastream, support for Linux dedicated servers, a suite of new components, new Cloud Canvas functionality that helps you choose between multiple deployments (e.g. test or release) of AWS resources when launching your game and to protect your live deployments against inadvertent modifications, and an 8.4GB reduction in our initial installation size.

Our team also spent several days game jamming with Lumberyard, to put the engine and new systems through their paces. Like most game jams, the end results were often hilarious, but full of learnings for the team, which will result in many quality-of-life improvements in the upcoming releases, especially around component entity, scripting, and slice workflows.

Now we’re well in December, and putting a bow on the features coming in Lumberyard Beta 1.7, which you will see early next year. This new release is our biggest one yet. We’re currently tracking over 400 improvements, new features, and fixes, which we believe reflects our growing team, the culmination of many months of development, and more and more customers like you giving us feedback. Beta 1.7 includes Visual Studio 2015 support, the ability to deploy Android builds directly from the Editor, dozens of improvements to Component Entity workflows, Cloud Canvas support for consoles, and lots more that we’ll tell you about next month.

When we started Lumberyard, we had tremendous conviction that a free AAA game engine, deeply integrated with the cloud and a massive community would help developers move faster and better engage players in the types of experiences fans are demanding today. Our vision is not to settle with the premise of creating a world-class engine alone – we aspire to help you create experiences that would otherwise be impossible to build today. While we’ve worked hard this year and had a lot of fun in the process, it is still day one for us, and we’re looking forward to delivering more improvements, more “cloud and crowd” features, and more big ideas next year.

If you have some great big ideas, or feedback for us, we’d love to hear from you. Happy holidays from the Lumberyard team.

We’re excited to announce the release of Lumberyard Beta 1.6, which you can download here. This release contains over 337 new improvements, fixes, and features, and introduces Twitch Metastream, a new feature designed to help you build games that are as fun to watch and broadcast as they are to play.

Streamers are huge influencers today. Each month, over 1.7 million active streamers use Twitch to reach 100 million viewers who watch an average of 421.6 minutes each month. They’re your most passionate fans – dynamic, energetic, and provocative, and they act as a force-multiplier and magnet to build communities around your games.

Metastream lets these passionate streamers customize their streams with overlays of statistics and events from their game session. Using any web authoring tool, such as Dreamweaver or CoffeeCup, streamers can create custom HTML5 pages to control the information, graphics, layout, and behavior of each unique overlay they wish. With Metastream, streamers can create more polished, interactive viewing experiences on any of their favorite streaming services, similar to what you see in professional esports and TV broadcasts.

In the following example from Amazon Game Studios’ upcoming game Breakaway, you can see that the streamer has created an overlay showing stats from the two leaders in the match. Metastream lets him dynamically highlight the leaders’ highest stat areas, such as gold collected, Kills/Deaths/Assists, and damage dealt, and even pulls character art of the game and displays it dynamically. The streamer also displays each player’s position in the standings relative to the rest of their team:

The Metastream overlay you see above is completely customizable, and streamers can use OBS, XSplit, or other software, to switch back and forth between different graphic overlays timed to game events, or on the fly with a simple hotkey. Metastream content only appears on the broadcast, so the streamer’s own view is that of the original game, without the additional broadcast graphics.

While one streamer might like to highlight two great players, others may have an entirely different take on what your game should look like streamed. If you tuned into TwitchCon 2016 when Breakaway was announced, you might have seen two commentators showing a broadcast that looked like this:

In this example, the streamer is using a picture-in-picture style, with a minimap on the left of the screen that shows where the Relic is (in Breakaway, teams compete to move the Relic across the map), as well as live team stats on the bottom. Much like “time of possession” in football, this streamer can show fans one team’s constant momentum and domination, and viewers can easily see team tactics play out on the larger minimap.

This third example above shows how a streamer better engaged viewers in a pre-game show. The streamer toggled this Metastream overlay with the press of a button on his controller, using displays to highlight the strengths and weaknesses of each character (and appropriately trash-talk the competition) before the match got started.

It’s easy to get started with Metastream. Turning on the local HTTP Metastream server included with Lumberyard is as simple as including the Gem in your project from the Project Configurator, and enabling the Gem with an in-game setting. Stats and events can easily be exposed by adding a single line of code for each event you want your streamers to access. Included with Lumberyard is a Metastream sample that shows you how to access the simple API, and display the stats on an HTML page so they can be overlaid on a broadcast on not only Twitch, but also on any other popular streaming service.

We’re excited that Metastream provides another path for streamers and developers to interact, and have no doubt we’ll be surprised by the content and creativity it will inspire. To read more about Metastream, see our documentation.

There’s more in Lumberyard Beta 1.6 as well, including a robust component suite that gives you the ability to more easily use all the features of the engine to build game entities, Linux support for dedicated servers, new Cloud Canvas functionality that helps you choose between multiple deployments (test or release) of AWS resources when launching your game and protect your live deployments against inadvertent modifications, and a 8.4GB reduction in our initial installation size. For details on everything new in the release, check out the full release notes here.

As we’ve been working on Lumberyard over the last couple of years, we’ve assembled a team of industry veterans who are inspired to build a AAA game engine that uses the vast compute and storage of the cloud to help you build otherwise-impossible player experiences, and engage massive communities of fans. In fact, the typical developer on our team has over 10.8 years of industry experience building many of the games that have successfully built those massive communities.

Our team is still growing, and today we’re excited to announce that Lumberyard has opened a new office in Austin, one of the long-standing centers of gravity for great game development talent, and innovation in community-driven games.

We believe Austin is a perfect location for us to continue our quest to help game developers build the community-driven games that push both engine and cloud technology. From the early days of Ultima Online, to some of today’s most beloved MMOs, Austin game teams have helped lead the industry in large-scale, multiplayer experiences.

Building games that connect hundreds of thousands, or millions, of players together used to only be possible for the largest game studios. But today, we hear all the time that developers of all sizes aspire to build games that bring fans together to play, compete, create, and socialize. This isn’t surprising, given that 85% of top PC and console games feature multiplayer in some form, and the top 10 grossing mobile games charts are frequently dominated by games that require the cloud to provide their deep multiplayer, competitive, and social experiences.

Whether you’re about to launch your first Kickstarter, are an established indie, or have years of industry success, we want Lumberyard and AWS to help you spend your time and resources focused on building an amazing connected experience – not navigating all the heavy-lifting of building scalable infrastructure, or undifferentiated backend technologies that players only notice when they can’t connect to their favorite game.

Not only is Austin a great location for experts who have passion and deep experience building some of our favorite MMOs, multiplayer, and community-driven games, it’s also home to one of our new Twitch teams who just set up shop there in July. The Twitch team in Austin is focused on helping developers use Twitch in creative ways to grow community and make money, and we’re excited to work closely together (and have made sure that our desks are well within Nerf distance).

If you’re interested in joining our new Austin office and building on the foundation of Lumberyard, AWS, and Twitch to help developers make the next generation of multiplayer and community-driven games, check out our jobs page here.

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

One of our teams’ tenets is to move fast and give customers early access to the technology we are building. This gives you the opportunity to give us feedback at the earliest stages of development, which we believe will dramatically improve and focus our deliveries from release to release. We think that great technology isn’t developed in a top secret, airtight room for months or years at a time – the best game tools and systems come out of a tight feedback loop between the people using our technology and our engineers building that technology.

Of course, we want to be transparent on which pieces of Lumberyard are emerging, so you, as a game developer, better understands which areas will be evolving as you are building your game. To that end, we’ve created the Preview tag for features in early access. We define Preview as:

• The system may be missing features, but it is still stable, and delightful to at least one customer
• The user experience of any tools are high-quality and consistent, though may be missing functionality, and will likely change through iteration as we get more feedback
• Existing functionality has clear documentation, but samples and tutorials will come later as the system evolves
• APIs are subject to change, but our team strives to minimize any large structural changes that would cause you to do extra work migrating to future versions

Lumberyard Beta 1.5 materially advances three systems that are currently in Preview:

The first, the Particle Editor, is an example of a mature system in Preview, heading for general availability towards the end of the year. We’ve already gotten many months of great feedback on the particle editor from game teams and effects artists, especially in areas around improving iteration speed and optimizing particle systems. Lumberyard Beta 1.5 includes custom attribute panels so you can drag and drop the attributes you use the most into a UI panel, and save that setup for easy re-use or sharing amongst your team.

Because we believe great performance is critical to any game, the particle editor’s new level of detail system gives you finite control over optimizing visual effects based on their distance to your game’s camera. You can modify emitters on a per-attribute level and seamlessly blend between the levels of detail you specify. For example, you can create stunning effects for your hero characters as they are close to the camera, but more performant effects for characters in the distance. If you have other methods of optimization you’d like to see in our particle editor, let us know.

The second, the Component Entity system, is an example of a system in the middle of its life as a Preview. The new Component Entity system provides a modular and more intuitive method for constructing game and engine elements, so your team can build faster and create more complex behaviors.

The Component Entity system employs reflection, serialization, and messaging using the Lumberyard event bus (EBus) to automatically expose features of components to designers – no additional engineering required. The system lets you drag-and-drop and edit components in the Lumberyard Editor, and also supports fully cascading prefabs, which we call slices. This month, you will find a new suite of pre-made components to help you create gameplay faster, including components that cover primitive shapes (you can create triggers, colliders, volumes, and other spatial features your game needs in a few clicks), skinned meshes, audio, ragdolls, and character physics. One popular customer request was the ability to tag and filter components – to better organize a large toolbox of components – so we delivered that this month too. Our team plans to improve the Component Entity UX and grow our overall component suite using your feedback. If you have ideas on what kind of components you’d like to see next, let us know.

Finally, a new system makes its Preview debut in this release – the Lumberyard Asset Builder SDK. Many of our customers build custom tools that require specialized assets types. Often times, these tools help developers differentiate their games, or enable their team of experts to work faster. For example, one developer we talked to uses .EPS from Adobe Illustrator to quickly generate sidescroller levels. This SDK enables you to use the Asset Processor to track, reload, automatically rebuild, and process any assets your game or in-house tools require. The Lumberyard tools team would love to hear what specialized asset formats your team relies on, and how the Asset Builder SDK is working for those assets.

We are excited to get your feedback on our Preview systems. To make this easy, we’ve set up a new section in our forums dedicated to Preview features, so let us know what you think.

Lumberyard Beta 1.5 contains many other updates as well, including support for OSVR, performance improvements to the Asset Processor, support for Clang on Android, a VRAM profiler so you can more easily optimize graphics for your game, and more. For details on everything new in the Lumberyard Beta 1.5 release, check out the full release notes here.

It’s still day one on Lumberyard, and you will see sneak peaks of more Preview technology this year. In the coming releases, we will deliver Linux support for the Lumberyard multiplayer server, which combined with Amazon GameLift’s new Linux support can save you up to 45% of your EC2 infrastructure costs for session-based multiplayer games; a unified Asset Browser so you can browse, tag, search, and monitor all of your assets from a single location in the editor; Visual Studio 2015 support… and some fun surprises that we’re not quite ready to reveal yet.

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 [email protected].

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.