読者です 読者をやめる 読者になる 読者になる

Niwatori’s diary

鶏がプログラミングをする時に考えてること。

C#:Unityってやっぱり楽だけど難しい!

 

Unityが楽だからって、甘えられるなんてことはないんだよね。

 

C#の書き方も大分慣れてきた。

しかし、普段C++使ってるとC#の書きやすさはとろけそうなくらい楽。

一番は、メソッドやクラスの変更時にヘッダとソースを行き来したりしなくていいのがすごく楽。

 

ただ、当然といえば当然だけど、一ファイルに多量のコードが混在するせいでとても見辛くなりやすい。

まぁここら辺はクラスの分け方とか書き方とかプログラマーの方で対処できるし、見辛くなってしまうのはプログラマーの方が90%悪いと思う。

 

一つ、いつC#を使っても思うのは、グローバル変数を作れないのがどうもなぁ。

そもそもグローバル変数なんて作らないに越したことはないし、無いのが良いコードだと理解はしているけど、逆に無いとコードが汚くなるケースはごくたまにある。

特にUnity上だと、Unity的な制約が結構多いのでそこにC#流を厳守せよ、と言われると結構大変。

 

もちろん、グローバル変数が無いとどうしてもダメっていうケースは多くはないし、回避できないケースはそうそうない。

 

結局何が言いたいかというと、C#を使ってると、C++よりもクラス単位程度の粒度の小さい設計をきちんと考えるようになるなーっていう。

ちゃんと考えないと、汚いし効率悪いし、良いことないので、半ば強制的に考えさせられているとも言える。

 

これにUnityが絡むと、機能はいっぱいあるから良いものの、本来のC#ではない常に変化球的な書き方をしているみたいで若干の辛さも感じるんだこれが。

 

元々XNA使ってゲーム作ってたので、なおさら変なC#っていうイメージが強くなっているんだと思われる。

 

まぁ、なんやかんや言いつつ、C#様にもUnityさんにも文句言えるほどの技術レベルを持っていないので従うしかないのだ。

 

ちなみに、今回はグローバル変数をつかえないのがやだーって記事を書いたけど、そういう割にはグローバル変数を使わないアプローチで実装してみると、案外収まりのいいコードになるので、言うほど辛さを感じてないっていう。

 

すげーなーC#。面白い

 

 

開発の道草②

 

ゲームのUI、かなり難しい。

 

最近の開発状況としては、まずUnityのパフォーマンスを阻害せず、制作中のゲームに必要なメソッドを作って揃えている感じ。

それと同時に、ゲームのUIを作ってるんですが、イメージはある程度頭に浮かんではいても実際に実装するとなると、UIをどう配置したらいいのかわからなくなってくる。

 

先の記事でも書いたように最近DOTweenを導入したので、アニメーションを付けつつユーザーの邪魔にならないようなUIを考えているんだけど、どうにもしっくりこない。

 

色々とUI設計に関する記事を調べて見て、「あーなるほどー」とか思うんですが、いざ実装する時になると「えーでもなぁー」って感じになってしまいます。

 

もう収拾つかないので、細かいことは気にしないようにして何とか開発の足手まといにならない程度の演出を作って一旦ストップすることにしました。

 

難しいなぁ。

 

ちなみに、普段結構気を付けているんだけど、変なこだわりで時間をロスしすぎないように意識してます。

今回のUIについてもそうだし、普段の作業の中でも、ソースコードの書き方とか、設計とか、気にはしても、数分悩んだらキリのいいところを見つけることを最優先にして打ち止めるやり方を心がけてます。

 

結局物事の結論は一つだし、そこに至るルートを無限に考え続けるもの良いけど、プログラマーは生産してなんぼの生き物なんだと気づいた時から、パッパと切り替えて、多少の問題は抱えながらもフットワークの軽い開発もまた良いものだと思えるようになりました。

 

最終的には「パッパと最適解を抽出してさっさと実装して次に行く」という、確実性も生産性も高いプログラマーになれたらと思います。

 

ゲームのUIに関しては、自分自身結構ゲームやるおかげか、引き出しは少なくないと思うし、あとは下手に悩みすぎるところだけ気を付けよう。

 

 

Unity:DOTweenを使ってみた感想

 

結構いい感じかもしれない。

前までiTweenってやつ使ってて、それの方が使いやすい印象あるけど、ガッツリ使うならDOTweenって印象がある。

といっても使い込んだわけではないから本当に感想でしかないけど。

 

気になったのは、アニメーションを行うオブジェクトのインスタンスがないと使えないところ。

それこそもっと調べれば解決するのかもしれないけど、DOTweenって基本的にObject.GetComponent<...>.Do(...);って書くから、オブジェクトとアニメーションを切り離して管理することができないんだよね。

 

自分は普段Cocos2d-x使ってるんだけど、Cocosはアニメーションが一つのモジュールとして独立していて、ビュー系のオブジェクトに用意されているrunActionっていうメソッドの引数にアニメーションのインスタンスを渡せば勝手にやってくれる。

この場合、アニメーションを作成する処理は適宜ファクトリクラスみたいなのを用意することもできるし、他のクラスから引き渡すことができる。

これと比べると、DOTweenを使った時のコードはやや煩雑になりやすい印象があるかなぁなんて。

 

まぁ、郷に入ったら郷に従えといいますか、Unityにはこの形が良いと判断されたからこそDOTweenはこういう設計なんでしょうね。

まだまだにわかの自分が生意気言える領域ではありません。

 

そういえば、今日ちょっとした名言を聞きました。

「世の中には悪いものはない。」

というのは、悪いものなんて自然と淘汰されてしまうし、逆説的に、残っているものには多かれ少なかれ必ず良いところがあるということらしいです。

 

ただ、それだけです。

 

Unity:ビルボード実装について

 

Unityで3Dゲームを作るとき、高確率で「ビルボードが欲しい!」ってなるんだけどUnityには搭載されてなさそう。

なんでだろう。需要は少なからずあると思うんだけど、どうでしょう。

 

でまぁ、自分は大概transform.lookAt()Update()の中で呼ぶことで画像だろうとテキストだろうとビルボードっぽい動きを実装してきたんだけど、これ大丈夫なのだろうか。

まぁ、自分はスマホ向けに作っているわけでもないし、パフォーマンスを気にするほどの開発段階に来てはいないんだけど、lookAtって軽い処理ではないような気がして、使うのもなんか気が引けてしまう。

 

いいのか。まぁ、いいのか。

 

 

 

 

開発の道草①

 

 

ゲーム作ってるんだけど、開発中に思ったや感じた、なんてことない一言をシリーズ化して書いていくことにした。

このくらいハードルの低い心持ちじゃないと、定期的な記事の投稿なんてできなさそうだし。

 

で、記念すべき第一弾。

 

自分はWindows、Unity、VisualStudioっていう感じの開発環境なんだけど、Macの方でXcode使う時となんか違う感覚を得た。

別に、ついこの間WIndowsでUnity開発始めました!って感じでもないんだけど、さっきなんとなく原因に気付いたので書いておこうかなと。

 

でまぁ、VSって、プログラマーが書いたコードに対してより最適な書き方を提案してくれる機能があるんだけど、これはなんか今まで「コードを書くだけ書いて気になった箇所の最適化や高速化の仕方を調べる」っていう自分の勉強のプロセスとは違って、まるで「自分が書いたコードを家庭教師の人に付きっきりで見てもらいながらコードを打ってる」みたいな状況だな、と思いました

 

つまり、独学でなんとかしていくというよりは、より正しい記述の仕方を先生に教えてもらいながら書いていく、っていう感じ。

 

でさらにいうと、その感覚を得たことは別に対して重要ではない。

 

というのも最近、AI関連の技術が進化が著しい中、自分は特に恩恵に与かる機会は特にないと思っていたけど、考えてみれば今回の様な形でエディターから思わぬ助言を受けて「へーこんな書き方できるんだ」って思った以上、やはり見えない相棒に助けられていて、AIというほど賢くはなくとも、少なからず自分はありがたいと思っている。

 

でも僕はメンバ関数の呼び出しにthisを付ける人なので、いくらいらないとはいっても勝手に半透明にされるとちょっと気まずい。

 

 

もう一つ書きたいことがある。最近やっとUnityの使い方が固まってきた。

特にUIと3Dオブジェクトの管理はすごく悩んでいて、どう管理しても簡単に抜け道が出来てしまう上にUnityの使い勝手の良さを殺すような実装しかできなくて辛かった。

でも「悩むのもいいけどとりあえず作ろう」という気持ちでいろいろ思考錯誤しながらもコード書いてたら、ふと良い感じに収まったので今後は開発のスピードも上がりそう。

結構わくわくしながらコード書いてます。