Difference between revisions of "HPL3/Scripting/Scripting Guide/Scripting Workflow and Structure"

From Frictional Wiki
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{wip}}
 
 
 
{{Hpl3ScriptingGuideMenuBasic}}
 
{{Hpl3ScriptingGuideMenuBasic}}
 
{{shortPageTitle}}
 
{{shortPageTitle}}
 
This article describes the scripting workflow in HPL3 and the basic structure of a map script file.
 
This article describes the scripting workflow in HPL3 and the basic structure of a map script file.
  
== Introduction ==
+
==Introduction==
  
 
A level script should not be thought of as a file for programming. A level script should be written and read as though it is a story, or a sequence of events if you wish. In the level script you are crafting the experience for the user and the script should be read as the manuscript of that experience.
 
A level script should not be thought of as a file for programming. A level script should be written and read as though it is a story, or a sequence of events if you wish. In the level script you are crafting the experience for the user and the script should be read as the manuscript of that experience.
Line 13: Line 11:
 
The game has been made to provide feedback during the scripting process relay information as frequently as possible.  
 
The game has been made to provide feedback during the scripting process relay information as frequently as possible.  
  
== Scripting Workflow ==
+
==Scripting Workflow==
 
When running the game / mod from the developer menu, the script will be reloaded every time you task-switch from CodeLite to any other editor.  
 
When running the game / mod from the developer menu, the script will be reloaded every time you task-switch from CodeLite to any other editor.  
  
 
When making smaller changes in code that are constantly updated, then simply task switch to see your new code in action.
 
When making smaller changes in code that are constantly updated, then simply task switch to see your new code in action.
  
Inside the F1-menu you can also turn on <code>Update script constantly</code> which checks for script updates as soon as you save the code. It can be useful if you have two monitors and such, or if you want a very fast feedback loop.
+
Inside the developer debug menu, you can also turn on <code>[[HPL3/SOMA/Modding/Developer_Debug_Menu#Reload_Script_Constantly|Reload Script Constantly]]</code> which checks for script updates as soon as you save the code. It can be useful if you have two monitors and such, or if you want a very fast feedback loop.
 
If there are any updates that require the map to restart, meaning any initialization or properties in the map, then you of course need to reload by pressing F5.
 
If there are any updates that require the map to restart, meaning any initialization or properties in the map, then you of course need to reload by pressing F5.
  
 
+
==Scripting Structure==
== Scripting Structure ==
 
  
 
The editor generates a new script file when saving a new map. Expand the box to view the script file.
 
The editor generates a new script file when saving a new map. Expand the box to view the script file.
Line 149: Line 146:
 
}} {{clr}}
 
}} {{clr}}
  
Now it might seem like a lot, but I want to quickly go over each section of the script here, in which you will learn more about each one of them as you progress in this tutorial series.
+
For now, let's have a quick look of the overall structure of the file, from top to bottom.  
 
 
* Includes section:
 
First of all we have the includes section, then class declaration, then we have the main functions, types and variables, callback functions and comments.
 
  
We will touch on all of these later, but right now I need to clarify something about the comments and the overall structure of the script file:
+
*Includes section
 +
*Class declaration
 +
*Main functions
 +
*Types and variables
 +
*Callback functions and comments
  
Since your code can get quite big, it is important that the same structure is maintained.
+
Since your code can get quite big, it is important that the same structure is maintained. This way it makes it easier for you and others to find what they need to do to change something, and this is what comments are for.
  
This way it makes it easier for you and others to find what they need to do to change something, and this is what comments are for.  
+
Anything that has been marked as a comment is ignored by the game, so you can type in whatever you want without worrying that it will screw up the program.
  
Anything that has been marked as a comment is ignored by the program, so you can type in whatever you want without worrying that it will screw up the program.
+
==See Also==
  
 +
*[[HPL3/SOMA/Modding/Developer_Debug_Menu| Developer Debug Menu]]
 +
*[[HPL3/Scripting/Level Scripting - Best Practices|Level Scripting - Best Practices]]
  
{{NavBar|HPL3/Scripting/Setting up CodeLite|Setting up CodeLite|HPL3/Scripting/HPL3 Scripting Guide|HPL3 Scripting Guide|HPL3/Scripting/Hello World|Hello World}}
+
{{NavBar|HPL3/Scripting/Scripting_Guide/Setting up CodeLite|Setting up CodeLite|HPL3/Scripting/HPL3 Scripting Guide|HPL3 Scripting Guide|HPL3/Scripting/Scripting_Guide/Hello World|Hello World}}
  
 
[[Category:HPL3 Scripting]]
 
[[Category:HPL3 Scripting]]
 
[[Category:English]]
 
[[Category:English]]

Latest revision as of 14:05, 7 November 2020

This article describes the scripting workflow in HPL3 and the basic structure of a map script file.

Introduction

A level script should not be thought of as a file for programming. A level script should be written and read as though it is a story, or a sequence of events if you wish. In the level script you are crafting the experience for the user and the script should be read as the manuscript of that experience.

Note icon.png If the level script file contains rows of code that does not match the above description, then the rows of code does not belong in the level script, they belong in a helper file or even deeper down in the hierarchy of script files.

The game has been made to provide feedback during the scripting process relay information as frequently as possible.

Scripting Workflow

When running the game / mod from the developer menu, the script will be reloaded every time you task-switch from CodeLite to any other editor.

When making smaller changes in code that are constantly updated, then simply task switch to see your new code in action.

Inside the developer debug menu, you can also turn on Reload Script Constantly which checks for script updates as soon as you save the code. It can be useful if you have two monitors and such, or if you want a very fast feedback loop. If there are any updates that require the map to restart, meaning any initialization or properties in the map, then you of course need to reload by pressing F5.

Scripting Structure

The editor generates a new script file when saving a new map. Expand the box to view the script file.


For now, let's have a quick look of the overall structure of the file, from top to bottom.

  • Includes section
  • Class declaration
  • Main functions
  • Types and variables
  • Callback functions and comments

Since your code can get quite big, it is important that the same structure is maintained. This way it makes it easier for you and others to find what they need to do to change something, and this is what comments are for.

Anything that has been marked as a comment is ignored by the game, so you can type in whatever you want without worrying that it will screw up the program.

See Also