クレイじいさんの言

HOMEへ戻る
呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉

  呉ソフトの でございます。(あれよあれよで70を過ぎたプログラマ)

2023年2月11日

FQ1の素材を使い倒して早**年、ついにゲーム機でのリリースに到達しましたぁ
始めは、各種プログラムの勉強。
アセンブラ→C、CPP言語→JAVA→フラッシュ→C#
エディターも言語に合わせて、VS→エクリプス→etc と回って、VSに落ち着いてます。
ネット系のゲームに対応するため、サーバーサイドのプログラムもかじりましたが、これは容易ではなかったですね。
サーバーでも、スピード重視なら「C」が良いような気がしますが、とても大規模になって大変です。
描画関連の手法はハードの進化によって、何万というモデルが描画可能になってきました。
通信でも速度はあがってますが、スピードネックの要因がこちらの範疇ではないものも多いので、未だに早い通信プログラムを作るには、「通信しない」のが原則だと思ってます。
あ、脱線しました。

FQ1の素材はUNITYに落とす事によって、スマホで拡散できる見通しが生まれました。
UNITY特有の機能は使っていません。JAVAからC#に移しただけです。
この間UNITYもバージョンが変わる度に仕様が代わりましたが、最低限の基本機能しか使っていないので、そのまま使ってます。

ゲームが形になってからは各プラットフォームの勉強をさせてもらいました。
アップルとグーグルでも、データの扱い方が違います。アップルではこちらでのデータ圧縮が必須ですが、グーグルはグーグルがやってくれる圧縮が強力なので、任せた方が良い感じです。
また、検証方式も違い、不合格の基準を違うようです。
そんなわけで、他のプラットフォームのやり方が頭にあると帰って誤解をまねく事があります。

で、またPCのCPPプログラムに戻して、PCプラットフォームさんのお世話になりました。
C#からCPPに戻すのは、メモリーの開放さえ気を付ければ簡単です。
少しプログラムの話になってすみませんが、プログラムを動かすには、プログラムやデータの使う領域を確保しなければなりません。確保したからのには、使い終わったらその領域を開放しないと使える領域がなくなってしまいます。
そういった作業はプログラムをする本質の作業の妨げになるという考えから、JAVAやC#では、「使わなくなったら自動的に削除する」とい方式になってます。
削除するタイミングはシステムにまかせる事ができますが、確保する頻度が多いと掃除が間に合わず、メモリーがパンクしてしまう事があります。
なので、できるだけメモリーを確保する「new」命令を使わないようにするのが、無難ですね。
CPPは面倒だけれど、メモリー管理もプログラムのうちなので、しっかり管理できれば安心していられます。
なんといっても、高速処理が可能になるので、システム的に余裕が生まれます。

スマートフォンでは、iOSとGoogleの2大プラットフォームを扱わないといけないので、UNITYはとてもありがたいものでした。

今回、FQ1NEXTをスイッチに落とし込むのに、スマホのUNITYプログラムを元にしました。
何もしなくても、スマホのプログラムがそのままスイッチで動作したのは驚きました。
動作速度も問題ないようでしたので、そのまま入力の変更を行いました。

出来上がった所でいろいろ検証すると、PCプログラムからの移植のほうが良かったかと思う部分もあります。
思ってはみたものの、手間を考えると一度できたものを作り直すだけの根性がすでにないです(いつポックリいくかもわからないトシですからね)。

ゲーム内容のスイッチ用のプラスとして、リザードマンの拠点攻略を加えました。
なた、各部隊ごとアイテム袋を1つに統一して、どこにいる部隊にでもアイテムを即座に届ける事ができるようにしました。理屈よりは利便性という事ですね。

いろいろなご意見を伺って、このような形になりましたが、一番大事なのは少しでもユザーの皆様が楽しんでいただける事だと思ってます。


呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉呉


◆HOMEに戻る◆