募集要項

  • ■ボイスの募集は終了しました。

    非常に沢山のご応募ありがとうございました!

     結果はこちら
2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

« 2013年5月 | トップページ | 2013年7月 »

2013年6月

2013年6月30日 (日)

【Unity Action】初期イベントは(とりあえず)完了

なんとか初期イベントは作成完了。
全部載せるとさすがに製品出す意味無くなるので、
最後の1カットのみ動画でペタリ。

イベント用のスクリプト整備やバグ修正除けば、
実質1イベント全体の作成にかかった作業期間は2日程度。
とはいえ質より速度を優先気味なので、お察しな部分も。

次は、イベントに関連する以下の処理の対応を予定。

・クリア後は別のイベント再生可能に
・ステージクリア時にもイベント挟めるように
・イベントによる敵の配置をバトルにも反映させられるように

他には、バトルのチュートリアルもここで入る予定ですが、
実装は後々(もっと全体が出来てから)にします。

色々揃ってはきてるけどまだまだ足りないもの多いですねぇ(´-ω-`)

余談ですが、今日で一カ月毎日更新達成です!
ショボイ更新も多いですが、ここまで連続で更新できたのは初ですね。
この調子で引き続き頑張らなければ…。

そして最初からこのペースで作業できてれば(ごにょごにょ

2013年6月29日 (土)

【Unity Action】 ボーン位置変更ェ・・・

本日、キャラの頭のボーンの位置が変な事に(今さら)気づき、
後々になるほど面倒なので、割り込みで修正する事にしました。

まぁここまではよくある(と困る)事ですが、
モデル自体の修正とUnity側での再設定は予定通りだったんですが、
モーション回りで色々と誤算がありました…。

誤算① リグ問題
       ⇒モデルに多少の変更があっても
         リグ側で吸収できるように作っていたのですが、
         顔だけピンポイントで対応してなかった事が発覚し、
         顔周りのリグ構造の修正と、
         顔にモーション付けていたデータの全移植作業をする事に。

誤算② 一部再出力のはずが…
       ⇒フェイシャルモーション使用しているデータ以外は
         移動値は出力してない(例外除き)はずなので、
         そのままで問題ないかと思いきや、
         エクスポーターを整備する前のデータが
         結構混在していて、結局念のため全データ再出力する事に…。

誤算③ 一部モーションが…
       ⇒一部のモーションデータ自体が紛失していました( ; ゚Д゚)
         かなり前のデータとはいえ、探せばありそうな気もしましたが、
         作った方が早そうだったのでモーション新規作成
         改めてフォルダ整理してSVNに上げ直したのでもう大丈夫なはず。


と、いった感じで、かなり面倒な事になってしまいました…。

つまりは全部自業自得なんですけどね ・゚・(つД`)・゚・

まぁ全データ整理できた・・・と前向きに受け取ります (。・x・)ゝ

結局この割り込み作業のおかげでイベントは終わらず…。
明日に持ち越しですヽ(T∀T)メ(T∀T)メ(T∀T)ノ

2013年6月28日 (金)

【Unity Action】 テストイベント作成中②

昨日に引き続きイベント作成中。
今日は機能対応と作成半々くらいで作業できました。

主だったイベント用スクリプトの機能追加は以下
・キャラクターのメッシュの表示非表示(フレーム指定)
・メッセージを飛ばしても、かならず○○秒は再生機能

等。後は細かい修正、調整…がたくさん。

作成自体は大体の間や、ザックリとしたモーションの作成が
出来てきたところで、あとは作り込みを丸々残した感じ
細々とした懸念点はあるものの、
なんとか明日には一段落しそうなペースです。

しかしやはりデモは大変ですね…
費用対効果考えて入れるとこは厳選しないと…。
手間的にもメモリ的にも。(◎´∀`)ノ
このゲームだとストーリーはおまけみたいな物ですし。

↓おまけ。スライムに襲われたの図(イベントの一部抜粋)
  でもバトル中にはこんな攻撃してきません(キリッ
130628_2
実は口から泡出してるけど半透明の優先度のせいでほとんど見えてない罠。

2013年6月27日 (木)

【Unity Action】 テストイベント作成中

イベント作成用スクリプトの動作確認も含めて
初期イベントを作成開始しました。

が、早々に色々と不足要素等が出て、結局そちらの対応(↓)がメインになりました。。。
┐(´д`)┌ヤレヤレ

・メッセージを非表示にしてイベントを見せるタイミングを設定可能に
・カット毎にプレイヤー、モンスターの位置調整を可能に
・フレーム指定で武器の表示非表示を可能に
・Mayaからのモーション出力を拡張(イベント用対応)
・他、細々としたバグ修正や機能調整等


後は予想はしてましたが、
メッセージ送り待ちがあるため、
作るのが単純に面倒です…。
どのタイミングで次のメッセージ/カットに行くかがユーザー次第なので、
カメラや動き等に色々と気を使ったり、
ボタンを押さないユーザーを考慮してそれぞれにループモーション等が必要になったり…。
時間経過で自動で進行するデモの方が作るの楽ですね・・・(´ヘ`;)

さらに、見下し前提のマップなので、全方位カメラに耐えられない!
という難点も。一応「イベント時のみ表示する追加オブジェクト」という設定は
作ってますが、あくまで軽い補強程度です(天球や天井、追加の木とか)。
1つ1つの素材にあまり時間かけられないので色々キツイですねぇ((・(ェ)・;))
やはりイベントは数を絞らないとダメそうな予感。

ちなみに、モーション、カメラに関しては、
以前作ったエクスポーター(モーション / カメラ)がほぼそのまま使えてます。
作っておいてよかった・・・( ; ゚Д゚)
130627_3
同一シーンで複数キャラクター同時&分割モーション出力や、
リファレンスによるネームスペースに対応しといたのも
地味に助かってます。

とはいえ、イベントに関しては、まだもう少し機能追加必要そうなので、
その辺の対応も含めて明日、遅くとも明後日には終わらせたい所です(*゚▽゚)ノ

2013年6月26日 (水)

【Unity Action】 イベント用スクリプト暫定完成

引き続きイベント用スクリプトの作成。
で、なんとか基本部分は一通りできました。

↓な感じです。
130626_0_2
イベントに出すキャラクター/モンスターの指定、
エフェクトや音も指定タイミングで再生できるようになりました。
イベント専用のリソースの読み込み、廃棄とか地味に面倒でした(´ヘ`;)

ちなみに、同じ内容を普通のインスペクター表示と比べると
↓みたいに長さが違います。
ウィンドウ幅は元より広いく、追加でボタンも設置しているのに…。。。
というか普通の表示だと何所に何があるか分からなくなりそう…。

130626_1

CustomEditorは色々便利ですが、
実装の手間が面倒なのが最大の難点ですね
。* ゚ + 。・゚・。・ヽ(*´∀`)ノ

で、軽く確認したところ、それぞれの機能はちゃんと動いたので、
ここからは実際に素材を作りながら完成度を上げるフェイズに
移行しようかと思います。

実際に組んでいくと、色々欲しくなるんだろうなぁ・・・(´-ω-`)

2013年6月25日 (火)

【Unity Action】 イベント用スクリプト作成中

と、いうわけでイベント用のスクリプトを作成しています。
現在デモ別の
・メッセージの登録(+-ボタンでメッセージの追加/削除可)
・メッセージ毎のキャラクターモーション(ターゲット、開始タイミング、補間F指定可)
・メッセージ毎のカメラモーション(親、開始タイミング、補間F指定可)
・イベントのリプレイ機能(確認用)

まで。まだ色々足りません(´ヘ`;)

今回は珍しくCustomEditorでInspectorの表示を拡張してみてます。
(そうしないと見難い上に、長い文字列だと見切れるので…)

現状メッセージのみであれば↓のような感じ
130625_1_2

メッセージ毎にモーションやカメラ、エフェクト、サウンド等を
入れていく場合は、自動的に↓みたいに拡張されます。
130625_2_2

メッセージ量は少なめな予定なので、
この方向で詰めてけば行けるかなーと思いますが、
しんどそうだったらバトル用のデバッグ機能を流用して、
タイムライン制御できるようにとかも検討する必要もあるかも。
このあたりは費用対効果をちゃんと検討しなければ…。

@は、そこまで物量増えなそうなのと、
何気にメッセージ以外の要素も多いので、
Excelへの書き出し、読み込みは見送り予定。
当然ながら作る手間もありますしね(;´д`)ゞ

2013年6月24日 (月)

【Unity Action】 初回ステージ作りつつ思った事とか

最初のステージをザックリ作成。

イベントの都合上、屋外なのですが、
モバイルだとTerrainが重すぎて使えないので
めんどいです( ; ゚Д゚)クッソゥ。
背景は贅沢できない…(;つД`)

頂点アルファでやろうかとも思いましたが、
狭いステージな事もあり、
色々悩んだ結果(手間とか処理負荷とか)、
Terrainでテクスチャをヌリヌリした結果を
1枚のテクスチャにまとめて、それを使う事に。

さすがに丸々テクスチャで持つとメモリを食いますが、
処理的には一番優しいはず。
屋外ステージはあまり作らない予定なので、
ギリギリこれもアリかなと。

屋外メインのゲームだとなかなか使えない手法ですね…。
容量気にしなければいけますが(マテ)

■後作ってて思った事メモ。
・LightMapを焼き付けた後は、
 ほぼほぼマテリアルをUnlit(Supports Lightmp)に変えたり、
 ShadowのCast/Receiveを切ったりするので、
 後から焼き直す場合、再設定が面倒(´ヘ`;)
 この辺スクリプト作った方がいいのだろうか・・・。

・ライトマップは解像度落としても、
 Truecolorにした方がいい場合も多そう。
 (1024とかそうそう使わないと思いますが)
 陰影が広範囲で変化する場合とか特に顕著ですね。
 減色ツールとか使えば別かもですが。ヽ(`Д´)ノ持ってないよ!
 (↓分かりやすい場所抜粋)
130624_2

正直ステージはあまり作った経験が無いので、
他の人はどうしてるのか色々と気になりますね。

他には、別件で以下のスクリプトを作成。
「破壊オブジェクトの配置スクリプト」
 ⇒座標とオブジェクトタイプのみ保存して呼び出している為、
  手動入力がめんどくなって作成。
「敵の出現範囲指定スクリプト」
 ⇒ステージの形状によって、範囲外に出現してしまう為。
まだまだ色々機能が足りません(´▽`;)

明日はイベント作成用に色々と処理の下準備予定。
会話とカメラ、モーションのリンクとかを
できるようにしないと…。
後はメッセージはエクセルで管理できるようにしたいなぁ…(今は直打ち)

2013年6月23日 (日)

【Unity Action】 やはりイベント回りが・・・

引き続き全体物量の精査。

おおよそ見えてきた物の、
やはりイベントをどの程度の量を、どの精度(クオリティ)で
入れるかで大分変わりそう…。

と、いうわけで、
諸々検討&機能実装の為に、初期イベントあたりを作ってみる事に。
ステージも新たに用意せねば…。

何をするにも全部自分に返ってくるので
あまりはりきりすぎないようにしないと(´▽`;)
落とし所大事!

2013年6月22日 (土)

【Unity Action】 ⊂⌒~⊃。Д。)⊃ごろごろ~

ゲームの土台のシステムがやや落ち着いてきたので、
ちょっとPCから離れてゲーム全体の構成を改めて検討。
…してたら必要以上にゴロゴロしてしまいました…⊂⌒~⊃*。Д。)-з
煮詰まるとダメですね(笑)

色々現実的な所に落ち着けなければとは思いつつ、
どうも妄想だけは広がります(´▽`;)
ノベル系じゃない&個人製作なので、
話の風呂敷広げ過ぎても畳めるボリューム作れなそうですし ・゚・(つД`)・゚・

1つ1つメモしながら整理していくしかないかなぁ。
検討する事は山盛りです><;

2013年6月21日 (金)

【Unity Action】 敵を新しい制御に載せ替え。

本日は、既存のモンスターを
新しい制御に載せ替えてました。

と、言えば一言ですが、
やっていくうちに早速色々機能が足りない事に気づき、
実質機能追加作業がメインに(´;ω;`)ウウ・・・

例えば
・専用登場処理対応
・ボス用制御対応
・飛び道具追尾系オプション追加
・飛び道具発生角度変更処理
・敵用死亡処理の拡張
・1制御で複数モーションの組み合わせに対応
・敵用軌跡対応

…以下略

といった物など。今まで直にスクリプトに書いてしまっていた部分を、
Inspectorの設定だけで適応できるようにしてた感じです。
そうしないと量産からのバグ対応で死にますからね…(´ヘ`;)

あと、単純な移植だけじゃなくて、
怪しい制御部分の見直しやバグ修正してたりしました。

と言いつつも、
まだ後少しだけ行動を移植(する為のの機能追加)作業が残ってるので、
終わらせてから寝よう~(;´д`)ゞ

2013年6月20日 (木)

【Unity Action】 デバッグ画面一段落!

なんだかんだで一週間少々かかってしまいましたが、
やっとデバッグ用のプレハブ作成が終わりました(◎´∀`)ノ

細かい機能は書いてくとメンドイので動画でペタリ。
なんとなくどんな事ができるか分かるかと思います。

今回の要点として、エディターじゃなくても使用可能に、
というのもあり、ゲーム画面内で全て完結させています。
こういった画面は初めて作りましたが、やっぱ大変ですね…。

とはいえ結局のところ、1画面に表示できるのは大枠の情報くらいなので、
詳細はInspector等で確認するしか無いですね(^-^;

今後もこれを拡張しながらデバッグを行う事になるかと思います。

…しかしデバッグとかいいながら、行動、武器等を実装する時に
一番使いそう…( ; ゚Д゚)
なんか…デバッグ画面というか…便利画面?

しかしザコを操作できるのはやっぱ楽しい。
何かしら使えるネタがあれば考えようか…いやでもバグ怖いしなぁ…

というわけで?、ゲームの土台となる処理が大分できてきたので、
そろそろ量産に向けて色々物量を
精査していきますかね。

・・・スライム以外の敵キャラの行動、CPUを
新しいスクリプトに載せ替えてから…っ! 。* ゚ + 。・゚・。・ヽ(*´∀`)ノ

2013年6月19日 (水)

【Unity Action】 CPU修正

今日はCPU処理修正メイン。
(結局デバッグ画面終わって無い)

というのも、昨日書いたように、
敵のスクリプト改造により、今まで使っていたCPUが動作しなくなった為。

ついでに、今までCPU処理はキャラクター制御用スクリプトに直で書いていたので、
分離、汎用化して、Inspector上でCPUの設定、調整できるようにしました。
その為、想定以上の大改造(というか作り直し)になりました。

といっても、まだ出来る事は少なめ。
行動パターンを登録して、
行動毎に設定した使用可能距離、使用頻度等を参照して
行動を自動選択する程度です。
一応移動は指定範囲まで行ったら終了するとか細かいのもありますが。

一応、CPUの行動パターンの確認、保存は
作成中のデバッグ画面でも行えるように
もしました。
ボタンを押すと、登録したCPU動作を行う感じです。
やはり実際の動作を見ながら調整できると楽ですね。
↓こんなのです。
130619

それぞれ、移動、攻撃、ウェイト等を組み合わせたものが作れ、
数も自由に変更可能。

ちなみに最初CPUのスクリプトはキャラ本体のルートにくっつけてたんですが、
プレハブ保存する際に色々と不要な物もまで上書きしてしまったので、
別プレハブとして扱う事に。元プレハブ上書きは怖いです><;

尚、相手のフラグ状況(攻撃中か移動中か等)や
状態(瀕死、敵の数や密集具合)等に応じての
行動の変化等は今のところは無し。
弱い敵なら現状でも大丈夫そうですが、
強い敵とか作るのを考えれば流石に追々必須っぽい気がするので
多分追々追加で作ります。

他には、行動パターンの登録は現在手入力ですが、
デバッグで動かした結果を
自動登録、編集できる機能とかも欲しい…。

Inspectorの表示もEditor弄って専用の配置にしたい…。
(入力し易くしたい)

でも費用対効果考えるとこの辺は後回し(もしくは見送り)ですかね(´ヘ`;)
なんとも悩ましいです。

あ、明日こそはデバッグ画面終わらせる・・・っ!
・・・・・・・といいなぁ(´-ω-`)

2013年6月18日 (火)

【Unity Action】 デバッグ用対応もうちょい

デバッグ用に敵用のスクリプト修正がもうちょいで終わりそうです。
なんとか明日いっぱいでデバッグプレハブ作成は終わらせたい所。

と、いうわけで今日はあまり進展は無し!( ; ゚Д゚)

具体的にはデバッグ対象を敵にもできるようになったり、
敵の硬直表示等の大枠の部分の対応は終わったんjんですが、
いろいろ変えたせいで

今はCPU動かない!ヽ(`Д´)ノ

いやぁ・・・色々飛び火しますな(自業自得

2013年6月17日 (月)

【Unity Action】 ダメージ表示UIの表示優先度

敵の制御用スクリプト修正が地道な作業で載せる事もないので、
前から気になってて修正した点についてです。

多段ダメージ等でダメージUIが重なって表示された場合
UISpriteの描画の優先度が
「後から発生させたUI」>「元々発生していたUI」
になってしまっていたのを、
「元々発生していたUI」>「後から発生させたUI」
になるように修正しました。

↓な感じです。(UIは徐々に上昇してます)
130617_3

ちなみに、ダメージUIの発生位置のtransform.position.zが同じ値の場合、
↑図左のように、
「後から発生させたUI」>「元々発生していたUI」
の描画順になってしまいます。

そこで、なんとか↓図のように
後から発生したUIの方がzの位置が前になるように
すれば、描画順の問題は解決します。
(発生順:青⇒赤⇒黒)
130617_1

ではどうしたか、ですが、
「発生地点自体を前にずらす」事も考えましたが、
発生している数や位置の管理が必要になる上、
大量に発生した際に、意図しない位置まで前に発生してしまう可能性もあります。
なので、

「UIが発生した後は↓図のように、
position.zを徐々に下げるアニメーションを付与する」
事で対応しました。
130617_2

こうする事で、発生したタイミングが早いUIが前にあり、
遅い方が後ろにある事になり、描画順も安定します。

UI表示のカメラは、Orthographic属性のカメラの為、
zを動かしても絵的な見え方に影響が無いので使えるやり方ですね。

2013年6月16日 (日)

【Unity Action】 引き続きデバッグ用機能実装中

本日はデバッグ機能として以下の機能を追加。

------------------------------
■技、コンボ数の任意変更と保存機能(昨日の続き~完了)
■装備の任意変更機能
■ステージの任意変更機能
■任意の敵の呼び出し機能
------------------------------


という感じで、大枠のデバッグ機能はできてきました。
元々1シーンで作ってたので切り替えもスムーズに。(◎´∀`)ノ

ちなみに要素変更毎にResouce.Loadで必要な物のみ読み込んで、
不要になったものは随時破棄してます。
流石に全リソース乗っけるのは実機(スマホ)じゃ厳しいですし(;つД`)

また、今まで「デバッグシーン」と呼んでましたが、
実際の所は「デバッグ用プレハブ」が正解
かも。
専用のシーンで無くても、
バトル中であれば、このプレハブを呼ぶことで、
いつでもこのデバッグ機能が使えるようにしてます。

その為、
開発中はポーズメニュー辺りに呼び出しコマンドを入れて、
怪しい時の確認にも使用できるようにしておく予定。
ただ実機だと、デバッグボタンやスライダーが小さいので、
タッチペンとか使わないと厳しそうです(笑)

次は攻撃側とは別に、
■ダメージ側の情報の表示(ダメージ属性、硬直フレーム等)(※硬直差等が見易いように)
■ザコキャラも同様のデバッグ機能が使えるように(※ザコの技確認用に)
拡張予定・・・なのですが

そのためには、
敵キャラのスクリプトを大幅に書き換えないとなので、
これはちょっと時間かかりそう。
とはいえ、どちらにしても、現在敵の制御は微妙なので、
良い機会だと思って拡張、修正作業に移ります (。・x・)ゝ
当初の考えが色々甘かった(適当だった)なぁと見つめ直す日々です。。。
ノンプログラマーなので経験不足ですね(;´д`)ゞ

デバッグ機能実装は結構時間かかっちゃってますが、
こういった機能は作成中のゲームに限らず、
別のゲームを作る際にも流用できるので、今後の為にもなりますね(という言い訳)
まぁ作成中のデバッグ機能はアクション系のゲームにしか使えないですが(´▽`;)

2013年6月15日 (土)

【Unity Action】 UIPopupListを改造してみた

デバッグ用にNGUIのUIPopupListを弄ってみました。

といっても、大した事はしてなくて、やった事は、
・ポップアップする位置の設定を可能に(指定オブジェクトからのオフセット)
・ポップアップリストの自動改行を行えるように

という2点のみです。

↓こんなの(変更ボタンを押すと、右のウィンドウがポップアップ)
130615

で、何で今回この形を選んだか、ですが、
理由は以下の通りです。

----------------------------------------------------------------
①PC上だけじゃなく、実機デバッグ中にも使用できるように
②通常のUIPopupListだと、選択数が多いと選択が難しく、
 もしスクロール等を追加しても、後半のリストの選択が面倒
③自前でUIStrageとか実装するよりはUIPopupListの改造の方が手っ取り早そう
----------------------------------------------------------------

まぁ攻撃の種類が100越えると画面内に収めるのもキツクなってきますが、
通常攻撃とスキルでリストは別なので、さすがに大丈夫でしょう。
もし超えても、このリストにスクロール機能を足せば十分・・・のはず。

で、実質足したパラメータも以下の4つくらい。
public GameObject parentTarget; //ウィンドウの発生元
public Vector2 startOffset; //発生元からのオフセット
public float windowHeight; //列毎の高さ
public float columnSpace; //列毎の固定幅

という感じです。
汎用的に使えそうなので、
一度作っておくと便利かもしれませんね。

※元のUIPopupListは残しつつ、
 別のスクリプトとして複製してから弄ってます。

【Unity Tips】 using UnityEditorを使うけどEditorに入れたくない

今日はあまり作業出来てないので小ネタを投下。

昨日の記事
using UnityEditor;
を使って、インスタンスから
生成元となるプレハブの置き換えをしましたが、

using UnityEditor;を使用しているスクリプトが
Editorフォルダに入ってないと、エディターで実行する分には問題ないですが、
ビルド時にEditorフォルダに入れてね的なエラーが出ます。

ですが、正直今回の場合のように、
完全にデバッグ用に一部入れてるだけの場合、
スクリプトをEditorフォルダに移動させたく無い場合もあります・・・・・・よね?(;´д`)

そういった場合、プラットフォーム別の#if設定をすれば大丈夫っぽいです。
例えば以下のような感じになります。

--------------------------------------------------------------------------
#if UNITY_EDITOR

using UnityEditor;
#endif
~略

#if UNITY_EDITOR
  Prefab.Add(PrefabUtility.InstantiatePrefab((GameObject)Resources.Load("Skill/"+AtkPrefab[0])) as GameObject);
#else    
  Prefab.Add(Instantiate((GameObject)Resources.Load("Skill/"+AtkPrefab[0])) as GameObject);
#endif
~略

--------------------------------------------------------------------------

プラットフォーム判別の#ifは色々あるので、必要に応じて使い分けましょう。

■プラットフォーム依存コンパイル(ドキュメント)
http://docs-jp.unity3d.com/Documentation/Manual/PlatformDependentCompilation.html

2013年6月14日 (金)

【Unity Action】 進捗と実行中に編集した内容を元プレハブに反映とか

引き続きデバッグ画面実装中です。

で、今日は細々としたバグを直しつつ
使用可能な行動のウィンドウを作成。
武器によって使える行動が変わるので、
その辺りを考慮したデバッグパーツです。

130614

・左チェック:その行動を実行中かどうか
 これは、自動的に切り替わります。

・中心のラベル:行動名(黄:通常攻撃、青:技、赤:デバッグ拡張枠)
 ここをクリックすると、その行動が再生され、
 該当する技のインスタンスが自動的に選択されます(編集し易いように)
 また、赤色の技は、事前に指定しておけば、
 武器の設定とは別にいくつも行動を追加できるようにしてみてます。

・右ボタン:技の変更と、パラメータの保存ボタン
 通常時は技の置き換えになっていて、
 技ラベルををクリックすると保存ボタンに変わるようになってます。

…技変更はまだ未実装ですヽ(゚∀゚)メ(゚∀゚)メ(゚∀゚)ノ
Editor拡張でウィンドウ作るか、ドロップダウンリストで済ますか…。悩みます。。。


で、以下今回の主題です。

実際にこのデバッグシーンで編集した技の設定を、
元のプレハブに反映させるには・・・?という所でちょっと引っかかりました。
色々調べたんですが、とりあえず結果だけ。

//ゲームオブジェクトの元となるプレハブを取得
Object _Prefab = PrefabUtility.GetPrefabParent(編集オブジェクト);
//元のプレハブを編集したオブジェクトに置き換える
PrefabUtility.ReplacePrefab(編集オブジェクト,_Prefab);


苦労した割に、結局これだけでいけました( ; ゚Д゚)

で、一応ですが注意点が3点ほど。

using UnityEditor; が必要

・編集オブジェクトは「Instantiate」ではなく、
 「PrefabUtility.InstantiatePrefab」で生成しないとプレハブが取得できない。
  ⇒デバッグ時のみPrefabUtility.InstantiatePrefabで生成し、
   ビルド時はInstantiateにする等の考慮も。

・ReplacePrefab後に、リンクが切れたりする。
  ⇒必要に応じて再設定を。

他のデバッグ機能でも使っていきそうなので、
覚えておいて損は無さそうです。

【Unity Action】エフェクトの親子設定関連

エフェクト生成時の親子付け設定のパターンを
列挙型でInspector上から選択できるようにスクリプトで拡張してたのですが、
分類が小ネタ的になってきたので簡単にまとめ。

もちろん生成時は親子設定以外にも色々必要ですが、
親子付け関連物だけ抜粋。
---------------------------------------------------
・親子付け無し
  プレイヤー(敵)に起こる事よりは、環境として起こる事が多め(ダウン煙とか)
   ⇒その場に置いてくるようなエフェクトであれば基本的にこれ。

・親子付け有り
  特定の物(プレイヤーやオブジェクト)から発生する効果が多め(オーラとか)
   ⇒エフェクトの特性によって、色々必要になる
    ⇒親のノードの指定
    ⇒親子付け時のオフセット指定
    ⇒移動値X、Y,Zそれぞれの追従の必要性
    ⇒回転の追従の必要性

・親子付け解除、変更のタイミング指定
  ⇒必ずしも、最初から最後まで同じ設定が良いとは限らない。
   ⇒フレーム指定で親子設定変更
   ⇒行動が終了したら(ダメージによるキャンセル等も含め)親子関係のみ切る
---------------------------------------------------

等、色々考慮しながら実装が必要だなぁと実感しました。
頭で理解してるのと、体感するのはやはり違いますね(´ヘ`;)

まぁ結局のところ、ちゃんとゲームとして整えていくと、
色々な設定が必要になってくる、という事ですかね(*゚▽゚)ノ

2013年6月13日 (木)

【Unity Action】修正色々( ・ω・)

今日はデバッグ用のシーンの局地的な作り込みや、
発見したバグ修正等が中心でしたので、画像は無し。
デバッグ機能を実装していくのにあたって
色々と対応が必要になり、回り道中です。┐(´д`)┌ヤレヤレ

↓主な対応物↓

デバッグシーン作成
 昨日UPしたデバッグ画面のタイムライン表示の所で、
 再生、停止、コマ送り、等のボタンを実装したり、
 手動でタイムライン動かした時に、動きだけじゃなくて当たり判定も反映されるように。
 後、技設定が矛盾してた際の優先度の見直し(※1)等、細々と進行中。
 ※1:(例:攻撃判定の持続より総フレームの設定が短い等)

行動中の状態の追加
 自由に動けるようになるタイミング(※2)を実装したつもりで
 全然実装されてなかったので、ちゃんと実装。
 ※2:モーションは再生し続けているが、
    他の行動(移動や攻撃)を入力する事で動きをキャンセルが可能なタイミング。
    コンボによるキャンセルとは別に必要。
    この機能があると、モーションの自由度、発展性がグッと上がりますので、
    個人的には3Dアクション、格闘を作る際には必須な機能。

■技数の制限排除
 未だに通常攻撃のコンボ数、スキル数が完全固定になってたので、
 可変に対応。

■テスト用機能の修正
 デバッグ用のデモ自動スキップ機能の動作が不安定だったので修正。
 地味に根深い問題でした・・・。

他、細々とパラメータ類の修正、拡張

・・・まるで日報のようになってしまった。。。!
企業の人も日報をブログ形式(社内でのみ閲覧可能)にするのはどうだろうか(ぇ
・・・いや、規則性なくなると流石に管理する側が大変か・・・
でも遊びあるとオモロそうだなぁ(´-ω-`)

2013年6月12日 (水)

【Unity Action】 攻撃デバッグシーン ~時間経過と効果~

引き続きデバッグシーン作成中。
流石に明日作成終了は無理な気がしてきました(笑)

本日は使用している技の状況を表示するタイムスライダーの実装。
細かい部分はまだ途中ですが、

攻撃判定、軌跡表示タイミング、エフェクト表示タイミング、音、外力、
向き直り、強化、キー受付タイミング等が一目で分かるようになってます。


130612

一番上が初期状態で、何か行動をすると自動で更新されていきます。

時間経過を表すバーの色は
動作してないときは白
自動反映中は赤
手動でスライダーを動かしているときは黄色

といった感じになってます。

これで、どのタイミングで何が行われてるかは大分わかるようになりましたが、
おかげさまで細々とバグが見つかってます(;´▽`A``

バグ直しながらのデバッグシーン実装なので、
やはり時間かかりますね・・・マ、マケナイ!\(;゚∇゚)/

2013年6月11日 (火)

【Unity Action】攻撃、スキル確認&調整用シーン作成開始

攻撃、スキルの汎用化したスクリプトを元に、
色々確認し易いデバッグシーン作成を開始しました。

130611
確認用に視点とかも変えられます。

基本的には、
通常のバトルと同じように動かす事もできるし、
指定した行動のみ行う事もできる感じにする予定です。
敵とかステージの設定もリアルタイムに弄れる感じに。

で、常にキャラクターの状態を画面に表示しつつ、
実際の見た目やフラグを見ながら実装、調整をしていく感じですね。

デバッグオプションとかも諸々追加予定です。
バトル中のバグ修正とかもこのシーンが基本になりそう。
出来るだけパッと見で主要な要素は分かるようにしたいです。
(例:ここからコンボ可能、ここからキャンセル可能等)
文字列や数字だと分かりにくいので…。

とはいえまだガワを作ってる途中の段階なので、
本格的な作業はこれからです(;´д`)ゞ
機能していない部分がほとんどで、現在完成度20%程度?

上手くできれば最後まで重宝するシーンになるはず…
なんとか明後日あたりで一旦ケリをつけたい所。
※実装、確認してるうちに色々バグが見つかるので、その量次第ですかね…。

・・・しまった、攻撃の汎用スクリプト対応、敵キャラやってない。。。
プレイヤーの対応が終わったら、このシーンも含めて諸々敵用の対応しなくては…!

・・・早く素材作りたいわー 。* ゚ + 。・゚・。・ヽ(*´∀`)ノ

2013年6月10日 (月)

【Unity Action】 軌跡小話

ちょっと息抜きに、
攻撃管理スクリプトの汎用化の際に拡張した物の一つである、
軌跡話でもしてみます(見た目的にも分かりやすいですし)

前も書きましたが、現在プログラム軌跡の作成には、アセットの
「MeleeWeaponTrail」を流用して使ってます。

基本的にはそのままでも使いやすいのですが、
動きの特徴、1f遅れて生成される点や、行動のキャンセル等により、
軌跡の終了タイミングが設定し難い場合が結構あります。

要は
「軌跡がパッツリ切れて見えたり」
「綺麗な軌跡を描けなかったり」

という問題ですね。
モーションで解決できる部分は良いですが、
必ずしもそうとは限りません。

そういった問題の緩和の為に、プログラム軌跡のパターンとして、
軌跡が徐々に閉じていくフラグを追加してみたりしてます。
↓こんなんです。

130610_2

もちろん従来のままの方が良い場合もあるので、
生成する軌跡毎に、「軌跡タイプ」を設定できる感じにしてます。
その攻撃の特性にあった軌跡の生成が重要ですね。
他にも、生成毎に「軌跡のスケール調整」、「軌跡の色は武器に依存するかどうか」等、
細々とした調整もできるようにしてたりします。

もちろん見た目重視なら、専用の素材を作るのが一番良いのですが、
費用対効果を考えると色々と悩みますね。。。
当然ながらメモリの問題もありますし(◎´∀`)ノ

・・・そういえば1日で2記事は久しぶりヽ(´▽`)/

【Unity Action】 攻撃管理用スクリプト汎用化一旦完了

なんとか攻撃、スキル管理スクリプトの汎用化が一段落しました。
といっても、あくまで「現状の攻撃にのみ対応した物」なので、
当然ながら今後も随時拡張していく必要はあります(;´д`)ゞ

ちなみに、現状で一番要素の多い攻撃ですと、↓画像のような長さです。
ちょっとクラッときますね。
(※もちろんシンプルな攻撃、行動ならもっと短いですし、
   この攻撃でも配列を閉じれば1画面に収まる程度です。)

130610_1_3

とはいえ、1つの行動に攻撃判定の種類、サウンド、エフェクト、物理挙動等が
複数存在する攻撃の場合、どうしても長くなります。

今後の拡張でもっと要素も増えそうですし。。。
とはいえ、触る所自体は極端に多いわけじゃないのですが(´▽`;)

アニメーションのエディタみたいに、
タイムラインで要素を管理できれば色々見易くはなりますが、
費用対効果的に(略


これで汎用スクリプト1つ直せば全技連動して直るので、
大分修正とかはし易くなりましたし、
確認、調整作業も、プレイ中にInspecter上でパラメータを弄れば
そのまま反映されるので、前より楽になりました(≧∇≦)b

2013年6月 9日 (日)

【Unity Action】 攻撃管理スクリプト・中編

はい、汎用化終わりませんでしたorz

汎用攻撃管理スクリプトの残り作業は
・指定フレームでのサウンド再生
・バフ(自己強化)処理反映
・発生フレーム順に配列自動並び替え処理
・既存スキル、攻撃全載せ替え

といった所。
動きやらフラグやらエフェクトと、見た目部分は大体終わりました。
一部機能拡張したりして脱線したのがイケなかったのか…( ; ゚Д゚)

もう少しではあるので、今日寝るまでに終わらせたいですが、
ちょっと足出るかもです。。。

も、もうひと踏ん張りっ ヽ(`д´;)/

2013年6月 8日 (土)

【Unity Action】 攻撃管理スクリプト大改造中

現在の攻撃を管理しているスクリプトだと、
ヒットスローを絡めた場合に動作の不安定になるのと、
今後技を増やして行くにあたって、
実装の簡易化とデバッグのやり易さを考慮して
技(通常攻撃、スキル)周りの制御の汎用化が必須

と思いましたので、
技のパラメータを管理しているスクリプトを大幅に改造中です。
量産入りたいけど我慢我慢・・・!

基本的には、
「共通のスクリプトを使いつつ、Inspecter上の設定で全て完結できる」
というのを1つの目安として考えてます。

なので、今後色々な技を追加する際に、スクリプトは弄らなくて良い。
という感じに。(元々はある程度は直で書いてました…)
Inspecterの見た目も、スライドバーつけたりとか、アイコンとか色々見易く
という事もできるとは思いますが、費用対効果的に低そうなので、
そういった見た目部分は保留(どうせ自分一人しか弄らないですし・・・)

とはいえ、

技毎の属性や威力、硬直、浮量、ノックバック量、軌跡の発生や色や持続、ヒットスローの時間やレート、
攻撃判定の発生、持続、サイズ、アタッチノード、位置、回転、当たった際の振動の強度や時間、
キャンセル可能タイミング、ディレイ受付時間、重力や移動地変更、地上と空中の分岐、
多段攻撃設定、地面設置後の分岐、エフェクト発生フレーム、位置、ペアレント設定、
近距離、遠距離攻撃、アニメーション設定、判定に依存しない画面揺れ等々…
全部書くときりがないので以下略


・・・つまりは要素が多い!  (ノ`Д´)ノ彡┻━┻

というわけで、対応にはもう少々時間かかりそうです(現在6~7割くらい)
単純に1モーション、1エフェクトとかそういう単純な物でものなら
楽ですが、まぁそれだと出来る事が限られてしまうので仕方ないですね…。

とりあえず明日いっぱいで汎用化は終わらせておきたい…けどどうなる事か(;´д`)ゞ
ずっと作業してるわけでも無いですしね(笑)

ちなみに、スクリプトの汎用化できたら、攻撃実装、調整用のシーンを作る予定です。
やはり動かしながら確認、設定、調整できないとめんどいですしね。
こちらは脳内で設計を思案中レベル。

今日は疲れたので湯船にノンビリつかって休憩タイムに入ります!
ε=ε=ヾ(*゚ー゚)シ |風呂

2013年6月 7日 (金)

【Unity Action】 ボス出現時の修正(1fズレ、自動文字送り処理変更とか)

最近珍しく更新が続いてますヽ(´ー`)ノ

というわけで、今日は基本的にボス出現時周りの修正作業してました。
大きな物は無いですが・・・(;´д`)ゞ

------------------------------------------------------------

・ボスカメラへの切り替わりが1f遅かった
  ⇒これは企業でのゲーム製作現場でもよくありますね(偏見
   カメラの切り替えと、そのほかの処理がちょっとずれると
   起こります。
   処理順を整理して修正。

・ボスカメラ後、戦闘に入るとボスが着地アニメーションをしてた
  ⇒ボスのフラグの初期化がおかしかったので修正。

・ボス名の表記がスコアUIに被る
  ⇒めっちゃ被ってました…。
   ボス名のUIを変更して被らないように修正。

・ボス出現警告UIの解像度が足りない
  ⇒汎用フォントだとさすがに無理があったので、
   専用素材に変更。ゲームオーバーと同じような作りに。
130607_1

・ボス演出のせいでコンボ数が必ず途切れてた

  ⇒イベント中はコンボ判定の時間が経過しないように変更。

・ボス名の表示処理(1文字づつ表示される処理)を変更
  ⇒今までchar[]に文字列を入れ込んで、
   1文字づつ足していく形にしてましたが、
   「Substring(,)」で簡単に行けるやんけ、と気付き処理を変更。
   基本的には↓な感じ。

  string _text = "表示したい文字列";
 int _length = 0;    //現在の文字の表示位置
 while(_text.Length>=_length&&isEvent){  //表示しきったら終了orデモスキップしても抜ける
   UILabel.text = _text.Substring(0,_length);//UIラベルの文字変更
   AudioSource.PlayClipAtPoint(SE,Pos,SEVol);//サウンドを鳴らす必要があればサウンドも
   length++;    //次の文字へ
   yield return new WaitForSeconds(0.03f); //1文字毎のウェイト設定
 }

   処理的には汎用的に使えるので、
   バトル開始前のデモもこちらの処理で自動文字送りを反映しました。
   ↓のとこですね。
130607_2
  尚、↑画像のようなテキストの場合の
  クリック時の挙動としては、一般的?には
  「メッセージが表示しきってない状態」 ⇒ 表示中のメッセージを全表示
  「メッセージが表示しきってる状態」   ⇒ 次のメッセージへ

  といった感じで、挙動を分ける必要がありますので注意。
  このあたりはメッセージ表示中かどうかのフラグを絡めて分岐させましょう。
  
------------------------------------------------------------

と、いった感じです。
この調子で途切れないように頑張ろう(≧∇≦)b

2013年6月 6日 (木)

【Unity Action】ゲームオーバー関連画面終了

なんとかゲームオーバー画面と、
それに絡む画面のフローの実装が終わりました。

色々動かしてはいますが(画像じゃ分からないですが…)、
まぁ普通に地味な画面ですね。
重要な画面ではありますが、
特に見どころはありません(笑)
130606

次はボス出現時のUI調整と、
ボス出現デモ周りで処理的に怪しい所が数点あるので
そちらを修正予定。

それが終わったら攻撃、スキル周りのスクリプトを
全面的に見直さないとですかね…。

現状のままだと構造的に
ヒットスローに対応しきれない事に気づきました(;つД`)

色々進んできてはいますが、
まだまだやりたい事が山積みです( ; ゚Д゚)がんばる。

2013年6月 5日 (水)

【Unity Action】 ゲームオーバー画面作成開始

現在ゲームオーバー画面素材作成&フロー実装中。
遅くとも明日中には一段落しそう。

今回UI素材はMaya上で作成(↓Maya画像)。
130605

やっぱり動きは3Dツール上で作る方が楽です…(´-ω-`)
Unity上だとモーション付け難いです…ハイ。
とはいえ実装、調整の手間等も含めると
どっちがいいかは一概には言えません(笑)
やはりケースバイケースですかね(≧∇≦)b

一応は文字毎に別々に動かしてますが、
メッシュ毎にモーションを付けるとドローコールが増えてしまうので、
1メッシュとしてまとめて、ボーンで動かしてます。
(ウィンドウ、背景はイメージを掴む為のダミー)

2013年6月 4日 (火)

【Unity Action】 敵への向き直り処理修正

今日は時間があまり取れなかったので
ちょっとした処理の修正してました。

具体的には、攻撃時の相手に対しての向き直り処理の不具合修正です。
現在の向き直りの基本的な概念は以下な感じです。
--------------------------------------------------------------
■ターゲットの有無判別、向き直りパラメータ参照
 一定距離以内に敵や破壊オブジェクトが存在したら
 指定時間の間、指定角度で向き直る(攻撃毎にパラメータ有り)

■向き直りの優先度
 基本的に最も近い対象に対して向き直る。
 但し、優先度は「敵<破壊オブジェクト」。
 一定距離内であれば、破壊オブジェクトよりも敵を優先してます。
 例外として、方向キーをオブジェクト側に入力している場合は
 その方向(指定角度)のみ参照する為、
 敵が近い場合でもオブジェクトを狙う事も可能。

■向き直りの例外
 コンボ中は攻撃毎に向き直り判定は行わない(場合によっては行う例外処理も)
 但し、敵が死亡したり、ターゲットになっているオブジェクトが
 破壊された場合は攻撃毎に新たなターゲットを検索する
--------------------------------------------------------------
※判別距離は現在は固定ですが、
 今後判定距離自体も攻撃側に持たせる必要がありそうな気も。

で、
・ターゲットまでの距離、優先度関連が正しく動いてなかった
部分を修正してました。

あー、そういえば相殺可能な飛び道具がある場合、そのあたりも
向き直り対象にしないとですかね・・・まぁそちらは追々で。

基本、スマホは操作性がアレなので、
向き直り具合の方針としては
-----------------------------------------
方向キー使わなくても戦えるが、
ちゃんと使った方が有利。
-----------------------------------------
くらいで考えてます。

この辺りは後半まで調整が必要ですね(´▽`;)

明日からゲームオーバー画面関連のフローの
本格的な実装に移る予定です。

・・・多分!

【雑記】 カレンダー変更してみた

ブログのカレンダーを、
前月も参照できるカレンダーに変更してみました。
というか標準のカレンダーでその月しか参照できないってどうなんだ・・・( ; ゚Д゚)

ちなみに
ココログカレンダーPlus
ってヤツを使わせて頂いてます。

2013年6月 3日 (月)

【Unity Action】 ヒットストップ(スロー)修正

以前作ってたヒットストップ(スロー)の処理に
細々と問題があったので数点修正したりしてました。
主な点は以下。

--------------------------------------------------

①どの攻撃でも一律フレームでストップ(スロー)になってた

②fpsによってストップ(スロー)の時間が変化してしまってる


③ストップ(スロー)で処理がずれた分の補正が正しく効いていない

--------------------------------------------------

以下詳細。

①どの攻撃でも一律フレームでストップ(スロー)になってた
  今までは手抜きで、ダメージを受ける(与える)と一律のフレームで
  ヒットストップがかかるようになってたのですが、
  やはり製作が進んでくると、
  「この攻撃はストップじゃなくてスローにしたい」
  「この攻撃は特別に長いフレームストップしたい」
  「この攻撃は短く、もしくはストップしないように」

  等、色々やりたくなってきます。
  と、いう訳で、
  攻撃を管理しているプレハブに
  攻撃(判定)毎にストップ、スローの値を追加し、
  そちらを参照するように変更しました。

②fpsによってストップ(スロー)の時間が変化してしまってる
 今まで、「xフレームの間ストップ/スロー」という処理になってしまってたので、
 「x秒間ストップ/スロー」という処理に修正。
 可変フレームなのでまぁそうですよね…。

③ストップ(スロー)で処理がずれた分の補正が正しく効いていない
 
たとえば、
 ・ヒットストップにより、軌跡エフェクトが、振り切る前に消えてしまう、
 ・多段攻撃で見た目と判定がずれる

 等の問題です。
 

 「攻撃したプレイヤー、攻撃を受けた敵の動きは止めるが、
  その他の敵やエフェクト等の要素は止めない」


 という処理になっているので、
 TimeScaleを使えない事から、地味にメンドイです。
 こちらはストップ(スロー)でずらした分のフレームを保持しておく部分に
 不具合があったので修正&その値のチェック場所を数点追加。
 例:剣軌跡にはMeleeWeaponTrailを使ってますが、ストップ(スロー)した分だけ
   Emitをfalseにするまでの時間を遅延させる。




…とまぁ、既存の実装項目でも色々と改良をしていってます。
……この他にも今のうちに直しておきたい所多いなぁ…(´-ω-`)

2013年6月 2日 (日)

【Unity Action】 ポーズメニュー怖い(Time.timeScale = 0 関連の話)

と、いう訳で、ポーズメニューの処理を一通り実装してみました。
久しぶりに動画でペタリ(ポーズ部分)。

ちょっと見た目が安いので、追々見た目は調整予定ですが、
処理的には一段落です。

今までは、バトル中に装備変更とかできてましたが、
本来は想定してない仕様なので、色々シンプルになってます。

で、ポーズメニューで出来る事自体は少ないので、
サクッとできるかなーとか
甘いこと考えてましたが、
思いの他手こずりました…。

ポーズメニューには前提として、
「Time.timeScale = 0;」で時間の経過を止める
事をしています。
そうしないと、動くすべての物に対して静止処理が必要になり、
大変な上にバグが山のように出る事が懸念されたため。

で、今回問題になったのは、おおよそtimeScaleが0なのが原因です(笑)

以下、引っかかった点等のメモになります。


■timeScale0だとアニメーションが再生されない

  これは「前の記事」でも問題にしてましたが、
  時間が静止しているので、
  animation.Play("xxx")や、iTween.xx等はまともに機能しません。
  なので、動かすオブジェクトに対して、
  自力で時間経過をお知らせする必要があります。

  
  animation["アニメーション名"].time += 経過時間;

  とかですね。
  経過時間の取得は、「前の記事」のコメントにて助言頂いた
  やり方で取得するようにしました。

  併せて、そのスクリプトは、ポーズ中のみ機能さるようにしましたが、
  スクリプト実行後即上書きしたdeltaTimeを使用すると、
  数値が不安定でしたので、若干バッファを入れたりしてます。

■アニメーションの終了の取得
  当然ながら、timeScaleが0だと、自動でモーションは終わってくれないので、
  自力で取得する必要があります。
  if(!animation.IsPlaying("アニメーション名")
  で、再生されてるかどうか判別可能。
  モーションの長さは
  animation.["アニメーション"].length;
  で取得可能。

  その辺りを元にモーションの終了を取得しましょう。
  ただ、while等でループしている場合、連続で同じモーションが
  呼ばれると、処理が重複してしまう可能性があるため、
  それ+αの判別を必要に応じて用意する必要も。

■アニメーションイベントが取得されない
  timeを主導で加算してる関係で、
  アニメーション自体にイベントを仕込んで関数を呼べないようです。
  なので、animation["アニメーション名"].time で現在の時間を参照して
  必要に応じて関数を呼ぶ等が必要でしょうか。

■「AudioSource.PlayClipAtPoint()」やNGUIの「Button Sound」が使えない
  timeScaleが0の場合、
  PlayClipAtPoint()やButton Soundを使用してもサウンドが再生されません。
  自力でAudioSourceの付いたオブジェクトを用意してそこに対して
  PlayOneShot等で再生しました。

■ボタンの封印
  これはポーズ画面に限った事じゃないですし、
  TimeScaleも関係ないですが一応。
  コントローラー操作と違い、スマートフォンだと
  同時、連続でタップできてしまうので、
  その時々でちゃんとボタンのColliderのON/OFFを
  切り替えましょう。

■NGUI(Tween)は案外動いた
  TimeScaleが0でも、Tweenxx系はちゃんと動いてました。
  ……PanelのAlphaくらいしか使ってませんが。



といった感じでしょうか。
書くと一瞬ですが、各所で色々な試行錯誤が行われてます(汗
まだまだ勉強が足りません…( ̄Д ̄;;

2013年6月 1日 (土)

【Unity Action】 破壊オブジェクトからのドロップアイテム

昨日の記事にも書いたように、
破壊オブジェクトからのアイテムドロップ作ろうと思ったのですが、

まず落とすアイテムのネタどうしようと小一時間
手抜きでAssetStoreを眺めること30分

結局回復とお金はあまり(無料で)良い物が見つからなかったですが、
スコアは安直に「Gem Shader」のAssetを使わせて頂く事に。
まぁお金に関しては、マーク等を他のUIと合せないといけないので、
どちらにしても作らないとです (。・x・)ゝ

と、いうわけで回復とお金のモデル、UI、テクスチャをモリモリと新規作成。

Unity_action_2

結局全体的に無難な選択になりました(笑)
アップで見るものではないのでやや適当気味ですゴメンナサイ(;つД`)

ドル袋は、そのままだと分かりにくかったので
コインをやや溢れさせました( ; ゚Д゚)
紐の意味無いとか言っちゃダメ 。* ゚ + 。・゚・。・ヽ(*´∀`)ノ
そのうち紐緩めくらいはした方がいいかも。

で、作った素材をUnityに入れ込んで、簡単なエフェクトを追加。
タイプ別に記号的に色分けしました。

Unity_action__2


で、
破壊オブジェクトから確率で発生させたり、
出現、ループアニメーション作ったり、

出現エフェクト、取得エフェクト作ったり、
取得処理、取得ディレイ設定等々を
地道に作ったり実装したり、
バグを出したり直したり、

TV見ながらお茶飲んで休憩とかしたら…

なんとかオブジェクトを壊して出現したアイテムを…
Unity_action__3

拾って効果が反映されるように!(回復、お金も)
Unity_action__4

と、なんとか一通りの要素は実装できました。
実際のゲーム性には大きく影響しない要素ですが、
これでオブジェクトを壊す意義が出たかなーという感じです。

今回は一気に作りきったのでちと疲れました…今日は寝ます(ρw-).。o○ zzz

追々余力があればアセットのGem Shaderのヤツは他のネタに
変えたりする…かもしれないしそのままかもしれない…。

« 2013年5月 | トップページ | 2013年7月 »

Twitter等

  • にほんブログ村 ゲームブログ ゲーム制作へ

メールフォーム

  • 直接コンタクト取りたい方はこちらからどうぞ

サイト内検索
ココログ最強検索 by 暴想