RPG
The RPG is currently still in heavy development with many features still unimplemented. With the advent of the 2.7.0 release it has entered the Alpha stage. It may still change dramatically in the near future, but the various interfaces at this point are more or less stable and should function correctly with future releases.
Contents
References
Tutorials
Misc. pages
Internals
The creator is capable of defining and manipulating a great many facets of his game, and future releases promise to increase these capabilities and freedoms.
Cutscenes
Cutscenes unlike definitions can contain things other than numbers in their names and aren't loaded into memory until they are needed. Cutscenes can always be skipped and you as the creator should therefor make sure that the post script takes care of any changes of state that need to happen, additionally during cutscenes are the only time the player can be commanded via AI commands.
There are two parts to the cutscene system, the first is directives for the camera and the second are 2D elements to be drawn on screen and their containers.
with respect to the 2D elements, the cutscene system functions like the HUD in this regard, fitting a proportionally scaled 1600x1200 virtual screen into yours and then adjusting the size to cover the entire screen and storing the size in the hud_right and hud_bottom variables.
Containers basically group a series of actions together and influences them in some way (eg, rotates 2D elements). Containers are destroyed when they no longer possess any children. A very handy use for these are to allow layers. For example, you could create a slide container and a subtitle container, this will result in the subtitles always being drawn above the slides.
Definitions
The creator can define just about anything, from creatures, monsters, maps, containers, scripts, dialogue, cutscenes, HUDs, GUIs and particle effects. The definitions are sourced from the game's data directory and can be changed in real time during the game. It should be noted that unless things use these definitions as a template, any effects from ingame modifications will not persist across sessions. We therefor recommend that you only use those that accept references as any changes to them will persist unless you simply wish to test and fine tine some variables quickly and easily.
Also note that all definitions must be defined in a separate text file named solely by a number with a .cfg extension. Any other .cfg files will throw warnings and the game will abort if there are any gaps. At least that is true for the hard-coded directories - you may add additional ones and use include to include their files in your scripts and definitions.
For example, there is a definition for a bear creature with 40 strength. I might increase this to 90 in game, but any existing bears will still have 40 strength. Likewise I could create a few new bears which would then have 90 strength. if I was to save and reload my game, any new bears will have 40 strength but those spawned with 90 strength will still exist and walk about.
Game state
All map related information, short of the map's entities, waypoints and geometry are stored in a hashtable. This hashtable includes the properties of the map, the script, the name and the entities currently present as well as any queued actions that are awaiting the player's arrival.
Generally speaking, any map besides the current map isn't updated and is in a state of limbo until the player goes there.
GUIs
The RPG defines a series of commands to facilitate the creation of custom GUIs, unlike previous iterations the GUI isn't hard coded although it depends on a few hard coded names.
Essentially all the RPG does in relation to this is to force the talk GUI open during conversations and to pause the game while a GUI is open. newui currently isn't properly supported.
HUDs
The placement of all HUD entities are defined entirely through script, the script itself is evaluated once every update and can be redefined at any part of the game using a r_hud invocation.
The HUD pretends to be a 1600x1200 screen scaled to fit inside your screen and then has its dimensions adjusted, these dimensions are stored in the variables, hud_right and hud_bottom which you should query when you draw items offset from the bottom or the right. The only benefit of using such a size is that it's far easier to get a sense of scale and to understand in general than a 0.f to 1.f range.
In case you're wondering why there is a hud_bottom and not a hud_up, the reason is that the screen coordinates are flipped and that the top left is therefor (0, 0), not the bottom left.
Multiplayer
The RPG wasn't designed to accommodate multiplayer. We may consider NWN style coop sometime in the distant future but the RPG simply lacks any multiplayer capability what so ever.
In other words, this module is presently single player only and will likely remain so.
Savegames
Savegames store the game state and the game definition source. Definitions and the AI's state isn't stored, the one exception is recipes in which a portion of the flags slot is saved. specifically the portion that tells us if the player knows the recipe.
Otherwise, everything is saved in a compressed archive, from maps and their contents, to the various properties of each and every existing entity to the whole reference table.
It should be noted that you cannot save at certain points, specifically during dialogue, cutscenes, in editmode and on maps with the F_NOSAVE flag set.
Scripts
Scripts are signal based, you define a signal to listen for and a set of actions to execute when that signal is received. There are several types, those the game sends on every update, those the game sends under certain conditions and those the creator manually sends himself via r_signal.
The second and probably the most important facet of scripting is the use of references. The reference system is type safe, prone to whining (the solution is to fix what it's complaining about, not ignore it) and is implemented as a layer utilising cubescript as opposed to being a part of it.
The reference system is implemented as an array of hashtables, which introduces the concept of scope and shadowing and there are also some hard-coded reserved references. At present these are specifically, "player", "curmap", "talker", "self" and "actor", you should not change them and they will likely be read only in the near future. In addition there are also temporary references, these aren't saved in the save game and are cleared at the end of the update cycle. Some of the destinations may persist for a long time but there is no such guarantee.
