The Character Def is a setup file used to define properties of the player character such as his art, his Movement Modes, his animations, and his own unique script functions. The Game Def contains a list of these files to load for each player character type |
Aside from the Character Def file, there is an additional file that contains only script functions,
which serves as a list of functions that all player characters can use. This is in addition to the Character-Specific Functions
listed in each Character def, so that functions that more than one player character can use do not have to be stored
more than once. The Game Def contains an entry that should be set to the name of this file Although it's not usually necessary, if a Script Command that references this Function List must be used to access a Character-Specific Function, that Function may be referenced by calculating its "Full List ID". This ID is calculated as if all Player-Specific Functions were set in a single list in the order in which the Character Def files were loaded, immediately following the Common Functions. For example, if there are 5 Common Functions, and the Command must reference Character 0's Function 3, then its Full List ID (5+3) would be 8. If there are 7 Common Functions, and Character 0 has 5 Functions, the Full List ID of Character 1's Function 2 (7+5+2) would be 14. |
The Player Variables are settings that are read and modified during gameplay by HCGE and script functions to determine or control where the player is and what he is doing |
Movement Modes are set up within the Character Def,
and are used to create differing player states, in which the player reacts differently to input and
the environment. script functions may change the Movement mode at any time by changing
the Player Variable Player_Movement_Mode to create such effects as
causing a player to react to taking damage, or change the player's action in response to certain input.
Movement Modes are separate from Path Modes, and changing both independantly
can cause different effects. They are made up of the following parts:
|
Path Modes are the hard-coded movement modes which HCGE uses to move the player based on his Velocities
and test for collision against objects and level tile planes. These modes are the first part of the Movement Phase,
and occur before the scripted Movement Mode handling, which are responsible for all other player control functionality. The velocities by which the player is moved are "fixed-point" values, meaning that they are whole numbers that describe whole and partial pixel movement counts. This value allows for 256 units of partial movement before the player is moved one unit across the screen, which means that the number of whole pixels that the player will move is velocity/256, or velocity>>8. At the beginning of player movement, the current X and Y Velocities are added to the Count variables, which are used as counters while the player moves one whole pixel unit through the level at a time. After each unit of movement, the player tests for collisions with the current solid level plane, runs the scripted collision functions for each active game object, and removes 256 (one whole pixel unit) from the counter, until there are less than 256 units of velocity left, which are left in the counter until the next frame. This method allows for smooth acceleration when the player's velocity is increased by units less than 256 (one pixel), since partial units of velocity are preserved between game frames, and collision testing for every whole unit of motion allows for finer collision testing, allowing the player to react to collision at the exact moment that it happens (during player movement, though not during object movement) The player's velocities are made up of the X and Y "component velocities", and the "Path"/Vector velocity. The "Path Velocity" is the speed at which the player is moving along a path, or in freespace. When the player is flagged for "vector movement", the Path Angle is used to break the Path Velocity into the component X and Y velocities, which are used as described above. When not using vectored movement, or when in freespace, the full Path Velocity value is used as the player's speed based on the current Path Mode in the following way: Floor: X = Path, y = y Ceiling: X = -Path, y = y LWall: Y = Path, x = x RWall: Y = -Path, x = x Other: x = x, y = yThere are 9 valid Path Mode settings that control in what direction "path" collisions are processed: 0 - _PPM_Floor
1 - _PPM_Right
2 - _PPM_Ceiling
3 - _PPM_Left
4 - (No Collision) 5 - (No Collision) 6 - (No Collision) 7 - (No Collision)
8 - _PPM_Debug
Each of the first four Path Modes are made up of two parts: - Path Tracer
- Freespace Movement
|
The Player Movement Object is a built-in game object that causes the player to process his movement and
script functions. This object must be spawned for each player that is meant to function in each level. This object
processes in three phases, which occur in the following order: - Movement Phase
- Input Phase
- Update Phase
|
The Player Draw Object is a built-in game object that must be spawned and assigned to a Player Character before that Player Character will become visible. When this object is reached during Game Object Processing, the last display frame set by the player's currently-running Animation will be drawn to the screen. When this happens in relation to the drawing of other Game Objects is determined by the Priority assigned to each object |
Player "Fetching" is the method by which Players are set as the "Source" and/or "Destination" for Script Commands that manipulate Player Variables, or any other aspect of a Player. Because there are at most two Sources and one Destination used by any Script Command, there are three "References" that any Player can be "Fetched" into. Using the mathematical add operation as an example, the general rule is:
Where: This is also true for operations with only one Source operand, and for non-mathematical operations. Any Player that is being manipulated in any way is considered to be the "Destination", while any Player or Object that provides information for the manipulation of the Destination is considered to be a "Source". If a Command uses only one Source, The one Source Parameter is "Reference 0". If there are two Sources that are both Players, then the first Source Parameter is "Reference 0", and the second is "Reference 1". Since Players are considered distinct from other Objects, they have their own set of References; this means that if there are two Sources, one Object and one Player, the first Source Parameter is "Reference 0" in terms of Objects, and the second Source Parameter is "Reference 0" in terms of Players. A single Player may be "Fetched" to more than one "Reference" if it must serve as both Sources, one Source and the Destination, or both Sources and the Destination. Pointers to Players can be obtained by use of the Func_???_Equ_Pointer_???_Chr Script Commands and stored in any Player Variable, Game Variable, or Object Variable for later retrieval by "Fetch". This method of Player referencing can allow any part of the game to keep up with any one Player for any reason. |