Locations

Locations are essentially multi-purpose containers in QSP. They can contain code, just text for display or dialogue, raw data and even any number of combinations of this (which is the worst part i currently deal with). Once understood some basic rules how and where to place things is easy.

Taking advantage of this we define 3 different sets of locations:

• physical locations (places, streets, buildings, rooms)

A phys. location has actually very few elements: A Name, a picture, a description of itself, a description of interact-able objects or persons and a list of related actions (movement between locations or interaction with objects/persons in the location). Since html can be used some rules are applied to its usage as well. HTML may only be used for formatting reasons and never includes calls to actual code. The ONLY exception is for tips/help messages. Note: When i am done with the worst of the clean-up each phys.location will consist of exactly 6 sections (template already inside the qsp called 'loc_template'):

- Preamble (general variables and commands that need to be set here and cant be part of a outside module due to qsp structure like clear screen commands, location variables etc)
- Name
- Picture
- Description self
- Description other
- Actions​

• modular objects (beds, alarm clocks, wardrobes, mirrors, showers etc - basically anything that can be placed into a phys.location)

an object that is not unqiue (gods left middle-finger is unique as there is only one) is to be considered reusable thus modular. Ideally there exists only one version of it in the code which includes all possible features that can be chosen by sending the right parameters to its call​

• functional locations (these contain the actual code to do something)

Code can appear in a variety of forms. From complicated algorithms to data storage. Simple rule is that EVERYTHING that belongs to that particular group is in one and ONLY one location. If there are to be several versions of something they still go into the same location but get a distinctive call argument. Example: we need a function to set an alarm clock and an alarm on our phone. Both functions dont qualify as module as they are integral functionality of a object thus belong into those object locations. But a function to manipulate the player's arousal qualifies as module as it manipulates core stats and/or attributes. Thus every possible version of manipulation goes into a single module called MOD_Arousal and we provide separate parts for adding, subtracting etc​

Naming conventions (abbreviations are a big no-no for this unless universally agreed upon in the real world):

• loc_clear unique name of the place, street, building or room

• obj_clear unique name of the object

  functional locations contain code - thus we need more names than the others

• QW_clear unique name of the questchain (everything related to checks, quest progression etc goes here)

• MOD_clear unique name of the modules overall function (this contains code that is responsible for a certain core functionality)

• DATA_clear unqiue name of the data stored here (this contains predefined static data for NPC, events etc)

That leaves variable and function names. Same rule as above applies: fully written names that clearly state what the function does, what the variable is for , what the argument you pass on in your code is meant for.

Example

Original code:

if razradbeg = 0: 'You''re registered for a beginner''s race.'

   `act 'Go to the stadium':gt 'beg1', 'br'`

We make this:

!Here we check for the number of competitions won and assign the player to a competition level they are eligible for

if racing_wins = 0: 'You''re registered for a beginner''s race.'

   `act 'Go to the stadium':gt 'MOD_racing_competitions', 'beginner_race'`