関数と言えば普通は Function だが、GM：S のリソースツリーでは製作者が GML を使って自作した独自の関数を「スクリプト ( scripts )」と言う名前で管理している。
※注意点
どうしても筆者には強い違和感があるので、GM:Studio でユーザ定義によって独自に作られる関数をスクリプトと呼びたくない。このため、当ブログではスクリプトと呼ばずに「ユーザ定義関数／独自定義関数」などと呼称します。「関数」と書いた場合にはBuilt-In Functions の関数(標準ライブラリ関数)を指します。
ユーザ定義関数の必要性
コードを使って動作定義を書いていると、似たような処理が別の箇所でも重複して必要になる場合があります。この場合、まず該当処理のコピペ（コピー＆ペースト）が原始的ながら効率的で、とりあえずこれで動く、ならばこれでも良いです。独自定義の関数なんぞ使わなくとも困りません。
しかし同じ処理を何度もコピペで貼り付けることによってコードの量がどんどん増えてしまい、コード全体の見通しが悪くなった場合はどうでしょうか。
あるいは同じ処理をさせるつもりでコピペしたら、どこかでコピペにミスる可能性もあるし、コピペの元となったコードに修正が必要になった場合、これまで何度もコピペした分を全部修正する必要があります。つまりコピペは万能ではなく、このような場合はユーザ定義関数を作ってそれを使うべきだったのです。
ルーチンワークをユーザ定義関数化
ルーチンワークの例として「刺身の上にタンポポのせる仕事」というネタがあります。プログラムではこれをユーザ定義関数化することができます。
上記例でものせるだけなら単なる流れ作業ですが、果たして本当に流れ作業なのでしょうか？
例えばのせるタンポポが痛んでいたらそのタンポポは弾かれるべきだし、刺身が腐っていたら？その刺身を使う事自体がマズイです。与えられた材料や素材の状態を判断して具体的な処理や処分を決定する必要がありそうな作業ですね。
絶望のルーチンワークの中でも、状況に応じた「最適判断」を実行するためには、与えられた材料を診断したり評価したりといった演算能力は最低限必要という事です。
プログラムにおける「関数」は頼まれた仕事を黙々と処理する働きをしますが、「引数」という要素を関数に与えて、状況に応じた判断を関数の内部で実行させることもできます。関数に引数を与えれば、刺身の上にタンポポだけではなくチューリップを載せたりトリカブトを添えたりと業務内容の拡張も容易です。
そして作業終了後に報告が必要なら、return ステートメントを使って結果報告させる機能もあります。
関数 【 function 】
ルーチンを実行する。引数を与えられた場合は引数を元にした条件判断を関数内部で行い、return があれば結果を戻り値として関数の呼び出し元に返す役割までをセットに行う。
引数 【 arguments／Parameter 】
関数に与える材料・素材としての数値や文字列、配列などデータ。引数を必要としない関数もある。与えることができる引数の数は上限がある。GML では
16個まで。
戻り値 【 return value 】
関数で return 文が使われた場合に返って来るデータ／値。return が無い場合もある。
参考 (YoYoGames)：Scripts
