Learning Lumberyard has a steep learning curve, because it is a AAA game engine which is still in beta. The transition from Unity to Lumberyard can be difficult, however this document is here to help guide that transition by bridging the terminology differences and comparing features/editors.

Where Unity has had time to mature and cater to the needs of the developers using the tool, Lumberyard is still in very early stages. Lumberyard can be compared to versions prior to Unity 5 with regards to user experience. However, being a AAA engine means Lumberyard has some features better implemented than Unity. Like Unity, Lumberyard is iterating versions to improve the engine. However, unlike Unity, Lumberyard is still in the phase of making feature breaking changes, deprecating systems, and pushing partially implemented features to developers. Unlike Unity however, Lumberyard’s engine code is openly available to view/modify, so fixing these issues can be done prior to the next version release.

Downloading Unity is a streamlined process, with the ability to download any version prior to the most recent as well the new beta versions of the year. Lumberyard’s download process is more complicated, split between an express and custom install. Beta for Lumberyard isn’t the same as Unity’s betas, because in Lumberyard, there are bugs which can be game breaking rather than a specialized use case. There are past versions of Lumberyard available, however it is not recommended to download them unless there is specific project which utilized the older version. Older versions are less feature-rich, missing features of the current version, and are less bug-free than newer versions. Lumberyard doesn’t offer versions prior to version 1.9, because the engine has advanced so much since.

Unity downloads are filtered into 3 versions: Personal, Plus, and Pro where certain features are locked behind a monthly subscription, including the dark theme. In addition, Unity requires developers to contact them directly for their source code license, who’s price is not publicly available. Lumberyard differs in that the engine source code is directly packaged with the download, as well as developers are provided the ability to compile the Lumberyard editor and tools. The Lumberyard engine has no pay tiers and is completely free, and developers can directly edit the engine code. Developer generated Gem code is coupled with the engine code, so changes will be seen through all projects rather than a specific project.

Being built on top of the CryEngine, Lumberyard is aimed at AAA developers who have experience. The engine isn’t easy for hobbyists trying to learn game development or individuals trying to produce a game; it is built for teams. Unity, however, being built from the ground up in the indie space works great for hobbyists, indie developers, and now many AAA developers are using.

The community of Unity is almost unrivaled with any other game engine, and they are a large reason Unity is able to thrive. The community provides tutorials, forum answers, and insight on much of the game engine which help newcomers as well continue to provide support for more advanced developers. The community of Lumberyard is relatively small, there are forums however most answers are provided by Amazon developers, the sub-reddit has only a few hundred people, and the most active group found was a slack group with hobbyists. The hobbyists of Lumberyard don’t seem to be as concerned with developing games as much as developing features, which contrasts most Unity’s developers.

The Editor

The Lumberyard Editor has a familiar feeling to most game engines, and has similarities with the Unity editor. 

The basic components in Lumberyard are also similar to Unity.

Camera Movement

The navigation in the Unity editor is focused mainly on mouse movement and rotating about a GameObject/panning, with the secondary movement of the fly-through cam. Lumberyard’s movement is similar to Unity’s fly-through cam, but closer resembles a first-person shooter (FPS) controller. Unity’s fly-through cam in (Lumberyard’s default FPS movement) has functionality of moving the camera vertically with the Q/E keys, which Lumberyard is desperately missing. However, Lumberyard has features which Unity is also missing, the ability to set the camera’s movement speed. Unity allows you to hold shift to increase speed, however lacks the ability to change the granularity of speed. Lumberyard’s camera also has the ability to enable collisions in the perspective editor, which stops the camera from passing through objects with colliders or the terrain as the camera moves about the level.

GameObject vs. Entity

Unity classifies objects in the scene as GameObjects, creating a new, empty GameObject within the scene assigns a transform to an object and allows for other components to be attached. Lumberyard uses the terminology of entity, to match computer science terminology of the component-entity-system. Entity and GameObject are essentially the same.

Adding components in Unity and Lumberyard is essentially the same, both categorize components and allow developers to modify component parameters. In Lumberyard, creating a Gem allows you to create a component which is built into the engine much like the prebuilt components. Developers can create their own grouping as well as icon for the component, and assigning to an entity is the same for assigning a C# in Unity. Creating a Lua Script is similar to C# scripts, however to assign a Lua Script to an entity requires a Lua Script component then assigning a the script to the script property, an additional step which is tedious but differentiates Lua and C++ code.

Prefabs vs. Slices

Lumberyard has prefabs and slices, however a prefab is a deprecated CryEngine feature so for the remaining of the paragraph prefab will refer to Unity’s prefabs. A Unity prefab is similar to a slice, however slices have the additional functionality of being able to be nested. Just as in Unity, entities cannot be reassigned to a slice when detached or duplicated. A slice save file can also not be overwritten from the editor like Unity prefabs. Where in Unity any GameObject can be dragged over a prefab to overwrite that prefab, once a slice is created the slice save file cannot be overwritten. The process of saving slices is more involved than just “applying” the changes. Within the Entity Outliner, right clicking the slice will allow you to quickly save the slice or advanced overrides, which allows you to specify which features should be pushed to slice (including added/deleted entities).

Folder/File Management

In Unity files can be moved and folders created to organize your project from within the editor. In Lumberyard folder management must be done in the file explorer and cannot be done in the editor. This stops files from being moved into/out of the editor/engine folders, but the main reason is because of Lumberyard’s Asset Processor which processes files for correctness and specifies the location of the file.

In Unity meta files are generated for each type of file, however Lumberyard doesn’t have a meta file generated within the project. There may be some files generated in the cache directory and Lumberyard does generate .assetinfo files for models.

UnityPackage (Packaging/Exporting Assets)

There is currently no way of bundling assets in Lumberyard like a UnityPackage. If the same folder structure isn’t maintained after transferring information or all dependencies aren’t passed, data will most likely be corrupted, such as script assignment and animator data. Gems were a suggested alternative, however seem to suffer the same consequences. After talking directly with a Lumberyard support employee, the only method Lumberyard recommends is transferring through version control. Although this may be intuitive to do always, there are some use cases for transferring through harddrive which we are hoping Lumberyard address in future release.

Asset Store

Unity has the Unity Asset Store which provides developers with art and code assets created by Unity developers as well as the community.  While this resources doesn’t exist in Lumberyard, the engine does come packaged with a few projects which can act as templates, as well as having free scripts and art assets which can be adapted to the project.

Engine Feature Support

Most SDKs developed are targeted for Unity/Unreal, and the asset store helps the community develop features and new SDKs. Since Lumberyard doesn’t have that support yet it lacks integration with some major software such as Houdini. However, Lumberyard has the advantage of being an Amazon product and so it has direct integration with AWS and Twitch. From a brief search of Twitch with Unity, there are assets however they are paid versus Lumberyard’s free integration. In addition adding to the Amazon services is allowed because it is bundled with the engine code.

Projects

The Unity project and Lumberyard project serve very similar purposes. Although, switching projects within Unity is much smoother, since you don’t need to leave the editor when you select to open a new project. Project transfer also isn’t as user friendly because it could require a recompile of the game rather than just import and play. Unlike Unity where projects can be located anywhere, Lumberyard projects must be located within the Amazon Lumberyard installation dev folder. This restriction may seem insignificant at first, but it stops you from having the freedom of being able to organize your projects.

Levels/Scenes

Lumberyard levels are analogous to Unity scenes, where in both cases the object must be located within the project folder in order to be opened. Each have data associated with them, however Unity’s packaging is in scene format where no scene data can be altered from the file explorer but with Lumberyard this isn’t packaged as tightly. [expand]

Creating Builds

Unity has streamlined the build process to be located within the editor and, on a successful build, all data is located within a folder specified by the user. Builds in Lumberyard are a multi-step process and require the editor, command line, and batch scripting. There is a 5 step process, each with sub-steps, for a successful build to be made. Unless the batch file is scripted with pauses, which the examples are not, an error can occur without alerting the developer, where Unity will just abort the build. The final step of a Lumberyard build is moving files to the right folders, which Unity does automatically for the developer. Lumberyard can deploy to PC and mobile devices without building the game, and selecting other platforms requires knowledge of command line options, unlike in Unity, these options are not all within the editor.

Engine Access

Installation Options

Both Lumberyard and Unity offer installers to install the game engines. Lumberyard only supports Windows as a platform, whereas Unity Windows and Mac. Lumberyard comes in a single installation package where the installation is customizable. Unity on the other hand offers tiers – Personal, Plus, and Pro. They also support tailored solutions for larger teams through Unity Enterprise.

The Lumberyard installation process is not entirely smooth, since there’s a need to use the command line to compile the game engine. There’s no one-click like method to resolve all dependencies, and can often be a tedious process. Unity installation is fairly straightforward where the installer takes care of pretty much everything.

Compiling the code/engine (precompiled vs runtime compilation)

Installing Lumberyard may require a developer to build the entire engine from scratch. For most use cases, this is a necessary step and can take more than an hour just for the compilation itself. And it’s not just a one-time installation burder. Creating a new project or enabling/disabling gems in a project requires configuring the Editor again. While it may not need an entire engine compilation, it still requires configuring solutions and compiling the game code through command line.

Unity does not require any explicit compilation of the engine. Once installed, any runtime compilation happens in the engine itself during loading a project, or in the background as the project is being updated.

Access to engine code

Lumberyard’s source code is freely and openly available to download and modify. There are licenses in place that prevent or regulate redistribution of the software. Developers are free to dive into the engine code and make changes that are suited to them. Lumberyard’s main revenue comes through its integration with paid AWS services. Unity source code is not freely available to use, but the license can be purchased from them. Their tailored solutions for enterprises puts an additional layer of access between users and the engine.

Creating/Configuring Project

Process

Creating a project in Unity is simple and straightforward. You can create a new project either from the Home Screen of the Unity Editor, or by navigating to File->New project in the menu bar on the Editor. The Project Wizard allows opening up an existing or creating a new project. You can customize the project creation by marking the project as a 2D or 3D project and importing assets from an asset package or the Unity Asset Store. Unity then compiles the project and the scripts in the assets and opens up the project for you.

Lumberyard project configuration happens through its Project Configurator. You can create an empty or a sample project. Project creation can take up 10 minutes where Lumberyard compiles all the files. Once the project is created, you can configure gems into the project. To select which project to open up in the Editor, Lumberyard requires the user to set a project as default in the project configurator (a button on the top right corner).

Solutions

Unity game code exists as a set of scripts. Unity has its own metadata on the existing scripts and other components. By default, Unity supports MonoDevelop for writing scripts, but also let’s the user choose their own default IDE for scripting, including Visual Studio.

Lumberyard solely uses Visual Studio for scripting purposes. Engine and Game code is distributed between various Visual Studio solutions. No other IDE is supported.

Programming

Languages

Transfering from Unity to Lumberyard can be overwhelming because CryEngine, the base engine of Lumberyard, is AAA industry veteran used in game development, where Unity has been built-up from the indie perspective and evolved into a AAA engine. Where in Unity, programmers are only given the option of using the language C#, Lumberyard offers the Lua and C++ language as well as script editor, Lumberyard’s visual programming.

In the current version of Lumberyard, it is much more difficult to start programing coming from Unity where function documentation is abundant and any question you may have has probably been answered in a few forums and by the Unity developers through updates to the engine. Lumberyard is currently lacking much of this, which leaves it to the developer to educate one another, be technically competent in reading the lines of documentation, and be able to read engine code. Unlike Unity where engine code is hidden, quite literally by a paywall, the Lumberyard source code is openly available to read to understand functionality as well as modify to meet your needs. Having access to the engine allows you to create missing functionality, where in Unity most functionality required is there, the current Lumberyard version is missing/removing some basic functionality which is useful in game development. Simple functionality that Unity developer’s take for granted, such as FindObjectByType, isn’t built into Lumberyard and similar functionality is currently being deprecated and rendered unusable.

Lumberyard’s Lua scripting is analogous to Unity’s C# in that it is the built-in, default programming language. Lumberyard includes a Lua editor, similar to Monodevelop, however with documentation of classes, bus, and notification systems built-in. This documentation however, doesn’t mean there is autocomplete feature, it requires you to understand how the Lua language operates more than C# in Unity does. We recommend you start development using Lua, and once you’ve become comfortable with Lua delve into the C++ code as the logic is coupled with the engine logic.

When assigning source code to an entity, for a Lua script you must take an additional step of assigning a Lua Script component and then assigning the script as a value to the script variable of that component. A C++ component acts the same in assigning as a C# script.

Legacy Versions

Unlike with Unity documentation where you can trust a source from over a year ago, Lumberyard is advancing and evolving so rapidly that it is dangerous to rely on anything prior to the release of your current build. Even documentation after your current build was released can be of questionable authority, because the Amazon team is struggling to keep up with their own progress. What we recommend is to try things that worked in the past, and adapt based on the version. Adapting may be you looking into engine code or simply trial and error, once you have a successful compile make sure you let your fellow developers know. Lumberyard will only become as big as Unity if the developers help build a community that welcomes newcomers and provides answers for one another. [expand]

Code Editor

Although Monodevelop is packaged with Unity and set at the default external editor tool for editing scripts, it isn’t the same as the Lua Editor. Monodevelop and Visual Studio are independent development environment, they can be used to develop other software outside of Unity. The Lua Editor is exclusively for the Lumberyard engine, and isn’t as useful for other application, although it may be used as an overqualified text editor. Another editor can be used to edit your script, however it won’t be integrated into the engine, there currently isn’t a way to set an external preference for editor like in Unity. Which means, whenever a script is double-clicked in Lumberyard the Lua Editor will open rather than the preferred editor.

Scripting

Outlined are pieces of a Lumberyard Lua script compared with Unity, see the technical documentation for structure. Adjusting to the language change will take time, especially with Lua being focused more on non-programmers ease to use rather than a programmer focus, with arrays starting a 1 and the language itself not being object oriented. Calling functions uses a colon (:) rather than a dot, variables aren’t typed and variables can be added to the table (“class”) in any function.

Requiring a script in Lumberyard is akin to having the using namespace. The parameter required holds what was returned from the require script, so to access variables index into the table (require.variable) and to call functions has the same syntax (require:method). Any global variables/functions from the required script will also be included.

local required = require("scripts.path.to.file");

The table, typically the first defined, returned at the end of the script will be the script/functionality exposed to the inspector. If the script isn’t returned the editor won’t recognize the script as a valid script.

local ScriptName =
{
}
return ScriptName;

The properties table within the returned table are the variables exposed to the editor. The variables are similar to [SerializeField] variables from Unity, since the variables can’t be accessed from other scripts only the inspector.
Properties =
{
},


OnActivate within Lumberyard is like Start within Unity, since it will only be called once, once the entity is spawned within the level. Here the EBuses which will be required through the life of the script should be connected and stored.

function ScriptName:OnActivate()
end


OnDeactivate is correlated with OnDestroy, and is called when an entity is removed from the level or when the game exits play mode. Here the EBuses which are connected should be disconnected, if a EBus is disconnected it can run while in edit mode, like [ExecuteInEditMode] but typically not intended.

function ScriptName:OnDeactivate()
end


OnTick is Lumberyard’s frame update function, Unity’s Update. Unlike in Unity where delta time can be retrieved from any function of the script, Lumberyard passes the delta time only to the OnTick function (which can then be stored to be used elsewhere). OnTick isn’t connected initially, even if the function is present, it requires the tick bus to be connected in another function to be used.

function ScriptName:OnTick(deltaTime, scriptPointTime)
end

Communicating with Scripts/GameOjbects

In Unity a GameObject can be gotten through different methods, such as FindObjectOfType<>, however in Lumberyard Event Buses are used. Event buses can only be created through C++ code, which requires compiling the game after each change, see live-editing. Finding specific entities in Lumberyard is difficult without learning how to properly use the event buses, and isn’t as trivial as it is in Unity. Lumberyard event buses do allow broadcasting information, sending to all listening entities, similar to Unity’s FindObjectsOfType<> however neither of these are typically good practice to use.

Once a Lua script has a reference to an entity, it cannot alter parameters or call functions of that script like Unity because as mentioned above the script itself isn’t known. There is no GetComponent<> built into the Lua scripting system, this behavior must also be programmed through event buses and isn’t a feature of Lua scripting. To generally communicate between entities in Lumberyard the gameplay bus is used.

Serialization/Reflection

Serialization/reflection is an important part of any game engine. From a higher level perspective of game engines, this is how variables, functions, etc are exposed to the users/designers. In Unity the “SerializeField” is used to expose variables to the inspector, in Lumberyard Lua scripting all variables in Properties table of the Lua script are exposed to the inspector. However, where in Unity the variables exposed in the inspector are defined in the order of declaration of the script, Lumberyard reorganizes the variables in alphabetical order (this is why sub-tables are useful). Lumberyard also has serialization/reflection of C++ classes/structs, which remain in order of declaration.

Live-Editing

Unity allows for live editing of parameters in the inspector during play, however Lumberyard restricts the mouse to the perspective viewport while in the Lumberyard software. The mouse cannot access the inspector, thus values cannot be changed while the game is playing like in Unity.

Where in Unity modifying a script requires the game to be stopped, modifying C++ code in Lumberyard requires the game to recompiled. What this means is the editor needs to be closed and a number of console commands need to be run to recompile the code (which can take minutes to complete). Only after the code is recompiled can the editor be reopened.

Entity Component System

Like Unity, Lumberyard has objects (entities in Lumberyard and GameObjects in Unity) located in the level/scene. The objects can have components added to them through the inspector, however unlike Unity scripts do not become components, only C++ classes can. Scripts must be added through Lua Script, which slows the process of adding components because of additional clicks and searching for the script in another menu. In Lumberyard, the scroll wheel on the mouse can also manipulate values in the inspector but lacks the dragging functionality that Unity has. Unity has the handy feature of resetting the position to Vec3(0,0,0) through the inspector, in Lumberyard the translation can only be changed manually. The Lumberyard inspector supports keyboard shortcuts for copying/pasting/cutting/deleting components which is missing from Unity.

Camera

The camera systems in Lumberyard isn’t as feature-rich as Unity’s, as seen by the side-by-side. Where in Unity the game window won’t display the scene without a GameObject with a camera component, Lumberyard uses the editor camera as the default camera. To align an object, typically used for aligning the camera, with the editor view Unity has a keyboard shortcut but Lumberyard takes that a step further and allows the camera to be controlled like it is the editor camera. This allows artists/designers to know exactly the view of the camera, and removes the uncertainty associated with the key press.

Lumberyard also has another component called the camera rig, which helps with camera movement and look direction, which Unity doesn’t have natively. The same effect can be achieved through creating a script or using Unity’s CineMachine tool, which has much more functionality than Lumberyard’s camera rig.

Environment

Terrain

When creating a new level in Lumberyard, a terrain is automatically generated at user specified size. In Lumberyard, it is easy to paint a terrain or import terrain height map through terrain editor, accessed through Terrain Editor. Unlike in Unity where terrain is a GameObject, Lumberyard terrain can only be modified through the Terrain Editor. The functionality between the terrain editor in Lumberyard and terrain component in Unity are fairly similar, both allow for the terrain to be raised, lowered, smoothed, reset, etc. Lumberyard will typically have better performance with large terrain, and terrain generated content because of its background in AAA FPS games. Lumberyard also allows for the placement of roads, rather than painting as you would in Unity.

Lighting

[fix]From the perspective of Unity developer, lighting configurations are all over the place. A good option is always adding an environment probe to the level to control the overall brightness, and lights can be used for partial lighting. Time of Day should only be applied carefully if performance is not an issue. This is different from Unity, where manually adding and editing lights are the major way of changing illumination. To add a general light to a level, there are two ways to do this in Lumberyard. First, there is a light entity that can be dragged and dropped into the scene under Tools – RollupBar – Objects – Entity – Lights. However, Lumberyard no longer encourages this method and it will be removed sometime in the future updates. The second option is to create an empty entity in the level,  and then add a light component to that entity. There are three types of lights to choose from, Point light, Area light, and Pojector light. Although different from Unity, a point light is an omni-directional light, and area light is a light emitter that has a length and a width. A projector light equals to a spotlight in Unity.

Fog

Lumberyard takes care of fog in a way similar to Unity, where fog is separated into two categories, Standard Fog and Volume Fog. Unlike Unity where standard fog can be edited under Camera View, Standard Fog in Lumberyard is handled under Time of Day editor where it can be found at Tools – Other – Time of Day. Volume Fog is similar to FogVolume, where volumetric fog is generated inside a cube to cover a certain area.

Model/Materials

Model Import

Lumberyard upgraded from CryEngine’s system of .cgf files to accepting FBX models similar to Unity. However Lumberyard is not as forgiving as Unity is with regards to models and will often fail to accept a model because of repeated face/vertex. Unity also accepts other types of model files, but Lumberyard is more restrictive.

Once a model is imported correctly into Lumberyard, the model has properties which can be edited similar to Unity. Within the settings, Lumberyard allows for a Mesh pivot to be changed, however a mesh is differentiated from an actor (which is a skinned mesh).

Material Editor

Unlike Unity where material options and preferences are directly edited under the inspector, Lumberyard has the Material Editor window to edit all materials. The Material Editor and materials in the inspector share similar functionality, namely being able to change the shader, apply normal/height/emission maps, opacity, etc. Materials in both engines are saved as separate files, however modifications in the Material Editor need to be explicitly saved, whereas Unity’s materials are automatically saved.

Animation

Importing

Compared to Unity, it is more complex to import FBX into Lumberyard. Just dragging assets into the engine does not work for Lumberyard. And for different parts of the characters and animations, they have to be exported from Maya in different ways. But Unity does not need these steps in importing characters and animations.   

Animation Editor

Animation Graph

In Unity, things are very similar. The animator window shows the animator controller, which holds the same information as the anim graph in Lumberyard. Unity also provides different types of parameters to trigger animations, but the types are less than Lumberyard. In Unity, there’s no concept of motion set. Any animations can be added to the animator controller.

Character

The Actor component in Lumberyard is similar to that of a Skinned Mesh Renderer, it is the component which recognizes that the mesh has a rig and skin weights. The Anim Graph component in Lumberyard is similar to Unity’s Animator component.

Scripting Interface

The methods of calling animation is very similar to Unity. In Unity, there are also parameters that can control the animation. So it is easy to learn and understand how to use scripts to control animations in Lumberyard for developers who are familiar with Unity.

State Machines and Blend Trees

In Unity, the transition between the two animation clips can be adjusted by dragging the start and end values of the overlap.

Blend Tree

Unity has Blend Trees:

In Unity, when the blend tree is set up with Animation clips and input parameters, the inspector window gives a graphical visualization of how the animations are combined as the parameter value changes (as you drag the slider, the arrows from the tree root change their shading to show the dominant animation clip).

The blend tree in Lumberyard can also achieve the same result, and it can also be previewed in the Animation Editor.

Animation Layers

Unity uses Animation Layers for managing complex state machines for different body parts. An example of this is if you have a lower-body layer for walking-jumping, and an upper-body layer for throwing objects / shooting.

You can manage animation layers from the Layers Widget in the top-left corner of the Animator Controller.

On each layer, you can specify the mask (the part of the animated model on which the animation would be applied), and the Blending type. Override means information from other layers will be ignored, while Additive means that the animation will be added on top of previous layers.

Unity and Lumberyard works in different ways but they can achieve the same things in pose mask. In Lumberyard, the pose mask is achieved in a blend tree, which is different from Unity. However, understanding how animation layer works is definitely helpful in getting started in Lumberyard poseMask.

Scripting Interface

The script should be on an entity with both Actor component and AnimGraph component. In scripting, the animations are called by changing the values of the parameters which are pre-set in the animation graphs. In the animation graph, each animation is triggered by certain parameters, thus, having access to control these parameters means being able to trigger animations.

Input

User input is handled very different between the engines, because Unity doesn’t require input to be defined prior to listening for the input. In a C# script, input can be checked without binding the input outside of the script. In Lumberyard, input must be registered in a file and an input component must be present in the level with an input binding. Only events that correspond to input events within the input binding will be detected in a script.

In Unity, input events can be directly detected each frame in update function. There are no components related to input in Unity, and it is easier to add additional input. However in Lumberyard, the input events allow certain inputs to be disabled quickly as well as being more performing because an if statement isn’t being checked each frame.

The Asset Editor is similar to Unity’s Input settings, however is required to recognize the input. The Asset Editor is how input bindings are created, and allow for different input configurations and modification of the current input configuration quickly. Rather than checking each frame for a set of keys as you would in Unity, each of those keys can be bound to the same input event. Like other things in Lumberyard, events are strings which come with an inherent error of mistyping.

Physics

Physics in both the engines have a fairly similar way of working with there being a distinction between static and dynamic physics and having colliders and triggers for events. Lumberyard physics is still evolving and only includes the primitive types rather than Unity’s extensive physics component types. Lumberyard also does not currently have a dedicated 2D physics engine, unlike Unity.

UI

UI Editor

Unity has UI directly in the scene and Lumberyard stores the UI in a file separate from the level. Storing in a separate file allows the UI to be loaded dynamically, as well as having the level and canvas be easier to navigate. For the UI to appear in the level, an entity must hold a reference to the canvas as well as determine when the canvas is loaded (at start or on an event).

Lumberyard uses a separate UI Editor to edit the canvas.  Because the UI Editor is separate from other entities in Lumberyard, the inspector cannot reference other entities in the level but only the elements located on the canvas. Communicating with entities located in the level requires additional work through scripting. Unity UI has the advantage in that UI GameObjects can directly connect with non-UI GameObjects. Lumberyard requires entities to subscribe to the entity which contains the canvas, then entities within the canvas can message the parent entity.

Having the canvas built into the scene also allows Unity to achieve 2D games with less struggle. Although Lumberyard doesn’t have a dedicated 2D developer mode, 2D games are still possible through the UI Editor, but level components cannot be accessed.

Once in the UI Editor, the workflow for artists is similar to that of Unity. Entities (referred to elements in the Lumberyard canvas) are similar to canvas GameObjects in Unity, with defaults like image located within the slice library. The anchor system is also similar to Unity, where entities can be manipulated to anchor to certain parts of the canvas dependent on the screen resolution. Importing images to both engines is the same flow, however importing fonts is different since fonts are available in every project of the engine. UI canvases in Unity can be made prefabs however aren’t required to be, but within Lumberyard the canvas must be saved into a file. Previewing UI is possible in Lumberyard unlike Unity, a canvas can be previewed as if the game was playing with real-time UI effects, without playing the game itself.

For a canvas to be positioned in the level, Unity’s world space render mode option, the Lumberyard canvas must be set to render to texture with a valid render target. Unity has a concept of render targets which is storing the display of a camera to an image, in Lumberyard it is the same concept and for UI it is as though the camera is only displaying the UI. The render target is then associated to a material, which can be assigned to a mesh in the level.

Scripting Interface

Developing UI scripts in Lumberyard is similar to that of Unity. There is a dedicated set of components to attach to the entities and a separate set of scripting functions for only UI. Although in Unity you are required to add in the UI library, in Lumberyard the functions, classes, and events for UI are available, although not necessarily useful, in any script. A continued difference with Unity and Lumberyard scripting is with respect to obtaining another entity and sending messages between entities. In Unity, the UI GameObjects can communicate with any object in the scene because the objects are located within the same save file, however because Lumberyard’s UI entities are located within the UI canvas the entities can only communicate with entities in that canvas. This is the same logic to Unity’s prefabs not being able to store references to scene object, because the canvas is a separate save file of data to the level.

Audio

Currently, Lumberyard supports audio in the game only through Wwise. Lumberyard comes packed with the LTX version of Wwise where all the sound engineering happens. Audio is added to the game using sound banks that Wwise exports and the sounds can be played/stopped through script. Unity, on the other hand, has a powerful in-house audio system. It allows a very WISYWIG style of adding and modifying sound sources and clips. Unity also supports integration with Wwise, but is not the default option. While a lot more can be done with sound effects in a game through script, Unity does not make it mandatory. A naive user can just drag and drop a sound on an object and be able to control to a certain extent how and when the audio would play.

Lumberyard can achieve the same audio effects as Unity. Both of the engines use audio related component to add audio clips to entities (game objects). The difference between Lumberyard audio and Unity audio is the way they handle audio pieces, Lumberyard needs wwise project to set up audio triggers and all the audio properties (such as volume, 3D or 2D…). Lumberyard consider and organize audio files as one single audio project. In the script, the way to play an audio clip is to trigger the event triggers. This perspective is different from Unity. In rollup bar, Lumberyard also has audio box function to set an area as the play or stop trigger, which is useful organizing different ambient sound in different areas.

Shaders

Shaders in Unity use an adaptation of Nividia’s CG language named ShaderLab. Lumberyard uses a similar shader language as DirectX’s HLSL. Both the engines follow Physically Based Rendering and offer a wide variety of types of shaders that can be implemented. Lumberyard’s built-in shaders, however, are a lot more complex offering AAA-quality. Unity’s built-in shaders are limited in variety and complexity. Both game engines, however, have limited resources when it comes to dealing with shaders. However, Unity’s community have been creating tutorials and documentation on the subject. Lumberyard’s community and documentation team aren’t at the stage of creating in-depth documentation/tutorials on the subject, but since the shader language is similar to HLSL, there are tutorials on the shader language itself. Where Unity shaders are relative to a project, Lumberyard shaders are engine-wide, meaning a shader created for one project is automatically shared to others.

Twitch Integration

Unity currently doesn’t have built-in Twitch integration, but it seems possible using C# .NET functionality. There are assets available on the Unity Asset store which allow a Twitch connection, but they are paid assets. Within Lumberyard, this connection and process is simple with Twitch ChatPlay, JoinIn, and API already integrated into the engine. The documentation of Lumberyard’s Twitch integration can be confusing, however this is when having access to the engine code is helpful in determining and adding functionality.

AI

Navigation window

In Unity, the navigation window includes different tools to help navigate. Including:

Agents:

Help us to modify details of the agent which can navigate on the mesh.

In Lumberyard, agents’ properties can be edited in xml files.

Areas:

Help us to define different layers for the agent to navigate.

In Lumberyard, nav layers are defined by agent types.

Bake:

Help us to bake the navigation mesh in the scene. In Uniy, we have to bake the navmash every time after we change something in environment.

Lumberyard can auto-bake itself, which means the navmesh would generate itself everytime after we change the environment.

Object:

Help us to select a meshrenderer or a terrain from the scene

Components

AI needs a Nav Mesh Agent component to navigate on the baked mesh.

Lumberyard has the most basic settings of the agent in Navigation component, there are also ways to define the properties of different agent types by adding and changing values in related xml files.

Script

In Unity script.

man.SetDestination(targetTransform);

can be used to navigate.

In Lumberyard:

NavigationComponentRequestBus.Event.FindPathToEntity(self.entityId, targetEntity)

does the same things as SetDestination.

Physics

Physics in both the engines have a fairly similar way of working with there being a distinction between static and dynamic physics and having colliders and triggers for events. Lumberyard physics is still evolving and only includes the primitive types rather than Unity’s extensive physics component types. Lumberyard also does not currently have a dedicated 2D physics engine, unlike Unity.