Scripting Workflow and Structure

From Frictional Wiki
< HPL3
Revision as of 21:21, 8 August 2020 by TiMan (talk | contribs)
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 F1-menu you can also turn on Update 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.


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.

  • 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:

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 program, so you can type in whatever you want without worrying that it will screw up the program.