メモ(memo) - TejimaTuyoshi/returnread GitHub Wiki

日本の教育は「いい加減」。

プランナー　＝　「予定を立てる人」ではなく、「ゲームをプログラム以外で作成する人」。

企画書　＝　「お金を獲得するための説得素材」。いわば、納得させるためのアイテム。

目標を達成させるために必要であり、「自分のため」ではない。それは意味はない。

これは、ゲーム会社にいないと「ゲームにどれぐらいかかるか」も、「課金額」もわかりません。

というか、ターゲットは「課金勢」である。まぁお金欲しいからなぁ。

課金しない人たちは、「デバッガ―」のような形で「仕事人」である。というより「ゲームに遊ばされてる」。

これから抜け出せないと、「お金を取る側」にはなれない。

「ゲームが好き」という人は腐るほどいる。だから、そういう時は「尖って」みよう。

まぁ、「損得感情」だからね。社会の動き方における有用な方法は。

ちなみに最高の企画書は[1P]のみ。

プランナーの人は、企画書よりゲームの方が良い。

やる気＝きっかけ×うごく×つづける

きっかけ＝目的

うごく＝コード

つづける＝やり続けること

とりあえず「やる」ことが「つづける」ことにつながる！

自分を「追い込む」。

やらないと「〇ぬ」という環境を作る。

仕事=生きるために必要。

追い込むために「締め切り」を決める。

一日3時間が限界...=>その間にできることをやる。

「だれか」と作る。

他の人がやる=>自分もやる！

ただし、さぼると進捗が足踏みするのはNG

だれかと一緒にやるのはアリ！

☆きっかけの作り方

⓵使命感

私が作らなきゃ...何も変わらない...!!(絵描きが多い)

⓶敵を作る

あいつはいい物を作るが...俺はあいつより上手いんだ...!(ライバル思考)

⓷覚えるための仕事

知らないからやってみよう！(挑戦思考)

持ってると良い。

⓸金

お金をもらうための「道具」

一旦お金がもらえるかの挑戦をすると企業内でも慣れる。

⓹名誉

お金を求めるのは...

でも、「チヤホヤ」されたい...(実績に近い)

「自分」より「他人」。

企業にはあまり向かない。

☆続ける方法

⓵自分をほめる

インターネットに上げることでほめてくれる人は多い。

⓶作業に楽しさを見つける

楽しい＝続ける

=>楽しい環境にいる。

⓷習慣化

とりあえずやる=楽しさにつながるかも?

仕事であれば必ずやる=習慣

⓸小さい物と大きい物を交互にやる

詰まったら別の部分をやる=ゲームになってくる=>続けたくなってくる。

⓹そもそも論

そもそもこんな状況なんだよね＝その状況下でできることをすればよくない？

どんなものを作ろうとOK

⓺戦友を見つける

同じくらいのレベルの人と張り合いをする(会話)

技量が離れすぎるとイライラ...

話してて面白い人を探す。

☆時間の使い方

バイトで時間を使う際、「何のためにバイトするの?」を考える。

時間の使い方は逐一振り返ることも大事。

ゲームを作り方にも時間は考えるもの。

「どこ」に時間をかけるかを考えよう。

やれないものを作らない方が良い。

☆業界に入る「覚悟」。ありますか？

覚悟の違いで就職の勝敗が変わる。

「ヌルイ」やつには負けるな！

☆ゲームに置き換えて考えることも

Wiki読んでいるだけでもできないよね？

実際にやってみないとわかんないよね？

じゃあ実際にやってみよう！

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

自分のベストを尽くせるところは尽くす！

できないところは落とす。

失敗するかもしれないが、「やれる！」と思ったらやってみる。

二つの目に見える行動は「勘」と「情報制度」(勘:仮説を立てることができる)(情報制度:仮説を具体性に刑していくためのヒントと、ヒントの精度)

これらは「調べること」で知ることができる。

分からないなりに推測する=「勘」

やり方、実装方法->「設計」を考える->使える「デザインパターン」を考える->「ソフトウェア」で解決する ==なんとなくでは✖できる用に代わる。

仮説を具体化する=「情報精度」の向上

何作ろう...->調べる->やってみる。->できた!＝＞この繰り返しなのでOK

これいいのか？と疑問に思うかもしれないが、修正してみることで、さらに知ることが可能。

ゲームの要素内で欲しい物があるので、別の要素を消すのはアリ。

とりあえずゲームを作りたい=> やりたいことや設計はすぐ行う。

上手く失敗することが大事。

失敗=経験や対策の一種になる。

バグを出さない人=コードを書かない人、というぐらい失敗する。

ユーザーに迷惑になるバグを出すと怒られるが、それ以外であればそこまで怒られることはない。

なので、出す前に何度も確認してバグが出るか確認して失敗しまくること。

失敗した際の「保険」をあらかじめ残しておく。

挑戦的で量も多いことをしよう！

質より量とは言うが、「量をやる人は質も良くなる」

正直、授業より自分で調べることの方が大事。

検索するときの対象=>GoogleやGTPより「人に聞く」ことが大事。

公式のフォーラムに見に行くこともアリ。

分からない場合は、「何について知りたいか」を一度振り返ってみる。

なかなか見つからない=>検索環境,検索の目的の変化

GTP=>厳密な回答は求めない。めんどくさい質問はしない。

余計なことはしない。(ゲームプログラムだけにすること。)学校にまで影響が出てしまう。

信念とイキリを間違えない。=>自分の強い思いだけを通す。勝って兜の尾を絞めよ。

書類は早めに作る。=>作品に関してはたいして変わらない。

面接は練習を絶対する。=>必ず「ダメ」な場面を教えてもらえることはない。(面接に「勉強」はNG)

全てうまくいくとは限らない。=>無理なものは無理と言おう。

挑戦的なことをやる場合、必ず「バッファ」を持とう。(余裕を持つ。)

やめるときは「円満」にやめること。=>業界は狭い

世の中何が起きるか分からない=>未来なんて読めないよね。

燃やしたやつより、その状態を誘導したやつが悪い。=>犯人は一人じゃない。

仕様が決まらない。=>側は後。

パフォーマンス激悪=>定期的にやろう。

連携不足=>しっかり情報を伝達しよう。

プレイングマネージャー=>マネージメントとプログラミングを両立させてはいけない。

せめて、「実装させる」人と「書く」人は分けること。

終わりよければすべてよし。

最終的にうまく動いて利益につなげることは、逃げない事が大事。

しくじった後が大事=>やらかしたら逃げずに「やる」こと。

コネ大事。知り合った人から話がもらえることも。

転職は「コネ」が大事。

業界は狭い=>友達と仲良くすることで「コネ」ができる！

世の中には「チャンス」がある。

フリーになる=>お金をもらえない可能性も。

やばそうな会社は逃げる=>やりきるより「生活第一」

噂が聞こえてきたらやばい。大手でも起こりやすいので注意。

エンジニアは天下の周りもの。=>転職は普通。役職以外は使えない説。

「会社に依存しない考え方」は大事。

出戻りもある。

お金のある会社ならOK！=>給料が少ないなら反乱しようね。(ITはちゃんと払われている。)

回避ができるしくじりは避ける。

しくじりには「学び」がある。

チャンスは全力で生かす!=>チャンスを掴めるかは自分次第

運だけでない「コネ」も大事。

人生すごい失敗を１回しても大丈夫。

人生を「賭ける」ことも大事。

小さいことばかりでは変わらない。

大きいことをすれば変われる!

成功する人=>「継続」と「運」である。

当たるまで「続ける」。運に頼らない成功を何度でも行える会社が良い。

過去の出来事を「笑い話」にできるようにする。=>キツイことを引っ張るより、「それを笑い飛ばす人」の方が人が寄ってくる。

やりたいこと≠できること。

やりたいこと=>自分が「気づく」かどうか。

他の人ができないこと=>自分だけの特権なので「強み」として売ることが可能。

他の人がやりたくないこと=>手がついていないので入りやすい。

自分は何ができるか=>業界に入っても、「何ができる」のかを分析しよう。

次何が来るかを考える。=>「流行として」だけでない。

最初は避難される。=>進んでいけば許容される。

ゲームってダサい?=>ゲームが流行らなくなってきた。「Youtube」とかに移った。

流行っている物にゲームを結びつければ...?

ゲーム=>コスパはいいがタイパが悪い。「消費」されるので。

ゲームしなくても「ゲームできる」。

ゲームが「配信寄り」になる。=>生放送が多く「流行っている」ため。

「出尽くした」はない。=>新しいものを作れないと文句を言われるが、「うるせぇ、行こう!」のノリで新しいものを少しずつ作っていく。

価値ある未来を考えよう。=>否定意見なんて吹っ飛ばせ!(やりすぎ厳禁)

未来わかんない=>新しいものに飛びついてみる。

新しいものが作れる。=>「他の人にできる」状態。

自分にとってやりたいゲーム=>世の中にないゲーム

やりたいゲームを作ってみる。

未来の自分がどうしたいか。=>その就職先がゴールなの?

自分が何をしたいか、どんなものを作りたいかを考えること。

自分の価値って考えてる?=>どういう生き方をするか考えてる?

どんな「生き方」をしたいかを考える。(野望や目標)

ゲームを作るなら、「設計」を考える。(テキストより図のほうが良い。)

作る順番は、決める(そのゲームに必要不可欠な部分から。)

無くても進むけど、面白くなるものを後付けする。

それぞれのオブジェクトには「何ができるのか」をはっきりさせる必要がある。

共通にできそうな部分は、「管理させるオブジェクト」を作成する。

最後に「いくらでできるか」を見積もる必要がある。

デザインパターンは40年前から変化している。

多重継承。ダメ。

「ゼロ」があるかどうか=>データが「必ず設定されるもの」かどうかを判断する指標。

データが必ずあるものとして設計された場合、当然ですが、データが設定されなかった場合はエラーになる。Nullもこれに含まれる。

「たくさん」があるかどうか=>データが設定される場合、

「データが複数個設定される可能性があるかどうか」を考える必要がある。

「1つだけ」のものを処理する場合と、「複数ある」ものを処理する場合とでは、コードの書き方が大きく変わってくる。

「ソート」にもいろんな種類がある。時と場合によって使い分ける必要がある。たとえば、出力が同じでも、メモリの量や計算方法が異なるため使い分けよう。

ツリー構造=>親から子に伸びていく方法。

タスクシステム=>ツリーの一本バージョン。親ー＞子ー＞子のように、枝分かれはせず筋のようにつながっているもの。

(複数の)条件式と、(複数の)実行コード=>フラグ管理によるイベント実行に使われる。

ゲームを作るにあたって「限界」はある。ハードにできないことをしても意味がない。

これは「ネットワーク」で起きやすい。たとえば、「電波状況」。ラグは必ず起こるもので、直せない。

そんな形でやろうと思っても「できない」ことはある。

そのうえで「どうやって平等性を持たせるか」を考える必要がある。

ちなみに「企画制作」の時点で起こるのであらかじめ言っておこう。

人間はミスをする=>人間を信用してはならない。=>機械にチェックしてもらう。(IT化)

とりあえず「チェッカー」をプログラム上に置こうね。

正規表現と置換=>%PlayerNameこんな変数を作って「置換」している。

この置換が多くなってくると重くなる。

Regexというクラスが、正規表現を実行するクラス。

ビット演算=>以下の理由でない限りは使わない方が良い

• 何らかの理由で変数を増やしたくなく、複数の変数を必要とするとき(マスターデータなど)

• メモリが少ないマシン(ラズパイやゲームボーイなど)で動かしているとき

• フラグを使用するオブジェクトがとても大量に作られるとき

• GPUなどで処理をするうえで変数の転送コストを下げたいとき

プログラマのことだけのコードは2流=>一流は使う人のことを考える。(プランナーやデザイナーなど)

プログラムは難しくない。=>Unityが難しい。(Unityの使い方なの?コードなの?)

時間をかけるところをしっかり考える。

ワナビー(できなくて放っておく人)はダメ。

基本に立ち返る。=>最初の目的からズレてしまう。

理解を深めるために=>説明してみる。

ラバーダック・デバッグ=>独り言のようにとりあえず言ってみてどこがダメなのか(問題)を整理していく。

とりあえず全部読もう。

デザインパターンは数学に近い。=>計算するとき、「公式」を使う。＝「特性」を持ったやり方をする。

Facade=>UIの作成時に使用。

いい感じの「手抜き」を行う=>時間を節約できる。

Userがあまり見ていない場所をできる限り削る。

だれが使ってもいいように「作る」のはokだが、「計算が分かっていない人に行う」と危険

インターネットには嘘付きが多い。

4~5作を一年で作っているが、量より質に入ってくる。

内定が決まっても期限が切れてしまう可能性もある。

自分がやりたいことをやった方が後悔しない。

粘ることで入れる可能性がある。

下手に就職するより、バイトをして時間を延ばす方が良い。

むしろ+1年の方が覚悟があるとして良い印象を持たれる。

就活作品は2年の2月から作成している(これだけではないので一様には言えない。)

企業調べをする。インターンに行けたかどうかでは決まらない。

作品の方が勝負をする方が良い。

ゲーム会社だと、プログラム以外の事務作業も行うことが多い。

中小型の企業は福祉系はあまり期待できない。肉体的にキツイ。

大手でも残業する人はいる。

IP関連をしていると、版権問題でブラックアウトすることもある。

基本、変わった人だらけ。

自己理解度は大事。欠席しすぎると、アウトになるので注意。

色が無い人が多い。

一緒に働いているビジョンが見える人が良い。

体験談があった方が、より伝わりやすい。

気になっただけで受けてみるのが良い。

とりあえず行動してみる。

github=>read me に書くべき。

ホラーゲーム=>出てくるところが分かってしまうとあまり怖くない。＝不定期に出てくると運ゲームになってしまう。なので調整が難しい。

アークナイツは「グリッド」で動いているので計算処理が楽になっている。=>計算処理は「楽」なものに任せる方が吉。

商業的に戦う人 => 「みんな」で戦う。　いろいろな「知識」をもって作成しているので成り立つ物がある。

知識といっても「プログラミング」だけでなく、「音」や「映像」など様々な分野において使用される。

教養は、「一般常識」に当てられる部分。

努力を「ショートカットする」。現在は「教科書」や「ネット」によって「知識」や「教養」を得ることができる。

ゲームが目指している「目標」を知ることで「プログラマー」として作成できる。

教養の使用方法や取得は「スキルツリー」と似ている。

経済学 => ゲーム内の「お金」の使い方や回り方を考えないといけない。マルチでよく使用する。

心理学 => 演出やギミックに使用。

科学や物理など => 世の中の「物の動き」を再現するために使用する。ただし、現実でなくてもよい。

芸術 => ゲームの「雰囲気」を簡単に知らせることができる。

文学 => 日本だけでなく、いろんな世界の文化を知ってその文化をいかに投影するか。

情報技術 => パソコンが「どうやって動いているか」を知っておけ。

ゲーム => なぜ面白いのか。言語化は難しいが、感覚だけでは成り立たない内容なので難しい。

ゲーム理論 => 囚人のジレンマだけでなく、「オセロの最善手」もある。戦略で使用するため、「攻略」をよりよく考えることが多い。

メカニズムデザイン => 誰かの犠牲を元にしてさらに上を目指すこと。「オークションの競り」や「ソロモン王のジレンマ」などがある。

社会科学 => 進化をする上での環境を知るもの。

動物行動学 => 協力をする上で、「自分に利益がないと意味がない」といったこと。自分に利益がない行為をしてしまったりするのも一つのまとめ。

心理学 = ソシャゲを運営するうえで使用。でももうばれてきてるよね。うん。犯罪ギリギリなところも知ることができる。

流体力学 => 水や空気の流れを表現する際に使用。

芸術 => エッシャーのだまし絵。現実では表現しえないことも、ゲームなら可能である。

思考実験 => 仮に...を考える物。ゲームにおいては試作段階で使用される。これ自体をゲームにすることも、応用することもある。

Keep（継続する）、Problem（問題点）、Try（挑戦する）の三つは日報にて書くことを意識する。

しかし、「毎日」はさすがに難しい...

業務開始のタイミングにて書かされることもある。(その場合は予定になる)

1:本日の予定

2:抱えている仕事日

現在入っている仕事の時間も含めて書く(毎週ある物もアリ)

面接において難しい問題が出た...=>内容よりも「考え方」が大事

ゲームを作りたい=>頭を柔らかくする。

デバッグは「社内」で行う(デバッグチケットの書き方)

デバッグチケットに書く内容

優先度:「どのくらいゲームのバランス崩壊やバグの不具合による進行への妨害がおこなわれているか」をランク付けで行う。

名前:「何が起きているか」を書く

要件:「詳細および確認内容」を書く

フロー:「備考」を書く

発生率:どのくらいの頻度で起こっているかを書く(追記:スクショや動画があると良い)

発生環境:「そのバグが起こった環境」を書く

この部分は最低限である。

レビューの内容によっては「崩壊」する恐れがある。

丁寧に書くことをお勧めする。

文脈においては「否定を入れない」ことが大事。

ウォーターフォール型開発=>ゲーム作成の概要を一気にマージ(コンフリクト大)する方法。投げっぱなし。自由は聞くものの、フォローしづらく仕事の会話を取りにくい。

そのため、人数が少ないほうがやりやすい。

基本的にはそこまで考える必要はないものの、エラーを出しやすい状況になっている。

特に同じシーンを編集しているところはコンフリクト(衝突)が起こりやすい。

あと、配分が難しく時間が余計にかかることが多い。

アジャイル型開発=>二人で一つのpc(作成)を行う。

その後、レビュワー(指示者)とコーダー(作成者)に分かれる。

基本的には作成部分の時間はある程度削ることができるものの、

レビュワーによってはコーダーとの意見の対立が起こる可能性があり、一概にはいいとは言えない。

他の部署からのコメントに対してあまり反応することが難しく、

体力的にも、精神的にもダウンしてしまうことも。

衝突自体はそこまでせず、エラーやバグと言ったミスが起こりにくいものの、

ヒューマン側のエラーが発生する可能性がある。マジ大変。私は聖徳太子じゃねぇ(怒)

大体疲れているのでひとりにしてあげよう。自分の時間もほしいと思う。うん。

あとは、会話ができない(あるいは恥ずかしがり屋)ははっきり言って相方が疲労することが多い。

理由は単純。「意思疎通が取れないことで、自分なりに解釈して作成」しなければならない。

結局、ウォーターフォールに疲労感を更に足した感じになってしまうので、

二度手間である。相手のパフォーマンスに左右されやすいので注意!

また、新しい仕事ができた際に「誰がやるのか」を決めにくい。

「コミュニケーションの強制」が行われる。

ウォーターフォールの上の思想にアジャイルが存在する。(ベースがウォーターフォルで、アジャイルがその発展型)

つまり、ウォーターフォールが基本なのでここができないとアジャイルも行っても意味がない。

投げられたタスクを一旦見直したほうが良い。(環境を作成し直す方が良い。)

見積もりでは、アジャイルでは二人で決めたうえで「バッファ」の取り方を考えなくてはならない。

現場=>(例)1.5時間 = 1時間検証 0.5時間バッファ => ここから増減する必要がある。

マネージャー=> 全員の見積もり * 1,5 / 人数　で考えることが「多い」(人によって考え方は異なるのでなんとも言えない。)

ジョブシフトも考えることも。=>仕事はずっといっしょじゃないので、すべての人が同じレベルまでにすることが目標。

担当者に知識が偏らないようにみんなが仕事ができるようにする。(属人化の予防=業務の知識やノウハウが特定の個人に集中し、その人以外では業務を進められない状態を防ぐ)

見積もりを立て直す際、　一タスクあたり１６時間以下でできるように分解を行う必要がある。ただし、細かくし過ぎもだめ。

KPT=>keep,problem,tryの三つ。報連相と似たもの。

作成の「アプローチ」が言語であって、『作成プロセス』は大きくは変わらない。