進捗 ゲームシステム編 #01

 obake   character   progress 

作業を再開

ほぼ二ヶ月触ってなかったプロジェクトなので完全に仕様とか忘れた。

しかしブランク明けたら GMS1.4 がサポート終了期限も即来ちゃって、GMS2.0 の購入をどうするか考えなければいけなくなった。

GMS 自体は慣れてきたので問題無い。CF25 系の作り方が懐かしい気もするけんど、だけどオラァもう CF25 で作りたくねぇだよ。簡単なアプリで PC 用なら CF25 で良いけど、エクスポート機能が段違いの性能なので GMS で作る方が安心感あるあるある。

エクスポートに関してはだいたい三倍位ちがう＞安心感と安定感。

あとは CF25 だとボーンアニメーションが Spine 使えないのも痛い。F3 出てもアニメーションで Spine 系が標準サポートされない場合はしばらくスルーもあり得る。Defold も良いのだけど、Lua Script の弱点というかデータ構造系が弱いしバイナリオペレータも標準には無い。

GMS／GML が地味に良い点って、バイナリもデータ構造も基本は抑えているし動作も安定的な所だと思う。

開発再開メモ

変数や基本的なゲーム動作仕様についてはドキュメントがあるのでそちらを見る。

ゲームエンジンは基本的な動作部分はほぼ安定的で、どうも危なっかしい処理が多々あるけれど一応クラッシュしない。エクスポートもできる。

グラフィックスに関しては仕上げ以外だいたい目処付いた。量が多すぎてキャラクタを担当してくれた星少年の作業を脚引っ張りまくった。キャラクタはせめてこの半分にしとけ馬鹿、ということらしい。

最終版 GMS 1.4.9999 へアップ

制作環境を GMS1.4 の最終版へアップ。

懸念だった Android と HTML5 など外部出力系も合わせて動作確認したが問題なし。HTML5 でビルドしても動かなかった去年と違い、地道なアップデートのおかげで最後は動くよう戻ってくれた。HTML5 できちんと動くのはブログ的にもありがたい。

しかしいよいよ 1.4 系にはもう未来が無い。

1.4.9999 にはバグフィックス含まれているが GMS2.0 と共通化されている部分が主なフィックスだったので、 GMS1.4 としての完成度うんぬんよりも 2.0 へ繋ぐ存在としての 1.4 がここで切られたのだという印象のアップデータ。

GMS1.x シリーズは開発元の YoYoGames にとって大きな変化をもたらした存在だった。PC 以外のバイナリを出力するための外部出力機能は GM8 から開発の試みがあったようだが、 Clickteam と同様の問題を抱えていた。それが Windows PC 用のライブラリ、いわゆる MS ライブラリに依存した拡張機能。これが原因で簡単に移植できない仕組みだったが、モバイルやコンシューマ機で MS が不本意な撤退を余儀なくされるなか Windows PC あるいは PC 自体がモバイル繁栄の影に覆われて市場が狭くなって行った。Windows 以外でも動く共通化されたゲーム用のライブラリ構築が必要だったのだけど、スクラッチ＆ビルドで統合開発環境を新たに作るためには会社の規模が小さい YoYo では不利だった。GM シリーズとしての知名度を活かしながら Studio としてバージョンを一から出直しにしたのは、覚悟をもって GMS という製品の開発に取り組んだその意気込みの表明だったのだと思われる。

Clickteam が今取り組んでいる F3 は製品発表の時期すらいまだ表明できない程に開発がナーバスになっているけれど、元来やろうとしていることと会社の規模が釣り合わないから当然で、開発後も相当苦労することになる気がする。F3 でこれだけ拗らせた実績があると例えば F4 とか？更に次・次世代は想像すらできなくなってくる。

乗り越えても次々とやって来る大きな変化の波、五年周期くらいでスクラッチ＆ビルドを繰り返す企業体力が無いと、製品や開発会社は淘汰される懸念がある。GMS は設計とかコンセプトはかなり良かったのだと思うし、2.0 リリースも無事果たし旧製品はディスコンとなった。これが健全な流れであり、これが果たせないと将来が無い。2.0 になっても GMS は GMS なので買って損は無し。そして 2.0 は今より更にきっと良くなる。

しかし今は買わない。後もう少しだけ 1.4 で頑張る。

メモ

作業中

Scripts +–+ GameEngine +–+ EV_Step +–+ Init_VKS +–+ Create_GTimeBar

Scripts +–+ GameEngine +–+ Draw +–+ Draw_ToPBaR +–+ DR_GTimeBar

TopBAR などゲーム用ユーザインターフェース一般は .vks のイベントから必要なオブジェクトを作成している点に注意。

※すべて .ev からオブジェクトを作成しているわけではない

変更点

Scripts +–+ GameEngine +–+ EV_Step +–+ PickAroundFunc

PickAroundFunc 周辺の処理を変更。機能自体を無効にしても良いかを検討。あるいはフラグでオンオフ切り替えできるようにする。

現在の内部バージョンは 0070g なので、0071 を目指して機能を追加。

ev.Ct_TimeBar と ev.Ct_TimeBFlg の追加

ゲーム中の時間計測は Step を元に割り出している。

いわゆるフレームベースで作っているのだが、正確に時間を計測できないけれど処理落ちしてもゲーム動作がスローになるだけ。実際に HTML5 での動作はなんかもっさりしているのでこれだと時間の流れが遅い。

Room のスピードは 30 に設定されている。これは一秒が 30 FPS 、ゲーム開始から Step をカウントしているので、総 Step 数を Room Speed で割れば「経過秒」に変換できる。600 Steps の場合は約 20 秒って具合。もちろん全然正確ではないし厳密な精度を求めていない。

  • この方式だと一分は (30fps × 60sec) ＝ 1,800 steps である。

  • 一時間は (30fps × 60sec) × 60min ＝ 108,000 steps である。

Scripts +–+ GameEngine +–+ EV_Step +–+ UI_Timer

スクリプト UI_Timer は.ev オブジェクトの Step イベントで実行されている。やっていることは Step をカウントして、ルームスピードで割ってるだけ。ミリ秒以下の精度は無視されている。

ev.CtTimesN はゲーム開始後の総ステップ数が格納されている。

ev.CtTConvM と ev.CtTConvS という各インスタンス変数にそれぞれ経過分／秒が記録されている。

追加 DR_GTimeBar

Scripts +–+ GameEngine +–+ Draw +–+ DR_GTimeBar ユーザ定義関数を追加。

ev.CtTimesN にアクセスして総ステップ数を取得し、タイムリミットの設定に応じてバーの長さを動的に変更して見せるための仕掛け。

Objects +–+ GameEngine +–+ general_ui +–+ gtime_bar オブジェクトから呼び出される関数。

ゲーム中タイムリミットの設定

Objects +–+ GameEngine +–+ ev オブジェクトのインスタンス変数

  • TimeOverGE_M

  • TimeOverGE_S

この二つの変数に値を入れて設定できる。

ev.TimeOverGE_M に分を入れて、ev.TimeOverGE_S は秒を入力。

上記数値を計算に使ってリミットとなる値を求め、その計算結果が格納されているのが ev.TimeOverLimStp 。

  • TimeOverLimStp

このような構成になっている。

これら変数を用いて毎回バーの長さを計算して Draw している関数が DR_GTimeBar である。働き者。

計算自体は簡単だけど、文章にまとめるとそれなりにめんどくさい仕組みっていうのが分かる。

Create_GTimeBar() ユーザ定義関数の追加

Scripts +–+ GameEngine +–+ EV_Step +–+ Init_VKS に新規オブジェクト作成命令の追加。

問題点など

ビデオカードの情報を取得する際になにかエラーが発生している？

情報の取得に失敗しているケースがまれにあって、起動時に画面サイズなどを自動決定する際にこれが原因ですこし不具合が起こる。

デバッグ用に show_message を入れておいたが、入れた場所を忘れたのでバグが発生するのを待ってるところ。

メラーメッセージを見ればどこに仕込んだものかすぐ分かる。まだバグは発生してないので不明。




次へ

前へ