GameMainDefclass | misc.t[47], en_us.t[152] |
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 en_us.t[152]:
Language-specific extension of the default gameMain object implementation.
class
GameMainDef : object
(none)
(none)
GameMainDef
object
allowYouMeMixing
allVerbsAllowAll
cancelCmdLineOnFailure
filterPluralMatches
initialPlayerChar
scoreRankTable
useDistinguishersInAnnouncements
usePastTense
verboseMode
maxScore
newGame
restoreAndRunGame
setAboutBox
setGameTitle
showGoodbye
showIntro
allowYouMeMixing | misc.t[281] |
If desired, the game can set this flag to nil to force the player to use the correct pronoun to refer to the player character.
We set the default to allow using "you" and "me" interchangeably because this will create no confusion in most games, and because most experienced IF players will be accustomed to using "me" to refer to the player character (because the majority of IF refers to the player character in the second person, and expects the player to conflate the player character with the player and hence to refer to the player character in the first person). It is relatively unconventional for a game to refer to the player character in the first person in the narration, and thus to expect the player to use the second person to refer to the PC; as a result, experience players might tend to use the first person out of habit in such games, and might find it jarring to find the usage unacceptable. Furthermore, in games that use a first-person narration, it seems unlikely that there will also be a second-person element to the narration; as long as both aren't present, it will cause no confusion for the game to accept either "you" or "me" as equivalent in commands. However, the library provides this option in case such as situation does arise.
allVerbsAllowAll | misc.t[316] |
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.
cancelCmdLineOnFailure | misc.t[352] |
There's no perfect solution. As always, the ideal is to understand the player's intentions and act accordingly. But when a command fails, it's usually because the player's idea of what's going on is out of sync with the game's - in other words, if we're in this situation to start with, it's probably because our best effort to understand the player's intentions has already failed. This isn't always the case; sometimes we understand the player's intentions perfectly well, but the command fails anyway because of some surprising new development. In these cases, aborting the rest of the command is arguably the right approach, because the player will need a chance to reconsider the pre-typed commands in light of the new information. In other cases, though, it's not so clear. For many players, the prime virtue for the parser is to be predictable, and the most predictable thing to do is to simply plow through the rest of the command line in all cases.
Our traditional approach (from the early adv3 versions, and even in tads 2) has been the simple-minded approach - just keep going in all cases. So, we make this the default. You can abort remaining commands on a command failure by setting this to true.
filterPluralMatches | misc.t[297] |
This is set to true by default, which means that we exclude an object from matching a plural phrase when the object's "verify" routine for the verb has an "illogical-already" or an "illogical-self" result.
If you would prefer that plural words are simply matched to everything present that matches the vocabulary, without any filtering at all, override this and set it to nil.
initialPlayerChar | misc.t[53] |
scoreRankTable | misc.t[233] |
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.
useDistinguishersInAnnouncements | misc.t[368] |
(This is optional because the current implementation is a bit twitchy for most people's taste. The problem is that it's a bit *too* specific in many cases, showing more qualification than is really necessary. We make this an option so that authors can enable it and possibly tweak it a bit to meet their needs.)
usePastTense | en_us.t[167] |
This property can be reset at any time during the game in order to switch between the past and present tenses. The macro setPastTense can be used for this purpose: it just provides a shorthand for setting gameMain.usePastTense directly.
Authors who want their game to start in the past tense can achieve this by overriding this property on their gameMain object and giving it a value of true.
verboseMode | misc.t[248] |
We use a BinarySettingsItem to store the current mode, so that this setting's default will be taken from the user's global cross-game preferences.
maxScore ( ) | misc.t[200] |
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[89] |
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[128] |
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[176] |
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[161] |
showGoodbye ( ) | misc.t[75] |
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[65] |
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.