全体の流れを考える
ウディタにおけるイベントの作り方は人それぞれとは思いますが，ここではまず，選択肢イベントでプレイヤーが行うことを動画を参考にまとめてみましょう．
こんな感じでしょうか．少なくともこの流れを無視することは出来なさそうです．そもそも選択肢が確認できなかったり，クリックししても何の反応もなかったりするようなものは作りたくないですもんね．この流れに沿う形で，やりたいことをコモンイベントやデータベースに落とし込んでいきましょう．
コモンイベント・データベースの作成
まず，提示された選択肢を確認するためにはそもそも表示させる選択肢を設定し，それを表示する処理が必要となるはずです．クリックして選択する際にも，クリックされた選択肢はどれなのかを判定する必要がありますし，「判定された選択肢が何か」という情報も受け渡さなければ選択肢に応じたイベントを見ることもかないません．すなわち，上記の図はこんな感じに書き換えることができるのではないでしょうか．
黒枠で囲まれているところを「選択肢コモン」として一つのコモンイベントにしてしまいます．つまり右の図のように，このコモンイベントは入力として選択肢を与え，出力として選ばれた選択肢の番号を返すということです．ちなみに入力と出力はこのウィンドウから設定できますよ．
さて，前置きが長くなりましたがここからは実際にイベントを作っていきたいと思います．
...とその前に，何も考えずにこのようなデータベースを作っておきましょう．
このデータベースはピクチャ番号管理DBという名前の通り，処理に用いるピクチャ番号を管理するものです．このようなDBを利用する理由はとても単純で，後からピクチャ番号の変更を容易に行えるようにするためです．後から作ったコモンイベントのピクチャ表示のせいで，以前に作ったイベントのピクチャが隠れてしまった！とか，複数のイベントで同じピクチャ番号使ってるけど全部一括で別な番号に変えたい！なんてときに，当該コモンイベントをわざわざ開いて番号を修正するよりも，データベースで管理できた方が楽だよね？って感じですかね．
ちなみに僕は「データIDを最初の文字列データと同じ」にすることが好きな人間なので，わざわざID用の文字列データをとってます（不要なら省いてください）．また使い方によっては初めと終わりの番号ではなく，初めの番号とそこから何枚使うかという情報を格納してもいいと思います．そこはお好みで．
少なくともここで設定しなければならないのは，選択肢の枠のピクチャ番号と選択肢の文字列のピクチャ番号です．枠と文字列のピクチャ番号群を分けている理由は後程しますが，枠の番号＜文字列の番号になるようにしてください（枠の下に文字を置きたい場合は別ですが）
DBの設定をしたところで，選択肢表示のコモンイベントを作っていきましょう．ということで完成したものがこちらになります．
[やっていること]
・選択肢枠・文字列のピクチャ番号呼び出し
・選択肢表示座標（画面座標）の設定
・ループで選択肢の表示
ループでの選択肢表示ですが，今回は表示したい選択肢をコモンセルフ変数5～8へ直接入力しているため，4回ループを使ってコモンセルフ変数5から順に表示していっています．文字列が空欄となったタイミングでもループが中断するため，使いたい選択肢の数ぶん入力を与えてあげてください．4つ以上の選択肢を一気に表示したい場合は，選択肢の項目を格納するDBを別に作って読みだせばいいと思います．その時はループの回数も変えてくださいね．
次はクリックによる選択部です．例によって完成したものをどうぞ
[やっていること]
・常にマウスの状態を監視
・新たに左クリックされたタイミングで，マウスと重なっているピクチャ番号を算出
・重なっているピクチャ番号を1～3の値へ変換
このイベント中で呼び出されている，「重なっているピクチャ番号」というコモンイベントは以下の通りです．
[やっていること」
・指定された，「ピクチャ番号管理DB」のデータ群についてマウスと重なっているピクチャがあるか判定（枠ピクチャについて調べるときは，文字ピクチャとマウスが重なっていても反応しないということ）
・重なっているピクチャがあった場合，マウスがただ乗っているだけなら少し明るくフラッシュ，クリックされているなら明るくフラッシュ
各選択肢がクリックで選ばれたか否かを判定するだけならクリック後にこのコモンを呼び出すだけでいいのですが，横着してボタンのフラッシュ動作も中に組み込んでしまったので，選択部のループ毎に呼び出しています．また今回は枠のピクチャ番号を0～99の範囲に設定したため，「重なっているピクチャ番号」を呼び出すと0～99までで重なっているピクチャ番号があるか否かを判定することになります．また枠のピクチャ番号はDBに登録した番号の先頭から順に使われていくはずなので，マウスと重なっていたピクチャ番号とDBの数字から何番目に表示した選択肢なのかは容易に特定することができます．
[今回のコモンイベントたち参考にどうぞ（Wodipadを利用させていただきました）]
重なっているピクチャ番号判定
選択肢コモン
以上のコモンイベント・データベースを用いることで，冒頭の動画のような選択肢処理を行うことができると思います．それでは最後に少しまとめて終わりたいと思います．
今回のイベントの問題点について
問題点というより，このイベントではできないことや注意点についてまとめます．
本当は強みと弱みをいくつか挙げようと思ったんですけど，目立った強みが見当たらなかったのでこのタイトルに...強いて言うならキー操作よりも多少実装が楽な点？
今回のコモンイベントでは，マウスと重なっているピクチャ判定時に重なっているピクチャが存在した時点でそれを出力しイベントを終了してしまいます．ですので提示された選択肢から複数選択可能にするためにはコモンイベントを改造するか同様の選択肢をループで何度も答えさせるかしかありません．平にご容赦ください．
こもれ重なりピクチャ判定の話なのですが，基本的にピクチャ番号の小さい順に判定を行うため選択肢が画面上を自在に移動するような演出を行った場合初めに表示した選択肢が微妙に選ばれやすくなると思います（多分）．これを解決するなら，重なった時点でループを中断するのではなく，指定されたピクチャ番号群についてすべて判定を行い，結果を可変データベース等に記録するなどすればよいと思います．やりませんでしたが．
これは選択肢の表示処理の部分でも軽く触れましたが，今回の選択肢イベントはコモンイベントへの入力をそのまま選択肢として使用しているため，仕様上4つまでしか一度に判定することができません．もしそれ以上表示させたいならデータベース等を用いましょう．ちなみに表示さえさせることができれば選択部の処理は特に問題なく動作するはずです．
（本来なら横着せずにコモンイベントを分けるべき．そうすれば表示部だけ細かく仕様変更が可能になると思います．記事用のコモンなので許してください）
さいごに
ここまで自作選択肢イベントを制作してきたわけですが...そもそも選択肢って作る必要あるんでしょうか．選択肢，と聞くとこういうの思い浮かべますよね？（限りなく抽象化された何か）
ウディタにはもともと選択肢を行うためのコマンドが存在しています．mobとの会話，あるいはノベルゲーのルート分岐まで，この選択肢を使えばよいのではないでしょうか．
なんて思ってた時代がありました．
もう一度ここでこの図を見てみましょう．
提示された選択肢から何かを選んで，選んだものに応じた処理を行うという何の変哲もない流れですが，これってそもそも上に示したような一般的な「選択肢」に限った話なんでしょうか．「なにか選べるものが提示されて，選んだものによって違うものが見られる」ことって，ゲームだといくらでもありませんか？あまり意識はしないかもしれませんが，メニュー画面を開いてキャラクターのステータスを見たりアイテム欄を確認したり装備品を確認したり...これもれっきとした選択肢ですよね．それにこういうのはどうでしょう．
これは（結局使うことのなかった）パズルゲームです．パズルと選択肢とどういう関係があるのかって？このパズルも画面いっぱいに選択可能なドロップが提示され，選択されると，選択されたドロップに応じて異なる挙動を示す．という流れで見れば選択肢と何ら変わりありません．それにここでも今回用いたような重なりピクチャ判定のイベントを用いてますしね．
というわけで次の記事ではこのパズルゲームの作り方をご紹介したいと思います．自作選択肢もこうやって応用できるんだぞ～みとけよみとけよ～って感じです．それではまた．
1. ליווי בתל אביב
<a href="https://www.israelxclub.co.il/נערות-ליווי-ברחובות/">נערות ליווי ברחובות</a>
gder4563