ここ最近の改善の報告とCoRのβ移行に向けた課題など
投稿者: akasata 投稿日:2017/04/24 22:56
Rmakeのご利用ありがとうございます!
運営のあかさたです。
前回の報告から間が空いてしまって申し訳ありません。。。
個人的な事情でバタバタしていました。
バグ修正
改善
CoRのβ移行に向けた課題
CoRもaoihikawaさんのころたまEXのようなかなり込み入ったゲームも動くようになり、まずまずの完成度になってきたと思います。そろそろ、α版からβ版に移行するときが近づいているのかな、と。ただ、以下の問題が残っているので、すぐにというわけにも行かないのではありますが。。。
※ 現状のCoRもシューティングのような重なりを検出するような当たり判定はかなりうまく動いているのですが、(RPGのプレイヤーとNPCがぶつかったときのような)衝突時にめり込まないケースについて、いい感じのインタフェースと構造を持っているか検証できていなかったりします。この辺が問題なければ、2Dゲームに関しては大体どんなものでもいい感じに扱えるようになると思っているのでその検証を早めに行いたいと思っています。
なかなか改善が進みませんが、引き続きよろしくお願いします!
ツイート
運営のあかさたです。
前回の報告から間が空いてしまって申し訳ありません。。。
個人的な事情でバタバタしていました。
バグ修正
- 2017/03/26対応完了 CoRにて、シーンを複数回読み込んだとき、音楽素材が制限内なのに読み込めない問題が発生していた
- 2017/03/29対応完了 HTML5 キャラクタエディタにて、ポイントが0の場合にレベルを上げることができない
- 2017/03/29対応完了 HTML5 キャラクタエディタにて、編集と保存を繰り返すと設定数値がおかしくなる
- 2017/03/30対応完了 ゲームデータをロードする際、データに「β」「ω」などの特定の文字を含む場合、ロードが失敗する
- 2017/04/07対応完了 アクティビティフィードを連続して送信しようとするとゲームがフリーズする
- 2017/04/10対応完了 素材共有サイトにて、シーンが読み込めない
- 2017/04/12対応完了 CoRのエンディング画面にて音楽が流れない
改善
- 2017/03/26実施 CoRにて、put_mapメソッドのエラーログをわかりやすくしました
- 2017/03/30実施 RmakeのSSL証明書を更新しました
- 2017/04/11実施 CoRに以下の既存のRmakeの関数を追加しました
- loadGameData, saveGameData, removeGameData
- updateブロックのみで呼び出すことができます
CoRのβ移行に向けた課題
CoRもaoihikawaさんのころたまEXのようなかなり込み入ったゲームも動くようになり、まずまずの完成度になってきたと思います。そろそろ、α版からβ版に移行するときが近づいているのかな、と。ただ、以下の問題が残っているので、すぐにというわけにも行かないのではありますが。。。
- 汎用的に使えるセーブ・ロードの仕組み
- RPGタイプの当たり判定(※)
※ 現状のCoRもシューティングのような重なりを検出するような当たり判定はかなりうまく動いているのですが、(RPGのプレイヤーとNPCがぶつかったときのような)衝突時にめり込まないケースについて、いい感じのインタフェースと構造を持っているか検証できていなかったりします。この辺が問題なければ、2Dゲームに関しては大体どんなものでもいい感じに扱えるようになると思っているのでその検証を早めに行いたいと思っています。
なかなか改善が進みませんが、引き続きよろしくお願いします!
コメントする
コメントするには、ログインする必要があります。
コメント一覧
改善お疲れ様です~
ご報告ありがとうございます。
検索機能を復旧しました。
nicovideo記法ですが、ニコニコ動画がhttps対応(サイト通信の暗号化)をしていないため、サイトリニューアル前のβ公開時当初から動作せず、また、Rmake側の問題ではないため対応できない状況になっています。
(さすがにこれだけ大手のサイトでhttps対応していないのもおかしいと思うので、近いうちに対応されるんじゃないかと期待していますが・・・)
ニコニコ動画がhttps対応するまでは、youtubeなどをご利用いただければと思います。
下記ページの「既知のバグ」も参照してください。(pixivは最近https対応したため、pixiv記法は正常に動作しています。)
βテストについて
https://rmake.jp/blog/@akasata/7955
よろしくお願いします。
検索機能を復旧しました。
nicovideo記法ですが、ニコニコ動画がhttps対応(サイト通信の暗号化)をしていないため、サイトリニューアル前のβ公開時当初から動作せず、また、Rmake側の問題ではないため対応できない状況になっています。
(さすがにこれだけ大手のサイトでhttps対応していないのもおかしいと思うので、近いうちに対応されるんじゃないかと期待していますが・・・)
ニコニコ動画がhttps対応するまでは、youtubeなどをご利用いただければと思います。
下記ページの「既知のバグ」も参照してください。(pixivは最近https対応したため、pixiv記法は正常に動作しています。)
βテストについて
https://rmake.jp/blog/@akasata/7955
よろしくお願いします。
また報告です。
CoRのゲームでソースファイルを読み込んだ時、実行するシーンが今までに実行したシーンと同名の場合処理が行われません。
再現ゲームID:30838
宜しくお願いいたします。
CoRのゲームでソースファイルを読み込んだ時、実行するシーンが今までに実行したシーンと同名の場合処理が行われません。
再現ゲームID:30838
宜しくお願いいたします。
ご報告ありがとうございます!
同一のシーン名が複数ある場合は、開始するシーンが特定できなくなるので動作しないのはある程度やむを得ないかなと思いますが、エラーログとかを出したほうが良さそうですね。
できるかどうかちょっと検討してみます。
同一のシーン名が複数ある場合は、開始するシーンが特定できなくなるので動作しないのはある程度やむを得ないかなと思いますが、エラーログとかを出したほうが良さそうですね。
できるかどうかちょっと検討してみます。
ご報告ありがとうございます。
サーバ側の設定で読み込めなくなっていたようです。今は読み込めるようになっているので、一度ブラウザのキャッシュを削除してから再度お試しいただけますでしょうか。
サーバ側の設定で読み込めなくなっていたようです。今は読み込めるようになっているので、一度ブラウザのキャッシュを削除してから再度お試しいただけますでしょうか。
ささやかながら、
期待&応援しております。
こちらからも
また、何かありましたら
よろしくお願いいたします。
期待&応援しております。
こちらからも
また、何かありましたら
よろしくお願いいたします。
旧CoRの方に実装されておりました、
オブジェクトの円形当たり判定は
実装可能でしょうか?
急を要するものではありませんが、
ご検討頂けましたら幸いです
オブジェクトの円形当たり判定は
実装可能でしょうか?
急を要するものではありませんが、
ご検討頂けましたら幸いです
円形の当たり判定はあると良さそうだと思ったので、collision_circleメソッドを追加してみました。
詳細は以下をご参照ください。
https://github.com/akasata/cor/blob/master/doc/references/rmake/physics.md#collision_circleメソッド
ついでにお遊びでサンプルを追加してみましたw
https://rmake.jp/games/30765/cor_example
よろしくお願いします。
詳細は以下をご参照ください。
https://github.com/akasata/cor/blob/master/doc/references/rmake/physics.md#collision_circleメソッド
ついでにお遊びでサンプルを追加してみましたw
https://rmake.jp/games/30765/cor_example
よろしくお願いします。
まさかの、早急なご対応
ありがとうございます!
サンプル、
さりげなく、ずっと眺めていられるような
奇妙な面白さがありますね、、、(w
ありがとうございます!
サンプル、
さりげなく、ずっと眺めていられるような
奇妙な面白さがありますね、、、(w
また、追加要望なのですが、
スプライトの回転時、
中心点となる場所を
任意に指定することは可能でしょうか?
また、スプライトの回転時、
スプライトの移動と同様に、
当たり判定もリンクする形で
回転させることは可能でしょうか?
ご都合のいいときにでも
ご検討頂けましたら幸いです
スプライトの回転時、
中心点となる場所を
任意に指定することは可能でしょうか?
また、スプライトの回転時、
スプライトの移動と同様に、
当たり判定もリンクする形で
回転させることは可能でしょうか?
ご都合のいいときにでも
ご検討頂けましたら幸いです
さらに追加です
現在、スプライト同士の当たり判定処理時
自動物理演算によって
両方のスプライトの動きが変化しますが
片方のスプライトはその場に固定させ
衝突しに行ったスプライトのみ
動作を変化させる、ということは
可能でしょうか?
ご検討頂けましたら幸いです
現在、スプライト同士の当たり判定処理時
自動物理演算によって
両方のスプライトの動きが変化しますが
片方のスプライトはその場に固定させ
衝突しに行ったスプライトのみ
動作を変化させる、ということは
可能でしょうか?
ご検討頂けましたら幸いです
>片方のスプライトはその場に固定させ
>衝突しに行ったスプライトのみ
>動作を変化させる、ということは
>可能でしょうか?
>
こちらはmovableメソッドを使えばできます。ドキュメントに載せていなかったので、以下に追記しました。
https://github.com/akasata/cor/blob/master/doc/references/rmake/physics.md#movableメソッド
下記サンプルでも使用しています。
CoRサンプル - ジャンプアクションゲーム基本形
https://rmake.jp/games/30469/cor_example
>衝突しに行ったスプライトのみ
>動作を変化させる、ということは
>可能でしょうか?
>
こちらはmovableメソッドを使えばできます。ドキュメントに載せていなかったので、以下に追記しました。
https://github.com/akasata/cor/blob/master/doc/references/rmake/physics.md#movableメソッド
下記サンプルでも使用しています。
CoRサンプル - ジャンプアクションゲーム基本形
https://rmake.jp/games/30469/cor_example
>スプライトの回転時、
>中心点となる場所を
>任意に指定することは可能でしょうか?
>
原点を中心か左上で想定しているので、これはちょっと難しいかもしれません。
ただ、(追加したばかりの機能ですが)スプライトの親子関係を使ってみるという手はあるかもしれません。
(透明の親を作って、ずらした位置に子を配置して親を回転させる・・・という感じです。)
スプライトの親子関係について
https://github.com/akasata/cor/blob/master/doc/references/rmake/sprite_parent_children.md
CoRサンプル -親子関係テスト
https://rmake.jp/games/30797/cor_example
>中心点となる場所を
>任意に指定することは可能でしょうか?
>
原点を中心か左上で想定しているので、これはちょっと難しいかもしれません。
ただ、(追加したばかりの機能ですが)スプライトの親子関係を使ってみるという手はあるかもしれません。
(透明の親を作って、ずらした位置に子を配置して親を回転させる・・・という感じです。)
スプライトの親子関係について
https://github.com/akasata/cor/blob/master/doc/references/rmake/sprite_parent_children.md
CoRサンプル -親子関係テスト
https://rmake.jp/games/30797/cor_example
大変お忙しい中、
対応策の追加、および情報提供
ありがとうございます
ご連絡頂きましたドキュメント等にて
試してみたいと思います
対応策の追加、および情報提供
ありがとうございます
ご連絡頂きましたドキュメント等にて
試してみたいと思います
ご連絡頂きました情報を元に
手を加えてみたところ、
外見上の動作は、大体想定どおりになりましたが
当たり判定の動作、及び処理に
まだ、異常を感じるところです
テスト中ゲームID 30768
あまり複雑な処理には
難しいところがあるのかも知れませんが、
報告も兼ねて連絡いたします
ご都合のいいときにでも
確認を頂けましたら幸いです
手を加えてみたところ、
外見上の動作は、大体想定どおりになりましたが
当たり判定の動作、及び処理に
まだ、異常を感じるところです
テスト中ゲームID 30768
あまり複雑な処理には
難しいところがあるのかも知れませんが、
報告も兼ねて連絡いたします
ご都合のいいときにでも
確認を頂けましたら幸いです
コメントありがとうございます。
アームの動きに当たり判定がついていってないように見えますね。。。
子スプライトに当たり判定の矩形を設定している状態で回転させれば再現できるでしょうか。
ちょっと試してみます。
アームの動きに当たり判定がついていってないように見えますね。。。
子スプライトに当たり判定の矩形を設定している状態で回転させれば再現できるでしょうか。
ちょっと試してみます。
当たり判定の矩形を
ずらして設定しているのも
関係あるかもしれません
もう1点、、
自由落下スプライトの
すり抜けの発生も
確認しているのですが
こちらは再現されておりますでしょうか?
ずらして設定しているのも
関係あるかもしれません
もう1点、、
自由落下スプライトの
すり抜けの発生も
確認しているのですが
こちらは再現されておりますでしょうか?
情報ありがとうございます。
問題の切り分けをするために、まずは自由落下スプライトのすり抜けを再現する最小ケースを作ろうと思っています。
(該当のゲームで問題発生していることは確認してあります。)
ひとまず、下記の書き方では再現していません。何か他に思い当たる条件などありますでしょうか。。。
CoRバグ再現 - 当たり判定の突き抜け
https://rmake.jp/games/30811/cor_example
問題の切り分けをするために、まずは自由落下スプライトのすり抜けを再現する最小ケースを作ろうと思っています。
(該当のゲームで問題発生していることは確認してあります。)
ひとまず、下記の書き方では再現していません。何か他に思い当たる条件などありますでしょうか。。。
CoRバグ再現 - 当たり判定の突き抜け
https://rmake.jp/games/30811/cor_example
バグ再現スクリプトをコピペし、自由落下スプライトを縮小してみたら、めり込みを確認しました。
https://rmake.jp/games/30683/cor_example
縮小前はめり込みませんでした。
すぐに最小サンプルを作れませんが、
1、重力を持ったもの同士の多段衝突でのめり込み・すり抜け(重力の大きさに比例)
2、大きな速度を持ったもの同士の多段衝突でのめりこみ・すり抜け(重力より効果量は少ないが速度の大きさに比例)
3、tapdown?メソッドの処理中(trueの間?)、物理運動中のスプライトの当たり判定がなくなる(collide_world!は機能する)
があるように見えます
https://rmake.jp/games/30784/cor_example
3については、上のサンプルで、Bounce中にボタンを長押ししたりカーソルキーで指を動かすとわかりやすくすり抜けます
また、すり抜けとは関係ありませんが、
当たり判定の処理が多いような動きほど早くフリーズするように見えます
https://rmake.jp/games/30683/cor_example
縮小前はめり込みませんでした。
すぐに最小サンプルを作れませんが、
1、重力を持ったもの同士の多段衝突でのめり込み・すり抜け(重力の大きさに比例)
2、大きな速度を持ったもの同士の多段衝突でのめりこみ・すり抜け(重力より効果量は少ないが速度の大きさに比例)
3、tapdown?メソッドの処理中(trueの間?)、物理運動中のスプライトの当たり判定がなくなる(collide_world!は機能する)
があるように見えます
https://rmake.jp/games/30784/cor_example
3については、上のサンプルで、Bounce中にボタンを長押ししたりカーソルキーで指を動かすとわかりやすくすり抜けます
また、すり抜けとは関係ありませんが、
当たり判定の処理が多いような動きほど早くフリーズするように見えます
追加情報ありがとうございます。
めり込みについてですが、スプライトにscaleが指定されている場合に、以下の問題があることを確認しました。
(1) collision_sizeを指定すると、当たり判定の中心位置がずれる
(2) collision_circleを指定すると、show_debug_bodyメソッドで表示される当たり判定と実際の当たり判定が異なる
1は計算ミスのようなので、修正する予定です。
2はCoRで利用しているゲームエンジン(phaser.js)のバグのようです。下記の記事を見る限り最近修正されたようなので、近いうちに最新版に変更しようと考えています。
https://github.com/photonstorm/phaser-ce/issues/122
めり込みについてですが、スプライトにscaleが指定されている場合に、以下の問題があることを確認しました。
(1) collision_sizeを指定すると、当たり判定の中心位置がずれる
(2) collision_circleを指定すると、show_debug_bodyメソッドで表示される当たり判定と実際の当たり判定が異なる
1は計算ミスのようなので、修正する予定です。
2はCoRで利用しているゲームエンジン(phaser.js)のバグのようです。下記の記事を見る限り最近修正されたようなので、近いうちに最新版に変更しようと考えています。
https://github.com/photonstorm/phaser-ce/issues/122
>3、tapdown?メソッドの処理中(trueの間?)、物理運動中のスプライトの当たり判定がなくなる(collide_world!は機能する)
こちらの件ですが、コードを拝見したところ、wait_timeで二度押し防止をしているようですが、wait_time中は当たり判定の処理が実行されない(当たり判定はupdateブロック中のcollisionメソッドで実行されます)ので、仕様ということになります。二度押し防止はフラグを使ったほうが良いかと思われます。
(二度押し防止の汎用的な方法をCoRの基本機能として提供したいところですが・・・)
こちらの件ですが、コードを拝見したところ、wait_timeで二度押し防止をしているようですが、wait_time中は当たり判定の処理が実行されない(当たり判定はupdateブロック中のcollisionメソッドで実行されます)ので、仕様ということになります。二度押し防止はフラグを使ったほうが良いかと思われます。
(二度押し防止の汎用的な方法をCoRの基本機能として提供したいところですが・・・)
当たり判定のすり抜け現象について
まだ、原因の完全特定には至っておりませんが、
こちらの値で開始したところ、
同様の現象が発生しましたので連絡いたします
ゲームID 30812
変更箇所
majitai
position y
gravity y
scale
bounce
collision_circle
floor_base
position y
まだ、原因の完全特定には至っておりませんが、
こちらの値で開始したところ、
同様の現象が発生しましたので連絡いたします
ゲームID 30812
変更箇所
majitai
position y
gravity y
scale
bounce
collision_circle
floor_base
position y
ゲームエンジンを最新版にアップデートしたところ、ゲームID30812のすり抜けは発生しなくなったかと思いますが、ご確認いただけますでしょうか。(ID30768でも同様に改善しているかと思います。)
ただし、現在、show_debug_bodyの表示にscaleが反映されない問題は残っているようです。こちらの方は引き続き調査します。
ただし、現在、show_debug_bodyの表示にscaleが反映されない問題は残っているようです。こちらの方は引き続き調査します。
1点気になることがありましたので
報告いたします
add_childによる親子関係の生成で
layer_indexの重なり指定が
思うように動作しないのですが、
こちらは仕様でしょうか?
親(基準)となるスプライトよりも
下の階層に
スプライトを表示したいと思っております
親にすることで、対応しました
運営のあかさたです。
まだ、再現テストをしたわけではないのですが、親子関係が絡んだ場合にlayer_indexが正常に動作しないことはありそうです。対応可能か、調査してみます。
ご不便をおかけしますが、よろしくお願いいたします。
(一部コード省略)
上記のように、
親の下側に入るよう
layer_indexを指定したり、
子のlayer_indexを順次指定しても
(理想 > C→A→B)
実際の表示順は
親が一番下
次いで、add_childを行った順となっております
(現状 > A→B→C)
詳細調査、よろしくお願いいたします