Lumberyard & Amazon GameLift Blog

Announcing Per-Second Billing for Amazon GameLift

Amazon GameLift puts the power in your hands to create the perfect balance between cost efficiency and a great experience for your players. The ability to use an instance for an hour, and to pay only for that hour (as well as our FlexMatch, game session queues, autoscaling features), has enabled you to scale capacity to player demand in an optimal and cost effective way.

Today, we move one step further, introducing per-second billing for game instances, making Amazon GameLift more cost efficient than ever before.

While per-second billing will bring cost reductions, we believe this change will also give you the ability to tighten control over your game, giving you further flexibility to select a configuration that scales capacity to handle sudden player spikes and manage idle instances down to the last second.

Starting October 2nd, all newly launched and already running Linux-based Amazon GameLift instances in all of the 14 available AWS Regions will be billed per instance-second. Visit the pricing page to learn more. Per-second billing is not currently applicable to instances running Microsoft Windows

As part of the AWS free tier, you can get started with Amazon GameLift for free. Find out more and begin your free trial today.

Goodbye to Flow Graph and CryAnimation. Hello to Brand New Visual Scripting and Animation Tools.

Lumberyard is not the same engine it was yesterday. If you’ve been away for a while, now’s a great time to take another look.

 

Check out our new visual scripting and animation tools. Download Lumberyard 1.11 here.

 

Over the course of 19 months, we’ve replaced over 60% of the original codebase, made over 3,300 improvements, and added over 500 free unique assets for you to use in your game projects. But this latest release marks a crucial turning point for the engine and the experiences you can create with it. Here’s why:

  1. EMotion FX is now our new animation system, replacing CryAnimation (as well as Geppetto and Mannequin). Now you can create character animations in as little as 10 minutes with little to no engineering chops, including functionality like blendtrees, state machines, blendspaces, and motion extraction. EMotion FX has been used by the likes of EA and Ubisoft for over a decade, and now it’s a permanent part of Lumberyard, providing a powerful and easy solution for artists. (Give it a try using our character Rin in the new game sample included with 1.11! Learn more how to access the sample here.)
  2. Script Canvas is now our new visual scripting solution, replacing Flow Graph. Script Canvas provides an approachable solution for authoring behaviors while utilizing the same framework as Lua and C++. That means you can take those cool characters you animated using EMotion FX and quickly create scripted behaviors using Script Canvas—all in a matter of minutes, without the need for engineers. With its familiar node interface, Script Canvas will make it easier to build quality gameplay experiences, even if you have limited programming experience. We can’t wait to see what you build with it. (For a tutorial on how to get started with Script Canvas, you can check out latest documentation here.)
  3. With these new, forward-looking systems in place, we’ve also included a CryEntity Converter tool designed to convert legacy CryEntities to Lumberyard’s new Component Entity data format. This will help ensure that you’re benefiting from the new Lumberyard systems and providing a stable foundation for your games. There’s still a lot of work to do, of course, but we’re excited to continue to evolve and grow alongside such an amazing dev community. (To learn how to use this new tool, you can check out our tutorial here.)

 

EMotion FX

 

Script Canvas

Over 400 additional updates

There’s a lot more in this release. You can find full release notes here.

  • You get three new Cloud Gems, including the ability to easily capture in-game surveys from your players, a text to speech gem that leverages the power of Amazon Polly, as well as a gem to build speech recognition and conversational gameplay experiences using Amazon Lex.
  • There are now Project Templates that provide two starting points for new projects. The Default Template comes with a selection of Gems enabled and a simple level to use as a starting point. The Empty Template represents the bare minimum project for Lumberyard
  • A new Getting Started Guide that will get you up and running in Lumberyard quicker than before—you’ll also make a maze escape game that you can share with your friends. You can find the documentation here, but expect a new series of videos in the near future.
  • We also enabled an experimental feature that implements a full blown Toon Shader visual look for your games. For a fun demonstration of how this can transform your game, just load up Starter Game and use the console command ‘r_ApplyToonShading = 1’. This can be refined in shadeLib.cfi.
  • Plus dozens of usability enhancements thanks to your feedback, including: drag and drop support for reordering entities in the Outliner and Asset Browser, new visuals for slice entities, 1-click activation of entities on game start, and if you are creating your own components, you can now associate URLs with those components to help your team ramp up.

Let us know what you think.

As we mentioned last week, your feedback helps shape our roadmap, so please keep it coming. You can learn more about Lumberyard by watching our tutorials, visiting the community forums, and reading through our documentation.

Building a Better Engine – The Road Ahead

“So, what’s next for Lumberyard..?”

We hear this question a lot—and for good reason. So we thought we’d give you a preview for the months ahead and share some features that have us all really excited here at Lumberyard.

Simply put, our focus for the next few releases is to make Lumberyard easier, more powerful, and more modular. We’re working hard to deliver new systems and features that align with these goals, and your feedback has played a crucial role in that process. Thank you once again for helping us shape the future of this engine.

A lot has changed since we first launched the beta: we’ve replaced over 60% of the original codebase, switching out older, redundant systems (e.g. CryEntity) for more modern, performant ones (e.g. Component entity systems)—and this will continue to be the case. While some new systems are still in preview, we’re working to provide a stable foundation for your current and future games, so you can build and innovate confidently moving forward. You can also expect more detailed tutorials and documentation to support these systems in the months to come.

So what exactly are these new systems and features? Here’s a glimpse of what you can expect in the next couple of releases:

  • Script Canvas – Script Canvas, our new visual scripting language, will provide a high performance, flexible scripting language in a familiar node interface, so content creators can build gameplay with little to no programming experience. Built entirely from the ground up to be compatible with Lumberyard’s component entity and Behavior Context system, Script Canvas enables teams to easily use any combination of visual scripting, Lua, or C++ coding in their game project. Script Canvas will replace Flow Graph.
  • Brand new animation system – Siggraph attendees got a sneak peek at our new, robust animation solution, which was built from technology used by well-known publishers such as EA, Ubisoft, among others. Our goal here is simple: help animators build amazing characters in Lumberyard with little to no engineering help. This new system will replace the existing CryAnim functionality, including Geppetto and Mannequin, and include functionality such as a visual state machine, support for linear skinning, joint scaling, and much more.
  • CryEngine Legacy Deprecation – In addition to streamlining the editor experience, we will soon hide the legacy functionality to better signal to customers which systems are forward-looking. This effort will help developers migrate from legacy entity systems to the new component entity system, and will include a data converter tool for developers still using some of the older CryEntity systems. A significant number of legacy system data will be auto-converted to the new component model in the next few releases—all in an effort to remove CryEntity systems from Lumberyard early next year. (Note that we don’t expect CryLua, CryAnim, and Flow Graph to have data migration support.)
  • More Cloud Gems and AWS Integration – We will continue to build out our portfolio of Cloud Gems. Soon, you’ll see a Cloud Gem that helps capture in-game surveys from your players, as well as a gem that leverages the power of Amazon Lex and Amazon Polly to build speech recognition, text-to-speech, and conversational gameplay experiences. From there, our roadmap considers new gems that reduce or automate engineering effort to build common connected and social features (e.g. push notifications, metrics, monetization tools, dynamic content, etc.), accelerate production (e.g. asset processing), and enable new player experiences. We’ve gotten lots of great ideas from our customers already, and look forward to seeing more on the Cloud Canvas forums!
  • Component Entity Workflows – We will continue to improve our component entity workflows, especially in the areas around usability and interoperability with the Entity Inspector, Entity Outliner, and viewport. These improvements also include better support for working on large scale levels with lots of content, improved entity organization and manipulation capabilities, and better slice manipulation and collaboration tools – working towards the eventual ability to open and edit a slice that is not part of a level. We believe these workflow improvements will result in greater efficiency for you, especially if you’re building large, high-fidelity levels, or games that rely on massive amounts of content.
  • Location-independent Game Project – We plan on delivering Project Configurator changes and build system improvements that enable customers to store their game and gems in any arbitrary location. This has been a popular request from our community, and we’re excited to deliver it.
  • Mobile Performance and Optimization – We are also improving our mobile workflows and performance. Our efforts will continue to improve frame rate on minimum spec devices (iPhone 5S+ and Android Nexus 5 and equivalents), improve battery life usage for applications, and reduce our memory and app size footprint on iOS and Android (currently at ~25MB minimum size, but we’ll continue to work to make it smaller).
  • Memory Management and Thread Unification – We have two on-going initiatives underway to improve runtime performance (especially for PC and console platforms) as well as stability. First off, we will unify and optimize Lumberyard’s memory management. Our teams are focused on identifying and resolving existing memory leaks while improving the memory usage patterns throughout the engine. Second, we also plan on migrating the engine’s various threading mechanisms to the AZCore job system, enabling further threading performance improvements and load balancing.
  • New Shader and Material System – Our short term objectives are to improve the usability of the material and shader system by converting sub-materials into individual material assets, enabling the concept of a shared material library, and letting a developer author a new surface shader without compiling C++. Longer term, we’re planning a full refactor and modernization of the material and shader system, but we’re going to spend the time to get this right, and this work will go into next year.
  • macOS – Our vision has always been to provide a complete, cross-platform experience, so we are also providing the tools necessary for developing Lumberyard games on macOS. This includes the Lumberyard editor and all its associated tools, the asset processor, the shader compiler and, of course, the renderer. Mac support has been a popular request from our customers, especially the ones building iOS games, and we’re excited to give you a first look in the coming months.

And much more

Our team is moving fast, and there are even more initiatives on the horizon as well—we look forward to sharing them in future updates. As always, let us know what you think. Send us your questions and comments at lumberyard-feedback@amazon.com.

Starter Game gets a massive update, adds over 950 features and improvements

Ask any creative. Getting started is often the hardest part when it comes to making something new. That’s why we created Starter Game—a free game sample with over 500 unique assets to help you quickly prototype ideas and learn how Lumberyard works. Got an awesome game concept in mind? Starter Game will help you hit the ground running. You can download it here.

You can download the latest version of Starter Game here for free.

Today, we’re excited to announce the Action Update for Starter Game, which introduces over 950 enhancements and improvements. Some highlights include snappy gunplay mechanics, rocket jumping, a more responsive AI, and improved character control. You’ll also find a slew of customizable environments like a massive crashed airship with detailed interiors, a defense basecamp, a broad range of vegetation, and much more. There’s a lot to experience in Starter Game. Give it a try—we think you’re going to like it.

This latest update of Starter Game will feel like a more polished game experience overall. But in many ways, it’s more than just a game; it’s also a classroom. Under the hood, you’ll find examples of cascading slices, component entities, vegetation distribution, Lua scripted events—everything that makes Lumberyard tick. As the engine continues to grow and evolve with new releases, so too will sample content like Starter Game. (Make sure to keep a look out for more samples on the horizon…)

Here’s a glimpse of what you’ll find in this update:

  • Campaign arc – complete with a story, cinematics, mission objectives, a compass to point you to your next objective, and a narrative voice over to guide your mission
  • Over-the-shoulder aiming – improved aiming and shooting, with more accurate camera controls
  • Improved character control – including double-jumping, controller support, and crouching
  • More responsive AI – more AI variation and responsiveness to player actions
  • Track View for cinematics – Component based track view setup, scripted for game play events
  • UI for in-world menus – Updated UI systems for better player clarity
  • Component Entities that create and update instanced combat zones
  • Mission progression built with cascading slices

We’d love to hear what you think. Starter Game is a direct result of the community’s on-going feedback, and it keeps getting better with your suggestions. You can learn more about Lumberyard by watching our tutorials, visiting the community forums, and reading through our documentation.

 

About the author

John Noonan has spent most of his career working on AAA console games, including the Crackdown and Halo franchises. As Executive Producer on the Amazon Lumberyard Content Team, John helps create inspiring content that demonstrates the capabilities of Lumberyard.

Matchmaking, Your Way: Amazon GameLift FlexMatch and Game Session Queues

One of the crucial parts of any multiplayer game is ensuring that your players are quickly, consistently, and efficiently put into satisfying matches that keep them coming back for more.

To make that process better for you as a developer, Amazon GameLift now offers FlexMatch. This service provides a powerful range of customizable features that you can use to quickly create robust matchmaking. Whether you’re a game designer or backend engineer, FlexMatch’s customizable rules-based syntax simplifies the development process so you can tune your matchmaking exactly how you want it.

Using our analytics and the GUI in our management console, you can also quickly experiment with different settings to see how they affect the quality of the matches being played. The GUI makes data accessible for designers who want to experiment.

In this post, we’ll discuss how FlexMatch works with our game session queues, using flexible rules to create matches and then automatically place those matches into games. We’ll also show you how to use our analytics to track and iterate on your game rules. Finally, we’ll discuss advanced FlexMatch settings that let you customize your game’s matchmaking process even further.

Matchmaking: Questions to Answer

The challenge of matchmaking is striking the right balance between how fast matches are created and how optimal those matches are. As a game developer, you know your players best. Maybe your players want as little wait time as possible. Maybe they are willing to wait a long time for the best possible match. Likely, there is a balance that you need to strike between these two ends of the matchmaking spectrum.

To players, the matchmaking that makes this all happen appears straightforward and simple. You as a developer know that creating and managing a flexible and efficient matchmaking system is anything but simple.

So, where to start? How do you build a system that players will deem a success? Here are some questions to ask when designing your matchmaking system:

  1. How long are your players willing to wait?
    You know your players, so what do your instincts and data tell you about their willingness to wait for a match? Maybe they want to match quickly, or maybe they want to wait for the best match. What does your game session length tell you about matchmaking? For games with short sessions, perhaps your players want to optimize for as many matches as possible in as little time as possible. For games with longer session times, your players might prefer to wait longer to find a better match. Does your player base have both competitive and casual gamers that have different needs? In that case, you may want to have multiple matchmakers – one for casual players that want fast matching, and one for competitive players with more balanced, competitive matches.
  2. How latency-tolerant does your game need to be?
    Generally speaking, players want the lowest latency between game and server as possible, and they want to be in matches with players that share that same low latency. Knowing your players, what’s acceptable for your game when it comes to latency? Are your players willing to wait longer to be matched with players with similar latencies? Do your players prioritize playing with friends regardless of latency? Do you have different populations of players with different priorities when it comes to latency? Knowing the answers here will help you determine how to segment your players.
  3. How important is player skill?
    Players define what makes a game fun in different ways, and many times, playing with other players that have the same skill level can go a long way to keeping the game fun. Do your players value being placed in matches with players of similar skill? Do they prefer to have a challenge and want to play with players better than they are? Do they not care about skill at all and simply want to match as fast as possible? Understanding how player skill fits into your matchmaking will help refine the created matches even further.
  4. How flexible is your matchmaking?
    Wait time, latency, and skill levels all factor into your matchmaking, so how flexible is your system? Can you pick and choose what to prioritize? Do you have analytics that tell you what impact your choices are having on your players? Does your system relax matchmaking requirements over time automatically to find a game even under less-than-ideal circumstances? Does your system allow you to segment your players to provide the best experience for everyone?

In a recent post, we showed you how to create a serverless custom matchmaker using Amazon GameLift and other AWS services. Now we’ve taken the next step by creating a powerful and flexible framework for matchmaking, built right into Amazon GameLift: FlexMatch.

How to Use FlexMatch

On the surface, FlexMatch appears relatively simple, but go “under the hood” and you’ll find a great deal of power and flexibility.

Part of FlexMatch’s power comes from its direct tie into Amazon GameLift’s game session queues. With FlexMatch, you can group players together into matches based on criteria you choose. Then with queues, you can create fleets to place those matches that might represent all players on a given platform, or those in a specific region or game mode or map or language. Working together, FlexMatch and queues can quickly create the best, lowest latency matches for different segments of players, even across regions.

To help you better understand how to use FlexMatch with our queues function, let’s walk through an in-depth example, starting with FlexMatch configuration.

Let’s say your game is a team based shooter that needs equal team sizes with a minimum of 4 players and a maximum of 8 players per team. You also want a competitive match, so the teams need to have an average player skill within 10 points of one another. Finally, you don’t want players to wait too long to find a match, so you want to relax the skill rule to an average player skill within 50 points between teams after 5 seconds and 100 points between teams after 15 seconds.

Below is how you would configure FlexMatch rules to fit your game:

{
    "name": "aliens_vs_cowboys",
    "ruleLanguageVersion": "1.0",
    "playerAttributes": [{
        "name": "skill",
        "type": "number",
        "default": 10
    }],
    "teams": [{
        "name": "cowboys",
        "maxPlayers": 8,
        "minPlayers": 4
    }, {
        "name": "aliens",
        "maxPlayers": 8,
        "minPlayers": 4
    }],
    "rules": [{
        "name": "FairTeamSkill",
        "description": "The average skill of players in each team is within 10 points from the average skill of players in the match",
        "type": "distance",
        // get skill values for players in each team and average separately to produce list of two numbers
        "measurements": [ "avg(teams[*].players.attributes[skill])" ],
        // get skill values for players in each team, flatten into a single list, and average to produce an overall average
        "referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
        "maxDistance": 10 // minDistance would achieve the opposite result
    }, {
        "name": "EqualTeamSizes",
        "description": "Only launch a game when the number of players in each team matches, e.g. 4v4, 5v5, 6v6, 7v7, 8v8",
        "type": "comparison",
        "measurements": [ "count(teams[cowboys].players)" ],
        "referenceValue": "count(teams[aliens].players)",
        "operation": "=" // other operations: !=, <, <=, >, >=
    }],
    "expansions": [{
        "target": "rules[FairTeamSkill].maxDistance",
        "steps": [{
            "waitTimeSeconds": 5,
            "value": 50
        }, {
            "waitTimeSeconds": 15,
            "value": 100
        }]
    }]
}

Figure 1 – Example FlexMatch rules syntax.

After configuring your matchmaker, next up is configuring your queue.

Let’s say you want all of your players in Asia to be matched together. To do this, you could set up your Matchmaker in either Seoul (ap-northeast-2) or Tokyo (ap-northeast-1), then build a queue that contains fleets located in Seoul (ap-northeast-2), Tokyo (ap-northeast-1), and Singapore (ap-southeast-1). That queue could be configured to use player latencies to find the lowest latency region amongst the three for any given matched set of players.

If you had planned to launch your game in additional regions of the world, you could create additional matchmakers and queues and build different matchmaking rules for each region or group of regions. This approach is particularly useful if you’re releasing different versions of the game in different parts of the world. You could even assign different matchmaker rules to different matchmakers. This would allow you to group players into separate competitive and casual matchmaking queues, for example.

Whatever you decide, FlexMatch uses your rules to assemble a match and your queue configuration to place the match onto a game server.

Once you have configured your matchmaker and queue, you are ready to accept matchmaking requests. If you’ve configured other Amazon GameLift features, they then will be in effect as well. For example, autoscaling can start launching the right amount of servers to accommodate player demand.

We consider this approach holistic game session management, bringing together all the functions you need, in a way that provides “it just works” capabilities for your game backend operations and for your players.

Advanced Rules

The FlexMatch rule set also has advanced features for even more granular control over player experience.

For instance, you can group together players who prefer certain game modes, like Capture the Flag, or certain groups of maps.

You can also create matches with teams that feature at least one each of several classes of player characters. For example, you might decide that a valid team requires at least one warrior, one rogue, and one mage before a game starts. You can also allow asymmetric matches, like 1v5, in order to support new game modes.

Put simply, with FlexMatch, you have options. You’re in control.

Analytics: Understanding How Your Rules Are Working

Monitoring and optimizing your FlexMatch rules is an important part of fine-tuning your game design. To help monitor your rules, Amazon GameLift FlexMatch emits a set of matchmaking metrics that are easily accessible through the management console. As you test your game, you can use these analytics to balance your player experience. These metrics include:

  • Match Success/Failure Rates: Monitor your matchmaker’s ability to group prospective players and get them into games quickly. Track the rate that players are accepting or rejecting the matchmaker’s proposed matches to see how well the matchmaker is meeting player expectations.
  • Player Demand: See the number of matchmaking requests currently being processed. Track the rate of new requests and new players to get advanced notice of surges in player demand, etc.
  • Time to Ticket Success: Monitor the average length of time it takes for the matchmaker to successfully create a new match. Use this data to find the right balance between finding the best possible match and getting players into games fast.
  • Matchmaking Rule Effectiveness: Track the pass/fail rates for individual rules in a matchmaker. Use this data to fine-tune each match rule and optimize the matchmaker performance overall.

For a full list of metrics, visit the Amazon GameLift Developer Guide.

For example, if your analytics show that 80 percent of matchmaking requests are timing out, it might be that your rules can’t match players because they’re too strict. You might even have a problem if only 10 percent of games time out, depending on your definition of a good player experience.

Conversely, maybe only 2 percent of your matchmaking requests time out. Your FlexMatch rules could be perfect. Or they could have another problem: they’re too relaxed, leaving some players routinely playing against much better players.

In our example game, here’s how you use the analytics functions to track key issues such as these:

Figures 2 & 3 – Example FlexMatch analytics dashboard.

You also could use AWS Lambda to run a function in the cloud that monitors those analytics and reacts based on certain actions or notifications.

Rules Relaxation

As shown in the example rules, one very useful FlexMatch feature is rules relaxation. Rules relaxation allows you to control when and how player matching criteria are relaxed as a player waits for a match. It might sound counterintuitive in a rules-based framework, but relaxing rules can help hard-to-match players quickly get into the next best game.

For instance, you probably want each match to include only players within a certain range of skill levels, say, no more than +/-10 skill points of each other. However, if the player pool doesn’t have enough players within that range, you need a fallback. Maybe you allow players +/- 15 skill points to join instead.

In another example, maybe you need to relax matchmaking rules to search for players in more distant regions after players have been waiting for at least, say, 90 seconds. That means West Coast players might get placed in East Coast regions. Latency might be slightly higher, but your players will be playing instead of waiting in a matchmaking lobby.

Ultimately, it’s a question only you can answer: when and by how much should you relax rules for the hard-to-match players? FlexMatch’s framework lets you decide which of these matchups, even the imperfect ones, you’ll allow.

Conclusion

FlexMatch enhances Amazon GameLift’s already broad range of capabilities by giving you a built-in matchmaking framework with the power and flexibility you need to create a deeply customized multiplayer experience while automating a significant piece of game management.

FlexMatch consolidates pieces of multiplayer game management into a set of features that give you power, flexibility, speed to market, and controlled costs.

To get started with FlexMatch, download the Amazon GameLift SDK, upload your game to Amazon GameLift, and start configuring your rules.

About the Author
Bruce Brown is the Software Development Manager of the Amazon GameLift Player Experience team responsible for building the FlexMatch matchmaking service. He has been in the software industry for 12 years including time spent at Microsoft on the Xbox Live Cloud Compute, Xbox Multiplayer teams and at Riot Games working on the League of Legends Live Gameplay and Personalization teams. Currently, he is playing Zelda: Breath of the Wild with his 6 year old son, and he enjoys designing games with his wife in his free time.

Now Available – Lumberyard on GitHub

Today, we’re excited to announce that Lumberyard source is now available on GitHub. This has been one of the most requested features from the community, and we’re happy to finally make it a reality. You can check it out at www.github.com/aws/Lumberyard.

Because making games is challenging enough. Here are two ways that GitHub makes it easier.

 

Get Lumberyard using GitHub

Up until now, the only way to get Lumberyard was to install Lumberyard using our standard installer. This would place all of Lumberyard, including the source, on your machine, in a new but separate directory. We heard you loud and clear: it was tedious to incrementally upgrade Lumberyard. That changes with GitHub.

Now you can get the Lumberyard source code directly from our GitHub repository and easily use GitHub to manage your code. Integrating a new version of Lumberyard is now a relatively simple operation. And since each new release of Lumberyard is a separate branch, you can integrate against any version. Plus, you can even create your own GitHub account to use GitHub for source control on your own project and use that as your remote repository, giving you an easy way to collaborate with your team.

 

Submit changes and fixes to Lumberyard

In the past, Lumberyard devs were only able to submit up to 50 lines of Lumberyard code through the forums, which limited fixes to simple changes. (Thanks again for all your submissions!) Now, with GitHub, there’s a simple way to submit changes and fixes of any size to the Lumberyard team. With pull requests, you can submit as much code as you want, across as many files as you want, knowing your changes will be managed in a concise and correct manner. Your feedback and support are what drives our team, and we’re excited to be able to build this engine alongside you.

Keep in mind, though, that for us to keep the main branches of Lumberyard stable, the code submitted in pull requests can’t be immediately merged into the live release branch; instead, accepted changes will show up in future releases of Lumberyard. We’ll be in touch to confirm if your pull requests have been accepted or to clarify the intent of the code. And anyone who submits successful pull requests will be given credit in our release notes!

Also, it’s okay to create and post your own fork in our repo (see the Readme.md file on the repo for more info.) Lumberyard is still subject to the AWS Customer Agreement and Lumberyard Service Terms, but to make it as easy as possible to use, it’s in a public repo – you don’t need to log in to get it.

As always, let us know what you think. We have some really exciting things in store these next couple of months, including Script Canvas and some brand new animation tools—so stay tuned! You can learn more about Lumberyard by watching our Tutorials, visiting the community Forums, and reading through our Documentation.

 

About the author

Todd Gilbertsen has been building game engines, video games, and other software professionally since the late 1980s. 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.

Now Available – Lumberyard Beta 1.10

Today, we’re excited to announce the availability of Lumberyard Beta 1.10, our biggest release to date with over 546 improvements, fixes, and features. You can download it here.

Since launching last February, we’ve modified, ripped, and replaced over 50% of the original codebase. Thanks to your feedback, we’ve made some great progress—but there’s still a lot more work to do. We’re excited to have you on this journey with us.

Here are some highlights from this release. (Full release notes can be found here.)

Order-independent Transparency

Rendering transparent objects in games can be challenging. Take wine glasses for example: any graphics engineer knows that it’s time-consuming (if not downright annoying) to correctly display every single surface, and get every reflection just right—especially when those surfaces and reflections are drawn out-of-order. Order-independent Transparency solves this.

We first gave you a glimpse of OIT at GDC this year in collaboration with NVIDIA Research, and now we’re happy to integrate it into Lumberyard 1.10. We’re always looking for ways to make game development easier, while also pushing the boundaries of what’s possible in real-time rendering. We can’t wait to see how you leverage the power of OIT.

The left side of the screen showcases the benefits of enabling Order-independent Transparency.

 

Temporal Anti-Aliasing

We’ve all dealt with jagged edges (aka jaggies) and unwanted flickering in games—in many ways, we’ve gotten used to it. But it doesn’t need to be that way. With Temporal Anti-Aliasing, you can more easily smooth out imperfections caused by real-time rendering, getting you closer to achieving film-like quality in your games.

Because let’s face it: in film, you can spend hundreds of hours on just seconds of CGI effects. But in games, we need to do all of that in real-time. Together with Lumberyard’s advanced rendering technology, Temporal Anti-Aliasing will help you achieve that higher level of visual fidelity in your projects.

The left side of the screen showcases the benefits of enabling Temporal Anti-Aliasing.

 

Hundreds of additional features and optimizations

Thanks to your feedback, we’ve also made a bunch of important tweaks and fixes in this release:

  • We’ve introduced 35 improvements to component entity workflows to help speed up your iteration time. For example, you can now multi-select in the Entity Inspector (just use CTRL and SHIFT clicks), revert entities and components back to their slice defaults in one click from the context menu, enable and disable components from the Entity Outliner, and even customize your entity’s icons.
  • We’ve also added over 50 improvements to our Cloud Gems to help you better manage your player community. New features include the ability to create new users, reset passwords, and ban players outright in just a few clicks from in the Cloud Gems Portal.
  • Plus much more, including a brand new docking system for customizing the editor and performance improvements to the material editor.

Lumberyard’s new docking system

 

Let us know what you think

As always, let us know what you think. It’s only been 18 months, and in many ways we’re still just getting started. We can’t wait to incorporate more of your feedback and suggestions—so please keep them coming. You can learn more about Lumberyard by watching our Tutorials, visiting the community Forums, and reading through our Documentation.

Fitting the Pattern: Serverless Custom Matchmaking with Amazon GameLift

One crucial component for success in session-based multiplayer game titles is how smartly and efficiently they can put together competitive and exciting matches for their users, no matter the skill level, connection speed, or location. Reliability, flexibility and system smarts all play into making a successful multiplayer experience.

At the 2017 Game Developers Conference, Amazon GameLift’s Chris Byskal and Geoff Pare talked about Building Resilient Online Games using Amazon GameLift. In the talk, Chris and Geoff explain how Amazon GameLift can simplify the process of setting up different types of games in the cloud. They also talk about how Amazon GameLift can save thousands of hours of engineering time, significantly reduce idle active servers, protects game servers from DDoS attacks, and provides automated scaling and matchmaking.

This blog post will dive into the player-matching patterns mentioned in Chris and Geoff’s talk, and focus on a matchmaking architecture that uses a custom algorithm to group players and connect them with a server. It will also provide code examples so you can build your own custom matchmaking architecture.

Such a serverless approach provides significant benefits. It reduces the burden of undifferentiated tasks common when running and maintaining highly available server infrastructure in traditional environments. Most importantly, this approach can simplify the creation of a complicated and important back-end process, giving you more time to focus on building the best game possible.

Overview of Player-Matching Patterns

Multiplayer games today tend to come in two flavors. They either connect players for matches using server browser game selection or through matchmaking.

Server browsers are relatively simple to create, presenting players a list of available servers from which players can choose to join or create a specific game.

Game Server Browser Example

Figure 1 – Example of a server browser.

Should a developer want to use this approach, Amazon GameLift provides several options to simplify the implementation, using three API calls within the game client:

  • List all games – Amazon GameLift supports searches that match your player’s search criteria. For a server browser setup, we can either show all current game sessions or just those with available player sessions. For more information about using this API call, review the Amazon GameLift SearchGameSessions() API documentation.
  • Join a specific game – A player also can join a specific game with their clan or group of friends. Once a player has chosen a game session, the system requests that the player be added. If the game session is accepting new players and has an available player slot, Amazon GameLift reserves the slot and responds with connection details.  This approach does mean the game session could become full by the time the player has selected the session and requested to join. Read more on the Amazon GameLift CreatePlayerSession() API Reference.
  • Create a game – Amazon GameLift also can create new game sessions for a player. Once active, the game session can appear in the server browser, where other players may join. Players also may choose to make their game session private, so they aren’t shown in the server browser. For more information, see the Amazon GameLift CreateGameSession() API Reference.

The server browser approach is simple and gives players the opportunity to pick their own game from the list of available options. It’s also relatively simple to implement for developers. But that simplicity may not provide the best experience for players. The lack of matching based on player or team skill, or other important criteria, can create imbalanced matchups that aren’t fun for everyone.

The server browser approach also can make it more difficult to efficiently group players across your infrastructure, because players can join game sessions regardless of how full or empty they are. This can lead to “lumpy” player distribution across servers and unnecessarily higher costs.

Matchmaking takes a different approach. When players request to join a game, a customized algorithm typically locates player matches based on variables like player skill, server latency, friend preferences, and team groupings. Players are more likely to be evenly matched and thus more likely to grouped into competitive games.

This approach also groups players onto servers more efficiently, keeping game sessions full, reducing server instances and lowering cost. Matchmaking’s primary challenge is higher complexity.

Designing a Serverless Matchmaker

Should you decide to take the matchmaker approach, you’ll need to set one up. In this section, we’ll show you how to create a simple serverless matchmaker with a custom player-matching algorithm. Figure 2 (below) describes a multiplayer server architecture that includes:

  • Matchmaking based on custom variables or an algorithm
  • Game server management
  • Game session management
  • Automatic scaling of server instances
  • End-to-end versioning of game-connection flows

This serverless custom matchmaking process takes place in three primary steps.

Serverless Custom Matchmaking Example Architecture

Figure 2- Serverless custom matchmaking architecture.

  1. Requesting to join a game
    In Step 1, the player uses a client to join a game. The game client calls an Amazon API Gateway endpoint, which is backed by a Lambda function that will house our custom matchmaking logic and interact with Amazon GameLift to find a suitable game session for the player. Amazon API Gateway is a managed service that helps developers create, publish, maintain, monitor, and secure APIs. We are using API Gateway here because it creates a level of abstraction between our game client and the AWS Lambda/Amazon GameLift implementation underneath. This offers flexibility for situations such as:

    • Versioning – Game clients are isolated from changes in back-end processing. It’s useful in several ways: to future-proof the game so it can easily incorporate new technologies; to enable seamless cutovers to new Amazon GameLift implementations; to perform A-B testing.
    • Operational metric capture – We suggest using Amazon CloudWatch with API Gateway to monitor performance metrics of our API, and Lambda function to help quickly identify issues with our matchmaking service.
    • Security – With API Gateway, we can use AWS security tools such as Amazon Cognito to authorize access to APIs and control service operation access. This creates a seamless authorization process for players that is easy to configure and maintain.
  2. Finding a game
    In Step 2, we use AWS Lambda functions for matchmaking. Lambda lets you run code without provisioning or managing servers. Deploying to Lambda is as simple as uploading your code, Lambda handles everything needed to run and scale on demand. Your code can be set to automatically trigger from other AWS services or called directly from any web service or app. Lambda is a good choice here because matchmaking calls are short-lived and invoked moderately frequently. Server administration is kept to a minimum with high availability. Lambda usage is charged per execution, per 100ms. You can easily run in parallel multiple versions of processes, providing the flexibility to best support your game clients and players. For this design, let’s define three Lambda functions:
    • Enter Matchmaking – This function handles game-client requests to join a game. The function takes the request, accepts any necessary information passed in by the client (such as server latency), and persists it in an Amazon DynamoDB table of waiting requests to join games. The function notifies the client that matchmaking is in progress so that it can inform the player.
    • Matchmaker – This function runs at short intervals to create groups of closely matched players and prepares each group to join a game session. This is where the custom matchmaking logic goes to work. Each time the function runs, its algorithm iterates over the table of waiting join requests to match players into groups. Once it has created a complete group, the group is marked ready to join a game session. The function persists this information in the DynamoDB table and then terminates. Figure 3 (below) is a code snippet showing example logic for this function.
    • Server Connector – This function periodically checks for groups that are ready to be assigned a server and submits requests for game sessions. It uses an Amazon GameLift feature called game session placements.
def get_unmatched_players():
        table = dynamodb.Table(table_name)
        response = table.scan(
            FilterExpression=Attr('MatchStatus').eq('Open')
        )
        players = response['Items']
        
        print("Number of players watching for matches: " + str(len(players)))
        
        return players
        
def create_groups(players):
    print('Creating Groups')
    groups = list()
    
    # Sort players by skill
    players = sorted(players, key=lambda player: player['Skill'])
    
    # Group players into match sized groups
    while (len(players) >= match_size):
        new_group = {'Players': list()}
        for i in range(0, match_size):
            new_group['Players'].append(players.pop(0))
            
        groups.append(new_group)

    print("Number of groups created: " + str(len(groups)))
    
    return groups

Figure 3 – Example Python code for custom matchmaking logic.

With game session placements, Amazon GameLift looks across multiple fleets and regions for that player group’s best available hosting resources. We also can create a new game session and add our group of players to it with a single request.

In Amazon GameLift, a new game session placement request is added to a game session queue. We’ll need to set up a queue with one or more fleets to host the new game sessions (located in any region) and set a timeout value to limit the time spent fulfilling each request.

When fulfilling a placement request, Amazon GameLift evaluates each fleet associated with the queue until it finds one that can support the placement request or the request times out. By default, Amazon GameLift evaluates fleets in the order they are listed in the queue configuration. This makes it possible to define the order of preference we want Amazon GameLift to use when placing a new game session.

For games that require a low latency experience, Amazon GameLift can use latency data to place a game session in a region with minimal lag for all of that group’s players.

To use this feature, we need to collect latency data for each player in all regions. When Amazon GameLift receives the latency data for multiple players, it reorders the queue’s server fleets to prioritize regions with the lowest average lag.

Figure 4’s code snippet (below) shows a game session placement request. The StartGameSessionPlacement() function accepts a queue name, which we defined in our queue configuration.

Amazon GameLift also requires a unique placement ID. We’ll use this ID to track the request status. The developer defines placement IDs, which can be anything unique. In the example below, it uses a UUID, which is passed to the caller for further processing.

Optionally, our placement request can include game and player IDs for the session. If supplied, you can use the AWS console to view game sessions at the player level, making it easy to see when users are actively playing and for how long.

A new game session placement is created with a PENDING status. The example code in Figure 4 (below) prints the status returned in response to the placement request. Further tasks can be performed, based on the status of the placement request. For example, if the response is PENDING, we can inform the game client that the session is imminent and perform further checks on the status awaiting confirmation. If the placement request times out, we can resubmit the request or try again with a different queue.

def start_game_placement(queue_name, group):
    print("Starting Game Session Placement")
    
    placement_id = str(uuid.uuid4())

    desiredPlayerSessions = list()

    for player in group['Players']:
        desiredPlayerSessions.append({ 
                'PlayerId':  player['PlayerId'],
                'PlayerData':  player['Skill']
        })

    response = gamelift.start_game_session_placement(
	    PlacementId=placement_id,
	    GameSessionQueueName=queue_name,
	    GameProperties=[
	        {
	            'Key': 'Skill_Level',
	            'Value': 'Highest'
	        },
	    ],
	    MaximumPlayerSessionCount=match_size,
	    GameSessionName='My Matched MP Game',
        DesiredPlayerSessions= desiredPlayerSessions
	)

    print("Game Session Status: " + response['GameSessionPlacement']['Status'])
    
    return placement_id
    
def update_players_in_group_for_match(group):
    for player in group['Players']:
        update_player(player, group['PlacementId'], 'Matched')
    
def update_player(player, placement_id, status):
    print('Updating Player with Placement Id and setting status to Matched')
    
    table = dynamodb.Table(table_name)
    
    response = table.update_item(
        Key={
            'PlayerId': player['PlayerId'],
            'StartDate': player['StartDate']
        },
        UpdateExpression="set PlacementId = :g, MatchStatus= :t",
        ExpressionAttributeValues={
            ':g': placement_id,
            ':t': status
        },
        ReturnValues="UPDATED_NEW"
    )

 

Figure 4 – Example Python code for creating Amazon GameLift session placements.

  1.  Connecting to a game
    In Step 3, game clients receive game session details from the Lambda function and Amazon GameLift. Game clients can now connect directly to the game server and start play. The direct connection between the client and the game server means that Amazon GameLift adds no additional latency to gameplay.

In Summary

Multiplayer games continue to grow in popularity. To succeed, they will need rapid, seamless scalability and very high levels of reliability to support millions of players who love these experiences.

Many multiplayer games can benefit from customized matching that brings together the groups of users who will get the most from playing each other. Players in several game genres expect high-quality matchmaking to ensure the best experience possible. Therefore, your player-matching algorithm can be a key ingredient of your title’s success. The serverless matchmaker pattern we’ve discussed here allows you to use any algorithm and variables that match players for your game, while also taking advantage of Amazon GameLift’s benefits to better manage your server fleet.

Amazon GameLift’s game session placement feature is a good fit to support our matchmaker pattern while providing players the best possible gaming experience. As a robust hosting service, Amazon Gamelift also controls all management operations of the server fleet.

It can automatically scale capacity based on player demand and is charged on a pay-as-you-go basis, so you can better control costs while still serving your players. Amazon GameLift also makes it possible to run multiple versions of fleets in parallel and to switch between them via aliases. To get started, you can download the Amazon GameLift Server SDK and manage your operations using the AWS Management Console, AWS CLI, or the Amazon GameLift APIs, which are available in C++, C#, and several other languages.

Amazon GameLift’s ability to handle an unknown level of demand comfortably and automatically can allow developers to focus on making their gameplay experience unique and special. This serverless matchmaker pattern provides an elastically scalable architecture for your server backend that can handle unpredictable demand, and manage many aspects of your infrastructure automatically. The result: a reduced burden for game developers and operators, while giving your customers a superior and seamless experience.

Peter Chapman is a Solutions Architect in the Amazon Gamelift and Lumberyard teams. He has over 12 years of software development and architecture experience. He has designed solutions in many industry sectors including Retail, Healthcare, and Gaming.

 

SpeedTree 8 – Free for Lumberyard Developers

Following the release of Starter Game, we’re thrilled to give you another tool for building imaginative worlds in Lumberyard. Introducing SpeedTree 8 for Lumberyard, available free to all Lumberyard developers starting today. You can download it here.

The combination is a powerful one: take the industry-standard in 3D vegetation modeling, seamlessly integrate it with Lumberyard’s advanced rendering and lighting technology, and remove any subscription cost. The result is a faster, more intuitive way to create visually stunning worlds for your games. We can’t wait to see what you’ll build.

Over two years in the making, SpeedTree 8 comes with dozens of new features and enhancements. For a full list of updates, be sure to check out SpeedTree’s website. Here are some highlights you can look forward to in this release:

  • Full PBR material workflow and rendering – PBR rendering and a revamped material workflow give you more precise control over your maps. You can also adjust your models before exporting them into Lumberyard, saving you time and effort.
  • New Generators – Sometimes imperfections can make your trees appear more lifelike. With these new generators, you can create a variety of realistic features on your trees, including knots, fungi, gashes, and cavities.
  • New Shape Control – This feature allows you to easily bunch branches together, so you can achieve more natural, organic shapes in vegetation (such as the “broccoli” effect.) You can create large clumpy trees or small clusters within your tree branches.
  • New SpeedTree Library – Buy stock assets, including 2K leaf textures and 8K bark textures. Get access to thousands of species of trees from around the world—an incredibly diverse, high-quality collection of models and materials.
  • And much more – Including unlimited age variation; one-draw-call models with tiling textures, wind, and LOD; new techniques for low-poly branch structure modeling and mesh editing; and automatic vertex color painting for wind, with an in-modeler preview.

Getting SpeedTree 8 for Lumberyard is simple. Just visit the SpeedTree store and follow the steps to activate your perpetual license, which includes complimentary updates for the next year. There’s also in-depth documentation and a quick start tutorial to help you get started.

For more information on SpeedTree 8 for Lumberyard, you can check out our FAQ. And make sure to share your SpeedTree 8 screenshots with the Lumberyard community on Facebook, Twitter, and the forums.

Kevin Ashman has been working with game engine technologies since ’99, helping to build proprietary engine technologies, evaluating and migrating to commercial engines and middleware, and helping companies evaluate and migrate from their technologies to commercial game engines and middleware. He is now focused on the ecosystem of middleware and working with Lumberyard.

Now Available – Starter Game

by John Noonan | on | Permalink | Comments |  Share

Following the release of Lumberyard Beta 1.9, we’re excited to announce a big addition to our ready-to-use sample content. We call it Starter Game.

Starter Game is the first complete game sample to showcase the latest capabilities of Lumberyard, Amazon’s free AAA game engine. Think of it as a “what’s what” of engine features: component entities, real-time global illumination, 3rd person camera and locomotion, interiors and exteriors, particle effects—all of these come to life in Starter Game in a big way. It’s not just a quick path for getting started with the engine; it’s also a great example of what you can build today using Lumberyard.

We first gave you a glimpse of Starter Game at GDC 2017, and now we’re happy to give you the entire project for free, including full source and assets. Whether it serves as inspiration for a game of your own, or as a way of learning Lumberyard’s features, Starter Game is another tool for helping you reach your game dev goals.

Watch this video on how to download and install Starter Game.

In many ways, Starter Game started with you. We heard your requests for more sample content—please keep that great feedback coming by the way!—and then looked for ways to incorporate features from 1.9. So we started working with Climax Studios, known for their great work on Silent Hill: Shattered Memories and the Assassin’s Creed Chronicles series. With Climax’s decades of experience, and your great suggestions, Starter Game was born.

One feature that Starter Game leverages in particular is our new Component Entity system, which was recently updated in 1.9. This system provides a modular and intuitive way of constructing game elements, helping you create complex entities faster and with minimal effort. Starter Game uses the Component Entity system wherever possible, including Player Control, AI, UI and Particles. It also shows how this new system can be used in conjunction with legacy tools and APIs (e.g. terrain brush, FlowGraph, etc.), freeing you to adopt new features as you see fit.

In addition to components, another request we got from developers was to include an example of bipedal locomotion, since humanoids are the most common form of player characters. Enter Jack: the fully modifiable, two-legged robot of Starter Game, complete with a trailing third-person camera. You can learn from Jack’s setup, tweak parameters to change the feel, and bring it into your game to accelerate your prototyping. Jack also utilizes AimIK, an inverse kinematics system to point the held-weapon appropriately at targets, without creating bespoke animations. Thanks to AimIK’s procedural generation, you won’t need to create individual animations for every single angle or posture, saving you time and effort.

The world of Starter Game also takes advantage of Lumberyard’s voxel-based global illumination system, time of day editor, and sun trajectory tool. Lit by the sun’s angle at a particular time of the day, Starter Game shows off realistic effects like sun rays, long shadows, and volumetric fog across four square kilometers of terrain. Especially relevant for outdoor environments, the global illumination system is a great way to dramatically tweak the look and feel of your environment with just one single variable. We encourage you to play around with the game time to see how it affects the visual appearance of the world.

There’s a lot more to discover with Starter Game: waterfalls, a spaceship, indoor environments, and enemy robots—go check it out for yourself and let us know what you find! (Stay tuned for future content as well.) We’re excited to see what you build.

Be sure to share some of your favorite #StarterGame screenshots with our community on Twitter, Facebook, and the forums!

 

John Noonan has spent most of his career working on AAA console games, including the Crackdown and Halo franchises. As Executive Producer on the Amazon Lumberyard Content Team, John helps create inspiring content that demonstrates the capabilities of Lumberyard.