【解説】仮想通貨の『何が』Twitter上で盛り上がっているのかをトピックモデル分析①
はじめに
前回行ったtwitterでの仮想通貨に関するツイートに対するLDA分析の手順の解説です．
思いの外アクセスが多かったので，もう少し具体的に公開していこうと思います．
前回は
です．ご参照あれ．
今後，だいたいこんな手順で公開していく予定．
1.Pythonによるデータ収集
2.LDAの前処理-ノイズ除去と形態素解析-
3.Perplexityの算出による評価
4.本格的なlda分析
5.総評価・まとめ
まずは，1.Pythonによるデータ収集 です．
内容
諸々まとめ
言語：Python 2.7
ライブラリ：tweepy 他
期間：1月31日0時0分0秒〜2月6日23時59分59秒の間約一週間分
ただし，RTとbotは検索対象から除く．
ソースコード
早速ソースコード掲載
（TwitterAPIのためのトークンは予め取得しているものとします）
collecter_only_txt.py
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import os
import tweepy
import urllib2
import csv
import datetime
import re
import codecs
import time
import sys
import gc
#いらないimportもあるかもしれない
print('start...')
#分析時間の計測開始
start = time.time()
#トークンまとめ
CONSUMER_KEY = ''
CONSUMER_SECRET = ''
ACCESS_TOKEN_KEY = ''
ACCESS_TOKEN_SECRET = ‘'
#apiを取得
auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
#ツイート取得エラーの回数を数える
error_count=0
#api.searchのcountを利用する
#180で15分が目安というか限界
get_data=180
try:
auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
except Exception as e:
print "[-] Error: ", e
api = None
#宣言，getdataの回数分だけデータを取得する
def search_tweet(api,max_id,count,tweet_data):
#繰り返し回数の出力
if(count%10==1):
time_check(api)
print(count)
#ウェイト．5秒×180が理想
#time.sleep(4)
print("wait...")
print(max_id)
#time_check(api)
#データ取得部
#最初の一回目は最新から，二回目以降最新から撮ったtweetIDの末尾から取得
if(max_id==0):
-bot -rt'\
,count=100,show_user=True, lang="ja",wait_on_rate_limit = True)
else:
#取得エラー回避（100回エラーが出たら強制終了，それまで再帰）
try:
-bot -rt'\
,count=100,show_user=True, lang="ja",wait_on_rate_limit = True,max_id=max_id)
except Exception as e:
print "[-] Error: ", e
global error_count
error_count += 1
print(error_count)
if(error_count>100):
sys.exit()
#一応待機してから再帰
time.sleep(10)
search_tweet(api,max_id,count,tweet_data)
#tweetIDの末尾を記録
max_id = result[-1].id
max_id = max_id-1
#print(result.max_id)
#データ記録部
for tweet in result:
tmp=tweet.text.replace('\n','')
tmp_t=tmp.encode('utf_8')
#JSTに合わせるための補正（+9時間）
tmp_c=tweet.created_at + datetime.timedelta(hours=9)
tmp_i=tweet.id
tmp_d=tweet.source.encode('utf_8')
tmp_u=tweet.user.name.encode('utf_8')
#print(tweet.source)
#wirteの時点でタブ区切り指定できるので採用
tweet_data.append([tmp_i,tmp_c,tmp_t,tmp_u,tmp_d,tweet.retweet_count,tweet.favorite_count])
#繰り返し回数足し算
count=count+1
#get_data分取得が終わったら終了
if(count<get_data):
writecsv(tweet_data,max_id)
#メモリ軽減のためのリセット
del tweet_data
gc.collect()
tweet_data =
search_tweet(api,max_id,count,tweet_data)
else:
writecsv(tweet_data,max_id)
print(tmp_c)
print("Last check max_id:{0}".format(max_id))
#csvファイルを作成する部分（正確にはtsvファイル）
def writecsv(data,max_id):
#初回だけ列名を作成
if(max_id==0):
#タブ区切り
#with open('txt_data.csv', 'a') as f:
with open('txt_data.tsv', 'a') as f:
writer.writerow(["id","created_at","text","user","device","rt","fav"])
#writer = csv.writer(f, lineterminator='\n')
#writer.writerow(["id\tcreated_at\ttext\tuser\tdevice\trt\tfav"])
pass
else:
#with open('txt_data.csv', 'a') as f:
with open('txt_data.tsv', 'a') as f:
#writer = csv.writer(f, lineterminator='\n')
writer.writerows(data)
pass
#main関数
def main():
#初期値．続きからやりたければmax_idを指定してカウントを1以上にする
max_id=0
count=0
#とりあえず空のデータ．ここにappendしていく
tweet_data =
print("main do")
if(max_id==0):
writecsv(api,max_id)
#引数はtweepyの基本と最新tweetIDと取得回数
search_tweet(api,max_id,count,tweet_data)
time_check(api)
#時間と残り回数の出力
def time_check(api):
#残り実行回数の取得（tweepyの限界）と実行時間の出力
limit_data=api.rate_limit_status()
j=(limit_data['resources']['search']['/search/tweets']['remaining'])
print("Remain:{0}".format(j))
elapsed_time = time.time() - start
print ("elapsed_time: {:.3f}".format(elapsed_time) + "[sec]")
#最初に実行される部分
if __name__ == '__main__':
main()
ソースコードの解説
多分プロフェッショナルから見たら無駄が多いかもしれません…が，一応これでデータ収集できます．
def search_tweet(api,max_id,count,tweet_data):
の部分で検索ワードをベタ打ちして，検索ワードにヒットしたツイートを取得しています．
取得しているデータは，ツイートID，ツイート日時，本文，ユーザ名，ツイートされたデバイス名，リツート数，ファボ数です．
やろうと思えばもっと多くのデータを取得することもできます．
工夫点
.tsvファイルによる書き出し
通常こういうデータは.csvで取得しますが，このコードでは.tsvファイルで取得しています．
これは，ツイートの本文に頻繁に,（カンマ）が現れることがあるからです．これを回避するために，タブ区切りでデータを取得する必要がありましたので，そうしました．
max_idの指定
ツイートIDを取得しているので，もうちょっと遡ってツイートを取得したいと思ったらmax_idを指定することで可能です．これを上手いこと繰り返すことで1週間分丸々データを集めることができます．
検索ワード指定
また，当然といえば当然ですが，仮想通貨以外の検索ワードにしたら，そのワードを含むツイートを取得できるので，様々な分析を行うことができます．
で，これを2月6日くらいからイソイソと回し始めた結果，34万3555件ものデータを集めることができたわけです．
課題
・180回以上データを収集し始めるとメモリが圧迫される
→何処かで余計な処理が発生しているか，tweepyのapiが悪い影響及ぼしている？
・対処法
max_idを指定すればそこから再検索できるので，pythonの処理を止めながら進めればサクサクできる．
pythonは不慣れですができたほうだと自分を褒める…
今回は以上です．
次回はノイズ除去や形態素解析について述べていこうと思います．
参考まで．
仮想通貨の『何が』Twitter上で盛り上がっているのかをトピックモデル分析
はじめに
仮想通貨流行りすぎですよね．
個人的には仮想通貨に一体どんな価値があるのかよくわからないのです．あれ自体で何か商売をして儲けているわけじゃないのに，忽然とした需要が価値を押し上げているような…
まあ，みんなが「金の延べ棒欲しい」っていったら金の値段が上がるように，仮想通貨もそういうものなのかなと思いつつ（はっ！だから「マイニング」っていうのか！（？））分析してみました．
※一応ですが，仮想通貨について何か確定的な言及をするものではありません．あくまでデータ取って分析して，私なりに考察した結果であることは注釈しておきます．
目的
Twitterユーザーは仮想通貨の何に関心を持っているのか
今回はテキストマイニング手法の一つであり機械学習手法として大分一般化してきた（と思う）トピックモデル分析を行います．
トピックモデル分析
簡単に言うと，文書集合の主なトピック（話題）を半自動的に分類可能な手法です．これを仮想通貨についてつぶやいているTwitter文書に利用することで，仮想通貨に関する主な『話題』が抽出できるのではないかと考えました．
また，これに関する記事は昨日まとめてみましたので，興味のある方は是非．
その他，LDAで検索してみて調べてみると面白いです．
仮説
どんなトピックが出そうかなんとなく類推してみます．
- 値段（相場）の上がり下がりの話
- どの仮想通貨が良いか，悪いかの話
- 取引所の話
- 将来性の話
- 仮想通貨に関する感想・意見
この辺りがトピックとして出てきて，なんか意外なトピックが出てきたら面白いかなーと思いながら分析です．
大雑把な手順
- Twitterから仮想通貨に関するツイートを取得
- トピックモデル分析してどんなトピックがあるのか分析・考察
細かい手順
以下，分析内容に関心のある人は是非ご覧ください．プログラマーとかアナリスト知識人向け．ディープな話は今後公開していく予定です．今回は概要レベル．
TwitterのAPIを使ってツイートを取得
- 言語：Python 2.7
- ライブラリ：tweepy 他
- 検索ワード：「仮想通貨 OR ビットコイン OR bitcoin OR BTC OR アルトコイン」
- 期間：1月31日0時0分0秒〜2月6日23時59分59秒の間約一週間分
- ただし，RTとbotは検索対象から除く．
全部で34万3555件取得できました．34万ツイート…複数検索とは言え多いですねえ．関心の高さが伺えます．
ノイズ除去
- 言語：R言語
- ライブラリ：lda，topicmodel, RMeCab 他
- URLや＠〜を各文書から削除
- 重複する文書を削除（新しい文書が残るように）
- 名詞，動詞，形容詞，形容動詞を対象に品詞分解
- 2品詞未満の文書を除去
最終的な分析対象は23万8133件になりました．何回も同じツイートをしている場合やいわゆるパクツイ，bot除外できない事実上のbotなどが結構含まれているみたいですね．あとは一言ツイートも除外対象ですので．
これらはTwitter自体の性質に近いので，しょうがないということにします．
今回の分析ではトピックモデル分析のLDAを用います．
解釈しやすく，精度も良い（それなりに）適切なトピック数を探索
- Perplexityを算出
- 5-fold out クロスバリデーション（データの80%を学習データ，残りを試験データとしてPerplexity算出
- 各種パラメタ
- α：50/トピック数，η(文献によってはβ)：0.1
- 方法：ギブスサンプラ，
- 反復回数：100回
反復回数は多いほうが良いのですが，計算コストが膨大すぎたのでこの程度で留めました．1000とかにすると余裕で1日掛かります．
評価基準
このシミュレーションをクロスバリデーションのパターンを50パターン用意してPerpelexityの平均値で判断
一般に，トピック数を増やせばPeplexityは良い評価値になるが，トピック数が多すぎても解釈が難しくなるので，トピック数が少ない（30以下）中で，比較的Peplexityが良いトピック数を採用．
LDAの方法
良いトピック数で分析し，各トピックの代表的な単語からトピック名を決定
各トピック割合が大きい上位の文書などから考察
制約
Twitterのデータは過去一週間分しか取得できない．これは個人開発者レベルでのTwitter apiの制約なのでしょうがない
Perplexityの算出など各分析では違うライブラリを使っているので，もしかしたら微妙に誤差生じるかも．（手法やパラメタは一緒のはずだから許容範囲内だと信じる）
結果
結果としてトピック数6,10,13,18,でそれなりに良いPerpelexityと言えるものが出ました．
今回はトピック数13の結果・考察を載せます．
トピック名とトピックを代表する単語
トピック名の判断にはトピックを表す代表的な単語を算出します．ここではライブラリだよりですが，解釈としては「そのトピックに出てきやすくて，他のトピックに出にくい単語に重み付け」といったところですかね．
これと本文も参照しながら，Twitter上で仮想通貨について何が主題として語られているのかを判断します．
名付けたトピック名と代表的な単語の一部を表に示します．数字は除いています．
| トピック名 | 代表的な単語 | |||||
| 取引所ごとの相場 | 円 | btc | 価格 | % | xrp | 時間 |
| 国外流出疑惑ニュース | 億 | 日本 | 流出 | 韓国 | nem | 分 |
| 興味 | 最近 | 人 | 広告 | て | やっ | みたい |
| 投資価値 | する | 投資 | いる | し | こと | ある |
| 価格推移 | 万 | btc | 日 | 月 | 年 | ドル |
| 不信感 | 笑 | w | 今 | 損 | 怖い | し |
| 取引所 | 通貨 | 仮想 | し | 事業 | 参入 | 下落 |
| バブル感 | 通貨 | 仮想 | 崩壊 | 信頼 | 性 | い |
| 下落 | 相場 | 株 | 買い | 暴落 | 見 | 下げ |
| まとめ・ブログ記事 | 仮想 | 通貨 | さん | 人 | 税金 | まとめ |
| 仮想通貨の仕組み | ブロック | マイニング | なる | 利益 | ない | 理解 |
| 主要アルトコイン | コイン | ビット | fx | リップル | 暴落 | あり |
| 某社の盗難ニュース | チェック | 仮想 | 取引 | 通貨 | ニュース | 所 |
考察
うーん広告・ニュース・ブログ記事が多い．初心者を釣ろうとする広告と煽ったようなブログ・ニュース記事が多い．普段眺めるメディア系とかよりも，遥かにお金が直接絡むからしょうがないけど，これじゃあ人間のユーザーの生の声を抽出するのも難しいです．
一方で，この「広告やブログ記事まみれであるという事実」が，Twitterから得られる仮想通貨に関する情報とも言えるかもしれません．
あとはニュースサイトが発信する文書に関するトピックですね．確かにユーザーが求める情報としては有益なのかもしれません．ニュースに対する意見などもツイートする場合もありますし，分析結果としては納得できます．
あとは分析期間の関係で，某社の盗難ニュース，仮想通貨が国外（韓国からハッキングされて北朝鮮に流れたのでは？という疑惑の）ニュースなどのトピックが出てきました．
まとめ
約1週間で34万件以上のデータ収集しトピックモデル分析（LDA）を行った．
主な話題（トピック）は今回13種類抽出できた結果について述べる．
- 取引所ごとの相場（取引所での価格について言及したトピック）
- 国外流出疑惑ニュース（北朝鮮に流れたのでは？という記事のトピック）
- 興味（やってみたい，とかのトピック）
- 投資価値（いつ投資しよう，株みたいなもの？，とかのトピック）
- 価格推移（価格の推移自体について述べるトピック）
- 不信感（怖い，損した，などネガティブなトピック）
- 取引所（会社名などを挙げて述べたトピック）
- バブル感（年末年始の高騰・暴落について言及するトピック）
- 下落（時期的に価格が落ちきって，上下している事に関するトピック）
- まとめ・ブログ記事（記事タイトルなどのトピック）
- 仮想通貨の仕組み（ブロックチェーンの話や，よくわからん，といったトピック）
- 主要アルトコイン（リップルやリスク，モナコインなどに関するトピック）
- 某社のニュース（盗難された某社のニュース記事からその感想まで）
所見としては，ニュース記事，転載ニュース記事，広告，botらしきものが非常に多い印象です．
一方で，こういったツイートが多いこと自体が，仮想通貨の今を表しているのでは，とも思います．
また，世間を賑わす某取引会社に関するトピックがあったり，「興味あるー」といったツイートや，価格の下落に関するトピックがあったりと，仮想通貨に対する期待と不信感が入り混じったトピックが得られました．データ収集した時期の影響もあるかとは思いますが，納得の結果ではないかと思います．
また，検索対象に入れていない「リップル」「モナコイン」や「リスク」「xem」などがトピックを表す重要な単語として出現したことから，「仮想通貨」及び「アルトコイン」の中でも注目されている通貨が炙り出せたのではないかと思います．
あとは，まあ，Twitterの特性というか風潮というか，『w』とか『笑』とか絵文字とかネットスラングに近い言葉がよく出てくるという印象です．良く言えば『お気軽さ』『奥ゆかしさ』ですし，悪く言えば『煽り』『罵詈雑言』です．
例えば「自業自得だと思います」とはつぶやかず，「ざまあww」とつぶやく方が多いのではないでしょうか…日本語の文章として破綻していても，日本人はなんとなく読めますが，分析者としては扱いに困るところです．
今後は，細かいトピック数に指定して分析することや，カテゴリに分けた上でLDAすることでより詳細な話題が見える可能性も十分にあると思います．これらはまた後日行いたいところです．
懸念
Twitter自体単語数が少ないので変な過学習がないか心配．あとは，トピック割合が異なっても，パッと見同じような本文も散見されたので，解釈が難しい点がありました．
また，転載ニュース記事とか広告ツイートとか選択的に除く方法がわからなかったので，分析文書に含んでいます．
これが全体のトピックを歪めている可能性あるかもしれません．本当は個人ユーザーを中心とした感想・意見・所見などを収集できたらよかったのですが…どうしたら良いですかね…．
「やったほうがよかったかな」のまとめ
- 転載ニュース記事とか広告ツイートとか削除
→個人の意見に関するトピックの抽出可能か
- 逆に転載ニュース記事や広告ツイートのみに限定した分析
→どんな記事タイトルが多いのか
- 仮想通貨用の辞書作成
→【ビットコイン】という単語は形態素解析した時に【ビット】と【コイン】に分かれてしまう，などがあった
今後やってみたいこと
- 今回の結果を仮想通貨のチャートと合わせて分析
例えばネガティブワードが多い数分後に下落していたら面白いですよね．影響力の強いユーザー・ブロガーやニュースサイトが炙り出せるかもしれません．
- 時系列を考慮した分析
今回のLDAは一週間分のデータを一括で分析しましたが，時系列を考慮したら日毎のホットワードが取り出せるかもしれません．
- 広告などを除いた分析（要は人間のユーザーの関心トピックの詳細が知りたい）
長くなるから今回避けましたが，そのうち分析の中身をソースコードとともに公開しようと思います．
プログラミングに精通した偉い人にアドバイス貰えたら嬉しいなぁ (このブログの本当の意図はこっちにある…)
参考まで．
LDA（Latent Dirichlet Allocation）について調べたので自分なりにまとめる
はじめに
普段はUnityのことばかりですが，分析系にも高い関心があるので，備忘録がてら記事にしてみました．
トピックモデル分析の内，LDAについてまとめていこうと思います．
自分の意見や使ってみた印象も混じっているので悪しからず．引用元は明記しているはず…です．
LDAは文書集合から，主たる話題を半自動的に推定することができるテキストマイニング手法です．
内容
文献調査
大元の文献はこちらです．
David M. Blei, Andrew Y. Ng, Michael I. Jordan, "Latent Dirichlet Allocation,"Journal of Machine Learning Research 3, (2003), pp.993-1022,
私たちはテキストコーパースのような離散的データの収集のための生成確率モデルである，潜在ディリクレ配分法「LDA」について述べます．LDAは3層の階層型ベイジアンモデルであり，各収集ノードは基礎となる話題（トピック）の集合の有限混合分布としてモデル化されています．各トピックは，トピック確率の基礎となる集合全体において，無限混合分布としてモデル化されます．テキストモデルの文脈としては，トピック割合は文書の明白な表現を提供します．
3層の階層型ベイジアンモデル，というのが，よくLDAで検索した時に出てくるグラフィカルモデルを指します．
もっと具体的に応用し，科学系論文の文書を対象にLDAを利用した文献です．
Griffiths TL, Steyvers M., “Finding scientific topics”,Proc Natl Acad Sci U S A. vol.101, (2004), pp.5228-5235
文書の内容を判断する最初のステップは，文書アドレスのトピックを決定することである．私たちはBleiらによって導入された文書生成モデルについて述べる．各文書は，トピックに関する分布を選択し，この分布に従って選択されたトピックから，文書内の各単語を選択することで生成される．私たちは，推論のためのマルコフ連鎖モンテカルロアルゴリズムモデルを提案する．
（「文書アドレスのトピックではなく」，「文書のトピックの所在」，とでも訳したほうがわかりいい？）
訳は参考程度にしてください…ひどく自信がないです…
LDA自体がLSIと呼ばれる分析の派生というかリスペクトしたモデルです．LSIは次元圧縮を行い，トピックと似た次元を抽出することができます．簡単に言うと，よく似た意味で使われる単語をグルーピングしてくれます．
一方，LDAは確率的にトピックを割振ります．この仕組みは，例えば，未知の文書などにおいて得られた，「直接的に観測されていない単語の組み合わせを含む文書」についても，トピックを予測することができる仕組みになっています．
何ができるの？
- 大量の文書集合からトピック（話題）を半自動的に，推定することができる
- 話題を推定することで個々の文書でどんな話がされているのかを半自動的に分類することができる
だから〜…それができると何ができるの？
- 自動分類自体に価値がある．例えば，流行り廃りや，ブームの系統を見出すことができる．ビッグデータ解析にも使える．
- よく似た話題の文書をレコメンドすることができる．例えば，前に見た文書が野球のニュースだったら，次のおすすめも野球の記事にできたりする．
- 同じ要領で，よく似た趣味やよく似た文書を閲覧する人をおすすめすることができる．
LDAの利点は？
- 比較的推定精度が良いらしい
- 一つの文書にいくつも話題があるかもしれない，ということを確率分布として表してくれるので，あらゆる可能性を否定しない
- 引用文献が非常に多く，今や各種言語でライブラリが豊富
- 最近は理論としては下火で，応用として多分野に渡っている印象
- テキストデータ以外にも使おうと思えば使える．物の配置とか人の動きとか画像の特徴量を分析すれば，同じようなニュアンスを持った配置や動き・画像を半自動分類できる
LDAの欠点は？
- データがたくさん必要
- 美しい文書でないと上手く行かない（という印象．まあどんなテキストマイニングもそうかもしれませんが）．ネットスラングが多かったり，日本語として文書が崩れていると，ノイズなのか意味を持つ文字列なのか判断が難しい．
分析しやすい←国や政府の文献>企業が出す正規の文書>ニュース記事>>ブログ記事>=メール文書>自由記述アンケート>Twitter>=2ちゃん（現5ちゃん）→分析しにくい
※あくまで私の印象
- 国や政府の文書：日本語がしっかりしている．最近ポッと出てきた単語やネットスラングは使わない傾向が強いので分析しやすい
- 企業が出す正規の文書：日本語がしっかりしている．ただし，製品名やカタカナ語が多いと分析が面倒になりやすい
- ニュース記事：日本語が比較的しっかりしている．固有名詞，()つき文書や，上記と同じくカタカナ語が多いと分析が面倒．
- ブログ記事：たまに日本語が崩壊している．本ブログもこれに該当する．固有名詞でも()つけでも，英語ローマ字混じりもなんのその，伝われば良い文書なので，基本的には分析するには事前のノイズ除去が必要
- メール文書：ブログ記事と同じく．あとは，定型文が多いので過学習するし，プライバシー的にも配慮に困る
- 自由記述アンケート：意外と人はきれいな日本語を書くことはしない．というのが私のこれまでの印象．ノイズ除去必須
- Twitter：言わずもがなですが，文書としては実に実に玉石混交．ニュースであったり，政府の通知であったり，小馬鹿にしたような文書まで色々あるのが分析上は厄介
- 2ちゃん（現5ちゃん）：ネットスラングの元凶とも言える新しい言葉を生成する．「www」とかですら分析上は厄介ですし，「www」も意味を持つ単語と位置づければそうとも言えるので，解釈が大変難しい
LDAの評価基準
LDAの評価基準には諸説あるため，最終的な解釈が重要となる（客観性を担保するのが難しい）
Perplexityという評価基準もあるが，最終的には人が解釈できないと意味がないとする解釈もあるようです．
確かにライブラリなど駆使して使ってみた感じでは，Perplexityが絶対というのはよろくなさそう．表現のゆらぎやノイズが完璧に考慮できていないと良い結果にはならないと思います．
LDAどんなもんじゃい
word2vecが流行った影響で現在は下火感強いですが，私的には大変利用価値のある手法だと思っています．要はケース・バイ・ケースです．
まとめ
- LDAは大量の文書の半自動的にトピック（話題）を推定し，分類することができる手法
- 流行り廃りを把握したり，おすすめをレコメンドすることに利用することができる．
- 汎用性が高く，やろうと思えばテキスト以外にも用いることができる．
今後
近々LDA使った分析についてアップしたいです
publicを利用してGameObjectをコンポーネント上で操作できるようにする
はじめに
前回の続きみたいなものです．
前回はpublic指定した値をコンポーネント上で操作する機能について説明しました．
今回は数値ではなくヒエラルキー上にあるオブジェクトも操作できることについて説明します．
publicでGameObjectの変数を宣言
まず，適当に空のオブジェクト（Create Empty）を用意して，New Scriptをコンポーネント上で作成します．今回はそれをGameobject_rotationという名前にしておきます．
この時点では何もありません．スクリプトを下記のように編集します．
Gameobject_rotation.cs
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Gameobject_rotation : MonoBehaviour {
//publicで指定したオブジェクトを回転させるだけのスクリプト
public GameObject rotation_t;
void Update () {
rotation_t.GetComponent<Transform>().Rotate (3, 2, 1);
}
}
今回も回転させるだけのスクリプトですが，違いはpublic指定している変数rotation_tの方がGameObject型であるということです．
rotation_tのTransformというコンポーネントをGetして，Transformの中のRotateを(3,2,1)にしてね，という意味のスクリプトをUpdate()に記述します．
こうすると，コンポーネント上ではどうなっているかといいますと
前回数値が入力できたかのように，Gameobjectを入力できます．変数名はRotation_tですね．
GameObjectの入力の方法は，2種類
①ヒエラルキー上のオブジェクトをドラッグ・アンド・ドロップ
②右側の◎みたいなマークをクリックしてオブジェクトを選択
今回は②のパターンでやってみます．[None(Game Object)]の右側にある◎みたいなものをクリックすると
ヒエラルキー上にあるオブジェクトが一覧で表示されます．Assetで色々ダウンロードしていたらもっとたくさん出てきます．今回は予め生成しておいたCylinderを選択します．Cylinder…つまりは円柱ですね．
選択できました．これで，スクリプト上ではRotation_tはコンポーネント上にあるCylinderになります．
実際の挙動
この状態で実行しますと
やったぜ動いたぜ．
このようにしてヒエラルキー上にあるオブジェクトを視覚的に指定して，スクリプトに載せることができます．直感的にやりやすい…
まとめ
publicでGameObjectを指定することでヒエラルキー上のオブジェクトを操作することができる．
工夫次第では，同じスクリプトで同じ挙動をさせたいけどオブジェクトが異なるものを，同じスクリプトで賄うことができます．しかも視覚的に確認できる．良いですね．
Unity 2018.1 beta公開
はじめに
表題のとおりです．
2018年最初のUnityバージョンリリースが発表されました．
個人的に関心が強いので，バージョンアップ記事の突発的レビューです．
Unity 2018.1 beta 内容
大きな変更点は4点でしょうかね．
・視覚的なShader作成ツールのサポート
・C#Job Systemの追加機能
・旧パーティクルシステムの段階的な廃止
個人的には
・Wii Uサポートの廃止
・Mono Developmentサポートの廃止
これが関心ありますね．
以下，要約と意見です．
・GPUレンダリングの強化
そうそう，こういうのいいですよね．GPUレンダリングの発展はタブレットPCなど小型端末でも今後ものすごい伸びるであろう（と個人的に思っている）コンテンツですから，この辺のサポートを公式に発表するのは素敵なことです．
・視覚的なShader作成ツールのサポート
HP上ではShader Graph Toolとなっていますが，AnimationツールのShader版の認識で良いと思います．
スクリプトだけの記述では難しいところを視覚的にサポートする地盤が固まりつつあります．ある意味，個人アプリ開発者としては，敷居を低くするものであり，広まる意味では良いような，それでいいんかいな，という気持ちです．
だってスニペットみたいなツールばっかりでシステム作っても，それはエンジニアと言えるのか，って思っちゃうじゃないですか．
・C#Job Systemの追加機能
申し訳ない，これはあまりアンテナ張ってないです．でも本格的に取り組もうとしている？
以下，憶測を含みます．
マルチスレッド対応ですが…並列化計算の関心はGPUに合わせて関心が高まっているわけですね．視覚的なプログラミングが多い印象のUnityでも求められることなんですねえ．
要は，レンダリング以外での並列化計算の効率化みたいなものですから，マルチエージェントとか，レンダリングの裏で動くアルゴリズムを高速化する意図ですかね…
・旧パーティクルの段階的な廃止
Shurikenが一般化しつつありますから，まあこれは妥当では．
むしろ，Shurikenの発展に期待します．パーティクルは，演出からシミュレーションまで工夫次第で面白くなりますから．軽くて汎用性の高いものであるべきです．
・Wii Uサポートの廃止
完全にNintendo Swichに移るわけです．当然ですが，時の流れを感じて私は切ないです．
Unity発のSwichソフトウェアは，増えた…かどうかは知りませんが，有名企業やコンテンツで「Unityで作ったぜ」とニュースを見るようになりましたからね．
今後もこういったが発展することを望みます．個人的にはWebGLの発展を望みますが，イマイチですね．やっぱりWebGLはスマホコンテツとの相性がよくない感．
・Mono Developmentサポートの廃止
これは驚き．ノーマークでした．Visual Studioメインでやると…
いや，いいんですけどね，どうも個人的にVisual Studio使いにくんですよ…個人的にですよ？（Mono Developmentが使いやすいとは言わない）
いっそUnity発のツール作れば良いのでは，と思ってしまいます．VisualStudio重すぎません？超軽量なツールのほうが私は嬉しいです．
まとめ
2018年Unityが驚きと面白みのあるソフトウェアとなって，更なるグッドニュースを望みます．グッドラック！
privateとpublicの違いについて図付きで説明
はじめに
privateとpublicはunity初見には意味不明です．
でも視覚的に見れば「なるほど」となります．今回はその例です．
本題
privateとpublic
publicとしてa
privateとしてbを宣言してみます．
Test.cs
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Test : MonoBehaviour {
//オブジェクトを回転させるだけのスクリプト
public float a;
private float b=10.0f;
void Update () {
this.transform.Rotate (0, a, b);
}
}
Test.csスクリプトはオブジェクトを回転させるだけの簡単なものです．
aとb，この二つがどのように異なるかです．
言うなれば，privateは文字通りプライベートで，そのスクリプト（class）でしか使わない変数にさせるのです．
言うなれば，publicは文字通りパブリックで，そのスクリプト（class）以外でも干渉できる変数にさせるのです．
unity上では特にそれがコンポーネント上に表示されます．
これ，とても便利なのです．
数値だけでなく，任意のオブジェクトやファイルを引用することもできます．
実行例1
実行
x軸回転はしません．aは0なので．（gif画像が動いてなければ横回転しているのだと思ってください）
次に，コンポーネント上でaの値を10に変えて実行してみます．
実行例2
実行
（gif画像が動いてなければ斜め横回転しているのだと思ってください）
デバッグなどにも使えそうです．
まとめ
private：変数を，そのスクリプト（class）でのみ使う指定をする
public：変数コンポーネント上で自由に扱うことできる指定をする
次回あたり，publicの更なる便利さを述べていきたいと思います．
Unityよくあるエラー〜"All compiler errors have to be fixed before you can enter playmode!"と “Please fix any compile errors and assign a valid script."〜
はじめに
私が苛まれたエラーランキングNo.1です．
そしてUnityへの数少ない苛立ちの一つです．
よくあるエラー
＝
All compiler errors have to be fixed before you can enter playmode!：
意訳）プレイモード実行前に，全てのコンパイラエラーを修正する必要があります！
Please fix any compile errors and assign a valid script.：
＝
実行時に出ます．このエラー見たときは「なんでじゃい」となるわけです．
原因：ネット上からスクリプトをコピペしたりする時によく発生します．
問題は超シンプル，多くの場合，スクリプトの名前が間違っているんです．要確認です．
コピペした時に変数名やらファイル名がミスっているなんていうときは，スペルミス，まあ不注意かなって思うわけですが…
Unityの苛立ちポイント
ここで本題の苛立ちポイント．
大文字小文字表示が「ある部分で理不尽」なんです．
コンポーネント名としての大文字小文字の差異
.csファイルなんかは，きっと皆さんローマ字で書きますが，大文字小文字のルールは人それぞれだと思います．
仮に，.csファイルの最初の一文字を小文字にしたとします．すると，混乱が起きます．
Obj_rotate.csは一文字目は大文字ですが，obj_rotate2.csは小文字です．しかし，コンポーネント名としてはどちらも大文字です．obj_rotate2.csのファイル名は小文字なのに…
これでは，普通にファイル名指定をミスるケースが出ます．
public変数として用意した”Temp”も，スクリプト中では”temp”で宣言しているんです．でも図中では，強制で大文字になってしまいます．
じゃあ大文字にしとくか，といって.csのスクリプトを下記のようにしたとします．
obj_rotate2.cs
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Obj_rotate2 : MonoBehaviour {
public int temp;
private int temp2;
void Update () {
this.transform.Rotate (5, 0, 0);
}
}
スクリプトの中身は言いたいことと関係ないので気にしないでください．
仮にclass宣言部の
public class obj_rotate2 : MonoBehaviour {
を
public class Obj_rotate2 : MonoBehaviour {
と大文字にしようものなら
Please fix any compile errors and assign a valid script.
です．
結果
普通に混乱します．いや，混乱しました．
じゃあどうするの．答えは
「.csなどファイル名は大文字始まりにする」というくらいです．
まあこれくらいなら良いか，って思います．対策対策．
ですが，先程も言いましたが，変数名もコンポーネントとしての表示上は，大文字始まりなのです．
変数名まで一文字目を大文字にするのはなんだか違和感があります．
うーん．いい解決法無いものか．というか，コンポーネントとしての名称はいいとして，変数名の一文字目も大文字にするの勘弁してもらいたい…普通に間違える…
まとめ
All compiler errors have to be fixed before you can enter playmode!
や
Please fix any compile errors and assign a valid script.
が出たときに主に確認する場所
・ファイル名とclass宣言部の名称が合っているか確認
・大文字小文字の差異，スペルミスなど確認
プログラミング経験者ならスペルミスなんて日常茶飯事です．しょうもないミスでモチベーションを失ってはいけない．
教訓
・c#のファイル名の一文字目は大文字推奨
参考まで．
