포럼: Open Discussion (Thread #25925)

IRC #kurakai会議 (2010-04-02 08:05 by hryksbt #49868)

蔵開チーム内の会議のログを公開するスレです。

2010年4月1日 第1回蔵開チーム会議 (2010-04-02 08:19 by hryksbt #49869)

参加者:たっきさん、nonさん、水上さん、iSTさん、裕之

<現在の成果状況>

#説明資料
・三国志ラフ ゲームシステムの概要説明資料
・Open三国志online(仮)クライアント開発案 戦闘システム詳細説明資料

#設計書
・gs概要
・Open三国志Onlineサーバクライアント構成 システム構成図
・Open三国志Online DBスキーマー DBテーブル設計書
・Open三国志Online通信プロトコル 通信プロトコル設計書

#プログラム
・オープニング画面
・翻訳機能付きTwitterチャット
・Twitter認証

#マスターデータ
・部将パラメータ
・マップブロックパターン

<この後の作業>

マップロジック作成(iSTさん)
通信プロトコル設計見直し(たっきさん)
BGM挿入(nonさん)

<サウンドについて>

中国風のサンプリング音源を使用してBGMを挿入する。
効果音については、ネットから無料素材を入手する。

<マップについて>

戦闘マップの元となるデータは作成済み。
データの大きさにより、ゲーム開始の最初の認証時にサーバからダウンロードする形を取るか、クライアントに始めから持たせるかを検討が必要
Reply to #49868

RE: 2010年4月1日 第1回蔵開チーム会議 (2010-04-03 09:46 by izumist #49873)

裕之さん
マップって現在100*100ですが、画面上に表示するのはどのくらいを想定していますか?

単純に100*100を表示するのは出来ているのですが、移動とかを考えると
現状ではパフォーマンスがとても悪いので、
画面に表示するマス数を教えて下さい。

また、拡大・縮小もあり、ですよね?

こういうゲームのマップってどういう風に描画するのがいいのでしょう?
ご存知の方、お知恵を貸して下さい。

別件(個人的なandroid開発)でも、一画面にView(ウィジェット)を大量に描画したり、
surfaceviewでdraw系を使って沢山描画処理をすると、とても耐えられるパフォーマンスが出ないのです。

宜しくお願いします。
Reply to #49869

RE: 2010年4月1日 第1回蔵開チーム会議 (2010-04-03 10:26 by okotaneko #49875)

iSTさん

おはようございます
おこたねこです

一回の描画で全部Viewに描画しているのでしょうか(・vv・)?
既にされていたら、ごめんなさいなんですけど・・・

もし格子状のラインを描画されているのでしたら、描画をやめて背景画像に格子を書いてしまうとか、どうでしょうか
この場合、拡大、縮小用の画像が必要になりますので、拡大、縮小は3段階にするなどで、対応が必要になります。
マップの中に配置するオブジェクトの位置関係を計算する部分も、拡大、縮小のロジックが必要になり、手間がかかるかもしれません

あとlayerのように重ね合わせはできませんでしたっけ、背景、layer1、layer2のような感じで、オブジェクトの種類ごとにlayerに分けて、各、背景とlayerを描画して、一旦Bitmapオブジェクトにしてメモリ上に退避して、画面上で一回まえに描画した内容と、今回描画する内容で変化が無かったら、メモリ状のBitmapをそのまま描画するとかすると、書き込むオブジェクト数と描画ループでのループ回数が減りそうに思います。

layerにするBitmapオブジェクトを透過にするとかが、必要かもしれません


Reply to #49873

RE: 2010年4月1日 第1回蔵開チーム会議 (2010-04-03 10:38 by okotaneko #49876)

iSTさん

おこたねこです
さっき書いた内容はjava swingでアプリを作った時にやった方法なので、androidでは勝手が違うかもしれません。

あとmapで画面からはみ出す部分は描画しないとかどうでうすか?
100×100を10分割にしてスクロールは10づつ動かすとか(・vv・)?
Reply to #49875

RE: 2010年4月1日 第1回蔵開チーム会議 (2010-04-03 10:55 by okotaneko #49878)

iSTさん
おこたねのです

もう一回で書けよ状態ですが
googleのなにかのイベント?カンファレンス?かでsurfaceviewよりも高速で画面を描画する方法?ライブラリ?をgoogleのエンジニアの方が発表されていました
コメントにandroidでもゲームは大丈夫と言ってたと記憶しています。
Reply to #49876

RE: 2010年4月1日 第1回蔵開チーム会議 (2010-04-03 21:27 by hryksbt #49880)

マップの仕様ですが、24x24のブロックパターンを、縦に20ブロック、横に20ブロック表示させると丁度いいという事がわかりました。
(24x20ブロック=480pixel)
全体では100ブロックx100ブロックになりますので、全部で25画面になります。
表示されている画面から、隣の画面へ移るには、スクロールではなく、完全に画面を切り替える方が、パフォーマンスがいいと考えてますので、この方式でOKだと思います。

今日おこたねこさんと、仕様についてかなり詳細なところまで決め込んできましたので、この点についても含めた形で仕様書にまとめたいと思います。
Reply to #49873

RE: 2010年4月1日 第1回蔵開チーム会議 (2010-04-03 10:21 by nonno #49874)

裕之さん

今日の蔵開チーム会議は開催されるのでしょうか?

non
Reply to #49869

4月3日蔵開会議 開催します!! (2010-04-03 21:38 by hryksbt #49881)

あと1時間弱と言う状況で若干無茶ではありますが、本日22:30より蔵開会議を、#kurakaiにて開催したいと思います。
集まれる方だけでも集まって頂いて開催したいと思います。
主にクライアントに関する仕様についての質疑応答の内容で進めたいと思います。
蔵開チーム以外の方も、仕様を共有する為に、是非ご参加下さい。
Reply to #49868

RE: IRC #kurakai会議 (2010-04-03 21:52 by nonno #49882)

裕之さん

nonは参加させてください!
開発経験が乏しいですが、参加させていただければと思います。

いろいろ教えて欲しいことがたくさんあります。

どうぞ、宜しくお願いいたします。

non
Reply to #49868

IRC #kurakai会議 2010年4月4日 (2010-04-04 22:16 by hryksbt #49896)

<参加者>
水上さん、iSTさん、nonさん、たっきさん、おこたねこさん、てんきさん、muraさん、akifumi3さん、裕之

<ゲーム仕様説明>
おこたねこさんと裕之で、仕様検討を行い、その結果を報告
現在作成中の資料(https://svn.sourceforge.jp/svnroot/sangokushi/trunk/Documents/Open三国志仕様書.ppt)にて詳細を確認してもらう。

<戦闘用マップについて>
24x24pixelを1マスとし、縦に20ブロック、横に20ブロックとすると、480x480pixcelとなり、残る部分をステータス表示画面などにすれば、Xperiaの画面に丁度良さそうだ。

iSTさんが画面スクロールの部分をHT03Aにて検証した結果、 24px*60コマを描画して、スクロールしても問題なし。

20x20ブロックだと、今用意している地図データ(https://svn.sourceforge.jp/svnroot/sangokushi/trunk/ScreenPatern)が、100x100ブロックの為、25画面必要になることになる。
画面切り替えを行って、隣の画面に移動するか、プレイヤーのユニットを中心にして画面を作成するかは、検討中。
後者の方が、ゲームとしては良さそう。

<戦闘のルールについて>
数分を1ターン(ゲーム中では1日)として、参加しているプレイヤー全員がサーバにコマンドを送信し、処理結果を全てのクライアントに返す方式と、プレイヤー同士の同期は取らない案を検討中。
後者の場合、数秒ごとにサーバへリクエストするか、クライアントをhttpサーバにして、サーバからデータをプッシュするなどといった方式が出た。

<Twitter認証について>
仕様を共有。現時点で資料等はないが、ソースはコミット済み。(iSTさん)
成りすましが出来ない様、何かしらの対策を講じる必要性があるが、方法については検討中。
IDはDBに保管する事をそうていしている(おこたねこさん)
Reply to #49868

RE: IRC #kurakai会議 2010年4月4日 (2010-04-05 10:05 by izumist #49906)

おこたねこさん、裕之さん
先日のIRCでのターンの考え方の件ですが、裕之さんのまとめていただいた資料を見ながら、
やっぱりターン制がいいかな、と思います。
このゲームでは、NPCの動きが結構重要な気がして、そうすると、ターンで区切っていかないと
やはり結構(実装が)大変な事になりそうな気がして。

コマンド入力後、他者の入力待ち(ターン制限時間内)の間に、待ち時間も気にならないソーシャル性のある
しかけが出来れば、いいんじゃないかと思いました。
(その内容は???ですけど・・・)


あと、ターンについて教えて欲しいのですが、

・1ターンは全範囲(100×100枡)で共通となりますか?
  (画面は20×20枡ですが、それ以外の場所の戦闘も同じターンとして処理される?)

・同一の戦場のターンは、ゲーム参加のタイミングに関わらず、絶対値として進行する?
  (ターン10から参加したユーザーは、その時点で10日経過、として参加?)

・上記にも関係するかと思いますが、ターンの開始条件は?


質問ばかりで申し訳ありませんが、宜しくお願いします。
Reply to #49896

RE: IRC #kurakai会議 2010年4月4日 (2010-04-05 14:03 by hryksbt #49909)

確かに、プレイヤーのみが存在するならターンの有り無しによって設計や実装のボリュームが大きく膨らむ事もなさそうですが、NPCも絡めると、ターン無しのパターンは、少なくとも設計とデバッグのボリュームが増大しそうな気がします。
IRCでも述べさせて頂いてますが、ゲームとして面白く且、実装が楽なのがベストではあります。
但し、A3目標という時間の限られた今のフェーズでは、どちらか選べという事になると、実装が楽な方を選択する事になってしまうと思います。
Reply to #49906

RE: IRC #kurakai会議 2010年4月4日 (2010-04-05 14:28 by hryksbt #49910)

すみません。。回答を忘れてました。

コマンド入力後、他者の入力待ち(ターン制限時間内)の間に、待ち時間も気にならないソーシャル性のある
しかけが出来れば、いいんじゃないかと思いました。
(その内容は???ですけど・・・)

⇒そうです。そうです。ご説明を忘れてました。
サーバから処理が返ってきてクライアントに表示されてから、コマンド送信時間となりますが、この間に次のターンの作戦を考え、1プレイヤーあたり、例えば2~3通ほどTwitterにメッセージを送る事ができるようにすると、150通/時間というTwitterの制限にも対応できると考えてますし、プレイヤー通しで協調して作戦を遂行できるような要素を持てるのかなと思います。

あと、ターンについて教えて欲しいのですが、

・1ターンは全範囲(100×100枡)で共通となりますか?
  (画面は20×20枡ですが、それ以外の場所の戦闘も同じターンとして処理される?)

⇒画面分割パターンと、プレイヤー中心パターンのいずれも対応できますので、共通の方がいいと思います。
それと、プレイヤーを画面の中心にする場合は、19×19枡の方が、プレイヤーを中心に表示させる事が出来ると言う意味では良さそうです。余白が出来ますので、そこは三国志っぽいテクスチャで飾るなどすればいいのかと思います。
それから、1枡24×24pixelだとやはり表示できる数値や、タッチの面で小さすぎるような気もしています。
32×32pixelだと、15×15枡となり、プレイヤーを中心に表示できるので実は調度いいかもしれません。
また、全体が100×100と言う点も、現時点で特に根拠は無く、実証様に作成したデータと考えて下さい。
実際、マップデータを結構作るのに時間がかかったので、この先を考えると60×60くらいで全画面へのスクロール可能とした仕様の方がいいのかもしれません。

・同一の戦場のターンは、ゲーム参加のタイミングに関わらず、絶対値として進行する?
  (ターン10から参加したユーザーは、その時点で10日経過、として参加?)

⇒途中参加の場合、既に10日経過していた場合、10日目からの参加です。
時間の違う同じ戦闘が存在すると言う想定は無く、今後マップを追加してゲームルームを追加する事を考えています。

・上記にも関係するかと思いますが、ターンの開始条件は?

⇒サーバーで"ゲームルーム"の開始を管理します。gs概要のアレです。
Reply to #49906

RE: IRC #kurakai会議 2010年4月4日 (2010-04-05 16:51 by izumist #49911)

裕之さん
ありがとうございます。随分理解できてきました。

とりあえず、

・進行はターン制
・マップはユーザー中心
・マップチップのサイズは[32px×32px]×15枡
・マップ全体サイズは(とりあえず)60×60枡
  →とりあえずは100×100の実証用マップを切り抜いて。
・マップはスクロール可能

と言うイメージでちょっと書いてみようと思います。
Reply to #49910