ファイル読み込みの部分がうまくいってないようですね。
GMSのファイル読み書きのデフォルトのパスは確か C:\Users\UserName\AppData\Local\ProjectName\ ですのでここにファイルがある必要があります。
ここにtext.txt（UTF-8で保存したもの）を置いて、これが動くか試してみてください。
var _file = file_text_open_read("text.txt"); var _str = file_text_read_string(_file); show_debug_message("_str="+string(_str)) file_text_close(_file);
正しく読み込まれて動作すればこうなります。
ゲームからファイルを作成し、書き込み読み込みをする処理の場合はこれでいいと思います。 (ゲームのコンフィグデータなど)
ですが、シナリオのテキストは予め自分で作ったテキストファイルをゲームに付属させる形になると思います。 ゲームを配布する時に、ユーザーのPCにこれをどうやって配置すればいい？となりますよね。 プロジェクトにファイルをインクルードすることで実現できます。
リソースツリーのところからファイルをインクルードすると、プロジェクトのフォルダ内にdatafilesというフォルダが作られ、そこにファイルがコピーされます。これで完了。開発環境でも動くし配布したゲームも動くはずです。テキストを編集する際はdatafilesにあるファイルを編集してください。
配布するゲームをビルド（Ctrl+F8）すると、このファイルはexeファイルと同じ場所に付属する形でコピーされるはずです。やってみてください。
ゲームを遊ぶユーザーから見ると、exeファイルがある場所にtext.txtがあるので開けば見たり編集できます。それをできにくくするなら暗号化したりという手段があります。それも解読不可能では無いと思うので、絶対見られたくないならシナリオテキストもプロジェクトのコード内に書く形にするしか無いのかなと思います。その場合でもリバースエンジニアリングで読まれる可能性は残ります。
私が書けるのはこんな感じで、「よく分からないがこうすると動く」的なことだけです。 コンピュータ、GMSのファイルI/Oについて、詳しい方からの解説を待ってます！ （サンドボックスとは？など私もちゃんと理解したい）
ご丁寧にありがとうございます。 細分化の考え方 非常に勉強になりました。
NPCの近くでSPACEキーを押すとシナリオが流れる機能と、全てのシナリオが終わるまでプレイヤーのスピードを0にしてキー受付を中断する簡単なポーズ機能は実装できました。 ですが各NPCにシナリオを割り当てる方法しか実装できず、色々調べてみたのですがテキストファイルを開いて配列に代入する方法がわかりませんでした。 シナリオはテキストファイルに一括で管理するイメージなので教えていただけるとありがたいです。
file_open_read()で開きfile_text_read_string()で配列に代入してfile_close()で閉じる流れはわかるのですが、テキストファイルの位置を指定してもファイルを開く関数でエラー(-1)が出てしまいます。
コード(NPCオブジェクトのcreateイベント内に記述しています) fid = file_text_open_read("text.txt"); show_debug_message(fid); str[0] = file_text_read_string(fid); file_text_readln(fid); str[1] = file_text_read_string(fid); file_text_close(fid);
エラー文 ERROR!!! :: Failed to open file: text.txt -1 ERROR!!! :: ERROR in action number 1 of Create Event for object oNPC2:
File is not opened for reading. at gml_Object_oNPC2_Create_0 (line 7) - str[0] = file_text_read_string(fid);
todoリストの機能をつけてほしいです。ただのtodoリストでもいいんですが、エディタ側にtodoのマーキングが出来て、todoリストからソースの該当箇所まで飛べたらさらにヨシです。
IMEをオンにするとショートカットが効かなくなる不具合を直してほしい。 （IMEをオフにして一度他のソフトの窓にフォーカスを移して戻ると直る）
日本語フォントの表示が荒れる問題を改善してほしい。 （何が原因か分からない。サイズ指定の問題？フォント固有の問題？しかしGMSだけで見られる諸問題）
code editorで日本語フォントの表示がおかしい不具合を改善してほしい。
windows環境ならAutohotKeyってユーティリティーソフトで、強制的にショートカット自作できます。 が、オフィシャルで機能付く方が圧倒的にスマートなんで、ついてほしいですねぇ。
room editorでの拡大率の表示。 あと100%, 200%とか切りの良い拡大縮小。
スペースとタブの違いを無視（数も無視）しての検索
リソースツリーのグループを指定しての検索
変数の参照の検索
ほしい
キーボードショートカットのカスタマイズ機能が欲しい(´_ゝ｀)
IDEのUIで、検索窓のサイズと位置を記憶して欲しい。 IDEのUIで、Workspace Overview(Ctrl+Tabで出るやつ)のサイズと位置を記憶して欲しい。
どこまで出来ているのかが分からないので、もしすでに出来ていることならすみません。 まずこういうシンプルなものを作ってみてはどうでしょうか。
▲画面にhello!と表示するだけ。 それができたら、 Spaceキーを押したらhello!と出す動きにする。 それができたら、 Spaceキーを押すごとに、hello!→good!→tank you! とテキストを順に表示する動きを実装する。
それができたら、キャラクターを動かす部分と「NPCの近く」の判定を実装。
自キャラを矢印キーで動かし、NPC（移動はしない）の近くでSpaceキーを押すとテキストを表示する。
このように、要素を切り分けて１つずつ実装していってみるのをおすすめします。 そうすると何が出来て何ができないのかも分かると思います。
その動作を実装するためにはいろいろな要素が関わってくるので、まず切り分けて考えてみます。
(1)はpoint_distance()などで判定できます。
(2)のゲームポーズは、これだけで1つの大きなテーマになり得ます。ポーズ中のフラグでオブジェクトの処理をスキップさせる、ポーズの瞬間の画面を静止画で表示しその間オブジェクトを非アクティブにする、など複数の実現方法が考えられます。ポーズと言っても完全に全てを止めるのか一部だけを止めるのかなどいろいろあるので、どういうものを作りたいのか具体的に仕様をまとめるといいと思います。
(3)外部ファイルから読み込む方法も複数あります。file_text_read_string()でもいいと思いますし、JSONに対応することもできます。"read text file gamemaker"、 "dialogue system gamemaker"などで検索するといろいろ出てきます。
(4)表示はdraw_text()でいいと思います。「1行ずつ」を実現するには、これもいろいろ方法があるでしょうが、配列に1行ずつテキストを保持し、現在の行を保持する変数を作り、Drawイベントで現在の行のテキストを表示、ボタンで行を送れるようにする、という形でいいと思います。
できるだけ要素を区切って考えて、１つずつ個別に実装してみてください、そしてうまくいかなければ その部分のコードをここに貼って質問もらえれば具体的な回答を得られると思います。
質問があるとこの掲示板が活発になり、他のgamemakerユーザーにも役立ちますので大変ありがたいです。 遠慮せず気軽にどしどし質問してください。 誰かが何かかしら教えてくれると思います！
ついでに似たやつ。プロジェクトのとっかかりに配置バランスを見たりするのに使います。
/// @description draw_center_v_line(view_number,color) /// @param view_number /// @param color /*=============================================================================== ビューのヨコ中央にタテ線を描画するためのスクリプト。 引数に対象となるビューの番号と色を入れる。 色は c_XX でビルトイン定義されているものか、make_color_rgb() で定義したものを使う。 ※別スクリプト、cener_xpos()が必要 ================================================================================*/ function draw_center_v_line(argument0, argument1){ var view_number = argument0; var color = argument1; var line_thickness = 1; //垂直ラインの線幅 var xpos = center_xpos(view_number, line_thickness); draw_line_width_color(xpos, 0, xpos, view_get_hport(view_number), line_thickness, color, color); }
上に書いたビューのX方向（ヨコ方向）の真ん中を返すスクリプト、念の為argumentを使うように直しておきます。おかしくなるかもしれないので。（そういうので引っかかることありますよねえ）
/// @description center_xpos(view_number, drawing_width) return center x-position. /// @param view_number /// @param drawing_width /*=============================================================================== 描画の対象となるビューのＸ方向（ヨコ）の中央にスプライトやテキストを描画するための X座標を返すスクリプト。引数に対象となるビューの番号と描画対象物の横幅を入れる。 ================================================================================*/ function center_xpos(argument0, argument1){ var view_number = argument0; var drawing_width = argument1; var xpos = view_get_wport(view_number) /2 - drawing_width /2 return xpos; }
どんどんできるようになる感覚を楽しんで！
そうなんですね。 （背景がない場合）これをオンにしても残像が出る理由がまだ分かってないのですが、 Clear viewport Backgroundの設定が優先されるということかもしれません。
自分のゲームの場合、viewを使っていて、背景が全て不透明の画像なので、 Clear viewport BackgroundもClear Display Bufferもオフにしています。
ありがとうございました。
サーフェイスのクリアみたいなもののようです。
現在のフレームから次のフレームに移る際、描画をクリアしてから再描画するのですが、ウィンドウ範囲内のルーム全体が完全な不透明で描画されている場合は「上書き」しても問題ないので、クリアしなくても良い事になります。
「クリアする処理」がなくなるので、若干負荷が下がる的な話に見えます。
例えば、ルーム内をスクロールしないようなゲームの場合は、一度描画してしまえば、クリアして再描画する処理を省ける事になります。
実際に使ったことはないので、マニュアルを読む限りの推測です。 用語として「バックバッファ」とか「ディスプレイバッファ」とか混在してて、若干の意味の違いはありますが、要するにApplicationSurfaceの後に描画されるネイティブウィンドウ描画領域の話かと思います。
GMSは関数への参照idを変数に入れたり、それを他の関数に渡したり渡された関数を実行したりできるので、それが該当するようです（GMSでの呼び方はよく分かりません）。
例えば、 Aが「歩く」のあとでBに演出表示をさせて「止まって」待機し、Bが完了したタイミングで「ジャンプ」に移る場合は、Aの「ジャンプする」の部分を関数jumpとして切り出しておいて、AがBに指示を出す時点で関数jumpを渡す（＝コールバック関数）。Bは自分の処理が終わったら渡されてるA関数jumpを実行。その結果、Aはジャンプすると。
// AからBに指示 with (B) { scr_effect_show(id, scr_jump); }
イメージ的にはAはBに「ジャンプ」の動きを移譲し、ぼーっと待機。Bは自分の処理を終えて関数jumpを呼び出し。Aは遠隔で操られ動かされる感じでしょうか（全然違うかもしれませんが）。
関数jumpがどうやってAを参照し動かすのかですが、たぶん上記のコードのように、Aがコールバック関数を渡す時に自分のidを一緒に渡しておけば下記のようにBはwith構文で実行できるのでこれで対処できそうです。
// Bの終了時 with (someone) { script_execute(scr_jump); }
これでBはAが誰だろうと知ったこっちゃなく何をするのかも知ったこっちゃなく済みます（と思います…）
教えていただいたキーワードでいろいろ調べてみようと思います。ありがとうございます。
>仮にBが終了したことをAに伝える形にする場合、どういう方法にすると独立性を保てるのでしょうか？
「Bが終了したら呼び出される関数」をBに登録できるようにして、Bは終了時に登録されている関数を呼び出す、という形で実現できます。Bは誰に何の関数を登録されたのか知りません。終了時にただ機械的に登録された関数を呼び出すだけです。この設計にすることでBはAの存在を知ることなく終了したことを知りたい人に伝えることが出来ます。
C/C++では関数ポインタやファンクタ、C#ではデリゲート等で実装できます。 （GMSは触ったことがないので実現方法が分かりません、、、ごめんなさい、、、）
私が最初のポストで挙げた「コールバック型」というのはまさに上記のような実装のことです。特定のタイミングで呼び出してもらいたい関数を登録する設計です。
無視できる負荷を気にするあまり、仕組みが手に負えない複雑さになるのも良くないですからね。 ありがとうございます！
考え方の説明も含めて参考になります。ありがとうございます！
ポーリング型、コールバック型、オブザーバーパターン、いろいろ勉強になります。 仮にBが終了したことをAに伝える形にする場合、どういう方法にすると独立性を保てるのでしょうか？
皆さんありがとうございます。 理由、考え方も含めてとても勉強になります！
自分が作ってるものに当てはめると、AがBを監視する形がいいようです。 ここで聞いてよかったなー。
皆さんご回答ありがとうございます。やはりそれぞれの性格に合ったものをみつけて、実行に移してらっしゃるようですね。。。自分ももう少し頑張って開発方法を見つけていきたいです。
「ポーリング(監視)型」vs「コールバック型」の問題ですかね
今回の例では「監視したい人(A)」と「監視される人(B)」が1対1の単純な関係性なので「AがBを毎フレーム監視する」という実装が一番シンプルになりそうですね。
Aの数が動的に変化するような場合は「コールバック型」を使います。その際「オブザーバーパターン」を適用することが多いです。
今回挙げられた例で避けたい設計は「Bが終了したことをAに伝える時、BがAの関数を呼び出す」という形です。この形にすると「BはAに依存する」ことになり「BはAなしには存在できない」ことになります。
自分が設計を行う際に最も気をつけていることの1つが「依存関係をシンプルにする」ということで、これを設計の指針にしていますね。仮に全体の実装が複雑になってしまう場合でも「依存関係をシンプルにする」ことを常に心がけています。
メンテ性を重視で、AがBのやつを監視するほうですね。 自分は負荷とかあんまり気にしてないでとりあえず動け精神でやってます。
GMSではないですが、自分はAがBを監視する構造にすることが多いです 理由は、Bがなんらかの理由で消失した場合に備えたり、全体の状況が変わった場合にBを停止させたりのように、どうせA側になんらかの管理の処理が入ってしまうので、それならBは「処理をやる。終わったら止まる」だけで完結したモジュールであるほうが汎用性が高まる気がするからです またAがBを複数所持することになった場合、監視型ではAにBのリストを持って全部監視するだけですみますが、通知型にするとAがすべてのBの通知をプールして判定するという煩雑な処理が結局必要になってしまうので…
deactivateしないのでinstanceは動き続けます。stepイベントも実行され続けます。 なので必要があればstepイベント内の処理をスキップさせたりします。
患者長ひっくさんのフォント http://www17.plala.or.jp/xxxxxxx/00ff/
今後のドットフォント関連はこの人のやつ主体になっていきそうな勢い
⓵まずは自分の中にあるものだけで考えてみる ⓶youtubeで調べてみる ⓷ここで質問する
特に⓷はぜひやってほしい。 初歩的な質問が少なすぎるので！
stepとか呼ばれてしまう感じですか？
全体像をつかみたいなら、しゅんさんのこの本いいすよ。書いてあるGMSのバージョンが古いのですが、読み替えられればすごい良書と思います。もうやってるかもしれませんが。 https://www.amazon.co.jp/dp/B00RA8ER7M/ref=cm_sw_r_tw_dp_9FR2TK6N1VAZQ9SW7QY0
真面目な人は勉強の必要範囲を大きく設定しがちなんで気を付けてください。本当にそうかはそうでも無かったりするのでなるべく絞っていくといいです。誰が最初に言ったか存じませんが「我々は数学者ではない」っていうなんか有名な言葉もあるので。
そうそう、youtubeも多いですね。
自分は目的駆動というか「こういうのをやりたい」が先にあって「GameMakerだとどうやるのかなあ」って考えます。ゲーム全体というより「この場面はこうしたいかなあ…」が多いです。GMSじゃない本を見たり、ツイッターで#screenshotsaturdayを追ったりしてカッコイイのがあって「（パクりまでいかないけど）似たことをやりたいなあ」っていう気分が高まったり応用アイデアが出てくると「んんんーーどうやるのかなあ」ってなるので、あとは公式のリファレンスを見たりサンプルソースをぐぐったり既存のアセットに無いか探したりします。そうしてるうちに何が必要かとか、何を使えばいいか、どんな勉強が要るかとかが次第にまとまってきます。勉強が要るとかは範囲が大きいと辛いのでなるべく絞ります。付け焼刃で構わないからそこだけでも！っていう感じですね。
私が勉強したのはYoutube動画でですかね。 やりたいことや分からないことがあればそれをyoutubeで探して観る。 それを繰り返してできることを増やしていきました。 抽象的なものを読んでもそれを実際にどう応用すればいいか分からないので自分にはそれが合っているようです。
マニュアル（ver2～2.2.x） マニュアル（ver2.3～） YoYoGames YoYoGames 公式コミュニティ GM関連のYoutubeチャンネル集 解説・資料サイト集（日本語） 解説・資料サイト集（英語）
ファイル読み込みの部分がうまくいってないようですね。
GMSのファイル読み書きのデフォルトのパスは確か
C:\Users\UserName\AppData\Local\ProjectName\
ですのでここにファイルがある必要があります。
ここにtext.txt（UTF-8で保存したもの）を置いて、これが動くか試してみてください。
正しく読み込まれて動作すればこうなります。
ゲームからファイルを作成し、書き込み読み込みをする処理の場合はこれでいいと思います。
(ゲームのコンフィグデータなど)
ですが、シナリオのテキストは予め自分で作ったテキストファイルをゲームに付属させる形になると思います。
ゲームを配布する時に、ユーザーのPCにこれをどうやって配置すればいい？となりますよね。
プロジェクトにファイルをインクルードすることで実現できます。
リソースツリーのところからファイルをインクルードすると、プロジェクトのフォルダ内にdatafilesというフォルダが作られ、そこにファイルがコピーされます。これで完了。開発環境でも動くし配布したゲームも動くはずです。テキストを編集する際はdatafilesにあるファイルを編集してください。
配布するゲームをビルド（Ctrl+F8）すると、このファイルはexeファイルと同じ場所に付属する形でコピーされるはずです。やってみてください。
ゲームを遊ぶユーザーから見ると、exeファイルがある場所にtext.txtがあるので開けば見たり編集できます。それをできにくくするなら暗号化したりという手段があります。それも解読不可能では無いと思うので、絶対見られたくないならシナリオテキストもプロジェクトのコード内に書く形にするしか無いのかなと思います。その場合でもリバースエンジニアリングで読まれる可能性は残ります。
私が書けるのはこんな感じで、「よく分からないがこうすると動く」的なことだけです。
コンピュータ、GMSのファイルI/Oについて、詳しい方からの解説を待ってます！
（サンドボックスとは？など私もちゃんと理解したい）
ご丁寧にありがとうございます。
細分化の考え方 非常に勉強になりました。
NPCの近くでSPACEキーを押すとシナリオが流れる機能と、全てのシナリオが終わるまでプレイヤーのスピードを0にしてキー受付を中断する簡単なポーズ機能は実装できました。
ですが各NPCにシナリオを割り当てる方法しか実装できず、色々調べてみたのですがテキストファイルを開いて配列に代入する方法がわかりませんでした。
シナリオはテキストファイルに一括で管理するイメージなので教えていただけるとありがたいです。
file_open_read()で開きfile_text_read_string()で配列に代入してfile_close()で閉じる流れはわかるのですが、テキストファイルの位置を指定してもファイルを開く関数でエラー(-1)が出てしまいます。
コード(NPCオブジェクトのcreateイベント内に記述しています)
fid = file_text_open_read("text.txt");
show_debug_message(fid);
str[0] = file_text_read_string(fid);
file_text_readln(fid);
str[1] = file_text_read_string(fid);
file_text_close(fid);
エラー文
ERROR!!! :: Failed to open file: text.txt
-1
ERROR!!! ::
ERROR in
action number 1
of Create Event
for object oNPC2:
File is not opened for reading.
at gml_Object_oNPC2_Create_0 (line 7) - str[0] = file_text_read_string(fid);
todoリストの機能をつけてほしいです。ただのtodoリストでもいいんですが、エディタ側にtodoのマーキングが出来て、todoリストからソースの該当箇所まで飛べたらさらにヨシです。
IMEをオンにするとショートカットが効かなくなる不具合を直してほしい。
（IMEをオフにして一度他のソフトの窓にフォーカスを移して戻ると直る）
日本語フォントの表示が荒れる問題を改善してほしい。
（何が原因か分からない。サイズ指定の問題？フォント固有の問題？しかしGMSだけで見られる諸問題）
code editorで日本語フォントの表示がおかしい不具合を改善してほしい。
windows環境ならAutohotKeyってユーティリティーソフトで、強制的にショートカット自作できます。
が、オフィシャルで機能付く方が圧倒的にスマートなんで、ついてほしいですねぇ。
room editorでの拡大率の表示。
あと100%, 200%とか切りの良い拡大縮小。
スペースとタブの違いを無視（数も無視）しての検索
リソースツリーのグループを指定しての検索
変数の参照の検索
ほしい
キーボードショートカットのカスタマイズ機能が欲しい(´_ゝ｀)
IDEのUIで、検索窓のサイズと位置を記憶して欲しい。
IDEのUIで、Workspace Overview(Ctrl+Tabで出るやつ)のサイズと位置を記憶して欲しい。
どこまで出来ているのかが分からないので、もしすでに出来ていることならすみません。
まずこういうシンプルなものを作ってみてはどうでしょうか。
▲画面にhello!と表示するだけ。
それができたら、
Spaceキーを押したらhello!と出す動きにする。
それができたら、
Spaceキーを押すごとに、hello!→good!→tank you! とテキストを順に表示する動きを実装する。
それができたら、キャラクターを動かす部分と「NPCの近く」の判定を実装。
自キャラを矢印キーで動かし、NPC（移動はしない）の近くでSpaceキーを押すとテキストを表示する。
このように、要素を切り分けて１つずつ実装していってみるのをおすすめします。
そうすると何が出来て何ができないのかも分かると思います。
その動作を実装するためにはいろいろな要素が関わってくるので、まず切り分けて考えてみます。
(1)はpoint_distance()などで判定できます。
(2)のゲームポーズは、これだけで1つの大きなテーマになり得ます。ポーズ中のフラグでオブジェクトの処理をスキップさせる、ポーズの瞬間の画面を静止画で表示しその間オブジェクトを非アクティブにする、など複数の実現方法が考えられます。ポーズと言っても完全に全てを止めるのか一部だけを止めるのかなどいろいろあるので、どういうものを作りたいのか具体的に仕様をまとめるといいと思います。
(3)外部ファイルから読み込む方法も複数あります。file_text_read_string()でもいいと思いますし、JSONに対応することもできます。"read text file gamemaker"、 "dialogue system gamemaker"などで検索するといろいろ出てきます。
(4)表示はdraw_text()でいいと思います。「1行ずつ」を実現するには、これもいろいろ方法があるでしょうが、配列に1行ずつテキストを保持し、現在の行を保持する変数を作り、Drawイベントで現在の行のテキストを表示、ボタンで行を送れるようにする、という形でいいと思います。
できるだけ要素を区切って考えて、１つずつ個別に実装してみてください、そしてうまくいかなければ
その部分のコードをここに貼って質問もらえれば具体的な回答を得られると思います。
質問があるとこの掲示板が活発になり、他のgamemakerユーザーにも役立ちますので大変ありがたいです。
遠慮せず気軽にどしどし質問してください。
誰かが何かかしら教えてくれると思います！
ついでに似たやつ。プロジェクトのとっかかりに配置バランスを見たりするのに使います。
上に書いたビューのX方向（ヨコ方向）の真ん中を返すスクリプト、念の為argumentを使うように直しておきます。おかしくなるかもしれないので。（そういうので引っかかることありますよねえ）
どんどんできるようになる感覚を楽しんで！
そうなんですね。
（背景がない場合）これをオンにしても残像が出る理由がまだ分かってないのですが、
Clear viewport Backgroundの設定が優先されるということかもしれません。
自分のゲームの場合、viewを使っていて、背景が全て不透明の画像なので、
Clear viewport BackgroundもClear Display Bufferもオフにしています。
ありがとうございました。
サーフェイスのクリアみたいなもののようです。
現在のフレームから次のフレームに移る際、描画をクリアしてから再描画するのですが、ウィンドウ範囲内のルーム全体が完全な不透明で描画されている場合は「上書き」しても問題ないので、クリアしなくても良い事になります。
「クリアする処理」がなくなるので、若干負荷が下がる的な話に見えます。
例えば、ルーム内をスクロールしないようなゲームの場合は、一度描画してしまえば、クリアして再描画する処理を省ける事になります。
実際に使ったことはないので、マニュアルを読む限りの推測です。
用語として「バックバッファ」とか「ディスプレイバッファ」とか混在してて、若干の意味の違いはありますが、要するにApplicationSurfaceの後に描画されるネイティブウィンドウ描画領域の話かと思います。
GMSは関数への参照idを変数に入れたり、それを他の関数に渡したり渡された関数を実行したりできるので、それが該当するようです（GMSでの呼び方はよく分かりません）。
例えば、
Aが「歩く」のあとでBに演出表示をさせて「止まって」待機し、Bが完了したタイミングで「ジャンプ」に移る場合は、Aの「ジャンプする」の部分を関数jumpとして切り出しておいて、AがBに指示を出す時点で関数jumpを渡す（＝コールバック関数）。Bは自分の処理が終わったら渡されてるA関数jumpを実行。その結果、Aはジャンプすると。
イメージ的にはAはBに「ジャンプ」の動きを移譲し、ぼーっと待機。Bは自分の処理を終えて関数jumpを呼び出し。Aは遠隔で操られ動かされる感じでしょうか（全然違うかもしれませんが）。
関数jumpがどうやってAを参照し動かすのかですが、たぶん上記のコードのように、Aがコールバック関数を渡す時に自分のidを一緒に渡しておけば下記のようにBはwith構文で実行できるのでこれで対処できそうです。
これでBはAが誰だろうと知ったこっちゃなく何をするのかも知ったこっちゃなく済みます（と思います…）
教えていただいたキーワードでいろいろ調べてみようと思います。ありがとうございます。
>仮にBが終了したことをAに伝える形にする場合、どういう方法にすると独立性を保てるのでしょうか？
「Bが終了したら呼び出される関数」をBに登録できるようにして、Bは終了時に登録されている関数を呼び出す、という形で実現できます。Bは誰に何の関数を登録されたのか知りません。終了時にただ機械的に登録された関数を呼び出すだけです。この設計にすることでBはAの存在を知ることなく終了したことを知りたい人に伝えることが出来ます。
C/C++では関数ポインタやファンクタ、C#ではデリゲート等で実装できます。
（GMSは触ったことがないので実現方法が分かりません、、、ごめんなさい、、、）
私が最初のポストで挙げた「コールバック型」というのはまさに上記のような実装のことです。特定のタイミングで呼び出してもらいたい関数を登録する設計です。
無視できる負荷を気にするあまり、仕組みが手に負えない複雑さになるのも良くないですからね。
ありがとうございます！
考え方の説明も含めて参考になります。ありがとうございます！
ポーリング型、コールバック型、オブザーバーパターン、いろいろ勉強になります。
仮にBが終了したことをAに伝える形にする場合、どういう方法にすると独立性を保てるのでしょうか？
皆さんありがとうございます。
理由、考え方も含めてとても勉強になります！
自分が作ってるものに当てはめると、AがBを監視する形がいいようです。
ここで聞いてよかったなー。
皆さんご回答ありがとうございます。やはりそれぞれの性格に合ったものをみつけて、実行に移してらっしゃるようですね。。。自分ももう少し頑張って開発方法を見つけていきたいです。
「ポーリング(監視)型」vs「コールバック型」の問題ですかね
今回の例では「監視したい人(A)」と「監視される人(B)」が1対1の単純な関係性なので「AがBを毎フレーム監視する」という実装が一番シンプルになりそうですね。
Aの数が動的に変化するような場合は「コールバック型」を使います。その際「オブザーバーパターン」を適用することが多いです。
今回挙げられた例で避けたい設計は「Bが終了したことをAに伝える時、BがAの関数を呼び出す」という形です。この形にすると「BはAに依存する」ことになり「BはAなしには存在できない」ことになります。
自分が設計を行う際に最も気をつけていることの1つが「依存関係をシンプルにする」ということで、これを設計の指針にしていますね。仮に全体の実装が複雑になってしまう場合でも「依存関係をシンプルにする」ことを常に心がけています。
メンテ性を重視で、AがBのやつを監視するほうですね。
自分は負荷とかあんまり気にしてないでとりあえず動け精神でやってます。
GMSではないですが、自分はAがBを監視する構造にすることが多いです
理由は、Bがなんらかの理由で消失した場合に備えたり、全体の状況が変わった場合にBを停止させたりのように、どうせA側になんらかの管理の処理が入ってしまうので、それならBは「処理をやる。終わったら止まる」だけで完結したモジュールであるほうが汎用性が高まる気がするからです
またAがBを複数所持することになった場合、監視型ではAにBのリストを持って全部監視するだけですみますが、通知型にするとAがすべてのBの通知をプールして判定するという煩雑な処理が結局必要になってしまうので…
deactivateしないのでinstanceは動き続けます。stepイベントも実行され続けます。
なので必要があればstepイベント内の処理をスキップさせたりします。
患者長ひっくさんのフォント
http://www17.plala.or.jp/xxxxxxx/00ff/
今後のドットフォント関連はこの人のやつ主体になっていきそうな勢い
⓵まずは自分の中にあるものだけで考えてみる
⓶youtubeで調べてみる
⓷ここで質問する
特に⓷はぜひやってほしい。
初歩的な質問が少なすぎるので！
stepとか呼ばれてしまう感じですか？
全体像をつかみたいなら、しゅんさんのこの本いいすよ。書いてあるGMSのバージョンが古いのですが、読み替えられればすごい良書と思います。もうやってるかもしれませんが。
https://www.amazon.co.jp/dp/B00RA8ER7M/ref=cm_sw_r_tw_dp_9FR2TK6N1VAZQ9SW7QY0
真面目な人は勉強の必要範囲を大きく設定しがちなんで気を付けてください。本当にそうかはそうでも無かったりするのでなるべく絞っていくといいです。誰が最初に言ったか存じませんが「我々は数学者ではない」っていうなんか有名な言葉もあるので。
そうそう、youtubeも多いですね。
自分は目的駆動というか「こういうのをやりたい」が先にあって「GameMakerだとどうやるのかなあ」って考えます。ゲーム全体というより「この場面はこうしたいかなあ…」が多いです。GMSじゃない本を見たり、ツイッターで#screenshotsaturdayを追ったりしてカッコイイのがあって「（パクりまでいかないけど）似たことをやりたいなあ」っていう気分が高まったり応用アイデアが出てくると「んんんーーどうやるのかなあ」ってなるので、あとは公式のリファレンスを見たりサンプルソースをぐぐったり既存のアセットに無いか探したりします。そうしてるうちに何が必要かとか、何を使えばいいか、どんな勉強が要るかとかが次第にまとまってきます。勉強が要るとかは範囲が大きいと辛いのでなるべく絞ります。付け焼刃で構わないからそこだけでも！っていう感じですね。
私が勉強したのはYoutube動画でですかね。
やりたいことや分からないことがあればそれをyoutubeで探して観る。
それを繰り返してできることを増やしていきました。
抽象的なものを読んでもそれを実際にどう応用すればいいか分からないので自分にはそれが合っているようです。