2015年を振り返る

みなさま、お疲れ様です

木村です

タノシマスは昨日12月29日

開発に関しては仕事納めをしました

私はひっそりと今日を仕事納めに!

(トホホ…)

そんなわけで、2015年!

このブログ投稿を最後のお仕事としようと思います

さて、今年は私にとっていろいろあった1年になりました

その1年間を代表目線で、

簡単に振り返ってみようと思います

開発に関しては来る2016年に、

チームメンバーからアレコレと話してもらうとしましょう!

(話してくれるよな…)

1月~3月

この3カ月間を起業の準備に費やしました

はじめはホントに何もわからず、

法務局ってドコ?

そこに行って何をすればいいの?

登記って何?

どこに行けば登記ってできるの?

などなど…

浮かんでくる疑問を左から右へ

撫で切りするように解決していきました

基本的に、

誰に相談して良いのかすらわかなかったので、

ネットの情報を頼りに動いていましたが、

思いついたところに速攻で電話しまくって、

足を使って実際に動いた方が早いです

一番最初に向かったのは、

会計事務所の先生のところだったと記憶してます

そこで言われたのですよ

『会社建てたら、またおいで』

わかりやすいですね

ここじゃ会社は建てられないということですよ

会社名を決めて、企業印を作ることを告げられて、

で!

順番としては、先に司法書士さんのところへ行く

といったことを教えられるわけです

もちろん、

速攻で司法書士さんにアポをとって、

会いにいってきましたとも!

そこで登記場所やら資金やらの話を聞き、

次に向かうべきは銀行ということを知るわけです

銀行に行ってみると、

融資やら補助金の申請などについての話をされるのですが、

その時の私はあんまり意味が分かってなかったように思います

とにかく、

ヤダ・借金コワイ

ってことだけが頭の中をグルグル回ってたな…

そんなこんなで、RPGのようにアチコチを転々とし、

現れる敵を撃破していったわけですが、

最後の難関は、

登記場所を決めるということでした

拠点となる場所なので、

どこにしよう?ってのもあるとは思いますが、

それよりも難易度が高かったのは、

登記OKって大家さんに言ってもらうこと

これ、本気でクリアできる気がしなかったですよ…

出会いを求めて旅にでるような感覚ですもんね…

コレに一番時間がかかった

ま、幸いにも素敵な大家さんを見つけることができ、

事務所内の開発環境を作ることに!

創業前にも関わらず、

低予算でガンバル!

というスローガンを掲げていましたので、

デスクなどは部品を買ってきて自分たちで組み立て、

応接室などに設置してある機材などは、

ほとんどを私物を持ち寄ったりで補いまして、

結構、お金かかってないです!(YEAH)

・・

そんなこんながありまして、

当初の目標だった4月1日に創業できることになったのでした

IMG_5112

4月~6月

一番最初にやった作業は、開発メンバーの募集でした

なんと、創業したにも関わらず、デザイナーが社内にいませんでした

そこで、とある場所に求人を出してみたのですが、

誰からもまーったく音沙汰がありませんでした

ま、ホームページがあるわけでもないしね…

その当時のタノシマスは、

どう考えてもアヤシイ会社だったと思うのですよ…

仕方ないと言えば仕方ない…

結果的に、

応募はこの後2カ月間、1通も来ませんでした

そして、求人を出した後は銀行さんと面談をくり返しまして、

なんとかかんとか融資を受けることができ、

ほどなくして創業補助金の申請資料を一式揃えることに!

事業計画書ってのを書くことになるんですが、

これがなかなか理系の私には厳しかったですね…

頭の中に大凡の構想とかを思い浮かべることができるんですが、

それを文章に起こすとなると難しいわけです

ホント、文章をお仕事にしてる方ってスゴイなと…

苦戦しながらも、事業計画書を作り上げて、

その他の資料もすべて集め、申請自体は完了させました

大体こんな感じであっという間に4月は終わり、

5月になると、

前もって制作をお願いしていた名刺が出来上がったので、

創業のご挨拶にいろんなところに行ってみたりしました

IMG_4979

そしてこの間、

並行して藤岡くんと二人っきりで細々と開発をやったりしてました

誰に渡すわけでもないのにバッヂを作ったりもしたっけ…

IMG_4986

当初は3Dモデルを使ってシューティングゲームを作ろうと思っていたので、

それ用のライブラリを作ってみたりしてましたね

(といっても作っていたのは藤岡くんだけど…)

そんなこんなで5月もあっという間に終わり、

訪れた6月の中旬、

あまりにも求人に応募がなかったので諦めていたのですが…

キマシタ!応募!

(ヤフー!)

しかも2通!

はい、おそらく求人を出して2ヶ月間、

きっと求人票が貼られていなかったんでしょうね…

面談の結果、二人とも採用しまして、

こうしてタノシマスメンバーは4人になったのでした!

IMG_6431

映像デザイナーのタナカくんことFireFly

IMG_6429

グラフィックデザイナーの貝沼さんことユウリさん

これでもうさみしくない…

この後も、ありがたいことに応募がいくつかありました

興味を持っていただいた方々、

本当にありがとうございました

7月

ここでちょっと開発的には寄り道をすることになります

開発メンバーも増え、運営コストを少しでも稼いでおこうと、

外のお仕事を引き受けてみようかと考えたんですね

結果的には仕事には結びつかず、

ただただプログラムを解析しただけという

無駄な一カ月になってしまったので、

ここで代表である私は、

ココロに強く誓ったのです!

自分たちでゲームを販売しよう!

と…

真面目な話、確実に仕事につながる制作をしないと、

ただのサービスになってしまいますから、

そんな余裕はありません…というのが本音です…

4月に申請した補助金が採択されたのが、

この決断を後押ししたのも事実です

IMG_5071

8月

先月の反省点を踏まえ、8月は開発強化月間と称して、

ゲームを自分たちだけで作れるところまで作ってみる!

ということを目標に、

それはそれは朝から晩まで合宿のようにメンバー全員で開発に勤しみました

デザイナーの二人は開発をはじめて経験するということもあり、

紆余曲折、いろいろありましたが、

この時点で『アカとブルー』のサンプルゲームは一度完成したのです!

IMG_5475

9月~10月

ここからはクオリティーアップとシステムの構築に奮闘してましたが、

正直、うまいこと予定を立てて進行させられず、

スケジュールは大きく遅れることになってしまいました…

とは言え、失敗の中に成功へのカギがありますから、

私的にはこれはこれで良かったのかもしれないと思っています

・・

結果として、この失敗を元に、

『アカとブルー』は一度、ゲーム構成を大きく見直し、

当初は、ステージごとに与えられた目的を達成するとクリアとなる

ミッションクリア型のものを想定して制作をしていましたが、

ステージの最後に待ち構えるボスを撃破するとクリアとなる、

ボス撃破型のゲーム性となるように制作方針を変更したのです

まだ見ぬ何かを作り出す前に、

基本に忠実なゲームを制作した方が、

迷いなく進められると踏んでの決断でした

IMG_5665

11月

イケダミノロックさんの番組に呼んでいただいたことを機に、

『アカとブルー』のゲーム画面を動く形で公開しようと思いまして、

みなさまにお見せできる最低限クオリティーのものにしようと、

自分たちの中で制作における〆切を設け、

それに向けてこれまで作ったものをほぼすべて作り直しました

ここで、滑り込むようにホームページが完成!

良い流れのまま、ゲームも公開することができ、

ご協力いただきました方々には、

ホントに感謝してもしきれないくらい、

背中を押してもらえたように思います!

KMRとミノロックさん1

そのときの映像はコチラ ⇓

イケダミノロックのそんなカンジでおネガいします

12月

11月にゲームを公開したのを皮切りに、

8月からはじまった開発で起こった失敗のすべてを反省し、

とにかく環境改善に勤しみました

これ以上、スケジュール遅延を発生させると、

みなさまの元に『アカとブルー』をお届けできるのが遅くなってしまう

これだけは避けたい!

ということで、

チームメンバーがこれからの作業内容を把握し、

クオリティーアップをしながら制作できるようにするには

どうすれば良いのかというのを必至に考えた1ヶ月でしたね…

総括

代表というものをはじめて経験した1年であり、

自分としてはうまいことやれたかというと、

そんなことはないと思いますが、

とにかく充実した日々を送ることができたように思います

元々、社長業のようなものを傍目で見ていたわけでもないので、

どこにお金がかかるのかなどわからないことばかりで、

些細なことでも悩んでしまい、何度も諦めそうになったこともありましたが、

その都度、家族や開発メンバーに支えてもらえたおかげで、

何とか乗り切れた!といった感じです

日頃は恥ずかしくて言えませんが・・・

みんな、本当にありがとう。

出会えたこと、共に働けていることに感謝しています

来年2016年は、

今年2015年にコツコツと作り、積み上げたものを全て出し切り、

待ってくれているすべての人の期待に応える年にしたいと思います

改めまして、

今年出会えた方々、起業・創業にあたり、力を貸してくださった方々、

タノシマスを応援してくださる全ての方々に感謝の気持ちをお伝えします!

今年もお世話になりました

本当にありがとうございました

来年もタノシマスにご期待・ご協力のほど、よろしくお願いいたします

株式会社タノシマス

代表取締役 木村浩之

Permalink  |  2015/12/29 + KMR

【雑記】開発チームについて

みなさん、お疲れ様です

木村です

昔からそうですが、

開発をしながらのブログ更新って案外大変で、

なかなかうまい具合に行かなかったりするのですが、

流石に一週間も何も書かないというのはマズいので、

サボってるわけじゃないだぜ…

今回は我々、

タノシマスの開発チームについてお話をしようと思います

うちのチームの構成ですが、

プログラマー1人

デザイナー2人

プランナー兼雑用係1人

の計4名となっています

この4人のうち、

デザイナーである2人は

アルバイトで且つゲーム制作未経験

特に将来ゲーム開発をやりたいといったわけでもなかったりします

人にうちのチーム体制のお話をすると、

『安くつくるためでしょ?』

みたいなことをよく言われがちですが…

実は違います

良く考えて下さい?

他えば、玄人を4人集めて1ヶ月ゲームを制作をしたとしましょう

そして玄人1人に対して、月100,000円のお金を支払う

この場合、1月に開発にかかるコストは400,000円になりますよね?

この場合、スピードを要求されますし、

クオリティーも保証されていないといけない

しかし、

同じ内容のゲームを、

玄人2人と素人2人で作ると考えますと、

作り方を教えなくてはならなかったり、

手直しをが多かったりするので、

玄人4人で開発を行ったときと同じようにするのは

非常に難しいのです

そこで!

1月の余剰分を設けて開発を行うとしましょう

玄人1人に対して、月100,000円のお金を支払い、

素人1人に月20,000円のお金を払うとすると

玄人2人で200,000円×2ヶ月で400,000円

素人2人で40,000円×2ヶ月で80,000円

となり、

この場合の2月にかかるコストは480,000円となります

え~

おわかりでしょうか…

高いうえに納期が遅くなるといった実情があるのです

結構大きなデメリットですよね…

ということで、

うちのチームをこのような構成にしているのは、

決して安くつくるためではない

です!

この辺のコスト感覚を見誤って、

過去に失敗したプロジェクトをいくつも見てきました…

こういうことって、

数字だけで見れるような内容ではないんです

じゃあ、

なぜタノシマスは敢えてデメリットのある方を選んでいるのか?

それにはいろんな意味があります

全部紹介するのはアレなので、

思いつく大きなものをいくつか紹介します

理由その①

ゲームを作った経験のある者と無い者が組んで

ゲームを作るとどうなるのかが知りたかった

長いことゲーム開発をしていると、

知らないうちに固定概念を持ってしまい、

自由に発想することができなくなったりしがちです

そこに、

開発経験のない者の自由な発想を持ち込むことで、

何か新しいモノができるのではないだろうかと考えたわけです

正直、

半年ほどやってきてこれについてはうまくやれていません

これについては今後、

何か実を結ぶのではないかと期待をしています

理由その②

これまで僕がゲーム開発で失敗した経験や、

そこでとった打開策で活かせそうなことを、

次の世代に何かしらの形で伝えたかった

ひょんなことから、

世間に出れば

社長!社長!

などと言われてしまう立場になってしまいましたが、

僕も過去にはたくさんの失敗を経験しています

成功続きだからここまで来れたのではなく、

失敗から打開策を打ち出し、

乗り越えてきたから今の僕があると思っています

とはいえ、

人1人ができる失敗の数なんてものには限界がありますからね…

伝えることで役に立つなら、

先に伝えておいて損はないと思います

ホント…

そして、

自分がやってきた

ゲーム開発を通してのモノづくりの経験って、

作るものがゲームじゃなくても通用するものだと思っています

大切なのは

お客さんに驚きや感動を与え、

喜んでもらうことに尽力する心意気

これって別にゲームだけに限った話ではないです

そういったことを開発未経験の方に知ってもらい、

後のモチベーションにしてほしいと思ったのでした

理由その③

チームとして成長していきたいと思った

元々、僕が起業した大きな理由は、

自分のチームを持ちたかったから

だったりします

何かを伝えられる方も、

理解したりと大変だと思いますが、

何かを伝える方も、

理解してもらおうと躍起にならないといけません

開発経験者と未経験者が一緒となることで、

お互いが成長することができる

そんなチームにしたかったわけです

理由その④

僕が寂しかったから

これまで仕事に一生懸命になっていたら、

知らないうちに孤独を感じるようになってまして

変に偉い人!って思ってほしくなかったので、

僕のことを全然知らない人がチームにいてほしかったわけです

コレ、ショボい理由に思われがちですが、

結構切実なんですよ?

他にもいっぱい理由はありますが、

大体おおきなところではこんなもんです

幸いにも、

こんなヘッポコ社長であるにも関わらず、

みんな文句も言わずついてきてくれて

大変ありがたく思っております

最初は結構手こずりましたが、

今はそれなりにうまくやれるようになりまして、

ゲームも着々と完成に向けて出来上がってきております

来年、その成果をみなさんにご覧になっていただけるのを

楽しみにしつつ、2015年!

最後まで開発をがんばります

ご期待ください!

Permalink  |  2015/12/19 + KMR

【技術雑談】Unity5.3リリース

お疲れ様です、プログラム担当の藤岡です

世間では Advent Calendar の季節ですね

参考になるものや面白いものまで、

非常に楽しく見て回っています

僕も何かやりたいと思っているんですけどね…

今はアカとブルーの開発が忙しいのでなかなか…

そういえば!

先日 Unity5.3 が正式リリースされましたね

Unity5.2からの更新内容については、

公式含め色んな方がまとめているので割愛するとして…

では実際に更新すると、

既存プロジェクトにどんな影響が出るのか?

今回は自分が実際に試してみて、

わかったことをご紹介していきたいと思います!

① なぜかiOSの入力精度が上がった(謎)

アカとブルーでは、

Input.touches[0].position の差分で

指の移動を検知しているのですが、

2フレームに1度、

同じ座標が送られてきて移動がガタつくことがありました

 

Unity5.2 まで私 のiPhone5/iOS9.1(※) と、

iPodTouch6G/iOS9.1 において、

その現象を確認しています

※iOS8.3だとUnityアプリはXcodeでのチェックが出来ず、
  アップデートを強いられるハメに・・・

iPadMiniRetina/iOS8.2 では、

この現象は確認できなかったので、

画面サイズなのか?

はたまた

Unity が iOS9 に対応していなかったのか?

実際のところわかりませんが…

いずれにせよ、

iPhone と iPodTouch でしか発生していない現象でしたので

こちら側で如何ともし難いところではありました

それがなんと!

Unity5.3 で完全に解消されてました!

3DTouch 対応の為に、

Input 周りがいじられたと考えられますので

副次的に改善したのかもしれませんが、

iPhone 環境下での操作性が劇的に改善され、

僕は喜び勇んでいたのです!

がっ!

喜び勇んでいたのも束の間、

ここで別の問題が浮上するのです…

② uGUIのTextでdynamic font以外は座標がズレる

Twitter で検索したところ、

海外の方にも同様の現象が発生しているようでして、

bitmap font が上にズレます

キャプチャ

全部ズレる

助けてください

仕方が無いので、

フォントをアトラスかした場合に正しく表示されるかどうか…

休日にでも検証してみようとは思ってますが、

フォントというか…

uGUIのTextの問題のような気がしてならないので、

対応できるかどうか・・・

Dynamic Font は今までどおり問題ないですが、

uGUI を酷使してるプロジェクトで、

上記のような現象が発生した場合は、

Unity5.3 への更新は見送った方が良い気がしてます

(パッチー!はやくきてくれー!)

 

③tvOS の BuildSettings はあるが PlayerSettings がない

Define Symbol をスクリプト側から一律設定してはいるのですが、


private void SetDefineSymbols(string symbol) {

foreach (BuildTargetGroup target in Enum.GetValues(typeof(BuildTargetGroup))) {

if (target == BuildTargetGroup.Unknown)

continue;

if (target == BuildTargetGroup.tvOS)

continue;

PlayerSettings.SetScriptingDefineSymbolsForGroup(target, symbol);

}

}

tvOS はPlayerSettings がないので設定しようとすると

怒られます

④SceneManager 実装によって ActiveScene のID取得が変わった

新しい namespace ができましたね

UnityEngine.SceneManagement.SceneManager

僕のところでは、

Scene は文字列でなく、

全て『定数』で管理しているので、

今まで Application.loadedLevel で

現在のシーンNoをとっていたところを、

SceneManager.GetActiveScene().buildIndex

に変更する必要がありました

しかしながら、

僕は namespace の using 宣言は極力減らしたい派なので、

一回しか使わないようなものは

namespace をしっかり書くのですが・・・

UnityEngine.SceneManagement.SceneManager.GetActiveScene().buildIndex

…うん…冗長…

その他、

Application.LoadLevel とかも、

SceneManager.LoadScene に修正しました

この辺は記述を変更するだけですね

ということで、

今のところ、

僕が実際に試してみて確認できた影響は上記4点となります

入力が直ったことは本当に嬉しかったですし、

ParticleSystem のローカルスケールも対応したらしいので、

uGUI の Text をカカッとパッチで対応してくれれば

もう言うことありませんね!(切実

次回は何を話そうか…

何か書きます!

おたのしみに!

 

 

2011/12/11/19:11 追記

AndroidでSpriteRendererのBatchingが5.2に比べて異常に重くなってる・・・?

Permalink  |  2015/12/11 + フジオカ

【朗報など】いろいろ報告

みなさま!

お疲れ様です

木村です

朗報その①

先のエントリーで点火しなくなったストーブですが…

なんと!

見事に復活を果たしたのであります

ストーブ復活!

これで開発室も暖かくなり、

より一層がんばることができそうです

(焼き芋が作れるぞ!!)

朗報その②

先月11月25日に僕が出演しました

イケダミノロックのそんなカンじでおネガいします(仮)

20回目ですが、

アーカイブとしてYoutubeにUPされたようです

当日、お仕事などで見逃してしまった方々、

是非、ご覧いただければと思います

配信中の画像

見逃した方はこちらをチェケラ!!

朗報その③

さて、タノシマスメンバーが一丸となって

現在開発中のスマートフォン向け本格シューティング

アカブルー

ですが、

iOSとAndroid

両方に対応します!!

(Unityを採用してますからね)

同時に発売できるかわかりませんが、

既に弊社内では両方の端末で動作しております

Andorid版 アカとブルー

Andorid端末を利用しているユーザー様に

これまで大変申し訳ないことをしたと思っていたので、

今回ははじめから両方のOSに対応させることを

決めていました!

なので、

今度こそご期待くださるとうれしい限りです!

また、うちのメンバー達が

さらなるクオリティーアップを図っていますので、

来年の早い時期にはまた一味違ったものを

お見せできると思っています!

きっと…

きっと…

きっと…

そんなわけで、

乞うご期待!

Permalink  |  2015/12/10 + KMR

アカとブルーの技術話その1【UnityでSTGを作るということ】

お疲れ様です、プログラム担当の藤岡です

今回は技術話ということでUnityでSTGを作る上での話をご紹介しようと思います

(※今回言っているSTGとはいわゆるiOS/Android環境下における2D弾幕系のSTGと定義します)

先に補足しておくと僕はSTGについてはド素人で何もわかってないですし、作ってみたのも今回が初めてです

(関わったことはありますがUIやiOS/Androidライブラリ担当だったので・・・Androidライブラリは日の目を見ませんでしたが)

なので、「コイツSTGをわかってない!」と思われることもあるかと思いますが、実際わかってないことをご理解ください

そして書いてるうちに盛り上がって、ちょっとくどくなってしまいました…

すみません…

さて、気を取り直して続きを…

STGというジャンルはゲームの進化系統図においてほぼ根幹に位置すると僕は考えていて

始祖は、皆さんがご存知のインベーダーになるんじゃないでしょうか

(ビデオゲームそのものとなるとPONGとかの話が出るんでしょうが・・・その辺は話が逸れるので)

そんな根源的であるジャンルにおいて、文字通り死ぬほど重要視されていると思われるのが、

「操作」「動作」ではないでしょうか?

「操作」における重要度

操作における重要度というと、

過去に、某案件で入力遅延が(僕の知らないところで)発生しまして、

取引先からちょいちょい電話で釘を刺され、

上司からドヤされストレスで血便が止まらなくなったぐらいトラウマでして…(実話)

スマホ(タッチパネル)における「操作」については、

未だ納得がいかない人もいるかと思いますが、同ジャンルのアプリを見ていると、

個人的な見解ではありますが、ある程度結論は出ていると思っています

ボタン入力の有無については、個々、人の好き嫌いかなと思ってますし、

3Dタッチが標準になればまた変わるかなとも考えています

入力遅延についてはハードウェアやOS依存の部分が大きいので、

アプリケーションレベルでは解消しきれないのが実情です

正直、操作感覚だけで入力遅延を感知出来ない鈍感な僕は、

コードレベルで遅延が発生しないようにすることしか出来ません

そして今回、

問題になるのが「動作」です

まずメモリ

iPhone3GS時代は100MB、iPhone4/4Sで150MB、iPhone5/5S/6は200MBが

単一のアプリが使える量のデッドラインと考えています

一般的なスマホユーザーは常に複数個のアプリを起動させますので

やはりiPhone6が1GBしかない現状で200MB以上メモリを使用するのは利便性がよろしくないと考えています

(Infinity Bladeのようなハイエンド端末のベンチマークアプリはまた例外と思いますが・・・)

とは言え数字だけ見る人達からすれば使用メモリ量は売り上げにならないことなので、

そこに予算や期間をなかなかさいてもらえないのも難しいところです

特に2DSTGでは、もっぱらコマアニメーションを多用しがちなので、

テクスチャサイズや枚数について何をどの程度使うか厳格に決めねばなりません

ちなみにAndroidは、Javaの仕様上物理メモリが多いほど、

端末全体の動作が安定するとかなんとか・・・(超適当

次に処理負荷

STGのようなアーケードライクなジャンルは、やたらと60FPSを要求されます

STGにおいてはやはり”物量”がものを言いますので、

ビックリするほど大量にオブジェクトを表示させることが一番の課題となります

今回はマルチプラットフォーム対応としてUnityを採用しています

(それだけが理由ではないのですが割愛)

処理負荷を考えるにあたって、Unityを採用することで起きる問題というと、

大きくは以下の2つに分類されます

1.Unity由来の問題

2.C#由来の問題

1については、Unityを正しく理解する学習コストがかかる、

またはUnity側のアップデート対応を待つしかないという問題が発生します

事実、Unity暦4年目ですが未だに全てを把握出来てません

2については、90%がGC(Garbage Collection)の問題です

今まで「UnityでSTGは作れない」とおっしゃるベテランの方が非常に多かった印象ですが、

基本的に、矩形ポリゴンが容易に出せないことが大半の原因を占めていたように思います

当初(Unity4.0時代)は、僕はNGUIで無理矢理2Dゲームを作っていましたが、

NGUIがそういう使い方を想定していないので処理が遅すぎてお話になりませんでした

既にUnityを使用して開発をしている皆さんはご存知かと思いますが、

Unity4.2においてSprieRendererとQuadが実装されました

もう正直これだけで、UnityでSTGが作れない理由の8割は解消しました

残り2割はUIの問題です

Unity4.6からuGUIが実装されましたが、

根本的なパフォーマンス問題はNGUIと大差なく

Unity5.2から大幅改修が入りましたが、

未だにデリケートな場面で採用するかの判断は迷うところです

(※メニュー画面では活躍すると思います)

そんなわけで、結局エネルギーゲージや体力ゲージのような部分は

自前でMeshRendererを作るのですが・・・(不毛な作業です

スプライトを反転させるにも、

マテリアルのカリング設定をOFFにして逆向きに回転する手段しかわかりません

(方法があれば教えてください)

Unity5.5までのロードマップでは、2D関連の更新が多く予定されているので、

その辺りはいずれSpriteRendererで全部対応できるんじゃないでしょうか

コードレベルでのUnityのパフォーマンスを引き出すTIPSについては、

また別途ご紹介したいと思います

C#、というよりは.NET Frameworkと言うべきなのか

いいところはたくさんあるのですが、GCだけはいただけない

他にもUnityC#で明示的なインラインコードの書き方を知っている人がいたら是非教えてください(切実

GCを止めるには、GCが許容出来ない場面でのヒープの確保をなくすことが必要になります

(※抑えるということではない)

GC発生時の処理負荷も確保した量ではなく、

確保した個数によってふくれるという話(検証したわけではない)なので

細かなヒープのつまみ食いこそが危険だと考えます

C#におけるヒープを食うありがちな要因はstringです

stringを使う場合は放射性物質を扱うがごとく、メモリをこぼさないようにしなければなりません

他にも、foreachは内部でヒープを食っている疑惑や、

そもそもforより遅いしでEditor拡張以外では実用的ではありません

delegateのインスタンスも必ずキャッシュするようにしています

(当初気づかずにラムダ式でコールバック設定して毎フレーム食い散らかすという失敗が・・・)

GC以外にも細かな処理速度には気を配っていたりはします

Collection系は参照速度が遅いので固定配列にします

Propertyの{get; set;}も、コール時のオーバーヘッドが気になるので、

極力メンバの宣言を省略せずにメンバの実体から参照するようにしています

そんな不毛な作業を繰り返せばパフォーマンスは上がりますし、

C++だとかC#だとかっていう垣根は言語宗教の域でしかないと思っています

いずれ、検証結果を交えたコードレベルでの

C#におけるパフォーマンスTIPSをご紹介したいと思います

長くなってしまったので実用的な紹介は次回以降の技術話でやっていきます

次回はまた、舞台裏のお話

敵配置のやり方をご紹介しようと思います!

お楽しみに!

Permalink  |  2015/12/04 + フジオカ