Difference between revisions of "Papyrus Introduction"
Applying the three new templates: InDepth, ProTip and WarningBox.
imported>Frenchfrog |
imported>Catwheezle (Applying the three new templates: InDepth, ProTip and WarningBox.) |
||
Line 25: | Line 25: | ||
<br><br> | <br><br> | ||
{{Template:InDepth|Scripts being called '''[[:Category:Script_Objects|Objects]]''' might be confusing to some people. Scripts are added to objects in the game, they describe their behaviour and functionality. They are the "soul" of a static mesh made out of triangles and covered with a few textures which make it '''look real'''. Papyrus scripts are what makes it '''real'''. What makes it a true, "full" '''object'''.}} | |||
Strictly speaking, a script is not really an object, rather an important part of it. Usually, an object has to be '''encapsulated''', contained in a single unit which might '''inherit''' some functionality from a parent class which is a more '''abstract''' or '''general''', if you will, version of it. This concept is easily employed natively in code, without a scripting language, where everything from "look" to behaviour is defined by one single, coherent, encapsulated unit of code which correlates to other units of code. "True objects" in the game are actually those which are responsible for showing the mesh on the screen (native code added on top of the Creation Engine), they encapsulate basic properties. Scripts are appended to these objects to give game designers a simple, versatile tool of defining their behaviour without going into battle with low level mechanisms that impede creativity and productivity. They extend the base object by adding behaviour to it or modifying its basic properties (eg. initiating animations in response to an event), they are not an object in their own right. They modify an object or add to it, sometimes they contain most of the object's definition. But they are not '''the object'''. That's why it's been emphasized that they correlate exactly '''for the most part''' to objects found in the editor's masterfile. | Strictly speaking, a script is not really an object, rather an important part of it. Usually, an object has to be '''encapsulated''', contained in a single unit which might '''inherit''' some functionality from a parent class which is a more '''abstract''' or '''general''', if you will, version of it. This concept is easily employed natively in code, without a scripting language, where everything from "look" to behaviour is defined by one single, coherent, encapsulated unit of code which correlates to other units of code. "True objects" in the game are actually those which are responsible for showing the mesh on the screen (native code added on top of the Creation Engine), they encapsulate basic properties. Scripts are appended to these objects to give game designers a simple, versatile tool of defining their behaviour without going into battle with low level mechanisms that impede creativity and productivity. They extend the base object by adding behaviour to it or modifying its basic properties (eg. initiating animations in response to an event), they are not an object in their own right. They modify an object or add to it, sometimes they contain most of the object's definition. But they are not '''the object'''. That's why it's been emphasized that they correlate exactly '''for the most part''' to objects found in the editor's masterfile. |