ARアプリ開発経験0から頑張ってみる:1日目
この記事
大層な感じのタイトルですが、要するにですね、最近時間がちょっとあまったのでswiftを勉強し始めた雑記などしていこうかと
ちょうど完全放置してたので、こっちに学んだこととわからないことを書いていきます。
目標
ARKit3を使って色々できるようになるのがゴールです。
やること
ARKit3を使うのでiOSアプリの勉強、つまりswiftから学習していきます。マカーなのになぜか一度も触ったことなかったという
SwiftはなんでもNullつけられない
関数呼び出しの際に指定することで、処理の設計にnullかどうかを判定する部分が不要になる。
?delegateがわからない?
処理の流れが決まっているという前提で、ケースによって処理の内容をかんたんに変えたいときに使えるデザインパターン
よく3つの登場人物に分けて説明されてる - 処理(プロトコル) - 処理を任せる人 - 処理を任せられる人
[Swift]"デリゲートデザインパターン"ってなに? - Qiita
処理の流れを決めていれば(プロトコル)、処理をお願いする関数の中身を意識せずに処理を実装できる。
?クロージャがわからない?
関数のスコープにある変数を自分が定義された環境に閉じ込めるためのデータ構造
ざっくり、関数呼び出し後も変数を保持し続けるための仕組み? グローバル汚染を防ぐために使う。
でもクラスでも実装できるので、もしかしたらクラスだと実装コストが掛かるような処理を簡易的に実装するための仕様なのかもしれない
ラムダ式とかもこれで表現できてる
- スコープに閉じられている変数をキャプチャする役割
- かんたんに無名関数みたいなものを記述できて便利
っていうのがメリットっぽい、というか分けて考えないとなんで使うのか永遠にわからなくなりそう
【swift】イラストで分かる!具体的なClosureの使い方。 - Qiita
わかりやすい
[改訂新版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus) | 石川 洋資, 西山 勇世 |本 | 通販 | Amazon かった
目的
- swiftでよく使われるデザインパターンがwebサイトとかにある説明だとイマイチわからなかった(他の人に伝えられるか不安)だったため、その補完として
- swiftの言語仕様について網羅的にわかりそうだったため
最初の目的は現状モヤモヤするので、なるはやで理解したい コード読むときに詰まったらやればいいかなと思う
## 関数の記述 swiftでは関数を書くとき次の2つのパターンがある - funcを使った名前つき関数 - クロージャを使った無名関数 どちらを使うかはケースによって色々ある(スコープ上に同じような関数を何個も作る,処理の規模とか...)
swiftは関数も一つのオブジェクトとして扱える(ファーストクラスオブジェクト)ので、しばしば引数とかに関数を指定するようなこともあるが、関数を渡すときに各パターンの記述方法の違いをはっきり意識したほうが良さそう
funcの場合は処理の内容を{}
で囲んでるが、無名関数の場合は全体を囲んでる
ちょっとめんどいな
num++
みたいなインクリメント気泡が使えない?0
とそれ以外
をBool値として変換できない(型安全性が高いの裏返しってことかな)、 でも逆に
let optStr: String? = "hoge" if let wrappedStr = optionalStr{ //なんらかの処理 }
これが通るのめっちゃもにょる
トレーリングクロージャー(Trailing Closures)
関数の引数がクロージャーだった場合、引数の記述を閉じて、その後にクロージャーを別に書くことができる記法 クロージャーとそれ以外の引数というふうに分けられる場合はみやすさに繋がりそう
`````` //Trailing Closures無 numbers.reduce(0,{total, number in total + number })
//Trailing Closures有 numbers.reduce(0){ total, number in total + number } ``````
クラス内オブジェクトのアクセス
基本的にself.
でアクセス可能
同スコープに同じ名前がなければ省略可能
Optional型のアンラップ
Optional型はそのままだと実際の値が取り出せない(wrap)、そのため値を使うときは、とりだせるように処理をする必要がある(unwrap)
ここにまとめてある
- Optional Binding
- Optional Chaining
- Forced Unwrapping
- ImplicitlyUnwrappedOptional型
これをみてると、null安全は勝手に安全になるというより、考慮すべきところでは考慮しなきゃいけなくて、考えなくても行けないところは何も意識しなくて済むようになる程度の仕組みっぽい?
Optional Binding
null避けにif
とguard
が使える、僕は圧倒的にguard
のほうがすき(正常時の結果を最後にかけるから)
Optional Chaining
Optional型のメンバ呼び出しするときに?.
でアクセスすることで、対象の変数がnil
だったときnil
を返してくれる記法
Optional Bindingの方との違いは、nil
だったときの処理をunwrapしてる箇所の外か中かでやるかってことなのかな。(あと、Optional型変数そのものの値を読み出したいときか)
nilだったときの処理が肥大化しなければこっちで良さそうに思える
Forced Unwrapping
Optional型のメンバアクセス時に!
をつけるとnullだろうがなかろうがアクセスする
当然nullの場合はerrorになるのでデバッグ用
ImplicitlyUnwrappedOptional型
Forced Unwrappingのやり方を変数宣言時にやるパターン
注意点も同様
swiftのgitignore
user関連のフォルダとかmac特有のバックアップっぽいファイルは外したほうが良さそう XcodeでiOSアプリ開発をする時の.gitignore - Qiita
swiftのライブラリ導入
CocoaPods
というRuby製のツールがあるらしく、そちらを使ってインストールするのが主流っぽい
ながれはnpmみたいな感じで設定ファイルに記述して、そのファイルに記述されたライブラリがインストールコマンド実行で入れられる(そしてimportでライブラリをモジュールとして使える)
$pod init
Podfile
unity1weekで1.6週間くらいかけてゲーム作った
はじめに
unityroomさんが主催しているunity1weekという出されたお題にそったゲームを一週間で作って公開するイベントに参加しました。
今回のテーマは『あつめる』でした。
自分の作ったゲームが↑です。
一言でいうと制限時間が決まったパズルをわんこそばみたいに解いていくゲームです、イベントはもう終わってますががよかったら遊んでみてね
書きたいこと
僕がこのunity1weekというイベントを知り、よっしゃ作るぞ~ってなってから今までずっと気になり続けてるポイントなんですが、
他の人、どうやってゲームつくってんの??
これに尽きます、自分の今やってるやり方は正しいんだろうか?絶対的正解はないはずだけど結構心配になるんですよね
具体的には限られた時間でどうやって設計/実装するの?とかうまく進行していくためにどうやって時間作るの?とかあーだこーだ
正解はなくてもせめてモデルケースみたいなやつはしりたい……
なので、そういう自分と同じような悩みを持ってる人に向けて、ひとまず自分のやり方を書いてみようかと思い至りました
これ見てくれてる人とかも、俺はこうしたぞ!ってのがあればどんどんアウトプットしてもらえたらすごーく参考になります…お願いします…
あと、タイトルにも書いてあるんで聡明な方ならすでに察していただいてると思うのですが、
締め切りが一週間後(日曜日)のところ、開発が終わったのは一週間後の木曜日です。
これで僕のモデルケースをどう活用すれば良いかわかりますね?
自己の紹介
初投稿なんで一応紹介から
都内で組み込みエンジニャ-してるdashimaki(@oinorisimasu)といいます、普段は趣味でイラストかいてます
ゲーム作りは本業ではないんですが、学生時代には一人でこんな↓やつをいくつか作ってました
androidでできるジャグリングゲームとか(これのエンジンはunityじゃなくてcocos2dxってやつです)
某戦車系女子のアニメをテーマにしたゲーム作ったりとか
ぼっちのクリスマスを祝うために作った「ケーキ型の爆弾に導火線としてつながっているロウソクめがけて火をつけに飛んでくる妖精たちから身をまもるゲーム」みたいなやつまであります(何でこんな発想に至ったんだろ)(でも一番これが気に入ってる)
(ちなみにunityがWebGL対応始める前のUnity Webplayerってやつで動くようにbuildされていて、すでにWebplayerは廃止されちゃったのでもうプレイ出来ません…)
しかし、ここ数年は仕事したり薄い本書いたりしていたため、ゲーム製作からは離れていました
経緯
そもそも、そういう自分がどうして急にunity1weekというイベントに参加してみたいと思ったか、そのきっかけがこちらの記事になります
別のgamejamの出来事なのですが簡単に内容を説明すると、はじめてのチーム開発で次々出てくる課題に対して一つ一つ対策していったり方針修正していったりする様子が時系列で追体験できます。(僕の駄文を読む前に見て)天才駆動開発というパワーワードが生まれた記事でもあります。
たぶん僕が同じ状況になったら、メンタリティ最低レベルなので一瞬で1歳児まで退行しそう、した、バブー
でも、一人でゲーム作るうえで問題の壁をどんどん掘り進んでいくのめっちゃ楽しそうだし、腕力もつきそうだしな~
そんなことをぼんやり思ってたところ、記事の最後にunity1weekの宣伝がされていたので、思いつきに近い感じで始めてみました。let's do it
今まで作ってたゲームもそんな時間かけて作ってないし、久々だけどいけないこともないとも思ってましたね
この時は
あと仕事でキーボードを叩く時間よりマウスを動かす時間のほうが長いコーディング()しかしてなくて、どこかしらでまともなプログラミングをしたかったのもでかめな要因です
目標
ゲームに関しては作りきることだけが目標なので、コーディングの目標をたてました。
SOLID原則を意識したコードが書けるようになりたい
どちらかというとまともなクラス設計ができるようになりたいって意味合いで書いてます。
組み込みという業種特有なのかもしれませんが、とりあえず動けばいいを延々と続けたあげくリリース後もコードレビューもされないままみたいなのがデフォみたいな
なので自分からそういう習慣をつけにいけるいい機会だと思ってですね
コーディングの感覚を取り戻したい
最近ほかのプロジェクトからポーティングする仕事ばーーーーっかりやってて、スクラッチで何か作ることを久しくやってなかったのが割とストレスになってたんですよね。。。(これも組み込み業種特有の悩み?)
期日に間に合わせるように動きたい
極道入稿ダメ、絶対。
そういう進行したいって意味です、無理そうだったら修正したり代替案を考えたりっていうのを作りながらも考え続けるようになりたい
サラッと書いてますが、これ身につけられたらマジで何にでも応用できますからね、そのため努力目標程度に
課題発表
第12回 Unity 1週間ゲームジャムのお題掲載されました〜。
— naichi (@naichilab) 2019年6月30日
今回のお題は「あつめる」です!
それでは今週もよろしくお願いします。ゲーム作りを楽しみましょう!https://t.co/2uhr9rdqDr #unity1week
7/1、ついに課題が発表されました。
ただ僕この時間普通に寝ちゃっていたので、確認できたのは朝になってからでした。
1日目
えー、ほんとは早速作業にとりかかりたかたったんですが
この日は新潟に帰って知り合いと祭りに行ってました。(もともと予定してた)
コーディング作業にはいるのが難しいのは分かっていたので、アイディアのもとになりそうなものがないか探そうとはしてたんですけどね
普通にそれなり楽しんだあと疲れて寝てました
2日目
というわけで、2日目が稼働初日になります、一応月曜日ですが有給をとっていたのでゲーム作りにあてられました
とりあえずの方針
gamejamは初めてですが、たぶんゲームとして形にすることが最優先でやらなきゃだと思ったので、次のことをまずやろうと決めました
- 早くアイディアだして
- それをプロトタイプまでもってくこと
これ言葉にするのは難しいんですけど、ゲームがゲームになるラインっていうのがあると思ってて、ラインを超えるきっかけはロジックだけじゃなくてグラフィックとかサウンドとかでも要因となることがあって。。。
すいません、一言でいうと『あっ、ゲームになってる!』って状態まで早くもっていくことでいいですね
そのために、テーマに沿ったゲームのアイディアを考えて、みたんですが
でない、アイディア、本当にでない
…考えてみれば今までは、散歩してたり集中できない作業してたらアイディアがフッて降りてきて、そのまま開発するという方式でやってた(天啓駆動開発)
もっと確実な手段をとるべく、一旦脳内を何かしらのフォーマットに則った上で紙に書き出してみようとしてみました
ここから絶対迷走する自信あったんですがね……意外とすんなり決まりました
まずはオーソドックスにテーマに沿ってそうなワードでゲームになりそうなものを洗いだし
この時点で数個くらいいけそうなやつはでてきた?って感触
ただし、期間が一週間しかないため、ゲームのスケールを見積もる必要がありました。
そこで今回はプレイヤーのアクション(の種類)がシンプルになるもの(かつ物足りなくならないもの)を選ぶように決めました。
上の書きかけは、もともと何となく『集める』と組み合わせられそうな動詞を書き出してみたらなにか浮かぶかなと思い書き連ねてみたもので、特に意味を考えて始めたものではないのですが、ユーザアクションの定義として使えそうだったので今回テーマ選びの基準にしています。
そして最初に出した案の中から基準にあいそうなものを選んで大枠の仕様を考えたところ
プリントを集めるために生徒を並び替える(???)Wave系のパズルゲーム
という形に決定しました。(並べる×あつめる)
もちろん、プレイヤーができる行動が少なくとも実装量が多いことは普通にあります。
ただ、単純にやれること少なければ考えるパターンは減るだろうという発想でやっているので……
それに、少なくとも自分を納得させられたのでこれでいいかと
(余談、ベースが決まって安心したところで#unity1weekタグ検索したらすでに画面作りまでできてるつよつよの者で溢れてて差を見せつけられたみたいな出来事があった)
とまあ遅いなりに進められてはいたので、あとから振り返っても悪くはなかった気がしています
俺?ゲームのイメージがようやく定まったとこ #unity1week
— dashimaki (@oinorisimasu) 2019年7月2日
進捗ダメ自虐してるのにこころなしか余裕そうな過去のぼく
3~5日目
担当プロジェクト→🌋🌋🌋🔥🔥🔥🔥🔥僕→😱🔥🔥🔥🔥🔥
— dashimaki (@oinorisimasu) 2019年7月5日
大地は割れ、海は荒れ狂い、空は憤怒に色を染めた
(訳すと、自分の担当外の機能の検査をしてたらかなり根深い問題があって、しかもなぜか一人で対応することになってしまった、帰りたい、つらいという意)
家につくのが12時近くという生活でゲーム作りに一人で励むのは流石に無理…厳しい…
そんななかで別チームの作業待ちになる時間があったので、
こんなかんじで紙に実装イメージを書き出してたり
もともと目標にしてたクラス設計についてこういうとことを見ながら学んだり、とりあえず隙間時間でやれることをやっていくようにしました
https://qiita.com/toRisouP/items/a868113c99179c585001
https://qiita.com/UWControl/items/98671f53120ae47ff93a
https://qiita.com/Marimoiro/items/2ad8a1b422a3fe98f938
ゲーム作るのはじめてで何をやれば良いかさっぱりわからんって人は、人のコードみて参考(多様なニュアンスが含まれている)にするのが早いかもしれない
6日目
地獄みたいな仕事が終わり(終わってないけど)、完全週休二日制に守られたおかげでようやく自由時間をゲット~
なんですが
でない、やる気、全くでない
あまりにやる気が出てこなさすぎて、やるべきことの対極にあるソシャゲのイベント走りとかやり始める始末…
おそらく↓らへんのことが原因だと思います
- 設計だけ肥大化しすぎて、やるハードルが高くなりすぎてしまった
- アウトプットする期間が途切れてしまったため、集中ボーナスが切れた
- 予定通りに進められないことが多くスケジュールがずれにずれまくってげんなり
+この時点でほぼ間に合わないのは確定していたので、モチベがだだ下がりしてました
間に合わないなら間に合わないで、無理にでもエンジンかけて進められればよかったのですが
はたしてそんな状態で、わざわざ面白いどうかもわからないゲームを作っていく意味あるのか?
どうしてもそう考えてしまう自分がいて、なかなかスイッチが入らない…(こうなる前に遊べるところまで持ってければよかったんですけど)
あとは、だんだん自分のなかでゲーム作りの作りたいって意欲が義務に置き換わっている感じも受けました
結局イベント報酬も取り終わり、モラトリアム期間が終了
すこし頭が冷静になったので、このあとの方針をたてることに
- このまま続ける
- なかったことにする
- ブラッシュアップして別のタイミングで出す
どれにしようか考えたんですが、自分で選択したことに最初から黒星がつくのがめちゃくちゃ嫌だったので無理矢理にでもすすめるという結論に至りました
っていうか正直3番目の選択肢は2番目と同じだなって今なら思いますね
unity1weekでは遅刻でも出来たものがあったら公開してもOKらしく、その懐の深さに感謝しつつ、これでもかと甘えることにしました。すいません!
進め方の見直し
作り続けることを選択しましたが、このままだ進めても無理そうなのは見えてたのでなんとかしなきゃいけないのは変わってないです
といっても、ウルトラスーパーマネージメントテクニックとかもなかったので、革新的な手法とかは当然思い付きません
これについてはひとまず、『少しでも効果ありそうなら取りいれてみる』策でいってみることにしました、意識的に変化をつけてくことがモチベ向上に繋がると思ったからです
ホワイトボードにやることをかいてく
普段はtodoistとかtrelloとか使ってるんですが、一人、かつタスクの変更が頻繁にされることから落書き用に使ってた家のホワイトボードでタスクを管理することにしました
結論からいうと、アナログなところが良い作用に繋がった印象です
タスクを書くために立ち上がる必要があるのも逆にgood
決められた時間に寝る
→徹夜はしない
オーバーする時間が1,2日できかなそうだったため、短距離ではなく中距離用合わせたに走り方に
あえて制限をたてることで、時間内に集中して作業させる狙いです
ただ、最初は1時までに寝ようとしていたんですが、時間がどうしても取れず、あとあと条件を緩める形になりました
他の人の進捗を覗きにいかない
今日からできる限りタグ見ないようにします(精神安定上
— dashimaki (@oinorisimasu) 2019年7月2日
もともとしてたけど一層徹底するようにしました
よそはよそ!うちはうち!!
覚えてる範囲だとこれくらいかな
7~10日目
当初の仕様通りに作っていると想定してない点がポンポン出てきます。
僕の場合は長らくunityから離れていたのと設計力皆無だったのが相まって、最終的な実装量が2.5倍くらいまで膨れ上がってしまいました…
それでも、新たなタスクを書いては一つ一つ潰していくことを念頭においたおかげで、比較的インクリメンタルに進行できたんじゃないかと思います
頭が動いてないのが分かったらホワイトボードを確認→プライオリティのチェック→取りかかるタスクを選定→実装手順を脳内で構築→組んだものを脳死で取り組む→できる(場合がある)→ホワイトボードにチェック→タスクを整理→………
なんだかんだで不安ゲージがたまる余地を与えず、他のことに脳を使うやり方が脳内麻薬だしながらやってる感じがあってよかったです(※限度はある)
ゲームになってる~!!
という段階になったのは終盤辺り
具体的にいうと、このゲームにはパズルができたかを毎waveの最後にチェックする処理があるんですが、その部分ができたときですね
矢印の最後までたどったあと成功判定がでたときは嬉しかったですね、嬉しさのあまり部屋の中で1分くらいシャドーボクシングを行う感情表現をしていました
そのあとすぐさまクリアとゲームオーバーの概念が生まれたので、ラストスパートをかけるべく演出を詰めまくる段階に移行します
11日目
ゲームとして最低限必要そうな演出の実装をすませ、ツイートボタンとwebglビルドの準備
どちらもunityroomさんのサイトに懇切丁寧な案内があったためすんなり実装できました
(ただツイートボタンの方はGUIの制御方法わかんなくなくてやめました…)
ビルド生成物を指示された通りアップするだけですぐ確認できます、unityroomしゅごい
unity1week初投稿です!!えげつなく遅れてすいません!!よくある『後ろから順にプリントあつめてきてー』ってやつをパズル風にしてみました。慣れるまで難しいかも。。。 よーしお前ら!プリント集めるぞー! | フリーゲーム投稿サイト #unityroom https://t.co/3a7cSnlby5 #unity1week
— dashimaki (@oinorisimasu) 2019年7月11日
評価タイム
unity1weekではゲームを作るだけで終わりではなく、作った人たちがお互いのゲームをプレイしあう期間というのが設けてあります。
ゲームを遊ぶとゲームを作った人にゲームを遊んだ人が作ったゲームのリンクが表示される仕組みであるため、人のゲームを遊べば遊ぶほど他の人に遊んでもらえる可能性か高くなるようになっています
今まであえてほかの人のゲームを遊んでこなかったので、怖さ半分期待半分で恐る恐る見てみたんですが、あの、どこもこれもゲームとしての完成度が非常に高くてびっくり、っていうか、同じルールでやってるんですよね?あれ??
最初に思った印象は、大多数の人は自分とは違うステージで戦ってらっしゃるんだなってことでした、つよつよの集まりこわい…
それとやっぱり何かに特化したゲームは人の心に残りやすいなーというのも実感できますね、世界観とまで言わなくても、芯となるテーマがあったり、一言でどういうゲームか言えたりするゲームは…強い…たのしい…
ちなみに僕ランキングでは数式書いてコインを集めるゲームが面白かったです、プログラマー狙い撃ちみたいな内容でものの見事にクリーンヒットしました。(でもレベル6までしかできなかったけど…)
得られたもの
色々あります、色々あるなかで一番はやっぱり
コメントもらえるのは本当にうれしい
僕のめちゃくちゃ遅れて出したゲームとかでも遊んでくれるし、コメント残してくれる神のような人たち、神々がおわしますれば、その一柱一柱が感想言ってくれるんですよ、(感謝を表現できる語彙力がない)
今まで作ってきたゲームはTwitterで宣伝したりしている程度しかできなかったんですが、それだと直で感想もらったりすることってまずないんです、せいぜいリアル知り合いに遊ばせて無理やり感想言わせるくらい
それがこんな簡単に、もらっていいの??
本当にうれしく非常に励みになります…コメントを返す時も長文になりすぎないように調整するのが大変でした
自分、かなり斜に構えるところがありまして、お互い感想を言うことで評価がのびるシステム上に成り立つコミュニケーションなんでしょ?ってはじめは思ってました。(もちろん感想がもらいやすいシステムであることは確か)
でもコメント読むとしっかり遊んでくれてるのが分かるし、だからこそ自分も腑に落ちるところがあって素直に自分の中で消化できました
やっぱりゲーム作りに真摯に向き合ってる人たちだからこそ人のゲームに対して丁寧な感想が言えるんだろうな…
そういう人たちがゲーム作って、お互い評価しあって、モチベになって、またゲームを作る…
なんて健全な創作活動……達成感ジャンキーになってまう…
イベントに参加して、何とか作り上げて本当に良かったと思う瞬間でした
振り返り
反省コーナーです。
まずは目標達成度を確認します
- SOLID原則を意識したコードが書けるようになりたい→×
- コーディングの感覚を取り戻したい→〇
- 期日に間に合わせるように動きたい→△
主に中盤あたりまではクラス設計のほうは意識づけてやる様にしていました、ただし仕様が膨らんできたり脳に睡眠が足りていない状態だと徐々にできてない状態が増えてきてしまいました。
あと抽象に依存ってやつをやってみたかったんですが、そもそも共通化をする脳と余裕がなかったためノーインターフェースでフィニッシュしました
今までのコーディングでは一回書いたら二度と読み解くことができないものが生まれるのが当たり前だったので、進歩しているといえますが…目標達成には遠いですね
でも久々にコーディングできて楽しかったです、最初は配列に格納されたGameObjectを入れ替える処理ですらまともに書けなかったんで、コードまともに書かない期間のブランクは解消できた気がします。
期日…間に合ってないけど、間に合わせる姿勢とか対策は結果に反映されていたので…間に合ってれば文句ないんですけど…
って感じです。あとここに書いてない反省点としては、予定していない技術の学習をgamejam中にするのは極力控えるべきってことですかね
つまり、忙しい中Unity2Dのチュートリアルをやろうとしたり、一度も描いた経験のないドット絵に手を出したりすることです
ただ実装のお手本を見ときたかっただけなのにunityチュートリアルはじめちゃってた・・・・・・・・
— dashimaki (@oinorisimasu) July 2, 2019
反省しろよ?
まとめ
- 僕みたいなとにかく作ることが目標の人間も楽しめる
- ブランクあったけどわりといける(ただし遅刻有)
- 一週間それに費やすことにはなるかも
- ゲームっぽくなったときめちゃくちゃたのしい
- あそんでもらえたらはちゃめちゃうれしい
- コメントも貰えたらしぬ
是非次も参加したいですね、今度は腕力つけた状態で…