こにゃにゃちわ=^_^=
最近やる事があんまりない、いや滅茶苦茶あるんだけど気が向かなくてぼ~~っとしてたら、なんか記事が大量に増産されてやんの。
まあでも、少ないのはちょっと問題だけど多い分には問題ないだろ、なんなら一日3件くらい登校してやりたい位だ(書くことが無いからできないがな!!!!!)
という訳で、更新日記。
前回は、ルートテーブルのjsonを書き綴ったところ辺りだったか。
まずロビーを少し装飾。パーティクル適当に浮かしておいた(負荷?知らんな)
あと、コマンドの方の移植の状況ね
こんな感じだった基盤部が
こうなりました。
・・・
いや端折り過ぎ!!!!!
まあ、実際これ一つで全てを管理する方式に変えた感じなんですけどね。そのほうがとっつきやすいからね
さっきの画像の手前に見えるのが、
こんな具合になった・・・・
って言えばわかるでしょう!ね!!!(圧)
一応、environment.mcfunctionとしてそういったシステム総合を統括するfunctionにて、どれだけ実装したんだって話なんだけど、
ざっといえば、新規にロビーに装飾をするためのコマンド、特定アイテムを権限者がなげたときの特殊挙動、暗視効果、レッドストーンブロックに乗ったときの処理、ロビーから待機場所への転送処理、場外処理、プレイヤーがサーバーに入ったときの処理、レベル管理、使用禁止アイテムのブラックリスト化、ゲーム実行後の初期化処理。
あといつぞやにはなした開発一時中断中のNekoyama Server(仮称:非合理的世界。サーバー)で実装していた武器を流用出来ないかと思って、今のところ使い道は無いけどMagicPoint、攻撃し続けるとステータスが一定時間上昇するオーバードライブシステム(FF13のブレイクみたいな奴。ただ、敵のステータスが下がるのではなく自身のステータスが向上するのだが。)とかも実装したりしてた。
あと、問題はミニゲーム本体ね。
一応、変換プログラムを使ってバンバン移植しようと考えているんだけど、Java版ならではの手法も色々あるから変換プログラムがどこまで効果あるかが未知数なところ・・・
変換プログラムは、そもそも無くても移植できなかったわけじゃないんだよね。単に趣味で当時シェルスクリプト書いてやりたかっただけ。(後々助言をもらってPythonで書きなおす事になるのだが。)
まあ、PythonのをまたPythonでそのうち書きなおすだろうな。ってところ
それは置いといて・・・
PON
からの
PON
とまあ、s __debug__から__switch__に受け渡して、何かしらのトリガーで__debug__の方を操作することでswitchが管理し持続してfunctionを実行するという仕組みをあらかじめ置いておいたので、超手軽に持続実行が必要なfunctionを管理する事が出来るようになった。
ミニゲーム開始時のステージ構築行程、
たったこの二行。s snのスコア(ミニゲームの時間軸管理用スコア)を実行中調整して、ステージ構築中は流れを停止させることも考えたんだけど、どうせステージ構築には200tick弱で終わるし、五秒間のカウントダウン時間がありゲームスタートする前に確実に処理が終わるので、まあいっかと放置。
という訳で、現状ではミニゲーム動作の基盤、ゲームスタートと終了の処理まで実行できるようになった。
変換は通すけど、基本的に今回作ったtest_cvt.mcfunctionに則って作っていこうかな。
activateFlagによって__switch__みたいに管理するんだけど、こっちはsとs_bupの二重にして何かしら問題が起きたときに実行維持できなくなるのを防ぐようにして、このfunctionを実行し続ける仕組み。
ステージ構築して、ゲームによっては初期設定して、カウントダウンして、始まったらs snを1000にセットして、本回路中の処理も加えて、終了トリガー(プレイヤーが最後の一人になった、チームが1つのみ、制限時間経過後エトセトラ)によってゲーム終了(s __debug__を1に設定するだけ)という流れ。
あとは微調整しながらミニゲーム自体を移植させていけば、いよいよ大詰めってところだね。
さて、こっからどう開発するか。
0
この記事へのコメント