添付のような感じでいかがでしょうか。

初期手札時点での各役の成立確率を、添付のとおり計算し直しました。130枚のカードから無作為に5枚を選ぶ選び方は、全部で約2億9千万通りで、ワンペアが成立するのは、そのうちの約7千5百万通りなので、大体4回に1回はワンペアが成立することになります。特殊役のうち最も成立しやすいのは「友達」で、10回に1回くらいでしょうか。なお、私も計算してみてはじめて気がつきましたが、「カルテット」「クインテット」は「フォーカード」「ファイブカード」よりもはるかに成立しやすいようです。

大変恐縮ながら、先ほどの私の確率の計算は、どうも誤っているようです。ワンペアはいくら何でも3%ってことはなく、10～20%はあるはずです。ただし確率の計算方法を忘れてしまったので、顔を洗って計算しなおします。

大雑把な計算ですが、5枚のカードが配られた時点での、役の成立確率は、概ね添付のとおりです。ワンペアですら3%なんですね。 私のサンプルプログラムのXCARD関数は、第2引数をFALSEにして呼び出すと、1度捨てたカードであっても、何度でも交換できます。

お待たせしました。「XKS3QEDF」をお試しください。前回の枚数判定のサンプルプログラムに、特殊役判定を追加しています。特殊役判定は、枚数判定よりもずっとめんどくさくなりますが、条件が表になってはっきりしている以上、必ずできますので、諦めてはいけません。もっとも、私のサンプルプログラムは、多分無駄な重複が多く、大幅に短縮できる気がします。サンプルプログラムの6～70行目あたりに、多くのデータ文をコメント化しているところがありますが、これは、自分の作った特殊役判定ルーチンが正しく判定しているか確認するために使ったものです。ちなみに、私も途中で次のことに気がつきましたが、今回のプログラムはこれらも判定できるはずです。 ・トリオとコンビは同時に成立することがある。・コンビが同時に2組できることがある(同じコンビが2組のときは、同時に2ペアかフルハウスになる)

なるほど、そういうことでしたか。判定の方法は、後ほどサンプルプログラムのようなものを作って説明させていただきますので、しばらくお待ちください。ところで「重複する特殊役」はどのように判定しましょうか？「重複する特殊役」とは、例えば「クインテット0番」が成立するときは、必ず「カルテット0番」も成立しますし、「クインテット3番」が成立するときは、必ず「トリオ1番」「主従1番」「姉妹1番」も同時に成立します。クインテット＞カルテット＞トリオ＞友達＞主従＞姉妹＞主人公の優先順で1つだけ、という感じでしょうか。

どうやら、DATAが私の考えと違うようです。（私の考えを説明していないので当然ですが）私の考えは、26種類のカード全てについて「種族」と「種族番号」をDATAで割り当てるというものです。例えば、私のDATAでは、カード種類番号0と1が「主人公」という「種族」に属し、かつ「主人公0番」という「種族番号」を有します。主人公は1組しかいないと聞いているので、カード種類番号0と1以外は全て「主人公」に属さないことを表す「X」としています。「トリオ」なら「トリオ0～3番」がそれぞれ3人ずつ、計12人います。「友達」の「種族番号」は「友達グループ番号」のようなイメージです。 nobuさんのDATA文がどのようなもので、DATAの意味を教えていただけると、アドバイスできると思います。（全てアルファベットで書かれていると拝察しますが・・・）

いえ、秘密と言うほどのことではなく、SWAPは文字どおり「交換」するだけで、新しい数字を「代入」するわけではないので、元の数列が重複していない限り、SWAPしたあとの数列も重複しない、ただそれだけのことですよ。トランプをいくらシャッフルしても、同じカードが2枚になったりしませんよね。 先ほど提案した、判定のための表をつくる件ですが、何よりご自身のアイディアを整理することが重要ですので、ぜひ実施することをお勧めします。

サンプルプログラムはしばらくしたら消去しますが、ご容赦ください。サンプルプログラムの先頭の「RS=130」は「RS=120」の誤りです。すみません。XCARD関数は割と使いやすいと思いますので、ぜひご活用ください。SWAP命令は便利です。最初に重複しない数列を作っておけば、それを何度どのようにSWAPしようと、数字が重複することは絶対にありませんからね。 ところで、特殊役判定は、添付のDATAような表を作っておくと、やりやすくなります。表の意味や、表を使った実際の役判定の方法等、わからなければご質問ください。逆に、特殊役に対する私の解釈に誤りがあれば、ご指摘ください。

We're so glad about PETIT COMPUTER III launch in US. And we're also praying to be released it in Europe A.S.A.P.

若い人の前向きな姿勢を見ていると、こちらもすがすがしい気分になりますね。

簡単なサンプルプログラムを作ってみました。「7KNN23K4」をお試しください。このサンプルでは、対戦相手の手札、自分の手札、場のカード全てWL配列変数で管理しています。また、1回につき1枚だけですが、任意の手札を好きなだけ交換できます。プログラム中にいろいろコメントを入れているので、ご一読ください。分からなければ遠慮なくご質問ください。 ところで、コンビ～クインテット判定の方法は、IF文の羅列で判定するとしても、まず役の組み合わせのパターンをはっきりさせることが先決です。まずこれを表・図などにまとめて整理してみましょう。

We're expecting you to make and release amazing games.

おおっ！これは見たい！ しかし、大喜利投稿を予定されているのであれば、ここはグッとこらえて、待たせていただくこととします。

ルールのご説明ありがとうございます。概ね理解しました。ご教示いただいたルールにのっとって、どのような流れで処理をすればよいか、なるべく早くその例を示したいと思います。 ところで、コンビ～クインテッドの意味を今はじめて理解しました。どのように判定すればよいか、ですが、カードの種類は、0～25の番号で表されるはずなので、まず、どの番号の組み合わせが「姉妹」になるのか、それを明らかにしましょう。 私の考えでは、0～4、5～9…のように、5種類ずつが姉妹の組み合わせになるのかな、と思いましたが、カードの種類は26種類なので、それだと1種類仲間外れになってしまいますね…

ところでnobuさん、既出であれば恐縮ですが、今一度おさらいをさせてください。本作は、 ①プレイヤーと、何人か分かりませんが対戦相手がいるゲーム ②対戦相手のカード配列は、はじめから決まっている ここまでは分かりました。 問題は次の③④ですが、これらが正しいかどうか、教えてください。 ③プレイヤーは、手札の一部または全部を、好きなだけ交換できるが、一度捨てたカードを再び手札に戻すことはできない ④26種130枚のカードは、次のABCDのうちいずれかに、必ず属する →A.プレイヤーの手札　B.対戦相手の手札　C.プレイヤーの捨て札　D.プレイヤーの手札交換用の山 いかんせん私も説明ベタなもので、もどかしい思いをさせてしまいまして恐縮です。分からなければ何度でもご質問願います。必ずしも速効でレスを返せるとは限りませんが、なるはやで回答するよう努めます。

The original poster of this thread is making his original card game with PETIT COMPUTER III which is BASIC interpreter for Nintendo 3DS. Currently he is worried how to distribute cards and judge the rank. The attached photo is not sourcery. It is sample program for PETIT COMPUTER III to judge the rank.

ご質問に回答致します。まず、カードを配る部分と、役の判定部分を離すことは、もちろんOKです。私のプログラムでは、5枚のカードをランダムに配る部分が4～7行目で、役判定が8行目の「SORT TE」以降から17行目までの部分です。ちなみにRSは残りカード数を表し、5枚抜くごとに、8行目で5ずつ減らしています。カードの交換などは、役判定開始前（SORT TEの前）に行えばよいです。おそらくnobuさんは、カードの交換時に、TE配列変数に交換カードの数字を代入するときのルールを知りたいのだと思いますが、それこそ好きなように代入していただいて結構です。どんな風に数字を交換しようと、SORT TEの実行時点で、手配の配列は先述の16通りのいずれかに、必ずなりますので、必ず判定できます。唯一の注意事項は、同じ数字がダブらないこと、これだけです。

昨日提示したプログラムに、130枚のカードからランダムに5枚を抜いて、手札TEに格納する部分を追加してみました。添付の4～7行目のFORループがその部分で、以前れいさんに教えていただいたFisher-Yatesアルゴリズムというものを応用しています。なお、添付では、まず130枚から5枚を抜いて役判定し、次は残りの125枚から5枚を抜いて･･･というのを、残りのカードがなくなるまで(つまり26回)繰り返します。

VSYNCは、1画素を描画するためのピクセルクロック（3DS液晶パネルのスペックは存じませんが多分数十MHz）を、水平方向のピクセル数（表示されていない部分を含む）×垂直方向のピクセル数（表示されていない部分を含む）で割った値なので、ぴったり60Hzにはならず、例えば59.94Hzなど、中途半端な値になることがあります。