#==============================================================================
# ** RMXP Standard Development Kit (SDK)
#------------------------------------------------------------------------------
# Build Date - 2005-11-22
# Version 1.0 - Near Fantastica - 2005-11-22
# Version 1.1 - SephirothSpawn - 2005-12-18 - (Near Fantastica)
# Version 1.2 - Near Fantastica - 2005-12-18
# Version 1.3 - Wachunga - 2005-12-19
#------------------------------------------------------------------------------
=begin
1.0 - Outline
The Standard Development Kit (SDK) aims to increase compatibility between
RGSS scripts by:
a) defining a set of scripting standards (see section 3)
b) restructuring often-used default classes and methods (see section 4)
c) providing a scripting tools module (see section 5)
#------------------------------------------------------------------------------
2.0 - Modifications to the RMXP Standard Development Kit
Since edits to the SDK may cause massive capability errors, any and all
modifications must first be approved by a member of the RMXP SDK Team.
The author of any modifications must be sure to update all relevant
documentation. This also includes the header, where the author is to put
the next version number with his or her name and the name of the approval
member (from the SDK Team) under the latest version in the following format.
Version # - Name - Date - (Approval Member Name)
#------------------------------------------------------------------------------
3.0 - Coding Standards
To be compliant with the SDK, a script must compy with the following
coding standards:
#==============================================================================
# ** Script Name
#------------------------------------------------------------------------------
# Your Name
# Version
# Date
#==============================================================================
All classes and methods must have a comment describing the process or what
was added. All code added to methods that can not be aliased must be
formatted as follows:
#------------------------------------------------------------------------------
# Begin Script Name Edit
#------------------------------------------------------------------------------
[Code]
#------------------------------------------------------------------------------
# End Script Name Edit
#------------------------------------------------------------------------------
Single line comments should precede the described block of code and should be
indented at the same level. Code that is not self-documenting should be
commented.
However, very short comments can appear on the same line as the described
code, but should be shifted far enough to separate them from the statements.
If more than one short comment appears in a chunk of code, they should all be
indented to the same tab setting. Attribute declarations should always have a
trailing comment.
#------------------------------------------------------------------------------
3.2 - Classes
All classes must be named consistently with the default code, namely:
Data - Any class that holds data
Game - Any class that processes data
Sprite - Any class that defines a sprite
Spriteset - Any class that defines multiple sprites
Window - Any class that defines a window
Arrow - Any class that defines an arrow
Scene - Any class that defines a scene
#------------------------------------------------------------------------------
3.3 - Variables
All variable names must be reasonably descriptive. Use of class and global
variables should be limited. Any variable used by the default system can not
have its use changed.
#------------------------------------------------------------------------------
3.4 - Aliases
Aliasing a method is preferable to overriding it; an alias should be used
whenever possible to increase compatibility with other scripts. All alias
names must have the following format:
Strings should normally be defined with single quotes ('example'); this
decreases the processing time of the engine. Double quotes are useful when
using the following features:
a) substitutions, i.e. sequences that start with a backslash character
(e.g. \n for the newline character)
b) expression interpolation, i.e. #{ expression } is replaced by the value
of expression
#------------------------------------------------------------------------------
3.6 - Line Length
Lines should not cause the the viewer to have to scroll sideways to view them
in the script editor. When the line needs to be broken, it should follow the
following guidelines, in preferential order:
Break after a comma.
Break before an operator.
Prefer higher-level breaks to lower-level breaks.
Align the new line with the beginning of the expression at the same level
on the previous line.
If the above rules lead to confusing code or to code that抯 squished up
against the right margin, just indent 4 spaces instead.
#------------------------------------------------------------------------------
3.7 - White Space
A blank line(s) should be used in the following places:
Between sections of a source file
Between class and module definitions
Between attributes and the class definition
Between methods
Between the local variables in a method and its first statement
Before a block or single-line comment
Between logical sections inside a method to improve readability
Blank spaces should be used in the following places:
A keyword followed by a parenthesis, e.g. if (some_boolean_statements)
After commas in argument lists, e.g. def method (arg1, arg2, ...)
All binary operators except '.', e.g. a + b; c = 1
#------------------------------------------------------------------------------
3.8 - Constants
New numerical values should not be "hard-coded", except for -1, 0, and 1,
which can appear in for loops as counter values. Instead, these numerical
values should be made into constant variables and these used instead.
#------------------------------------------------------------------------------
3.9 - Parentheses
It is generally a good idea to use parentheses liberally in expressions
involving mixed operators to avoid operator precedence problems. Even if
the operator precedence seems clear to you, it might not be to others -?you
shouldn抰 assume that other programmers know precedence as well as you do.
#------------------------------------------------------------------------------
4.0 - Engine Updates
The following is a list of classes and methods that have been updated by the
SDK to help improve compatibility:
The following tools are included in the SDK to help improve the development
process:
5.1 - Logging Scripts
5.2 - Enabling/Disabling Scripts
5.3 - Script Dependencies
5.4 - Standard Text Box Input
5.5 - Standard Event Comment Input
#------------------------------------------------------------------------------
5.1 ?Logging Scripts
All SDK-compliant scripts should be logged. This is done by calling the
SDK.log(script, name, ver, date) method, where
script = script name
name = your name
ver = version
date = date last updated
#------------------------------------------------------------------------------
5.2 ?Enabling/Disabling Scripts
When a script is logged it is also enabled. A script can be enabled and
disabled using the following calls:
All non-default scripts (and code added to default scripts) must be enclosed
in an if statement that checks whether or not they have been enabled, as
follows:
#--------------------------------------------------------------------------
# Begin SDK Enabled Check
#--------------------------------------------------------------------------
if SDK.state('Script Name') == true
[Script or Code]
end
#--------------------------------------------------------------------------
# End SDK Enabled Test
#--------------------------------------------------------------------------
Keep in mind that this if statement can not continue on to other pages and
every page needs its own if statement testing the state of the script. As
well every script should have its own test.
#------------------------------------------------------------------------------
5.3 ?Script Dependencies
Any script that requires (i.e. has a dependency on) another script can check
if that dependency is met provided that the required script is set up before
the script in question. This would be done in the following way:
p 'Script Name not found' if SDK.state('Script Name') != true
#------------------------------------------------------------------------------
5.4 ?Standard Text Box Input
Any script that requires input from a database text field should use the
following:
SDK.text_box_input(element, index)
where:
element = an object of the text field
index = the index in which your script call falls
The text field should be formatted in the following way:
Any script that requires input from an event comment should use the
following:
SDK.event_comment_input(event, elements, trigger)
where:
event = an object of the event
elements = the number of elements the method is to process
trigger = the text value triggering the script to start processing
or
SDK.event_comment_input(page, elements, trigger)
where:
page = an object of the event.page
elements = the number of elements the method is to process
trigger = the text value triggering the script to start processing
The method returns nil if the trigger can not be found; otherwise, it
returns a list of the parameters from the event.
#==============================================================================
=end
窥视卡
雷达卡
发表于 2024-4-19 15:32:27
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
