Scripting Workflow and Structure

From Frictional Wiki
< HPL3
Revision as of 14:05, 7 November 2020 by TiMan (talk | contribs) (→‎Scripting Workflow)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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