サルでもできるスロゲー開発

**名前は開発中のものです。** · 2006/05/09(火) 12:12:09

スロットゲーム制作の総合スレです。

以前はスロットサロン板でやっていました。

････過去ログ････
サルスレ用保管庫（仮）
ttp://rerebo.hp.infoseek.co.jp/

････資料サイト････
サル部屋
ttp://www.deepgreen.jp/~saru/

････関連リンク････
フリーソフトの面白いスロゲーを紹介しる　機能してないまとめページ
ttp://pachihell.at.infoseek.co.jp/suroge/index.html

**名前は開発中のものです。** · 2006/06/04(日) 01:59:41

>>128
すげーな。

**名前は開発中のものです。** · 2006/06/04(日) 02:02:23

すげー・・・

**名前は開発中のものです。** · 2006/06/04(日) 22:53:29

>>128
タックスヘブンな某国に引越しオメ、落ち着いたら住所教えてくださYO。

**名前は開発中のものです。** · 2006/06/05(月) 00:44:35

>>129-130
過去スレで一度はネタになってる事しか実装されてない気がする

とりあえず今気になってる点
フラッシュは3リール×5コマ分必要なのか？
回転中はバックライトも回すべきか？

>>131
サルスレの引越し祝いね
お祝い返しはスロゲー希望

**名前は開発中のものです。** · 2006/06/05(月) 00:55:48

そうなのか・・・
リール制御に移ってたけどリールの方見直すかな。

**名前は開発中のものです。** · 2006/06/05(月) 00:57:13

>>132
それよりDirectDrawを使うか使わないかが問題で
ブラックボックスに徹するならもっと細分化した機能が必要ジャマイカ。

**名前は開発中のものです。** · 2006/06/05(月) 04:44:42

質問させていただきます。
>>80
遅い命令を常時描画していると当然カクカクなります。
特にmesとかはよく使われるけど遅い命令です。

と書かれていますが
await 0とsleepを併用したとして最小でも正確に1ms
具体的に画面に表示するような処理以外については
あまり気にしなくても大丈夫なんでしょうか？
四則演算や条件判断、変数へを代入等の内部処理を
大量に使用することによっても処理は重くなりますよね？
リールの回転をスムーズにするためには上記の部分の
改善も必要になってくるということですか？

**名前は開発中のものです。** · 2006/06/05(月) 08:38:35

>>135
（）とかインクリメントとかビットシフトとかif swichとか、正確に言えば速度の違いは出てくるけど、
基本的には今の（ここ５年くらい。１０年くらいかも）ＰＣ性能ならぶっちゃけ変わらない。
少なくとも体感は出来ない。
でも、描画関係は速度に直結するから、描画関係は気をつけるべき。
特にmesやlineなど、Win32APIから呼び出すやつ。
リアルタイムにlineで描画しつつ、ウィンドウをアクティブにするかしないかだけでも速度が違うのが感じられるくらいやばい。

**某作者** ◆SAKURA7br2 · 2006/06/05(月) 09:26:02

>>135
リールの回転をスムーズにする事と
遅い命令で画面がカクカクするのは
基本的な原因が違う希ガス。

遅い命令を多用すると
目に見えて実行速度が落ちます。
重ねて、画面のチラツキが酷くなります。
まぁ、チラツキはある程度抑制出来ますが。

一方、リールの回転をスムーズにする為には
高速に描画することも重要ですが
回転のアルゴリズムを最適化することの方が
重要だったりします。
ちなみに、自分の公開しているソフトでは
前Verと現Verでは回転のアルゴリズムを変えていますが
目に見えて差が出ていますｗ

昔、PCが非力だった頃は、演算命令一つとっても
いかに早く処理させるかが重要でした（乗算を加算に置き換えたり）が
現在のPCの能力からすると、>>136さんの言うとおり
ほぼ関係ありません。

まぁ、一回は重い命令を使ってみて
その重さを体感するといい勉強になると思います。

**名前は開発中のものです。** · 2006/06/05(月) 10:08:00

朝からありがとうございます。
少し気にしすぎました。
描画関係には細心の注意を払って書いていますので
それ以外はそこまで神経質にならないようにしていくことにします

**名前は開発中のものです。** · 2006/06/05(月) 17:39:48

スロゲー作るのがゴールならいいんだけど
これからも他のジャンルのプルグラムをするつもりなら
細部までこだわった方が勉強になるよ

**名前は開発中のものです。** · 2006/06/05(月) 18:56:34

>>138
ここで自分のアルゴリズムを提示してみるのもアリだと思うよ。
失礼だけど今の段階では今までにも出尽くした方法だとは思うけど、欠点を指摘してもらえるかもしれない。

>>139
そりゃそうだけど、他のゲームを作るにしても、一度最後まで作り上げる事の方が何倍も重要な希ガス。
いちいち拘って立ち止まってたんじゃモチベーションが保てないしね。
仕事ならともかく。

**名前は開発中のものです。** · 2006/06/05(月) 22:41:36

>>134
DirectDrawは気が進まない、けどWaitForVerticalBlankしたい。
ボタンやランプ等の小物は管理しても、液晶みたい物はコールバックにしたい
正直言って先の事は考えてなかったり

とりあえずはマニュアルとフラッシュエディターを形にしてから出直して来ます

**名前は開発中のものです。** · 2006/06/05(月) 23:28:07

>>141
「WaitForVerticalBlank」＝リフレッシュレートの解決策だね。

気長にまってる。

**名前は開発中のものです。** · 2006/06/11(日) 21:45:58

age

**名前は開発中のものです。** · 2006/06/14(水) 20:09:51

age

**名前は開発中のものです。** · 2006/06/15(木) 01:53:54

終わったな！

**名前は開発中のものです。** · 2006/06/15(木) 01:59:57

いやー作ってたんだけどね・・・
自分はHSPからCに移そうと思って一時中断してるっぽ。
みんな水面下でやってるっしょ。

**名前は開発中のものです。** · 2006/06/15(木) 03:12:39

報告は自分のHPでしますし
これといって書く事もないし。

**名前は開発中のものです。** · 2006/06/15(木) 18:25:21

>>146->>147　この板不要なのねｗ

**某作者** ◆SAKURA7br2 · 2006/06/16(金) 10:45:55

>>148
技術的な討論をする場だと思ってますが
それじゃ駄目なんですかね。

出尽くした感はありますが…orz

**名前は開発中のものです。** · 2006/06/16(金) 11:31:09

簡単に報告してくれたほうがスレのためでは？

**名前は開発中のものです。** · 2006/06/16(金) 12:13:24

一応ＲＯＭってるけどなんだかんだ　みんなここをチェックしるのねｗ

**名前は開発中のものです。** · 2006/06/16(金) 16:01:09

このスレで開発中の神たちのＨＰまとめてくれ

**128** · 2006/06/19(月) 23:55:25

|-`).｡ｏO(ﾃﾞﾅｵｼﾃｸﾙｶ…)

**名前は開発中のものです。** · 2006/06/21(水) 11:46:40

全く知識もなく初心者なんですが、どんくらいでできますか？
ジョジョのスロット作りたくて・・・

**名前は開発中のものです。** · 2006/06/21(水) 12:00:48

まずは練炭を用意します

**名前は開発中のものです。** · 2006/06/21(水) 21:46:39

>>154
まったくのプログラム初心者？
俺はMSX BASICから始めて１６年かかったよ

**名前は開発中のものです。** · 2006/06/21(水) 21:50:48

>>154
人それぞれだと思うけど、HSPいじりながら過去スレ全部読んで見てから考えれば？
あとはどの程度のギミックをつけるかだけど、単純なものなら過去スレだけで作れるかと。
全く初心者なのに過去スレ読破できないって言うんなら…ｼﾗﾈ

**名前は開発中のものです。** · 2006/06/21(水) 22:00:16

今たまたまHSPからメール来てたのを見たけど、
HSP3.0に同梱されてるhspda.asはMTを使った乱数プラグインみたいだね。
もしかしたらもうexrandはいらないかもね。

**名前は開発中のものです。** · 2006/06/21(水) 22:07:58

>>154
初心者云々より、やる気の問題じゃないかな？

http://pc8.2ch.net/test/read.cgi/gamedev/1149170703/

**名前は開発中のものです。** · 2006/06/22(木) 17:48:50

>>153　ま～だ～出直せんのか？

**128** ◆Qhl3Z4WCS2 · 2006/06/24(土) 23:16:15

ttp://www.geocities.jp/anachronism128/

結局、リール以外のオブジェクトに手を出すのも辞め。
実際にスロゲ作り始めれば、問題点とか見えてくるんだろうけど…

**名前は開発中のものです。** · 2006/06/25(日) 00:02:52

>>161
乙です。　次はリール制御お願いします。

**名前は開発中のものです。** · 2006/06/25(日) 03:26:09

>>161
すげ乙
これでしばらく遊べそうだ
ちなみになんでこんなに滑らかに回るの？
出来ればコツとかヒントを下さい

**名前は開発中のものです。** · 2006/06/25(日) 20:08:27

>>162
テーブル方式のプログラム自体は簡単。
大変なのは押し順別、停止位置別、テーブル選択用テーブルの作成。
これはスロゲー作者固有の仕事で、ツールがないよりマシって程度。
下手するとテーブル選択用のプログラムを自分で書いた方が楽かもしれない。

コントロール制御を簡単にする構想はある。

>>163
a フレームレート = リフレッシュレートにする
b 出来るだけ高フレームレートにする
の２択(サンプルのデフォはb)

**名前は開発中のものです。** · 2006/06/26(月) 01:05:58

>>154
俺もCを大学で習った程度の知識しかなかったけど
1日でリール回転→ストップまではいけたよ
まあそっから頓挫してるわけだけど…

**名前は開発中のものです。** · 2006/06/26(月) 07:44:53

>>162
停止時に4コマ先まで検出して候補を搾り出して止まらせるってのはどう？（ハズレ時）
その際、何コマ滑らせるかは任意の振り分けでランダム。
ハズレ時は振り分け0だけどBR成立時には振り分けると所謂リーチ目を表現できる。
まあこれも既出だけど。

>>164
aはむずそうだなあ。
bも出来るだけそうしようとしてるんだけど、128さんのものと比べ物にならない…。
”見た目上滑らかに見える表現”にも興味が出来てきたんだけど、そのような事はしてますか？
例えば、市販のPSゲームを一時停止させてみた所、滑らかに見えるスロゲは、回転中にわざと絵柄を上下にブレさせてました。
そのような”見た目上”に関わる事はしていますか？
（128さんのものは回転中にSSを撮ってみましたが、ブレは見られませんでしたが…）

**名前は開発中のものです。** · 2006/06/26(月) 22:29:49

久々に開発再開しようかなｗ
この前実践でクソ負けしてからあんま触ってないや。

ところで聞きたいんだけど、リールを24コマ(25コマ)分用意して
滑らす方法以外の方法でやるときはリールの枠を15個
（通常の停止場所9箇所分と上下切れてるコマ6箇所）
それぞれで動くようにすればいいの？

**名前は開発中のものです。** · 2006/06/27(火) 02:18:48

>>167
その質問で開発再開って…
完成してないのﾊﾞﾚﾊﾞﾚ…

**名前は開発中のものです。** · 2006/06/27(火) 09:23:14

>>168
ドコに完成って書いてあったの？ｗ

あの変な質問じゃわけわからんツッコミがあっても仕方ないのか。

◆SAKURA7br2 · 2006/06/27(火) 18:51:51

>>166
＞”見た目上”に関わる事はしていますか？
164さんじゃないけど、俺はそうしてますよ～
リフレッシュレートが有限である以上
プログラム的な解決法は限界がありますので。

**名前は開発中のものです。** · 2006/06/27(火) 19:28:57

HSPでループ作るとどうがんばってもFPS64くらいまでしか行かないんだけどｵﾚ何か勘違いしてる？
もちろんそのループは画像コピーとかも全て削除した最小のループで。

**名前は開発中のものです。** · 2006/06/28(水) 03:51:13

>>171
repeat～loop間で特に重い処理をさせずに
そのフレームレートだったら
少しおかしい。

と思うなぁ。

**名前は開発中のものです。** · 2006/06/28(水) 14:12:18

#include"dsoundex.as"
repeat

timer
newtime=stat

if (newtime-oldtime)>=1000{
FPS=count
count=0
oldtime=newtime
}
count++

redraw 2
color:boxf
color 255:pos 0,0:mes FPS
redraw 1

await 1
loop
//端数は考慮してないけど何か間違っていますか？
//リフレッシュレートは75ヘルツにしてFPS64くらいです。

**名前は開発中のものです。** · 2006/06/28(水) 16:07:47

>>173
毎ループで塗り潰し+FPS書き込みという処理を行っている
この処理がFPSをそこまで下げるのに充分な重い処理になってるんじゃない？

**名前は開発中のものです。** · 2006/06/28(水) 19:53:29

>>166
>停止時に4コマ先まで検出して候補を搾り出して止まらせるってのはどう？（ハズレ時）
問題なのはテーブル方式なので…。

>そのような”見た目上”に関わる事はしていますか？
何もしてもません。
が、リフレッシュレートとの兼ね合いや、計算精度の問題でブレは発生します。

>>171 >>173
間違ってないから安心汁
await 0　時のFPSを>>172 >>174に教えてあげましょう。

**名前は開発中のものです。** · 2006/06/28(水) 20:41:53

await 0だと188～194くらいですけど、それだとCPUが100%になっちゃうんですよね…。
これはもうHSPでは高FPSは出せないのかな…。
（HSPDXFIXなどのDirectXプラグインを使ってもダメでした。）

ちなみに>>128のものはFPSいくつでしょうか？
CPUは50%くらいですね。

**名前は開発中のものです。** · 2006/06/28(水) 20:43:57

//あ、ちなみにboxfやredrawやmesの重そうな命令を削除しました。
//整数値ですので誤差出まくりですが、多分>>173の検証結果を証明するには充分だと思います。
#include"dsoundex.as"
repeat 1000

timer
newtime=stat

if (newtime-oldtime)>=1000{
FPS+=count
tmp++
count=0
oldtime=newtime
}
count++

await 1
loop
FPS=FPS/tmp
pos 0,0:mes FPS
stop

**名前は開発中のものです。** · 2006/06/29(木) 00:52:25

ちゃんと読んだら172は関係なかった。スマソ

>>176
期待してたより低めでしたが、171からの流れで重要なのはawait 1で
15ms以上の時間を消費してるって事です。

#include "kernel32.as"
#include "winmm.as"
timeGetTime
start = stat
repeat 64
await 1// await 0: Sleep 1でも同じ
loop
timeGetTime
mes (stat - start) + "ms"
stop

これが64msにならないのは、HSP特有の問題ではなく主にOS(2000/XP)の問題です。
解決策のヒントぐらいは現行スレにもあるのでこれ以上触れませんが、
176さんの環境では改善されてもSleep 1 = 約2msが限度かもしれません。

>ちなみに>>128のものはFPSいくつでしょうか？
描画にかかる時間が無視出来るほど短ければ1000FPSに近づきますが、
CPU使用率50%との事なので500FPS位だと思われます。

**名前は開発中のものです。** · 2006/06/29(木) 18:41:48

>>178
＞await 1// await 0: Sleep 1でも同じ
同じではない。

**名前は開発中のものです。** · 2006/06/29(木) 20:59:00

>>179
了解
2000/XPは同じ
98/Meは環境次第

まだ間違ってるようなら解説お願いします。

>>178
>CPU使用率50%との事なので500FPS位だと思われます。
これも間違ってるっぽい。

**名前は開発中のものです。** · 2006/06/29(木) 23:59:40

やっとリールが回転するアルゴリズムができそう。
まったりいくか。。

**名前は開発中のものです。** · 2006/06/30(金) 17:19:38

>>180
自分で
await 1 →　15ms以上
sleep 1 →　約2ms程度
って書いてるしょ。
await 0が13ms以上消費しない限り一緒にはならないが
そんな大量に消費するわけがなく…

**171** · 2006/06/30(金) 17:29:27

>>178
await 1とsleep 1では1000
await 0では16でした。
sleep 1でもawait 0でもタスクが奪われて固まります…。
そして結果からもawait 1以下の待ち時間にはなっていないようです…。

＞await 1で 15ms以上の時間を消費してるって事です。

そうですよね。。
むしろawait特有の問題＝HSP特有なのではないでしょうか？
>>128は何で作っているのですか？

HSP3ではllmodが使えないので（代わりはあると思いますが）HSP2.61限定ですが、
await
prm=1
dllproc "Sleep",prm,1,D_KERNEL
このようにsleepの精度を1にしてみたところで結果は同じ（精度1msになっていない？）でした。。

**名前は開発中のものです。** · 2006/06/30(金) 18:03:01

>>183
>むしろawait特有の問題＝HSP特有なのではないでしょうか？

これはOSの問題
OSが最小で計れる時間を決めてるんだから
だからそれを、変える必要がある

hsp　timeBeginPeriod

これで検索してみ、モジュールとかも出てくると思うよ

**名前は開発中のものです。** · 2006/06/30(金) 19:00:01

あれ？違ったかな
timeBeginPeriod 1
に、してもawait(kernel32.dllのSleepは変わる)の精度は変わらないからawaitの問題になるのか？
awaitの時間計測は別の所みてるのかな・・・

**名前は開発中のものです。** · 2006/06/30(金) 22:49:30

>>182
171が>>77を見つけて改善できたとしてもSleep 1が2msかもって話ね。
普通await 0が13msなんて発想する前に、Sleep 1を疑うと思うけど。

>>183
>HSP3ではllmodが使えないので（代わりはあると思いますが）
DLL呼び出しが結構楽になりました。
WINAPIは標準で付いてくるkernel32.as等に定義済みなので、
includeするだけです。相変わらず面倒なケースもいろいろありますが…

>>185
awaitのソースの一部
tick = GetTickCount();
if ( code_exec_await( tick ) != RUNMODE_RUN ) {
MsgWaitForMultipleObjects(0, NULL, FALSE, hspctx->waittick - tick, QS_ALLINPUT );

MsgWaitForMultipleObjectsはtimeBeginPeriodで精度UPするけど、
モード切替するcode_exec_await（ブラックボックス）の中の人がGetTickCount使ってれば
内部で無意味にawait 1のループ突入の予感(主に2000/XP)

**名前は開発中のものです。** · 2006/06/30(金) 22:54:09

tickそのまま使ってるだろうし、それだけでアウトか…

**名前は開発中のものです。** · 2006/06/30(金) 23:25:27

>>186
>モード切替するcode_exec_await（ブラックボックス）の中の人がGetTickCount使ってれば
なるほど、ありがとう

って、事はSetSystemTimeAdjustment で変えられるかもしれないって事か・・・
（色々面倒そうだからtimeBeginPeriod 1でSleep使うな・・・）

**名前は開発中のものです。** · 2006/07/02(日) 18:59:15

HSP3.0での関数について質問なんですが
戻り値がある関数は#defcfunc
戻り値がない関数（命令と呼ぶ？）#deffunc
ですよね？

下のほうで戻り値を持たないような関数を作る場合どうするか
分からないのですがどう作ればいいのですか？

**名前は開発中のものです。** · 2006/07/02(日) 23:34:43

意味わかんねーな
戻り値のない命令？

あんたの言う戻り値って何？
パラーメータとして渡した変数の内容が変わらない事？
もっと具体的に、その”戻り値を持たないような関数”の例でも挙げてくれ

**名前は開発中のものです。** · 2006/07/02(日) 23:53:06

hspdxfixは内部でtimeBeginPeriod 1してるからincludeするだけでSleepの精度は上がる。
でも、es_syncでウエイト調整出来るからSleep不要じゃん。
ウインドウモードで多少カクカクしても、フルスクリーンモードを用意しておけば
おつりが来ると思う。

>>189
戻り値のない関数だから、戻り値を省いてreturnすればOK

**名前は開発中のものです。** · 2006/07/03(月) 04:20:16

>>191
Sleepｈａ不要でもawaitは必要なのですよ。
await 1以上でタスクをOSに渡してあげないといけないってところがHSPの縛りでして…。

**名前は開発中のものです。** · 2006/07/03(月) 05:03:22

失礼。
フルスクリーン時にはawait要らないのですね。
ウィンドウモードではes_syncでV-BLANKを待たないからawait 1以上が必要なのですね。

**名前は開発中のものです。** · 2006/07/03(月) 11:59:59

>>193
素人考えなんですが、
ウィンドウモードでもes_syncでウェイト時間を指定してやれば(例 es_sync 16)、
await 0でもいいような気がするんですが、ダメなんでしょうか？

**名前は開発中のものです。** · 2006/07/03(月) 13:09:41

>193
await 0でもタスクはOS_に移るよ
画面モード、es_syncは一切関係ない
hgsyncは1以上でタスクを渡す
0にした場合awaitが必要

マウスの座標を収得してみれば分かるよ
await 0でも収得できるから

**名前は開発中のものです。** · 2006/07/03(月) 22:14:29

>>194
FPSは同じになりますがCPU使用率は大幅に違う模様。
FPS:await 1=es_sync 15
CPU:await 1<<<es_sync 15

>>195
await 0でもタスクは移るみたいですね。
ヘルプにはウィンドウモード時にはawaitを入れろとかいてあるけど、
フルスクリーン時にも入れないとALT+TABが効かなくなる…。

CPUを抑えて高FPSにならないものか・・・。

**名前は開発中のものです。** · 2006/07/05(水) 22:59:05

>>196
#include "kernel32.as"
#include "winmm.as"
;timeBeginPeriod 1 : onexit *exit_proc;
dim liFrequency,2
dim liCounter,2
lpFrequency = varptr(liFrequency) : QueryPerformanceFrequency lpFrequency
lpCounter = varptr(liCounter) : QueryPerformanceCounter lpCounter
mspc = 1000.0 / liFrequency(0) : Prev = liCounter(0)
repeat
QueryPerformanceCounter lpCounter : LoopCount++
if (liCounter(0) - Prev >= liFrequency(0)) {
loopAverage = mspc * (liCounter(0) - Prev) / LoopCount
DrawAverage = mspc * DrawSum / LoopCount
Prev = liCounter(0) : LoopCount = 0 : DrawSum = 0
}
redraw 0 : color 255,255,255
repeat 5;負荷
boxf
loop
if LoopAverage != 0 {
color 0,0,0 : pos 0,0
mes "描画処理 "+DrawAverage+"ms ループ "+LoopAverage+"ms"
mes "計算上のCPU使用率"+(DrawAverage * 100 / LoopAverage)+"%"
}
redraw 1 : BeforeDraw = liCounter(0)
QueryPerformanceCounter lpCounter : DrawSum += liCounter(0) - BeforeDraw
await 15; timeBeginPeriod有りでawait値を減らすとタスクマネージャ上の負荷が....
loop
*exit_proc
timeEndPeriod 1 : end

**名前は開発中のものです。** · 2006/07/07(金) 21:28:37

【道具】ゴト師御用達３【器械】
http://news18.2ch.net/test/read.cgi/slot/1152267279/l50

**名前は開発中のものです。** · 2006/07/12(水) 15:27:20

保守しなくちゃ

**名前は開発中のものです。** · 2006/07/12(水) 16:59:37

>>199
何のために？みんな個々のHPでやるから必要無いって言ってたよ！自然消滅をまて。

**名前は開発中のものです。** · 2006/07/13(木) 12:32:46

みんなってだれだよｗｗｗ
中二かよｗｗｗｗ
自然消滅を待てってｗｗｗｗｗｗ言いながら保守おつ

**名前は開発中のものです。** · 2006/07/13(木) 17:27:19

>>200
そのHP一覧をくれ

**名前は開発中のものです。** · 2006/07/18(火) 03:28:44

age

**名前は開発中のものです。** · 2006/07/18(火) 16:55:54

ageだけかよ

**名前は開発中のものです。** · 2006/07/18(火) 22:51:23

sage

**名前は開発中のものです。** · 2006/07/20(木) 09:54:54

設定やら図柄やらを外部ファイルで記述できる
スロットエンジンとかあれば盛り上がるんだろうけど…。

**名前は開発中のものです。** · 2006/07/20(木) 12:03:47

>>206
それ、意外と流行らない
制御のアルゴリズム次第で流行るかもだけど

**名前は開発中のものです。** · 2006/07/24(月) 14:01:47

簡単マクロとかで組めればか……理想だけど、設計をちゃんとしないといけないし大変そう
普通に組むだけでも意外と面倒っす。

**名前は開発中のものです。** · 2006/07/24(月) 21:42:27

第2,3停止のテーブル制御
これをバッサリ切り捨ててしまえば割と簡単な仕様になると思うけど、手抜きし過ぎでリーチ目が寒そう。
出目を登録してテーブル自動生成って道もありそうな気がするけど、手は全然動いて無い。

**名前は開発中のものです。** · 2006/07/25(火) 02:43:14

>>209
自動作成にしたら結局は皆同じ制御になってしまうんだが。
成立役引き込みとか非成立役のはずしとかの最低限の制御を自動にして
そこから細かく設定できるようにするのならわかるけど、
結局は一から作るのと変わらないと思う。

それに、自動にするにも、絶対に重複成立が避けられない場合とか、例外の処理も大変そう。
このアルゴリズムはかなり難しそう。
もしそれも手動または半自動にするならそれこそ一から手動で作った方が早そうだ。

**名前は開発中のものです。** · 2006/07/25(火) 15:21:28

オリジナル機種として作るならリールの配置さえ失敗しなければ問題ないと思う。

制御は順押し or 挟み押し　と　それ以外で分けてしまえばいいだろうし。
ただこれに意図的なリーチ目や純ハズレのようなテーブル制御みたいなものが入ってくると面倒かな。
と思う。

**名前は開発中のものです。** · 2006/07/26(水) 22:54:52

>>210
>成立役引き込みとか非成立役のはずしとかの最低限の制御を自動にして
これは当然として、リーチ目やハズレ目もあらかじめ設定しておく事で、自動化出来ないかなって事。

>絶対に重複成立が避けられない場合
動的にやるのは面倒そうなので、あらかじめ総当りで調べておく。

**名前は開発中のものです。** · 2006/08/04(金) 00:39:42

>>212
＞あらかじめ総当りで調べておく。

「～法則でリーチ目を演出したい」って時に結局は人間の手で確認しなくちゃいけないっぽ。
たとえば「リプは絶対に中段に揃う法則」とか。

**名前は開発中のものです。** · 2006/08/12(土) 02:52:44

今、自分で作っているスロアプリを作り始めた頃
テーブル制御とかを編集するツールを作成しようとした事があったけど
半分ぐらい作ってから、手書きでテーブル書いた方が早い事に気がつきますた。
まぁ、手書きだった分管理できなくなって破綻してしまいましたが。

コントロール方式サイコーｗｗｗｗ

重複成立？
リール配列でかわしちゃえｗｗｗ

**名前は開発中のものです。** · 2006/08/12(土) 20:05:06

最強。

午後の賭博2

**名前は開発中のものです。** · 2006/08/13(日) 01:18:28

気軽に出来るのがフリーソフトのいいところなのに、インストールしなくちゃいけないゲームなんてやらん。

**名前は開発中のものです。** · 2006/08/24(木) 18:19:21

ほすあげ

**名前は開発中のものです。** · 2006/09/01(金) 22:09:20

ほす

**名前は開発中のものです。** · 2006/10/04(水) 17:22:54

Jsn=PTT

**名前は開発中のものです。** · 2006/10/06(金) 11:52:15

VBで開発している人はいない？

VB2005版DirectXがきてくれれば作ろうかなんて思っているんだけどね。

**名前は開発中のものです。** · 2006/10/07(土) 01:51:31

VB2005版て？
普通にVB2005とManagedDirectXがあれば作れんじゃないの？

**名前は開発中のものです。** · 2006/10/10(火) 00:19:49

222

**名前は開発中のものです。** · 2006/10/30(月) 01:46:06

(´▽｀)

**名前は開発中のものです。** · 2006/11/01(水) 01:26:47

限りなく実機に近い滑らかさを再現させるべくCRTモニタを買おうか迷う

**名前は開発中のものです。** · 2006/11/01(水) 15:45:00

実機買えば？

**名前は開発中のものです。** · 2006/11/03(金) 21:22:26

>>225
実機は自由度が少ない

**名前は開発中のものです。** · 2006/11/28(火) 01:06:49

限界

**名前は開発中のものです。** · 2006/12/19(火) 12:18:40

作ってるよ