The Engine
The Engine
As mentioned above, Amazon offers Lumberyard’s source code on GitHub for free. This allows a lot of flexibility to developers to make changes to the engine for their requirements as they see fit. Understanding how to make changes to the engine required a prior knowledge of how and where things are present in the engine itself. Below we introduce you with some core concept that you need to know before you get started with development.
Gems
Gems are like packages of assets and code that can be included in projects. Each project is itself a game gem, which can hold assets specific to that game. Gems created in the Project Configurator can be included in multiple projects, which makes transferring assets and code between projects easy and quick. After a Gem is added to a project (or the default project is switched) the project must be configured in the command line to include the gem, and when code changes within the gem, the game must be compiled to include the new changes (this requires the Editor to be closed). Gems are, by default, created with an event bus, however the event bus doesn’t need to be used and can be removed.
Engine programming vs Scripting
Developing in Lumberyard can be divided into two main parts – engine programming, and scripting. While Lumberyard is primarily written in C++, it exposes all of the systems and components to game developers through it’s scripting language, Lua. If you’re looking to leverage the features, components, and systems Lumberyard offers out of the box, you shouldn’t need to worry about what goes on at the engine side, and all your work can be contained within the scripting language. However, there can be many reasons that a developer might need to delve on the engine side of things:
- If you want to add a feature to an existing system or component, you’d need to make changes directly to the engine. For example, shaders are something that exist at the engine level. To add or modify a shader, you would need to do it in the engine itself.
- If you want to expose your own data structure for passing around data while scripting, this is something that would need to be added to the engine in the form of a gem.
- Adding a new system, component, or functionality that you want to expose to Lua would also require engine programming in C++.
While it’s possible to also code an entire game project just in C++ or just in Lua, they both offer some advantages and disadvantages, it’s up to the developer to make those decisions as per their requirements. The programming section below discusses this further.
Legacy vs Updated Systems and Components
Lumberyard at its conception is a fork of Crytek’s CryEngine. Since the time it was launched in beta and up till now, every subsequent version released has replaced CryEngine’s systems and components with Lumberyard’s own. Lumberyard will remain in beta until there still exist legacy systems and components (the one inherited from CryEngine) within the engine.
In the current version of Lumberyard, the engine, Lua scripting, and documentation are going through large overhauls to remove deprecated features and add in new functionality in preparation for the full release. Anything marked with “Cry” or associated with the CryEngine is subject to be removed. The tutorials found on the Amazon Game Developer tutorial page are for the most part out of date, with developers extrapolating how the technology has changed. While its good practice to avoid using Legacy features so your project can stand for longer over future releases, some systems are not in a state to be replaced yet with the updated or “in-preview” mode. PhysX, for example, is not at a stage yet where it can replace the legacy physics engine.