A complete introduction to scripting for games using the versatile Lua programming language and the Core game development platform. Add an array of game coding skills to your toolbox and take your game development to new heights!
Creating a game involves building the visual and audio parts of your game, using 3D objects and materials, and then controlling their behavior, usually through scripts.
In order to be able to write that behavior, you will need a way to talk about it in code, a reference.
In this lesson, you will learn the many different ways to get references to objects in Core, and which ones to use in different circumstances.
When you talk about a Core Object, you could be referring to two different types of things, a specific object, or a type of object of which there can be multiple copies.
This is the same concept we studied in the Classes and Objects lesson when focusing on the distinction between an instance of a class and a prototype.
If you want to create an object from script, you will need a reference to the prototype, which is the Asset Reference. With this, you can use the
World.SpawnAsset() function to make a new instance of it appear in your game
If you have modeled your own object that you want to treat like a prototype, and be able to spawn copies of in game, you will need to make it a template. You can learn more about how to do this in the Core Documentation Template Reference, where you can learn how to make, change, and update templates.
Once a group becomes a template, you can create new copies of it from the Project Content window.
If you want a script to change an object, that object will need to be networked.
For an object in the Hierarchy, enable networking by right-clicking and selecting Enable Networking.
For a template:
The easiest way to get a reference to an object is to make it a custom property of the script.
One trick to tell if a Custom Property is referring to an object in the Hierarchy or an asset is in the generated variable code. If the object is followed by
:WaitForObject(), then it is already part of the Hierarchy, and we are telling Core to wait for it to load before defining the variable.
Any variable in your code can be made into a custom property. This will allow you to modify inputs to the program by changing them on the properties of an object
The Hierarchy can be arranged so that different objects scripts and folders can be nested under other ones. Those nested objects are children, and the object they are nested under is the parent.
If you nest a script under an object, that object is the script’s parent. Knowing that, you can easily reference it with
local objectToReference = script.parent
You could even get the parent of that object (like if it is part of a template) with
Using an object or script’s children is more complicated than getting a parent, because while an object can have only one parent, it can have many children.
There are two useful function for this:
GetChildren()will give you a table of every child of the object called on it.
FindChildByName()will allow you to give the name that shows up for the object in the Hierarchy as a string, and get a reference to it in your script.
You can also find parents of parents, Ancestors and children of children, Descendants using these CoreObject functions:
Every object in Core has a unique ID string that you can use to find the object with the
This method has the potential to create bugs later down the line. It makes it difficult to tell what type of thing you are dealing with, and will stop working if you try to make a new copy of the object referenced, or save it as part of a template. In general, you should avoid using MUID’s in your code, unless you cannot find an alternative.
Assets Core Content and Project Content and instances of objects in the Hierarchy both have ID’s. It can be easy to confuse the two, since they will not have any clear distinguishing characteristics.