GameMainDefclass | misc.t[56], objtime.t[156] |
Superclass Tree | Subclass Tree | Global Objects | Property Summary | Method Summary | Property Details | Method Details |
Each game MUST define an object called 'gameMain' to define how the game starts up. You can use GameMainDef as the base class of your 'gameMain' object, in which case the only thing you're required to specify in your object is the 'initialPlayerChar' property - you can inherit everything else from the GameMainDef class if you don't require any further customizations.
Modified in objtime.t[156]:
Modification to GameDef to add an additional property for use with the OBJTIME EXTENSION
class
GameMainDef : object
againRepeatsParse
allVerbsAllowAll
autoSwitchAgain
beforeRunsBeforeCheck
fastGoTo
gameStartTime
initialPlayerChar
paraBrksBtwnSubcontents
scoreRankTable
useParentheticalListing
usePastTense
verbose
getSaveDesc
maxScore
newGame
restoreAndRunGame
setAboutBox
setGameTitle
showGoodbye
showIntro
againRepeatsParse | misc.t[378] |
allVerbsAllowAll | misc.t[342] |
Some authors don't like to allow players to use ALL with so many verbs, because they think it's a sort of "cheating" when players try things like OPEN ALL. This option lets you disable ALL for most verbs; if you set this to nil, only the basic inventory management verbs (TAKE, TAKE FROM, DROP, PUT IN, PUT ON) will allow ALL, and other verbs will simply respond with an error ("'All' isn't allowed with that verb").
If you're writing an especially puzzle-oriented game, you might want to set this to nil. It's a trade-off though, as some people will think your game is less player-friendly if you disable ALL.
autoSwitchAgain | misc.t[386] |
beforeRunsBeforeCheck | misc.t[359] |
In many ways it's more logical and useful to run "check" first. That way, you can consider the action to be more or less committed by the time the "before" notifiers are invoked. Of course, a command is never truly* committed until it's actually been executed, since a "before" handler could always cancel it. But this is relatively rare - "before" handlers usually carry out side effects, so it's very useful to be able to know that the command has already passed all of its own internal checks by the time "before" is invoked - that way, you can invoke side effects without worrying that the command will subsequently fail.
fastGoTo | misc.t[401] |
gameStartTime | objtime.t[165] |
initialPlayerChar | misc.t[62] |
paraBrksBtwnSubcontents | misc.t[322] |
scoreRankTable | misc.t[303] |
This is a list of score entries. Each score entry is itself a list of two elements: the first element is the minimum score for the rank, and the second is a string describing the rank. The ranks should be given in ascending order, since we simply search the list for the first item whose minimum score is greater than our score, and use the preceding item. The first entry in the list would normally have a minimum of zero points, since it should give the initial, lowest rank.
If this is set to nil, which it is by default, we'll simply skip score ranks entirely.
useParentheticalListing | misc.t[312] |
usePastTense | misc.t[367] |
For a wider selection of tenses override Narrator.tense instead.
verbose | misc.t[392] |
getSaveDesc (userDesc) | misc.t[225] |
Some interpreters display information from this table when presenting the user with a list of files for RESTORE. The contents of the table are intentionally open-ended to allow for future extensions, but at the moment, the following keys are specifically defined (note that capitalization must be exact):
UserDesc - descriptive text entered by the user (this should simply be the contents of the 'userDesc' parameter). This is treated as ordinary plain text (i.e., no HTML or other markups are interpreted in this text).
AutoDesc - descriptive text generated by the game to describe the saved position. This text can contain the simple HTML markups <b>..</b>, <i>..</i>, and <br> for formatting.
Return nil if you don't want to save any metadata information.
'userDesc' is an optional string entered by the user via the Save Game dialog. Some interpreters let the user enter a description for a saved game via the file selector dialog; the descriptive text is separate from the filename, and is intended to let the user enter a more free-form description than would be allowed in a filename. This text, if any, is passed to use via the 'userDesc' parameter.
maxScore ( ) | misc.t[270] |
By default, we initialize this on demand, by calculating the sum of the point values of the Achievement objects in the game. The game can override this if needed to specify a specific maximum possible score, rather than relying on the automatic calculation.
newGame ( ) | misc.t[98] |
You can override this routine if you want to customize the startup protocol. For example, if you want to create a pre-game options menu, you could override this routine to show the list of options and process the user's input. If you need only to customize the introduction and goodbye messages, you can simply override showIntro() and showGoodbye() instead.
restoreAndRunGame (filename) | misc.t[139] |
This default implementation bypasses any normal introduction messages: we simply restore the game file if possible, and immediately start the game's main command loop. Most games won't need to override this, but you can if you need some special effect in the restore-at-startup case.
setAboutBox ( ) | misc.t[187] |
Note that an <ABOUTBOX> tag must be re-initialized each time the main game window is cleared, so this routine should be called again after any call to clearScreen().
setGameTitle ( ) | misc.t[172] |
showGoodbye ( ) | misc.t[84] |
We don't show anything by default. If you want to show a "thanks for playing" type of message as the game exits, override this routine with the desired text.
showIntro ( ) | misc.t[74] |
Most games will want to override this, to show a prologue message setting up the game's initial situation for the player. We don't show anything by default.