Изменения

''Это 11 глава перевода оригинального руководства по Dream Maker от разработчиков.''

''Это 11 глава перевода оригинального руководства по Dream Maker от разработчиков.''

<!--All user input seen so far has come at the initiative of the user. The player may type a command, press a direction key, click an object, etc. These forms of input are all similar because they are ultimately handled by verbs. In the case of the direction keys and mouse clicks, players don't need to actually type any command--the client does it all. However, from the programmer's point of view, these are all the same: The player calls a procedure and possibly passes some arguments to it.-->

<!--All user input seen so far has come at the initiative of the user. The player may type a command, press a direction key, click an object, etc. These forms of input are all similar because they are ultimately handled by verbs. In the case of the direction keys and mouse clicks, players don't need to actually type any command--the client does it all. However, from the programmer's point of view, these are all the same: The player calls a procedure and possibly passes some arguments to it.-->

Есть несколько заранее определённых операторов(verbs), принимающих ввод информации от игрока. Это кнопки направления\стрелки (напр. client.North()), щелчок мыши (client.Click() и client.DblClick()) и ссылки топиков (client.Topic()). Все остальные операторы(verbs) задаются программистом.

Есть несколько заранее определённых операторов(verbs), принимающих ввод информации от игрока. Это кнопки направления\стрелки (напр. client.North()), щелчок мыши ((client.Click() и client.DblClick()) и ссылки топиков (client.Topic()). Все остальные операторы(verbs) задаются программистом.

<!--The only pre-defined verbs are associated with the client data object. They are the direction keys (e.g. client.North()), mouse clicks (client.Click() and client.DblClick()), and topic links (client.Topic()). All other verbs are defined by the programmer.-->

<!--The only pre-defined verbs are associated with the client data object. They are the direction keys (e.g. client.North()), mouse clicks (client.Click() and client.DblClick()), and topic links (client.Topic()). All other verbs are defined by the programmer.-->

browse (Doc, Options)

browse (Doc, Options)

Doc is the message to display. Options are various window-specific options. Consult the reference for specifics.

Doc is the message to display. Options are various window-specific options. Consult the reference for specifics.

By default, each message replaces any previous message being displayed but the user can move back to previous messages stored in the client's memory. In many ways, the client terminal behaves like a telnet session and the browse window behaves like a web browser. One displays output sequentially in a continuous stream. The other displays it in discrete chunks—one document after another. The two are each useful in different situations.

By default, each message replaces any previous message being displayed but the user can move back to previous messages stored in the client's memory. In many ways, the client terminal behaves like a telnet session and the browse window behaves like a web browser. One displays output sequentially in a continuous stream. The other displays it in discrete chunks--one document after another. The two are each useful in different situations.

The document is often a text string. However, it may be a file instead. The type of file will determine how it is handled. Files may reside in the resource cache or in the file system. As always, cached items may be specified by putting the file name in single quotes. An external file, on the other hand, is indicated using the file instruction described in section 11.2.7.

The document is often a text string. However, it may be a file instead. The type of file will determine how it is handled. Files may reside in the resource cache or in the file system. As always, cached items may be specified by putting the file name in single quotes. An external file, on the other hand, is indicated using the file instruction described in section 11.2.7.

       usr.enemy_marker = image('outline.dmi',M)

       usr.enemy_marker = image('outline.dmi',M)

       usr << usr.enemy_marker

       usr << usr.enemy_marker

The code works by first deleting any old enemy marker. A new one is then made and displayed to the user. No one else will see the image—only the player who clicked on the enemy.

The code works by first deleting any old enemy marker. A new one is then made and displayed to the user. No one else will see the image--only the player who clicked on the enemy.

"I am very mad!"

"I am very mad!"

The start tag ''' turns on bold lettering and ''' turns it off. For a complete list of tags understood by DM, see page 3 in the appendix. The most commonly used ones are listed in figure 11.19 for easy reference.

The start tag <B> turns on bold lettering and </B> turns it off. For a complete list of tags understood by DM, see page 3 in the appendix. The most commonly used ones are listed in figure 11.19 for easy reference.

Figure 11.19: Common text tags

Figure 11.19: Common text tags

anchor (for hyperlinks)

anchor (for hyperlinks)

'''''' bold

<B></B> bold

<BIG></BIG> bigger text

<BIG></BIG> bigger text

<BR> line break

<BR> line break

<FONT></FONT> font face, size, and color

<FONT></FONT> font face, size, and color

'''' italic

<I></I> italic

 

<P></P> paragraph

 

 

 

paragraph

<S></S> overstrike

<S></S> overstrike

<SMALL></SMALL> smaller text

<SMALL></SMALL> smaller text

Whitespace refers to any spaces, tabs, or newlines. In standard HTML, whitespace serves merely to delimit words. The amount of space and whether it is a tab, space, or newline is irrelevant.

Whitespace refers to any spaces, tabs, or newlines. In standard HTML, whitespace serves merely to delimit words. The amount of space and whether it is a tab, space, or newline is irrelevant.

DM processes whitespace like standard HTML when it is inside of a pair of start and end tags. So, for example, inside of  

DM processes whitespace like standard HTML when it is inside of a pair of start and end tags. So, for example, inside of <P> and </P>, the paragraph markers, standard HTML rules are in effect; newlines, spaces, and tabs serve merely to delimit words. Note that an entire document could be surrounded by <HTML> and </HTML> to mark the whole thing as standard HTML.

 

and  

 

, the paragraph markers, standard HTML rules are in effect; newlines, spaces, and tabs serve merely to delimit words. Note that an entire document could be surrounded by <HTML> and </HTML> to mark the whole thing as standard HTML.

Outside of all HTML tags, DM handles whitespace a little differently. Spaces still delimit words, but newlines (embedded with \n) mark the end of lines. In other words, the newline is automatically converted to <BR>, the linebreak tag. That is convenient for use in messages composed by players when it would be annoying to write formal HTML with paragraph tags and so forth.

Outside of all HTML tags, DM handles whitespace a little differently. Spaces still delimit words, but newlines (embedded with \n) mark the end of lines. In other words, the newline is automatically converted to <BR>, the linebreak tag. That is convenient for use in messages composed by players when it would be annoying to write formal HTML with paragraph tags and so forth.

HTML tags, such as <FONT> may be used to directly format output text. Another approach, however, is to use HTML tags to specify purely structural information and use a style sheet to define how various elements within that structure should be treated. DM uses a subset of the Cascading Style Sheet (CSS) language, which was introduced for this purpose in HTML documents.

HTML tags, such as <FONT> may be used to directly format output text. Another approach, however, is to use HTML tags to specify purely structural information and use a style sheet to define how various elements within that structure should be treated. DM uses a subset of the Cascading Style Sheet (CSS) language, which was introduced for this purpose in HTML documents.

As an example of a style sheet, suppose one wanted combat and conversational messages to appear differently—perhaps using different colors. Instead of using the <FONT> tag to color the text, you could use <SPAN> to mark the beginning and ending of the text and to specify what kind of message it is. The result might be text such as the following:

As an example of a style sheet, suppose one wanted combat and conversational messages to appear differently--perhaps using different colors. Instead of using the <FONT> tag to color the text, you could use <SPAN> to mark the beginning and ending of the text and to specify what kind of message it is. The result might be text such as the following:

"[usr] spanks [targ]!"

"[usr] spanks [targ]!"

.system {color: red; font-weight: bold}

.system {color: red; font-weight: bold}

.command {color: green}

.command {color: green}

In this example, the background color of the terminal will be aqua, normal text from the server will be black, and all output from the client will be bold and red, except echoed commands and expansion lists, which will be bold and green. The more specific .command rule is placed after the general .system rule so that its color takes precedence. This is how style sheets are composed—you write general rules first followed by any exceptions.

In this example, the background color of the terminal will be aqua, normal text from the server will be black, and all output from the client will be bold and red, except echoed commands and expansion lists, which will be bold and green. The more specific .command rule is placed after the general .system rule so that its color takes precedence. This is how style sheets are composed--you write general rules first followed by any exceptions.

The advantage of using icon states in this way is that the code remains very general. All the map designer has to do is plug in different icons with the same states and a variety of doors can be made from the one basic definition.

The advantage of using icon states in this way is that the code remains very general. All the map designer has to do is plug in different icons with the same states and a variety of doors can be made from the one basic definition.

If the icon state specified by the flick instruction does not exist, it has no effect. In the above code, for example, a door icon could be used that did not have "opening" and "closing" states defined. Everything would work—only the transition would not be animated.

If the icon state specified by the flick instruction does not exist, it has no effect. In the above code, for example, a door icon could be used that did not have "opening" and "closing" states defined. Everything would work--only the transition would not be animated.