複数人で開発している場合、他の人が行ったコミットを自分の開発ブランチにも取り込みたい。
＃master ブランチを例に書きますが、どのブランチでも同じ。
1) ローカルのmasterブランチにリモートのoriginにコミットされた最新を取り込む
2) 開発ブランチにmasterブランチをマージする
git checkout master git pull origin master git checkout dev git merge origin master
ローカルの master ブランチに移動(checkout)して、
pull(fetch->merge) でリモートのmasterブランチに最新情報を取得(fetch)し、ローカルのmasterにマージする
その後、ローカルの開発ブランチにに移動して、
masterブランチと開発ブランチをマージする
▲開発中のゲームだよ^^
今回は、Asepriteで「レイヤーを部品ごとに分けたんでレイヤーごとに出力したいんだけど！」っていう記事です。
例えば、メニュー画面などで、
メニュー画面自体を描画するための背景画像と、
そのうえにのる実際のメニュー画面の要素（ボタン等）は、別々の画像にするかと思います。
うえにのる実際の要素はアニメしたり、表示・非表示が切り替わったりいろいろ変わるので一つの画像では表現できないためです。
というわけで、今回はAsepriteのLayerを部品単位に分けて開発してます。
こんなかんじ↓
これを、一度にレイヤーごとに出力する方法を今回書きます。
File -> Export File
で Layers から 対象のレイヤーだけ出力はできます。
が、今回はいっきに全部のレイヤーをバラバラのファイルに出力してほしいのです。
※バージョン v1.2.8
というわけでコマンドからは行けます。
$ ./Aseprite.exe -b --split-layers [asepriteファイル名] --save-as [出力ファイル名]
例）
$ ./Aseprite.exe -b --split-layers ~/Desktop/menu.aseprite --save-as ~/Desktop/menu.png
https://www.aseprite.org/docs/cli/#export-all-layers-into-different-png/gif-files
▼実行するとこんな風にレイヤーごとに出力されたよ。
ファイル名は自動で決まりました ⇒ 追記：指定できるー！「ファイル名をレイヤー名にする」見て
レイヤーごとにファイルを出力した場合、画像の大きさはすべてキャンバスのサイズになっていて、 不要な透明部分含めて出力されてしまう…
▲ こんな感じに、透明部分を含んだ大きい画像になってしまう。
そこで、--trim オプションを指定すると！不要な透明部分の除去もできた！素晴らしい！
$ ./Aseprite.exe -b --split-layers [asepriteファイル名] --trim --save-as [出力ファイル名]
例）
$ ./Aseprite.exe -b --split-layers ~/Desktop/menu.aseprite --trim --save-as ~/Desktop/menu.png
https://www.aseprite.org/docs/cli/#trim
▲ 透明部分を除去した画像が生成されました！
それぞれのファイルをレイヤー名で指定することもできた！
上述しているとおり、
ファイル名を指定しない場合は [画像名] ([レイヤー名]).png というフォーマットで出力される。
これを、レイヤー名だけにしたい。って場合は、ファイル名の指定に {layer} とつけるとできました！
例）
$ ./Aseprite.exe -b --split-layers ~/Desktop/menu.aseprite --trim --save-as ~/Desktop/{layer}.png
https://www.aseprite.org/docs/cli/#filename-format
↑ＥＤＧＥでいう、パレットのグラデーション作成をAspriteでもしたい。
↓パレットの「↓」の「Gradient」からできた
「ゲームプログラマになる前に覚えておきたい技術」（通称：ひらしょー本）
の「爆弾人」を
unityで作ってる作業きろく！！！
起きたのがバリおそかったけど、今日もすぐやる。
爆弾を爆発できるようにした。爆発で、レンガ、敵、プレイヤーも死ぬようにした。
爆弾の爆風をとりあえず時間経過とかなしで表示する。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・pushするときに毎回パスワード聞かれてうざい。httpでやってるからっぽいけど、すぐわからなかったのでタスクに。
爆弾を設置できるようにする。爆弾が爆発するようにする。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・pushするときに毎回パスワード聞かれてうざい。httpでやってるからっぽいけど、すぐわからなかったのでタスクに。
今日も朝から作業です。
「作る」は楽しめるけど「学ぶ」は苦手なので、今の作業は「作る」をしてる感覚でできる作業なので楽しいです＾＾
爆弾の爆風をとりあえず時間経過とかなしで表示する。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・pushするときに毎回パスワード聞かれてうざい。httpでやってるからっぽいけど、すぐわからなかったのでタスクに。
爆弾を設置できるようにする。爆弾が爆発するようにする。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・pushするときに毎回パスワード聞かれてうざい。httpでやってるからっぽいけど、すぐわからなかったのでタスクに。
今日も朝おきて一番に作業開始だ～.
プレイヤーが壁にぶつかったときに移動しないようにした。
以前使ったことがある、Physics2D#Linecast()を使って、
移動するまえに移動予定の位置にコライダーを設定したオブジェクトがあるかどうかを調べて、
あるなら移動しない。ないなら移動する。という具合に。
int dx = 0; int dy = 0; Vector2 tPos = new Vector2(0, 0); if (Input.GetKey(KeyCode.UpArrow)) { dy = 1; tPos = new Vector2(0, this.collider.size.y / 2); } else if (Input.GetKey(KeyCode.DownArrow)) { dy = -1; tPos = new Vector2(0, -this.collider.size.y / 2); } else if (Input.GetKey(KeyCode.RightArrow)) { dx = 1; tPos = new Vector2(this.collider.size.x / 2, 0); } else if (Input.GetKey(KeyCode.LeftArrow)) { dx = -1; tPos = new Vector2(-this.collider.size.x / 2, 0); } dy *= PLAYER_SPEED; dx *= PLAYER_SPEED; if (!(dx == 0 && dy == 0)) { //移動しようとしている //移動できるか判定 this.collider.enabled = false; Vector2 targetPos = this.rigidbody.position + new Vector2(dx, dy); RaycastHit2D hit = Physics2D.Linecast(this.rigidbody.position + tPos, targetPos + tPos); this.collider.enabled = true; if (hit.transform == null) { //移動可能なので移動する //this.transform.localPosition += new Vector3(dx, dy); //this.rigidbody.position = this.transform.localPosition + new Vector3(dx, dy); this.rigidbody.MovePosition(targetPos); } }
ミソなのは、移動できるかの判定処理で、
RaycastHit2D hit = Physics2D.Linecast(this.rigidbody.position + tPos, targetPos + tPos);
+ tPos ってしているところがあるんだけど、
これをしないと、画像の原点が中心になっていて、画像の中心で判定してしまうことになり、うまくいかなった。
▲こんなかんじで、プレイヤー画像の中心まで壁にめりこんじゃった。。
なので、移動方向によって画像の中の判定したい位置をもとめるようにしたってこと。
▲改善できた版！
次回は敵の配置やって敵も動くようにします。本的には、p226～
敵とプレイヤーの当たり判定処理がむずいかも。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・pushするときに毎回パスワード聞かれてうざい。httpでやってるからっぽいけど、すぐわからなかったのでタスクに。
今日も朝おきて一番に作業開始.
プレイヤーの配置(表示だけ)は昨日時点で終わっていたけど、
インスペクターでTransform#Positionを1動かすだけで、1マス分がっつり移動してしまう状態だった。
今日は1マスをTransform#Positionの100にするようにして、ちょっとずつ移動できるように、カメラサイズ等調整。
Transform#Positionでfloatの値でやってもよかったけど、整数の方がわかりやすいので。
これで、
1マス座標＝ローカル座標(`Transform#Position`)の100
という風になった。
見た目上の変化はないが、ちょっとずつマス単位でなくちょっとずつプレイヤーを動かすことができそうな目途がたった。
敵の配置
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・pushするときに毎回パスワード聞かれてうざい。httpでやってるからっぽいけど、すぐわからなかったのでタスクに。
昨日は1hやってそのあともう1hはやりたかったけど、見事にねてた。
やっぱり朝イチでやらないと時間が確保できないな。
今日も昨日の続きから。p198あたり。
床、壁、レンガ(レンガ率はまだ固定)を描画した。
とりあえず、解像度対応とかすべてなし。画面サイズ固定で作る。
ひらしょー本だと、床、壁、レンガというフラグを作って、フラグを元に描画するかんじ。
それに対して、unity公式ローグライクは、床、壁、レンガ、という単純なプレハブを作ってそれを配置している感じ。
ひとまずは後者で実装するが、プレハブ作るまでもないならひとつのクラスにまとめて、前者に変更するかも。
プレイヤーとアイテム(壁の中にあるので見えないけど)も表示した。
プレイヤーをマス単位じゃなく、ドット単位に動かせるようにする。p212～。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
今日は、「ゲームプログラマになる前に覚えておきたい技術」の７章 の途中 p198～
なんだけど、完成版のゲームをまだ起動できる状態になってなかったので、その環境作りから。
完成版のプロジェクト(C++で作られているもの)を動かせる状態にしておく。
古いバージョンしか対応していないので、自分の環境に入ってるVSで動かせるようにする。
いつも使ってる VS Com 2017 で動かしたいので、cmake でビルドをしなおす。
http://blog.techlab-xe.net/game-programmer-book-new-build
↑を見ればソッコーわかる！ありがたや～
cmake初めて使ったのでよくわからないけど、コンパイラのバージョン依存を解決してくれる？みたいなものっぽいととりあえず認識。
よくわかってないけど深堀しようとしすぎると、本当に進めないといけないところが進まなくなるのでとりあえずスルー。
そこで、、とりあえず手を出せるものから手を出すことにしよう。不確定な要素がたくさんあ るほど思考が迷いやすくなるし、見落としも起こりやすくなる。だから、すぐできることや、 どうせ必要になるとわかっている部分はさっさと片付けてしまおう。そうすれば不確定要素 が減り、同時に考えねばならないことも減ってくる。(p199)
タイトル、ゲームオーバー、ゲーム、エンディング はSceneにする。 準備、ポーズ、クリア、失敗、勝敗表示はゲームSceneの中で描画する。Canvasにするかもしんないけど保留。。
今日は、「ゲームプログラマになる前に覚えておきたい技術」の７章最初～
TextMeshProのTextMeshProUGUI#SetText()を使う。
Randam#Range() を使う。
Random.Range(1, 100);
1～100まで ↑の例だと1～99の乱数を生成してくれる。引数の1も100も含まれるので注意。
https://docs.unity3d.com/ja/2018.3/ScriptReference/Random.Range.html
デバッグ用の機能は、リリース時には含めたくないので、
BuildSettingsのDevelopment Buildにチェックが入っているときのみ含めるようにしたいので、
Debug#isDebugBuild を使う。
unityエディタ上で起動した場合もDebug#isDebugBuildはtrueを返す。
ステージ数や何回死んだらゲームオーバーになるかは好き好きでいいが、テストをすることを考えると2以上にはしたい。プログラミングには0、1、たくさんという三つの数があって、2は「たくさん」の中の最小値だからである。1と2は根本的に違うものなので、1でしか出ないバグや2以上でしか出ないバグというのは頻繁に発生しうるが、2で動くならだいたいは3でも動くものだ。 (p216から引用)
タイトル、ゲームオーバー、ゲーム、エンディング はSceneにする。 準備、ポーズ、プレイ(ゲーム画面)、クリア、失敗、勝敗表示はゲームSceneの中で描画を分ける。
・Debug.Log()もリリース版には含まない方がいいようなので、
Debug#isDebugBuildの判定をいれたunilityクラスを作っておきたいが、どう実装するか。単純にutilityクラスつくればいいだけと思ったけどコンソールからのリンクがすべてutilityクラスに飛んでしまってデバッグログ出すの意味が微妙になりそうかも。
・開始して1.5hで疲れたので今日はこれでおしまい
こんな風↑にAsepriteで3フレームのアニメ作ったので、 それをスプライトアトラスで出力したい。
File -> Export Sprite Sheet
Exportで出力できる。
unityとかでアニメさせればこんな↓かんじに
ローグライク記事、
サボってしまってた！けど9/3(月)から再開します！！
2018/09/12追記：
やるやる詐欺になってしまってるのが嫌なので遅くなりましたがご連絡します。
すいません（＞＜）、諸事情でしばらくお休みます。
見てくれている方、申し訳ありませんm(_ _ ;)m
