Case StudyDEV ELOPI N G ' T H E D.R.G . I N I T I AT IV E' WI T H A MA Z ON LUMBERYA RD

Graham WatsonDirector & Co-founder

Third Kind Games3rd July 2017

Introduction

• Talk about our hands-on experience using Amazon Lumberyard to develop ‘The D.R.G. Initiative’.

• Highlight some of the new systems that Amazon have introduced, and how we have made use of them.

• Talk about challenges we faced along the way.

• Tips on making a multiplayer E-sports title with Amazon Lumberyard.

Who are we?

• Third Kind Games (TKG).

• New indie studio, formed October 2016.

• 9 Senior AAA developers from former Activision Studio FreeStyleGames (DJ Hero, Guitar Hero Live).

• 1 Artist, 1 Designer, 1 Producer, 5 Programmers, 1 Tools/IT Programmer.

• Developer on SlingShot Cartel’s ‘The D.R.G. Initiative’.

www.thirdkindgames.com https://www.facebook.com/thirdkindgames/ https://twitter.com/ThirdKindGames

What is ‘The D.R.G. Initiative’?

• New E-sports game from SlingShot Cartel, built with Amazon Lumberyard.

• In development for 8 months so far. Pre-release later this year.

• Team-based fight-to-the-death TV show, set in a future post-apocalyptic world.

• Designed and built with E-sports in mind from the ground up.

What is ‘The D.R.G. Initiative’?

• Large, beautiful environments.

• Multiple factions with their own unique skills and play styles.

• Audience participation via Twitch. Voting for key game events such as loot drops.

• Gamemaster role controls broadcasting, audience participation, and match direction.

Why Lumberyard?• Acquired from CryTek, Amazon started with a mature and proven engine, so

they weren’t playing catch up.

• Significant technical investment from Amazon. Large internal engine team, as well as multiple internal Amazon studios building games with the engine.

• Heavy focus on E-sports and multiplayer gaming features from the start.

• Amazon owns Twitch, AWS, Gamelift, and continue to grow in the multiplayer gaming arena. Lumberyard makes it easy to tap in to these technologies.

• Young engine, opportunity to provide steer and not have to ride the wake of larger studios.

• Full source code means that we can modify the engine, fix bugs, and make tweaks without large production overheads.

Working with a Beta engine

PROS

• Full source code means you can modify the engine and fix any bugs.

• Modern code architecture, designed for today’s and tomorrow’s hardware.

• Regular releases containing new features and bug fixes.

• Responsive support from an upbeat dev team.

• No baggage from heavy-weight ancient games. Direction of engine is unrestrained as Amazon are free to deprecate and upgrade old systems.

• All the new stuff is much better than the old stuff!

CON S

• There are bugs!

• Sometimes, core systems may change with new releases.

• Some features are missing or not production-ready.

• Community is small, but growing.

• Lots of deprecated systems hanging around in the code base.

• Sometimes there is duplication of types, requiring conversion, e.g. string.

Feature highlight - Twitch

• Twitch Chatplay, Voting and JoinIn.

• Enables audience participation in the game.

• Game asks the audience to vote.

• Twitch chat votes are tallied up automatically and reported to the game.

• Game makes decisions based on the voting results.

Feature highlight - Metastream• Allows Twitch broadcasters to

completely customise their channel with bespoke game overlays.

• Game provides a HTTP server which can be queried via a RESTful JSON API.

• Web browser can query game details and render them via HTML/Javascript/etc.

• Broadcasting software such as OBS Studio and XSplit Broadcaster can overlay the HTML on to the broadcast stream.

Feature highlight – Component Entities

• Modern component-based entity system.

• Supports C++ and Lua components.

• Rich set of UI widgets for component properties.

• XML format, so can be merged easily in source control.

• Ever-growing list of stock components.

Feature highlight - Gems

• Gems are reusable nougats of code and/or assets, which provide features to the game.

• A Gem can contain components, scripts, assets, event buses, and systems.

• Encourage separation of purpose, and well-defined inter-system communication.

• Makes you code with reuse in mind.

Feature highlight – Event Bus

• Event bus (ebus) provides a clear and efficient mechanism to communicate between classes and components.

• Works across Gems, hiding the bother of dll export/import configurations.

• Works from Lua and C++.

C++

Lua

Feature highlight - Profiler• CPU, VRAM, and network profiler:

http://docs.aws.amazon.com/lumberyard/latest/developerguide/profiler-intro.html

Feature highlight – Lua IDE• Lua Editor and Debugger:

http://docs.aws.amazon.com/lumberyard/latest/developerguide/lua-editor-debugger.html

• Live link to engine.

• Single-step debugger.

• Built-in class and event browser.

Feature highlight – UI Editor

• Responsive, dynamic UI.

• Animation support.

• Component based and extensible.

• Scripting support via Lua.

‘The D.R.G. Initiative’ Game breakdown

• ~30 bespoke Gems providing additional features to the engine.

• ~24 bespoke entity components providing custom entity features.

• ~50 Lua scripts providing the high level gameplay logic, entity logic, and game rules.

• ~51 Flow modules providing UI flow, high level gameplay logic, and game rules.

Gems

A MA Z ON G EMS

• AWS

• Audio

• Boids

• Camera

• ChatPlay

• Front End

• Game Effects

• GameLift

• Input

• Lightning

• Metastream

• Multiplayer

• Substance

• Physics

• Rain

• Snow

• Tornadoes

T H I RD K I N D G EMS

• Ballistics

• Character

• Cinematographer

• Compass

• AI

• Analytics

• FlightRecorder

• Footsteps

• Inventory

• LevelManager

• MatchManager

• Minimap

• Online

• PlayerManager

• PopupText

• SpawnPoint

• Steam

• SurfaceMarkup

• Utilities

Network model

• LAN play with direct IP entry and session browser.

• Gamelift support with Linux dedicated server supported out-of-the-box.

• RPCs (remote procedure calls, guaranteed delivery) used for important events such as shooting, aiming, health, etc.

• Datasets (synchronised data blocks, eventual synchronisation), used for state synchronisation such as character movement.

• Custom motion prediction to allow clients to predict and correct the character motion between server updates.

• Server rewind to allow accurate server-authoritative hit detection.

Game rules

• Game rules define the overall gameplay logic such as match win/lose conditions, gameplay events, player join/leave rules, etc.

• Old CryEngine game rules system still exists, but is considered deprecated.

• Amazon have not yet replaced it with anything, so custom solution needed.

• Our game rules are built from a FlowGraph which is programmatically instantiated when the level starts.

• Flow graph is responsible for player tracking and general gameplay event handling.

• Flow graph is NOT good for gameplay logic such as checking if all players on a team are dead. Instead, we kick off a Lua script from our Flow graph, that provides the more complex game rules that benefit from scripting rather than Flow nodes.

Player management• Player management is the bookkeeping and co-ordination of players within a game session.

• Old CryEngine ‘Actor System’ still exists, but is considered deprecated.

• Amazon have not yet replaced it with anything, so custom solution needed.

• Our Player Management Gem fulfils this by providing a bespoke C++ system to track players.

• It consists of a system component that handles networking events and uses RPCs and Data Sets to keep the player list synchronised between all clients in a session.

• It holds key data, such as the player’s chosen characters, current possessed character, and ready-state.

• It communicates key player events to other Gems, such as ‘player joined’.

• Implemented with security in mind – Server is authoritative, and clients can only modify their own player data, with all the other players being synchronised to them from the server.

Characters• A DRG character is made up of components and Lua

scripts.

• Heavy use of Lua scripts (9 scripts per character) to control how the character’s components interact with one another and in response to external stimuli such as controller input or damage.

• Characters are stored on disc as Dynamic Slices (runtime-instantiated prefabs), and spawned in to the level by the game rules Flow graph on the server at the start of the match.

• The server then assigns the newly created entities to the players via the Player Manager Gem.

• The entities are replicated to the clients via GridMate, and clients assume control of their characters.

Multiplayer tips

• Build with security and anti-cheat in mind.

• Server-authoritative, plus prediction/correction on clients to avoid lag.

• Design your client-server communication with anti-cheat in mind, e.g. send inputs vs. send transform.

• Minimise client touchable data, for example ensure that a client can only send data about its own player’s characters.

• Use Datasets for state, and RPCs for important events.

Multiplayer tips

• Optimise your data. Bandwidth costs money!

• Use the network profiler:http://docs.aws.amazon.com/lumberyard/latest/developerguide/network-profilers.html

• Test in low bandwidth, high latency situations.

• Use the network simulator:http://docs.aws.amazon.com/lumberyard/latest/developerguide/network-carrier.html

Things to avoid• Don’t edit the engine code unless absolutely necessary.

• If you are adding code, make a Gem.

• If you need to fix an engine bug, mark it with a clear comment so that you can see that it has deviated from the vanilla version of the engine, otherwise future merges could get tricky.

• Use branches in your source control system to keep a copy of the vanilla version of the engine. Install new versions to the vanilla branch and then merge them to your mainline.

• Don’t add code to the game project itself.

• Other than bootstrap code for starting the game up, everything should go in Gems.

• The game dll may one day be deprecated as more legacy Cry systems are deprecated and their replacements use Gems.

Things to avoid• Avoid using the legacy Cry systems. Many of them are still in the process of being

deprecated and will soon disappear. In-particular:

• Avoid Cry Entities in favour of the new Amazon Component Entities.

• Avoid Cry Game Rules and Actors.

• Avoid Cry Lua scripting in favour of the new Amazon Lua scripting.

• Avoid Cry Input in favour of the new Amazon Input Bindings.

Learning resources

• Third Kind Games BlogTech blog and tutorials on all things Lumberyard and game dev.https://blog.thirdkindgames.com/

• Amazon Lumberyard ForumsOfficial forums for asking Amazon questions, reporting bugs, discussing techniques, etc.https://gamedev.amazon.com/forums/index.html

• Amazon GameDev TutorialsOfficial tutorial site.https://gamedev.amazon.com/forums/tutorials

• Amazon Lumberyard DocumentationOfficial documentation for Lumberyard.http://docs.aws.amazon.com/lumberyard/latest/userguide/lumberyard-intro.htmlhttp://docs.aws.amazon.com/lumberyard/latest/developerguide/Lumberyard-intro.html

Shameless plug‘The D.R.G. Initiative’ Mailing List

Receive news announcements on the game and opportunities to take part in betas.

http://www.thedrginitiative.com/

Thank You!