Coding in Lumberyard - Resources for getting started

The Amazon Game Services Solutions Architect Al Murray posted the great reply to the question “How do I get started using C++ with Lumberyard?” and I thought it was very useful information that might be helpful to anyone new to Lumberyard.

The first suggestion I have is to look into this video [[1](] which describes some of the underlying theory of Lumberyard engine's coding architecture and shows a very quick demo of how core concepts as reflection, code generation, components, events and slices work.

Then, actually start making a project in which the object is to create a native C++ component that can be attached to a game entity in the editor.

1. You will as a minimum need a Lumberyard project. It will be in charge of loading any gems that you create for your game. Open the <lumberyard_root_folder>\dev\Bin64\, then run ProjectConfigurator.exe. Create a new project there and give it a name.

2. Games in Lumberyard should be made as one or more gems. A gem is a way of isolating your own code from the engine code so that, imagine if you update your version of Lumberyard, you don't end up with a bunch of code that you have to untangle to update. Also it may make sense to break up the game into pieces for whatever reason, these would also be gems. Gem creation is covered here [[2](]. The structure of gems is discussed here [[3](] but you can basically assume that a gem contains assets that can be loaded, a code module, and some waf data to build the code module in the gem. [[4](]

3. Gems in the latest release of Lumberyard (since contain code created as AZ Modules [[5](] (which is a good thing). These are the libraries (static .lib or dynamic .dll) that contain the built code. The AZ module source includes an interface derived from AZ::Module and this contains a system entity and adds any required system components to it (one by default). It will also come with an event bus by default, and a single system component. System components are singleton components [[6](]. The module is registered with the autogenerated code, e.g.

AZ_DECLARE_MODULE_CLASS(HelloWorld_010c14ae7f0f4eb1939405d439a9481a, HelloWorld::HelloWorldModule)
4. You are also free to derive components from AZ::Component and include them in the gem. [[7](] Registering is as easy as the example code shows:

AZ_COMPONENT(MyComponent, "{0C09F774-DECA-40C4-8B54-3A93033EC381}");
5. If you will need to store any information out of the component instances, it must have metadata added in a reflect function which tells Lumberyard what will be stored, or serialized. If it is to be seen in the editor, so that you can attach it to a game object, for example, you will need to add metadata in the reflect function which tell Lumberyard what it does in the editor, including what settings you can make on the component and how the UI looks in the editor. Reflection is simply the term used for any code you write that tells another part of the system how to use your class. You may say in the reflection code that a particular function needs to be called when data is changed by the editore, and you should also write these change callbacks in the component. [[8](]

6. You should be able to create an entity in the editor now, and attach your component and set values in the object, and print them out or see them in the debugger.

7. You should learn about slices and dynamic slices now, to get you to the level where you can start using code effectively in Lumberyard. [[9](]

Please let us know if you run into difficulties, and I will be happy to help,

Al Murray :)
Solutions Architect
Amazon Game Services

[1] [](
[2] [](
[3] [](
[4] [](
[5] [](
[6] [](
[7] [](
[8] [](
[9] [](

Can we get more/better documentation on how threading and more specifically thread safety works using the new Component Entity System and the engine in general. I searched the Developer Guide for the term “thread” and only got 9 hits and the closest useful result was the EBUS Documentation. Even the System Documentation category in the Developers Guide had nothing in regards to thread safety or locking mechanisms and more specifically how thread safety works with multiple handlers attached to a Component.

I’ve seen cases where there could be both a TickBus(which isn’t documented) and an EventBus on a Component and in theory both could conflict with each other without a single locking mechanism if they each have their own. On top of that given the nature of how specific Components are to a specific feature or data it’s not unreasonable to want to directly access one component from another component on the same entity when handling a certain Event which could also lead to problems. Better documentation on threading and thread safety would help, especially for anyone new to Lumberyard.

You are right, the docs are pretty sparse at the moment and is something the documentation team is working very hard to address and update. You should start to see more documentation coming on board with each new release. Sorry for the inconvenience this has caused.


Thanks a lot Binky.