Blueprint -> Prototype

docs/en/manuals/building-blocks.md

@@ -70,7 +70,7 @@ Refer to the [component overview](/manuals/components/) for a list of all availa
 
 ## Objects added in-place or by reference
 
-When you create a collection, game object or component _file_, you create a blueprint, or a prototype. This only adds a file to the project file structure, nothing is added to your running game. To add an instance of a collection, game object or component based on a blueprint file, you add an instance of it in one of your collection files.
+When you create a collection, game object or component _file_, you create what we call a prototype (also known as "prefabs" or "blueprints" in other engines). This only adds a file to the project file structure, nothing is added to your running game. To add an instance of a collection, game object or component based on a prototype file, you add an instance of it in one of your collection files.
 
 You can see what file an object instance is based on in the outline view. The file "main.collection" contains three instances that are based on files:
 
@@ -80,15 +80,15 @@ You can see what file an object instance is based on in the outline view. The fi
 
 ![Instance](images/building_blocks/instance.png){srcset="images/building_blocks/[email protected] 2x"}
 
-The benefit of creating blueprint files becomes apparent when you have multiple instances of a game object or collection and wishes to change all of them:
+The benefit of creating prototype files becomes apparent when you have multiple instances of a game object or collection and wishes to change all of them:
 
 ![GO instances](images/building_blocks/go_instance.png){srcset="images/building_blocks/[email protected] 2x"}
 
-By changing the blueprint file, any instance that uses that file will immediately be updated.
+By changing the prototype file, any instance that uses that file will immediately be updated.
 
-![GO changing blueprint](images/building_blocks/go_change_blueprint.png){srcset="images/building_blocks/[email protected] 2x"}
+![GO changing prototype](images/building_blocks/go_change_blueprint.png){srcset="images/building_blocks/[email protected] 2x"}
 
-Here the sprite image of the blueprint file is changed and immediately all instances using the file are updated:
+Here the sprite image of the prototype file is changed and immediately all instances using the file are updated:
 
 ![GO instances updated](images/building_blocks/go_instance2.png){srcset="images/building_blocks/[email protected] 2x"}
 

docs/en/manuals/factory.md

@@ -7,7 +7,7 @@ brief: This manual explains how to use factory components to dynamically spawn g
 
 Factory components are used to dynamically spawn game objects from a pool of objects into a running game.
 
-When you add a factory component to a game object you specify in the *Prototype* property what game object file the factory should use as a blueprint for all new game objects it creates.
+When you add a factory component to a game object you specify in the *Prototype* property what game object file the factory should use as a prototype (also known as "prefabs" or "blueprints" in other engines) for all new game objects it creates.
 
 ![Factory component](images/factory/factory_collection.png)
 

docs/en/manuals/gui-script.md

@@ -45,7 +45,7 @@ function on_reload(self)
 end
 ```
 
-To attach the script to a GUI component, open the GUI component blueprint file and select the root in the *Outline* to bring up GUI *Properties*. Set the *Script* property to the script file
+To attach the script to a GUI component, open the GUI component prototype file (also known as "prefabs" or "blueprints" in other engines) and select the root in the *Outline* to bring up GUI *Properties*. Set the *Script* property to the script file
 
 ![Script](images/gui-script/set_script.png){srcset="images/gui-script/[email protected] 2x"}
 

docs/en/manuals/gui.md

@@ -17,7 +17,7 @@ GUI components are rendered independently of the game view. Because of this it i
 
 ## Creating a GUI component
 
-GUI components are created from a GUI scene blueprint file. To create a new GUI component, <kbd>right click</kbd> a location in the *Assets* browser and select <kbd>New ▸ Gui</kbd>. Type a name for the new GUI file and press <kbd>Ok</kbd>.
+GUI components are created from a GUI scene prototype file (also known as "prefabs" or "blueprints" in other engines). To create a new GUI component, <kbd>right click</kbd> a location in the *Assets* browser and select <kbd>New ▸ Gui</kbd>. Type a name for the new GUI file and press <kbd>Ok</kbd>.
 
 ![New gui file](images/gui/new_gui_file.png){srcset="images/gui/[email protected] 2x"}
 

docs/en/tutorials/car.md

@@ -78,7 +78,7 @@ Name the new collection file *car.collection* and open it. We're going to use th
 
 Also, it's possible to create a game object in place in a collection, as we did here. That results in a one-of-a-kind object. You can copy that object but each copy is separate---changing one does not affect the others. This means that if you create 10 copies of a game object and realize that you want to change them all, you will need to edit all 10 instances of the object. Therefore, in place created game objects should be used for objects that you do not intend to make a lot of copies of.
 
-However, a game object that is stored in a _file_ works as a blueprint. When you place instances of a file stored game object in a collection each object is placed _by reference_---it is a clone based on the blueprint. If you decide you need to change the blueprint, every single placed game object based on that blueprint is instantly updated.
+However, a game object that is stored in a _file_ works as a prototype (also known as "prefabs" or "blueprints" in other engines). When you place instances of a file stored game object in a collection each object is placed _by reference_---it is a clone based on the prototype. If you decide you need to change the prototype, every single placed game object based on that prototype is instantly updated.
 
 ![Add car gameobject](images/car/start_add_car_gameobject.png)
 

docs/en/tutorials/runner.md

@@ -86,7 +86,7 @@ When you are done editing a file you have to save it. Select <kbd>File ▸ Save<
 
 ## Setting up the project
 
-Before we begin, let's set up several settings for our projects. Open the `game.project` asset from the `Assets Pane` and scroll down to the Display section. Set the `width` and `height` of the project to `1280` and `720` respectively. 
+Before we begin, let's set up several settings for our projects. Open the `game.project` asset from the `Assets Pane` and scroll down to the Display section. Set the `width` and `height` of the project to `1280` and `720` respectively.
 
 ::: sidenote
 If your Display's refresh rate is greater than 60 hz then you might want to disable `vsync` and set a frame cap to a value like 60.
@@ -144,7 +144,7 @@ Game objects
 : These are things that exist in the running game. Each game object has a location in 3D space, a rotation and scaling. It doesn't necessarily have to be visible. A game object holds any number of _components_ that adds abilities like graphics (sprites, tilemaps, models, spine models and particle effects), sounds, physics, factories (for spawning) and more. Lua _script components_ can also be added to give a game object behaviors. Each game object that exist in your games has an *id* that you need in order to communicate with it, through message passing.
 
 Collections
-: Collections do not exist by themselves in a running game but are used to enable static naming of game object and at the same time allowing multiple instances of the same game object. In practice, collections are used as containers for game objects and other collections. You can use collections much like "prefabs" or "blueprints" of complex hiearchies of game objects and collections. At startup, the engine loads a main collection and breathes life to anything you have put inside it. By default this is the *main.collection* file in the *main* folder of your project, but you can change that in the project settings.
+: Collections do not exist by themselves in a running game but are used to enable static naming of game object and at the same time allowing multiple instances of the same game object. In practice, collections are used as containers for game objects and other collections. You can use collections much like prototypes (also known as "prefabs" or "blueprints" in other engines) of complex hiearchies of game objects and collections. At startup, the engine loads a main collection and breathes life to anything you have put inside it. By default this is the *main.collection* file in the *main* folder of your project, but you can change that in the project settings.
 
 For the time being these description probably suffices. However, a much more comprehensive dive through these things can be found in the [Building blocks manual](/manuals/building-blocks). It is a good idea to visit that manual at a later stage to get a deeper understanding on how things work in Defold.