対戦型カードゲーム

2 views
Skip to first unread message

ちび

unread,
Nov 24, 2011, 10:19:37 AM11/24/11
to Tatumak...@googlegroups.com
言葉に起こすのが苦手なので上手く長文にすることができませんが、ご了承ください。

カードに関する情報などは全部グループにする必要がありそうです。

また、Luaとiniによって外部データの取り込みを模索している現状です。

・対戦ルール
・カードステータス(エフェクト)
・敵AI

などはLuaとiniを使い分けて組み立てる方法を模索中です。

特にAIはLuaに判断させることによって格段にスピードアップすることができるのではないかと考えています。

また、特にFPSを気にしない体系のゲームであるため、ある程度の技術的な問題は無視でき、

経験を積むにはもってこいだと思われます。

また、フリーバトルだけでなくシナリオモードも実装しようか検討しています。

その場合は、シナリオファイルは外部ファイル扱いにしようと思っています。

どうでしょうか?意見があればどのような意見でも取り込んでいきたいと考えていますので、よろしくお願いします。

私的見解ですがいくつか参考になりそうなフリーゲームをまとめてみました。

どれも独自言語+Luaで構築されているゲームです。

・ネットワーク対戦カードゲーム「ABCD」
http://abcd.web.infoseek.co.jp/

・剛体シミュレータ「RigidChips」
http://www.iamas.ac.jp/~takeya04/software.html

Tatumakigen

unread,
Nov 24, 2011, 10:58:27 AM11/24/11
to Tatumak...@googlegroups.com

iniファイルは通常、プログラムの設定データ等を書きだしておくためのものですのでゲームデータ等の用途には向きません。
主に環境設定やユーザープロフィール等を保存するために使用します。

データの保存についてですが、一般的にtxtやiniファイル等の可読性の高いものに書きだしてしまうとユーザーが勝手に改竄してしまうという問題があります。
回避方法としてはバイナリデータに直してからビットをひとつずつシフトする方法や、ハッシュ値を使って改竄を摘発する等の方法があります。

また、データの保存方法にはCSVやSQLite等のデータベース等が一般的です。
多いけど大したこともなければCSV
膨大な量のデータに高速にアクセスするならSQLite といった感じに使います。
CSVはただのカンマ区切りのデータなので、こちらの可読性も非常に高いです。
SQLiteも同様ですが、こちらはデータアクセスのためにSQLite用のAPIを使うことになります。



描画速度が必要ないとのことなので、まずはGLを使う必要があるかないか というところから始めてみてはいかがでしょう?
AIに関してはうまく状態を管理してやればそこまで処理を肥大化させずになでしこのみで制作出来ると思います。

また、3次元頂点演算は恐らくCでDLLを書く必要性があると思いますので、GLでは対応できません。
Arle氏がActiveBasic用のDLLを使って3Dに挑戦していましたので参考程度にどうぞ。
Shoot!2


nightmare-pan...@ezweb.ne.jp

unread,
Nov 24, 2011, 11:08:24 AM11/24/11
to tatumak...@googlegroups.com
そうですか……

しかしなでしこの通常の関数では読み込みなどにやたらと時間を食うことはすでに検証済みですし……

GLを使うことによって動作とメモリが軽くなることを期待していましたので……

AIをLuaにするはユーザーが書き換えることができるようにするためと、

なでしこの演算速度に不安を覚えたからです。

Lua呼び出しのインターバルがあるとはいえ、演算速度は圧倒的にLuaに分があるはずです。

三次元描画などは現時点では全く考えていません

それは見た目にこだわりすぎて演算速度が圧倒的に遅れるようではゲームとしての快適性を損なうからです

以上長文ですが失礼します。

Tatumakigen

unread,
Nov 27, 2011, 8:14:49 AM11/27/11
to Tatumak...@googlegroups.com, tatumak...@googlegroups.com
GLは描画支援ライブラリなので、演算速度そのものは高速化しません。
ゲーム用の描画フレームワークの提供が本来の目的なので、高速化はアルゴリズムの最適化に頼られます。
また、GL自体がなでしこベースなので、演算や処理能力はなでしこと各CPUに依存します。

なでしこの演算速度は正確ではありませんが、10万回の演算程度なら1秒未満で片付くと思います。
勿論、環境によるためこれは最高値に近いので問題は残りますが、描画を凝らなければ演算に多く時間を回せますし、
今回に限って言えば一回のループを16msecに抑える必要もないので時間だけを見ればかなり余裕なのではないでしょうか。

また、AIフェーズのみ計算させるのではなく、ユーザーが考えている間や、ターン変更のエフェクト等の再生中もAIに思考させることはできます。
こうして分割することで長い演算もスタック無しで処理することができます。

兎にも角にも、実際に一度作ってみて、駄目であればLUAに移植する という方針では駄目なのでしょうか?

また、最初から圧倒的に時間が足りないと感じるのであれば、素直になでしこを諦めるというのも手ではあります。
あるいは別言語にも移植できるようにLUAで書き、インターフェースのみなでしこから提供する という手段もあります。
これの場合は、なでしこで無理だった場合にLUAスクリプトを別言語に載せれば容易に移植ができます。

手軽な文法で演算速度に優れている言語では、Ruby+SDLや、Java+OpenGL,HSP+WinAPI等、様々です。
御存知の通り、演算速度の優れないなでしこを、あえて使う意義 というものをしっかりさせてからゲームを作ってみるのが良いかと思います。

Reply all
Reply to author
Forward
0 new messages