Lumberyard & Amazon GameLift Blog

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
Justin Miles is a Software Engineer on the Amazon GameLift team and has been working at Amazon for the past 3 years. He is a graduate of Penn State University and has spent 10 years working across multiple industries, including e-commerce, healthcare, and games. Currently, he is playing Hex TCG, Zelda: Breath of the Wild and is a big fan of all things Mario, Legend of Zelda, and Wolfenstein.

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.

Now Available – New Particle Editor Features

Whether it’s adding atmosphere to environments or imbuing characters with special powers, particle effects help set the tone of your game. With the release of Lumberyard Beta 1.9, we’re excited to announce a slew of updates to the particle editor, introducing dozens of new features, a host of usability improvements, and new platform support — all intended to make creating visual effects quicker and easier. Let’s take a closer look.

Creativity meets efficiency
It takes time to bring a scene to life in a compelling and realistic way. Creating visual effects like fire, water, or smoke (or even using a particle system for motion graphics), can be a drawn out process. To help you work quicker, the particle editor includes a strength over lifetime curve on most attributes — both for emitter and particle lifetime. This feature helps you manipulate position, color, size, and other attributes in a simple, efficient way directly on the attribute itself. By combining animation over the particles lifetime with a curve also set on the emitter lifetime, you can achieve complex effects with a few simple steps.

Here’s an example of curves affecting particle size:

Another way Lumberyard 1.9 makes it easier to create complex effects is by integrating the particle system with the new component entity framework and EBus system. This integration provides a solution for adding per-entity-variety to particle effects at run-time, allowing you to set or script several attribute modifications to be event, time, or trigger based. The dynamic component attributes also provide the ability to set the influence of the strength curves shown above on a per entity basis.

We’ve also added a host of improvements to our GPU particles, bringing their feature support closer to that of CPU particles. One of these new GPU features is depth-based cubemap collision, which allows you to define an area around the emitter for particles to test against and achieve accurate view-independent collisions. Like CPU particle physics properties, these features can be tuned to interact with all or parts of your scene geometry. Lighting, wind, gravity and other rendering and physics systems are able to influence particles either globally or by local volumes, making your effects more believable and realistic.

New Emitters
We’re also excited to add five new emitter types to the particle effects system. When using these emitters on their own, or in combination with multiple emitter types, you can achieve very complex effects.

The new Point Emitter, for example, provides a spherical distribution emitter that you may be familiar with from other effects software. Whereas the Sphere and Circle Emitters provide less common features, letting you animate particles over relative axial coordinates.

You can animate streams of particles on standard XYZ coordinates with the Box Emitter, or confine them to a specified bounds on each axis. Additionally, the Beam Emitter can be used for more motion graphics type effects, as well as more organic beam results.

Create fast in a customizable environment
We’re always looking for new and creative ways to help artists move fast. To improve efficiency and iteration time, Lumberyard includes a dynamic library system that lets you work on several effects within the same environment — all without needing to reload particle effects or switch to another editor instance when working on a separate effect. Effect Libraries can contain many different particle systems categorized according to an artists needs. For example, a team might want to have all of the forest effects in a library named “Nature_Forest,” or libraries tailored to specific characters. In the library pane, you can interact with particle emitters by dynamically moving, parenting, grouping, and creating folders for organization in a hierarchy. In addition to displaying the attributes of selected emitters, this makes modifying any piece of an effect quick and efficient.

To maximize workflow efficiency, you can customize the Library, Attribute, and Preview panes in the particle editor. Attribute sections (such as movement, lighting, size, etc.) can each be docked and tabbed in the user interface and saved as a custom layout. In addition to customizing the interface, you can drag and drop a set of commonly used attributes into a unique custom attribute section and save for quick access. I always keep particle count, particle lifetime, color, size, and, speed in my custom attribute list. Since I’m constantly iterating on these five attributes, this helps me finish an effect and achieve the desired look with a base effect that’s fully optimized. Each layout or custom attribute pane can be shared across the team.

Samples and Testing Grounds
The Particle Technical Samples level is a great place to dive in and learn about these particle editor features. You can find it in the Lumberyard Samples project, which is the default project for any new install of Lumberyard. You can also check out our online tutorials to learn how to create a wide variety of stunning effects.

Here are a few samples you will find in this level:

“Creativity is contagious. Pass it on.” – Albert Einstein
The particle editor is a great example of how customer feedback has shaped feature development at Lumberyard. To learn more about using these new features, you can read our online documentation and visit our tutorials. As you familiarize yourself with the particle editor, we’d love to see the effects you’ve created. Be sure to show off your creativity in our particle editor forums. If you have questions or issues, we always appreciate hearing from you on the forums as well.

 

Trent Campbell has been directing art and animation in PC and console games for nearly fifteen years, including franchises like Star Wars, Aliens, and Dungeon Siege. Having joined Amazon in 2012, he now is Product Manager for graphics in Lumberyard. Aside from being an animation and visual effects nut, he enjoys telling stories through fiction writing and filmmaking.

Now Available – Lumberyard Beta 1.9

Today, we’re excited to announce the availability of Lumberyard Beta 1.9, our biggest release yet.

With over 473 improvements, fixes, and features, this release includes a new Player Account Cloud Gem for implementing player authentication in under 30 minutes, Component Entity workflow updates for building complex content faster, new GPU features and emitter types for the particle editor, so you can fill game worlds with visually stunning effects, and lots more. You can download Lumberyard Beta 1.9 here.

These improvements are a direct result of your feedback. We’ve talked in the past about kaizen – the Japanese word for “continuous improvement,” which remains one of our team’s core philosophies. Because of your great suggestions and ideas from GDC last month, we were able to reinforce our commitment to kaizen in some major areas of Lumberyard. Here are a few of them:

New Player Account Cloud Gem

One of the most common requests we got at GDC was to deliver more Cloud Gems. Released in February, our exclusive Cloud Gems Framework made it easier for developers to build and launch connected game elements (e.g. dynamic content, leaderboards, live messages) in as little as 30 minutes with one engineer. For this new release, we’re adding the Player Account Cloud Gem to Lumberyard’s growing collection of gems, providing a customizable, stand-alone solution for player authentication and management. If you’re looking to require a game key when players register for your game, or to store additional metadata for players in the cloud, the Player Account Cloud Gem will save you time and effort.

Here’s why. Traditionally, to implement a player account system yourself, you would need to setup a database service to store account information, implement secure hashes to protect player information, and then implement a service and e-mail system, so players can recover lost passwords and user IDs. You would also have to setup a login flow, identity caching, and expired authentication token renewal processes in the game client. This work could take several months for 2-3 engineers to accomplish, and if you got something wrong, there’s the risk your players couldn’t get into your game. With the Player Account Cloud Gem, this is simplified to just a few steps, so that one engineer can make it all happen in about 30 minutes. As a result, anyone can manage and update player data from the Cloud Gem Portal dashboard:

Component Entity Workflows

We also debuted the latest workflows for the Component Entity system at GDC this year. Because of your feedback, we were able to make some key improvements to this release, providing a more modular and intuitive method for constructing game and engine elements. The goal with the new Component Entity system was simple: to help developers create complex, working entities faster and with minimal effort, regardless of whether you are building a small, casual game, or a massive, AAA experience. Let’s look at some ways we’ve recently improved the Component Entity system.

First, the new Component Entity system employs reflection, serialization, and messaging to automatically expose features of components to designers, with no additional engineering required. This means you can drag-and-drop and edit component properties right in the Lumberyard Editor, creating fully cascading prefabs, which we call “slices,” in just a few clicks.

Second, to help reduce your effort and accelerate iteration, we made it difficult to create entities that don’t work. For example, if you try to add a duplicate component on the same entity (e.g. more than one static mesh), the system won’t let you make that mistake. If a component requires another component to function (e.g. the simple animation component requires a skinned mesh to work), we automatically add the dependency, so you don’t have to.

Third, we wanted to create more flexibility on how the new Component Entity system handles missing or mistaken configurations. An entity can now contain invalid and incompatible components, but we display any service problems with a new warning system. Warnings help you correct any problems and give you quick choices to fix missing dependencies. For instance, if you add a Primitive Collider without first adding a Shape, the Primitive Collider will suggest that you add a Shape, letting you choose the type of Shape you want in just one click. Until a Shape is added, the Primitive Collider doesn’t register, thus preventing runtime problems if you run the game before selecting a Shape.

Lastly, thanks to your feedback, we’ve also made new usability improvements to the Entity Inspector. The Inspector can now remember the order in which Components are added, allowing you to rearrange Components more easily through the right-click menu. (We’re also planning to add drag-and-drop in a future release.) We have also enabled cutting, copying, and pasting Components across entities, improved the search functionality to help you navigate large amounts of content, and redesigned the component UI to improve readability.



Particle Editor

The particle editor also received a big update this month. Moving out of preview with this release, the particle editor includes dozens of new features, usability improvements, and improved mobile platform support, so you can more easily create stunning visual effects for your game. You told us that you wanted simpler and more flexible emitter handling, so you could better achieve an epic scale of particle effects. You also wanted more specialized emitter types to help you iterate faster. With the release, you got it all. Lumberyard Beta 1.9 includes re-configurable emitter hierarchies for easily managing your emitter parent-child relationships, GPU feature additions for pushing hundreds of thousands of particles in an effect, and five new emitter types.

And More

There’s a lot more to Lumberyard Beta 1.9, so be sure to check out the full release notes here. Other highlights include a new one-step, express installation process, support for both Z-up and Y-up world coordinates in the FBX importer, improved search functionality for the Asset Browser, Component Entity and Lua support for the UI Editor and Twitch Metastream, support for versioned Gems, and much more.

Of course, it was impossible to address all of the great feedback that came out of GDC in just the last six weeks. We’re continuing to practice kaizen by aggressively iterating on workflows, improving engine performance, integrating new cloud capabilities, helping you build the most ambitious and highest-quality, multiplayer, live, and community-driven games. Please continue sending feedback and suggestions to our forums or by emailing us. The team loves hearing from you.

To get started with Amazon Lumberyard, please visit the Lumberyard website to download the engine. You can learn more about Lumberyard’s new features by watching our Tutorials, visiting the Forums, or reading through our Documentation.

Now Available – Lumberyard Beta 1.8, Introducing the Cloud Gems Framework

AirplaneWe’re excited to announce the release of Lumberyard Beta 1.8, which you can download here. This release contains over 234 new improvements, fixes, and features, and introduces Cloud Gems Framework, a new framework designed to help you build popular cloud-connected features in as little as 30 minutes with one engineer.

As AWS, we are fortunate to work with many of the industry’s best game studios, from the earliest pioneers in mobile and social, like Supercell and Zynga, to PC and console developers with galaxy-sized ambitions, like Cloud Imperium and Leslie Benzies’ Everywhere. We’ve seen developers harness the cloud for innovation and growth, connecting players together at a scale that was previously impossible, enabling new forms of competition and gameplay, and giving their teams deep and real-time insights into what their players like – and don’t like – about their games.

Customers tell us that as important as the vast compute and storage of the cloud is to their successful games today, the cloud will become even more critical to the creativity and scale of the next generation of games. The amount of developer demand for connecting global audiences, using mass compute to push creativity, and building more social and multiplayer features, made “deeply integrated with AWS” a founding pillar of Lumberyard.

We define “deeply integrated” in two ways. One, we want to make it as easy as possible for you to build common connected elements, like multiplayer, social features, and dynamic and live content updates, in your game. We want you to focus on great gameplay, not hiring expert backend engineers and spending months or years building undifferentiated infrastructure. Next, we aspire to help you create fantastic new types of gameplay and real-time interactions made possible by massive on-demand, global compute and storage. Here, we’re inspired by the game teams thinking about procedural gameplay, complex artificial intelligence, and games of huge scale and incredible fidelity.

Lumberyard Beta 1.8’s new Cloud Gems Framework makes it easier for you to build and launch connected game elements, such as dynamic content, leaderboards, and live messages. With the Cloud Gems Framework, you can add a connected feature to your game in as little as 30 minutes, with one engineer, freeing up the rest of your team to think about innovation and player experience.

The Cloud Gems Framework is made up of the Cloud Gem Portal, a web application that lets anyone on your team visually manage your cloud features (e.g. scheduling messages, releasing dynamic content, or deleting a fraudulent leaderboard score), and Cloud Gems – modular packages of discrete functionality and assets that include everything necessary for a developer to include that functionality into their project, including backend and client functionality. Cloud Gems can be used out of the box in production, and they come with full source code in case you want to customize their behavior in whatever way you choose.

Cloud Gem Portal

Lumberyard Beta 1.8 includes three sample Cloud Gems to help you get started quickly:

Dynamic Content Cloud Gem
Many of today’s successful games are live and “always-on.” Teams want to be able to better engage players by adding and changing content frequently, with as little friction as possible to the development team. With a dynamic content backend, your team can quickly respond to player feedback, offer special characters, A/B test gameplay features, or just add new characters or levels to a game to extend its life – all without requiring your players to download an updated executable and install it themselves.

To build a dynamic content system yourself, you would need to stand up servers to host the content, create a scheme to specify what dynamic content is available, deal with versioning of the content, build tools to upload the content to your servers, write engine code that queries your server to see when content has changed, build a robust downloading and verification system, and finally write the code that hot-loads that content into a running instance of your game. This work could take 2-3 engineers several months to get right, and if this system fails, players may never see the content your team worked hard to create.

With the Dynamic Content Cloud Gem, you can package, upload, and deliver content to your players in as few as 7 steps:

  1. Enable the Dynamic Content Gem in Lumberyard Project Configurator
  2. Click “Upload Resources” from the Cloud Canvas Resource Manager
  3. Open the Dynamic Content Manager from the Editor’s AWS menu
  4. Create the manifest that lists your dynamic content
  5. Click “New Package” from the Dynamic Content Manager
  6. Drag and drop the assets you want to upload
  7. Click “Upload Packages” from the dynamic content manager. This puts the content in the cloud and marks it as private.

Once your content is uploaded to the cloud, you can use the Cloud Gem Portal to release your content immediately or schedule the content for release later, letting you determine exactly when players receive the updates to your game. When the new content has been downloaded by the player, the Dynamic Content Gem automatically loads the new content and makes it available in the game.

Leaderboards Cloud Gem
Competition is a great way to foster player community – in January, eight of the top ten games watched on Twitch were competitive multiplayer games. Adding a leaderboard to your game is a popular way to encourage competition in your community. Traditionally, to set up a leaderboard, you would have to provision database servers (in a scalable manner) to store the high score data, write and deploy REST endpoints to gather the scores, write a web-based console or other application to manage the high score data on the server, and teach client-side developers how to make appropriate network calls to send the player’s score to the REST endpoint. With the Leaderboard Cloud Gem, this is simplified to 4 steps that an engineer can accomplish in about 30 minutes

  1. Enable the Leaderboard Cloud Gem in Project Configurator.
  2. Click “Upload Resources” from the Cloud Canvas Resource Manager.
  3. In the Cloud Gem Portal, create as many leaderboards as you want based on the statistics on which you want to rank your players.
  4. Send the player’s score or other data to the cloud at appropriate intervals using simple calls to the Leaderboard component from script or C++.

The Cloud Gem Portal also provides a console for managing the players on the leaderboard, and allows an administrator to delete fraudulent scores and ban players that abuse the system.

Message of the Day Cloud Gem
Another way to foster engagement is by sending messages to your players at opportune moments, whether to notify them of special offers, new content updates, or send any other timely communication as you wish. Traditionally, you would need to provision and configure a set of scalable database servers, write a web-based application to manage the entry, modification, deletion, and scheduling of the message content, write REST endpoints to serve the message content, and write client-side game code to request the messages and display them. Using the Message of the Day Cloud Gem you can get there, again in 4 steps and about 30 minutes:

  1. Enable the Message of the Day Cloud Gem in Project Configurator.
  2. Click “Upload Resources” from the Cloud Canvas Resource Manager.
  3. In the Cloud Gem Portal, create and schedule as many messages as you want.
  4. Query the list of active messages from Message of the Day component using simple calls from script or C++.

We have more Cloud Gems in development, so if you have any particular cloud functionality you want to see next, let us know on the forums. Also, if you’re going to be at GDC next week, stop by the Lumberyard booth to meet the Cloud Canvas team and get a hands-on demonstration of Cloud Gems, or sign up for our GDC devday to watch us take a game from zero to cloud-connected in real time. We’ll also provide some glimpses at our future vision for how the AWS cloud can enable new types of gameplay and real-time interactions.

There’s lots more to Lumberyard Beta 1.8, too. You’ll find a streamlined information architecture of our menus in Lumberyard Editor, root motion animation support in the FBX importer, mobile and console support for the multiplayer sample, multi-UV support for meshes, language support in the UI editor, and more. For details on everything new in this release, check out the full release notes.

To get started with Amazon Lumberyard, please visit the Lumberyard website to download the engine. You can learn more about Lumberyard’s new features by watching our Tutorials, visiting the Forums, or reading through our Documentation.

Streamline Case Study: Accelerated Launch with Amazon GameLift


About Proletariat

Founded in 2012 by five game industry veterans, Boston-based Proletariat is an indie game company focused on building innovative multiplayer experiences. They’re the masterminds behind the award-winning World Zombination, a massive online game where players work together to strategize with armies of zombies or humans to attack and defend cities. Their newest multiplayer game, Streamline, is built for audience interaction and allows streaming broadcasters and viewers to change gameplay rules in real-time during a match.

The Challenge

Proletariat announced Streamline at GDC 2016 in March and had planned to unveil their beta in September at TwitchCon 2016, the premier event for game streamers. But, when Amazon approached them with an opportunity to be included in the Twitch Prime public launch at TwitchCon 2016, Proletariat decided to accelerate their development to make Streamline available for everyone to play. Proletariat was excited but concerned that their custom game server solution was already too time-consuming to manage and lacked the functionality needed to support increased player demand.

Proletariat’s custom cloud solution was built around AWS Elastic Container Service (ECS), a container management service that makes it easy to manage applications on AWS EC2 instances. They manually operated basic game server functionalities, like running server health checks and connecting players to available game servers. These processes worked for their player load but would be too time-consuming to manage once Streamline became publicly available. Their custom cloud solution also could not identify which game servers had active game sessions. This meant that while they were manually scaling their server capacity, they could accidentally scale down an active game session and disconnect players from Streamline. It was also difficult to simplify testing because they could not run multiple game server processes on a single EC2 instance. Each game server needed a unique public port, but the team could not retrieve the public port number from inside its container.

Proletariat wanted to keep using AWS’s proven infrastructure to host their game servers, but it would take thousands of hours to build the functionality they needed. With TwitchCon 2016 fast approaching, Proletariat was introduced to Amazon GameLift; an AWS managed service that simplifies game server hosting and scales server capacity in minutes.

“For the team at Proletariat Inc., the choice was pretty simple – hire a team of engineers to spend months building out our cloud infrastructure, or deploy with Amazon GameLift in just minutes.” said Seth Sivak, CEO, Proletariat Inc.

The Implementation

Proletariat downloaded the Amazon GameLift Server SDK for C++, integrated it into their Unreal Engine game server build, and uploaded their game server to Amazon GameLift. To house their Unreal Engine game server, Proletariat needed to decide which of the 5 Amazon GameLift instance types would best fit their needs. “Being a real-time game, we needed network optimized Amazon GameLift instances, so we chose c4.xlarge.gamelift instances for our fleet,” said Cauê Waneck, Streamline’s Lead Engineer. ”Amazon GameLift lets us set our runtime configuration to support four game servers on each instance, which is perfect because our servers are single-threaded. This lets us leverage one game server process per vCPU, which greatly simplifies our testing and iteration processes.”

Proletariat used the AWS JavaScript SDK with Amazon GameLift to manage the creation of new game sessions between its custom-built Node.js matchmaking system and their C++ game servers on Amazon GameLift. They also used specific game session data to find game servers with available capacity for quick matches. This data helped them classify whether a server should accept new players and identify which game sessions had available player slots. “Amazon GameLift made it so easy for us to matchmake high volumes of players and reduce wait time. Amazon GameLift is super easy to implement and performs really well,” said Waneck. “It also helped us give our players the ability to host custom game matches because we could associate a game session with a party leader. “

Proletariat also activated Amazon GameLift’s built-in game session protection to prevent instances with active games from scaling down and taking players offline. “Amazon GameLift is like an insurance policy – it gave us peace of mind about server scaling, especially at launch,” said Waneck. “It was easy to set up and monitor using the Amazon GameLift console. We can also easily turn on automatic server scaling when we need it as well.”

The AWS Command Line Interface (CLI) with Amazon GameLift made it easier to launch new fleets and reuse commands when implementing logic in Proletariat’s build system. While deploying game client updates, Proletariat used simple commands to leverage Amazon GameLift aliases to transition players from one fleet to another with no downtime. Proletariat also used the CLI to launch its game servers in regions around the world in just minutes. “The Amazon GameLift team supported us the whole way through. It’s nice to know they are there 24/7 to help us tackle any operational issues, so we don’t have to,” said Waneck.

In just five days, Proletariat used Amazon GameLift to release Streamline with confidence at TwitchCon 2016. Amazon GameLift saved them thousands of development hours that they instead used to focus on polishing the innovative gameplay that lies at the heart of Streamline.

More information

Learn more about hosting and scaling dedicated game servers with Amazon GameLift. Read more about Streamline: playstreamline.com.