ebitengineでゲームを作る2

こんにちは！
システム開発部のK.Mです。

今回も前回からの続きとなりますが、ebitengineを使用して作ったシューティングゲームのようなものを改良していきます。
前回作ったものから、下記の内容で修正を行なっていきます。

ebitengineでゲームを作る

こんにちは！
システム開発部のK.Mです。

今回は前回からの続きで、ebitengineを使って簡単なシューティングゲームのようなものを作っていきます。

用意するもの

シューティングゲームなので自機・敵・弾などの各種画像が必要となります。
今回はいらすとやさんから調達させていただきました。

• 自機の画像
  

• 自機の弾の画像
  

• 敵の画像
  

• 敵の弾の画像
  

自機の表示と操作

画像ファイルのロード

ebitengineで画像表示するために用意されているAPIは、go標準の画像データを渡す形になっています。
そのため、goの処理にてファイルオープンを行いデコードした情報を渡す必要があります。

今回はpngファイルを使用しているため、下記の例はpngの画像ファイルをオープンする場合となります。

var drawImage *ebiten.Image
// ファイルオープン
file, _ := os.Open("pngファイルのパス")
defer file.Close()
// デコード
img, err := png.Decode(file)
if err != nil {
    panic(err)    
}
drawImage = ebiten.NewImmageFromImage(img)

ebitengineを触ってみる

こんにちは！
システム開発部のK.Mです。

はじめに

最近やっと落ち着いてきましたが、UnityのUnity Runtime Feeの件でこのままUnityを使い続けて大丈夫なのかという感じになった開発会社さんは多いかと思います。
一応、紆余曲折あり無難なところに落ち着いた感じはしますが、またUnity側でどういった変更が行われるか分からないのもあり、他のゲームエンジンに移行しようかと検討している方も居るかと思われます。

代替えとして、UnrealEngine（以降、UE）・GodotEngine・GameMaker・Cocosなどあったりしますが、今回個人的な理由でGo言語で作られた2D用ゲームエンジンのebitengineを使って簡単なゲームを作るために諸々確認をしていきます。

ただし、このebitengine、UnityやUEのような専用のエディターは存在しないので、昔ながらのDirectXのAPIを叩いて使う形になるので、その点注意が必要です。

インストール

今回はMacOS（M1Mac）の環境で、ebitengineをインストール・実行していきます。
ほぼebitengineのインストールページに沿った内容で確認可能ですが、少し補足を載せておきます。

DFrameを試してみる2

こんにちわ。 システム開発部のK.Mです。

今回は前回触ったDFrameに関してもう少し深掘りして行きます。
深掘りの前に、前回の実装で良くない実装をしていた部分を修正していきます。

HttpClientは使い回す実装にしよう

前回の記事の「APIにアクセスする処理を入れていきます。」で説明している箇所にて、指定された回数分ExecuteAsync()のみが動くものかと考えており、HttpClientをSetupAsync()内でnewをして、TeardownAsync()でDisposeしていました。

しかし、今回の調査時に判明したのですが、テスト実施の1セット内でSetupAsync()->ExecuteAsync()->TeardownAsync()という流れになっており、次の2セット目に入った場合に、再度SetupAsync()->ExecuteAsync()->TeardownAsync()を同じように実行する形になっていたため、HttpClientを毎回newしてDisposeする形になっていました。

HttpClientは本来再利用することを推奨されているのですが出来ていなかったので、まずはこちらを修正していきます。

修正内容としては、Workloadのコンストラクタでnewして、デストラクタで一応Disposeするようにしたうえで、SetupAsync()のnew関連の処理と、TeardownAsync()のDispose処理を削除しておきます。

DFrameを試してみる

こんにちは！
システム開発部のK.Mです。

今回の記事の経緯

以前こちらの記事にてMemoryPackの記事を書きましたが、サーバがC#で動いておりMemoryPackでリクエストとレスポンスをやり取りする形になっていると、MemoryPackを扱うためにどうしてもC#が必要になってきます。

その場合に少し困るのが負荷テストです。
LocustやGatling、JMeterを使用する場合、C#でテストシナリオが書けないので、一時的にリクエストとレスポンスをJson形式にして負荷テストすることになるのですが、その場合だとMemoryPackを含めた本番想定の負荷テストが出来ない状況になってしまいます。

そのため、C#にてテストシナリオを書けてMemoryPackでのやり取りが出来るものを検討する必要があります。
その際の検討段階に上がってきたのが、DFrameとなります。
（neuecc氏の術中にはまっていっている感じがしますが・・・）

neuecc氏が書いたDFrameの記事はこちら
githubはこちら