Unityでインディゲーム道!

プログラム、Unity初心者がインディゲーム制作を目指して日々思うことなどを書き綴ります。

"Yooka-Laylee TOYBOX"の感想とUnityの可能性について。[ Made with Unity ]

Unityエンジンによる、期待のゲーム"Yooka-Laylee"(ヨーカとライリー)の体験版である"TOYBOX"をプレイしたので、レビューを書きました。基本的には、このブログのテーマである『Unityでインディゲームを作ろう!』という視点からのものですが、単純にゲーマーとしての感想も織り交ぜています。 

さて、とうとうやりましたよ!そして本編発売までもう一ヶ月になろうとしています!悩んだんですが、もうSteam版でいいなと思い予約購入しました。Steam版は予約すると、TOYBOXがプレイできるようになります。体験版ではありますが、本編のポテンシャルを十二分に感じることが出来ました! 

追記!

本編を遊んだのでファーストインプレッションをまとめました! 

 

本編までのオモチャ箱 

f:id:miur-us:20170206004034j:plain

スタート地点。グリーンのステージなんで保護色になっちゃってますね。正にカメレオン。

 

本編の構成に沿った、サンドボックスの世界を探索するという趣向です。

Unityで言うところの"Cube"を地面や壁として設置して、マテリアルを貼って、という簡素なデザインになっています。(本編に出てくるであろうオブジェクトもいくつか出てきています。)

グラフィックいいですね。Unrealのシャープな感じとは対照的です。

 

初見であっても、この手のゲームが得意なら一時間ほどでクリアできるのでは?というボリュームでしたが、楽しめましたね。

(嵌ると時間がかかる仕掛けもありますけどね。)

あんまりこれをやりこみすぎて慣れすぎても本編楽しめないと思うんで、ほどほどにしておきたいと思います。

 

f:id:miur-us:20170206004335j:plain

本編はこれをはるかに凌ぐオープンワールドが待っています!

 

本編でも登場する光る葉っぱを100枚集めて、“ペイジー”という本のページのようなコレクトアイテムをゲットするという目的が一応設定されています。

(これについては、世界のSpeedRunはもう6分以内という領域に達してます。すげー)

 

しかしいくつかのちょっとした隠し部屋があるので、この世界をブラブラと探索することでも、それなりに楽しめます。

 

 

問題の操作性について

なんといってもアクションゲームは、最終的には操作性にかかっていると思います。その点さすがという他ありませんでした。

UnityだとRigidbodyにAddForceすることでモノを動かす、というような手段をとるわけですが、単純にそれだけだと快適な操作感は出せないです。しかしYookaは快適に動かせます!自由に爽快に世界を飛びまわれます!

 

なぜ操作性が大事か?

・うまく操作できないというイライラ
・ステージをクリアできないというイライラ

この二つはまったく別のものだからです。

前者は慣れることはあってもアップデートで改善でもされない限り、イライラはずっと残ります。逆にアクションが上手くいかず失敗したとしても、何回もやってクリアできたらそのイライラは達成感として昇華されて、プレイヤーはカタルシスを得ることが出来ます。

難しいけど面白いゲームで操作性にクセがあったとしても、この二つを履き違えているゲームはないと思います。

 

 

アクションゲーム伝統のギミック

さて実際にやってみて、やはりYooka-Layleeは3Dアクションゲームの伝統を正統に受け継いでいるなと思いました。 

f:id:miur-us:20170206010030j:plain

浮かびながら移動する足場。落ちないように!

 

バンジョーとカズーイの意志を継いだスタイルですが、マリオ64に通ずるものも感じましたね。まあバンジョーとはもともと兄弟ソフトのようなものかもしれませんが。 

f:id:miur-us:20170206010257j:plain

ヨッシーのヒップドロップよろしくスイッチを押す!

  

f:id:miur-us:20170206013826j:plain

 レトロゲーのような見下ろし視点に切り替わったり。

 

おそらく本編にも、ドンキーやバンジョーなどをやった元少年たちにとっては、馴染み深いギミックがたくさん詰まっていると思います。個人的にはトロッコが楽しみです

  

カメラについて

これは3Dアクションゲームにおける宿命なのかもしれませんが、カメラについては少し気になった部分は正直ありました。 

ゲームパッドの右スティックでカメラは動かせるのですが、気持ちその可動域が狭いのかな?と感じました。このゲームの性質上やはりカメラを動かして、探索することが多いのでここらへんは大事です。ここら辺は本編の方は改良されているかもしれません。本編では動かせるスピードも調整可になると思います。 

 

Unityによるゲーム作りの今後について

はっきり言ってしまえばUnity製のゲームはクソゲーである、というような風潮が少なからずここ数年あったと思います。

 

このTOYBOXだけで判断することは出来ませんが、少なくともUnityだからダメ、みたいな判断をされるゲームではないはずです。

単純にゲームとして面白いかどうかの判断をすべきレベルになるだろうからです。つまりはもうどんなゲームエンジンを使っているかは気にならないレベルの出来だろうし、プロ、アマを含めて、自分でゲームを作る以外の人達にとってはそのゲームが何で作られていようと関係ないからです。

 

いよいよUnityでもそういうゲームが出始めてきたのであり、Yooka - Layleeは今後のUnityの試金石的な作品になるだろうと思います。 

f:id:miur-us:20170206021211j:plain

歴戦のゲームデザイナーと若き才能が集結したPlaytonic games 

 

Unityは汎用ゲームエンジンということで自分のような素人を含め、気軽に使うことが出来る反面、よりシビアなゲーム作りは出来ないのではないか?というな論調があったと思います。

正直、PlayTonis Gamesはインディとはいえメンバーが元レア社だったりと年季の入ったメンバーなので、そりゃ変なものは出来ないよな、って感じではあります。しかしUnityでもきちんとしたゲームが出来るんだ!という証明をしてくれると思います。

 

とにかく本編をやってみてですね。正式な評価を下したい、というか単純に楽しみたいという気持ちが大きいですね! 

f:id:miur-us:20170206015205j:plain

探検の領域は水中にまで。

 

 まとめ

というわけでUnityの今後に希望を感じることができる出来でした。かといって素人がここまで出来るはずはないんですけどね!本編に関しては、後はボリュームが実際どうなのか?ってところですね。Steamだと9GBなんです。最近の大作洋ゲーは余裕で50GBくらいあるんで、Yooka - Layleeはグラはアニメ調でどうなるかな?という感じです。

 

ともかく、これを目標にしてUnityを触っていきたいなと思います。

 

Yooka - Laylee本編の初感について

 

プログラミングにおける可読化と抽象化。C#は英文に近いけど・・・編

C#はかなり英文に近く、そういう意味では読みやすそうに見えます。しかし、あくまでプログラム文を読むということは、自然言語文を読むということとはまた別の問題なんだ、ということについて、歴史を踏まえて考えてみました!

抽象化とは機械の感覚を人間に近づける、

ということだと思います。

  

『抽象化』を考える。

アセンブリにまで手を出し始めて訳わかんなくなってきたけど、とりあえずUnityもちょこちょこ触っています! 

この記事にも書いた『抽象化 』について軽くまとめておきたいなと。そして、それに関連したC#における落とし穴をまた見つけたんでそれについても。今までに学んだコンピュータ自体に関するまとめにもなってます。 

 

コンピュータはプログラミング言語を読まない。

プログラミングにおける抽象化です。

 

プログラミング言語の歴史とは

可読化と抽象化の歴史なのではないかと最近思っています。

 

コンピュータは機械語しか読めません。

機械語01しかなく最初期のコンピュータサイエンティスト達は、その1と0の羅列と格闘していたようです。しかも、それを機械式のスイッチを動かすことで物理的にプログラミングしていたと。考えただけで頭が痛くなりますね。  

しかし、そんなものやってらんなくなりますよね、当然。というわけで、プログラムつまりソフトとハードを切り離すことに至ったようです。しかし、それはまた別のお話。

 

 

プログラムは依然、0と1の集合体です。せめて桁数を短くしたい!というわけで16進数で表すようにしました。でもやっぱり数字は読みにくい、じゃあせめて何か英語を当てて多少読みやすくしよう! 

これがアセンブリです。ニーモニックという略語を割り当てることでつまり機械語である数字の羅列を人間も読めるようにした、ということになります。つまり機械語可読化した、ということです。(ここまでにどのくらい時間がかかったんだろう・・・。)

 

 

読めるようになったもののアセンブリ自体は原始語といえるもので、現代人の言語とはやはりかけ離れるんで、さらに自然言語に近づけたいわけです。命令自体も単純なことしか出来ませんからね。というわけで高級言語が作られるに至ります。(人間の自然言語に近い、という意味で高級。機械に近いと低級言語。“良い”“悪い”ではない。) 

 

よくリーダブルなコードを書くように!と言われます。(ダレに?)

結局これはダレのためでもない人間自身のためなんですよね。プログラミング言語自体、機械語を間接的に読み書きするための手段であり、読みにくいコード書いたら意味ないじゃんっていう。

 

 

言葉の持つチカラ

現代人は言語を使って、より抽象的な概念を考えたり、作り出すことが出来ます。

より柔軟なコミュニケーションが出来ます。

 

『アレやっておいたから』と家族、友人に言えば、きちんと伝わるのが人間です。これは極端な例ですが、例えば『掃除をする』で考えてみましょうか。

掃除をする、とは状況によりますが、より明確に言うならば、  

掃除をする、とは
・いるものといらないものに分ける。(それらを判断する基準?)
・部屋にある物をあるべき所に戻す(あるべき所とはどこだろう?)
・掃除機でホコリを吸い込む(掃除機はどう使えばいいか?)
・ゴミをまとめて、ごみ収集に出す。(いつ、どこに持って行く?)
これらを抽象化した言葉

掃除する、という言葉を選んだのに特に意味はないんですが、たった一つの言葉にいろいろな概念や作業が含まれていますね。で人間は状況に応じて、実際どうすべきかを判断するわけです。これって良く考えればすごいですよね。機械には出来ませんからね。

今のところは。

なんでこんな風に機械に命令できたらいいよねーって話になったと思うんです。なんで抽象化とは、機械に譲歩しないで済むための手段なのだと思います。

 

 

高級言語の登場!

というわけで生まれたのがFortranという初のプログラミング言語

詳しくはわかりませんが、不完全ながらも英文には少し近づいた表記になっているようです。

 

そして決定的な言語である、C言語の登場です!多くのコンピュータ言語が影響を受けたようで、場合によってはいまだになくてはならない存在のようです。これは、かなりもう英文っぽい一種の暗号のような表記です。

 

大きな注意点としては、コンピュータはこれら高級言語を直接は理解できず、コンパイラが間に入っているということ!つまりプログラミング言語自体をコンピュータは読まない、ということです。

 

思うんですけど、プログラミング言語の意味不明というか解せない所って全部、人間が機械に対して譲歩している部分だと思うんですよね。で今というかここ20年くらいコンピュータってなくてはならない存在だし、いろんなことやってくれて、それで現代社会が成立しているわけで、何でもできるってやっぱ思い込んでると思います。

 

 

しかし、やはり出来ないことの方が多いから、人間が折れるしかないわけです。そのコンピュータが、何ができて何が出来ないかを知らないとプログラミングって行為自体が理解できないよなーと思います。

 

 

さて、抽象化することで人間の感覚に近づけよう、という流れの中で我らがC#が出来ます!!

 

これはもうほぼ英文に近いです。

ただし、オブジェクト志向というものを理解する必要がありますが。

 

オブジェクト志向という概念については、もう役割分担でいいんじゃねーの?とか思ってきました。各機能ごとに担当を決める、っという解釈です。

 

一枚の紙に全ての命令を書くと読むのが大変だ!

じゃあ項目ごとに書く紙を分けよう!(“クラス”を作る)

別々に書いた紙をどう結合させる?各紙ごとの担当者が必要だ!

(オブジェクトを作り、オブジェクトに管理させる。)

オブジェクトはいわば架空の人物であったり、物なんですよね。

じゃあなんでそんな架空の存在を作り出すかと言えば、人間が楽だから。 

 

これも全て全部、人間のためのもの。

最終的な0と1の羅列である命令文を読み込み、処理するだけ。

なんかもう既にかなり機械に振り回されているんだな、とか思いますね。

 

 

C#はとてもいい言語だけど 

C#ですが、英文にかなり近いとはいえ、人間が譲歩すべき部分は本質的にあまり改善されていないので、あくまで面倒な部分が隠されているに過ぎません。

 

コードにある、コンピュータがどう動いているか?という性質、あるいはそのコードを書いた人のロジック、思考プロセスを読まないといけないんですよね。

 

ここら辺をきちんと説明してくれる人が少ないので困ってしまうわけですし、

初心者向けであるはずのC#で挫折してします人を生み出すんではないでしょうか?

自分も挫折しかけたというか一昨年の冬に入門を中断しましたからね・・・。

 

 

なんでC#を初めとした高級言語は人間のために、0と1の集合体を抽象化したものにすぎず、コンピュータ自体が実際どう動いているかイメージすることの重要についての考察でした。 

 

でもやっぱりC#じゃなきゃプログラミングなんてできなかったと思いますけどね。

もう少し教えてくれる人がいれば楽だあったかなー、という話でした!!

  

 

 

アセンブリ言語とC言語。コンピュータのコアの部分を知る。

 いまさらC言語なんて・・・ましてやアセンブリなんて・・・と思うかもしれませんが、人によっては最適な入り口は違うと思いますし、いろいろなプログラミング入門の仕方があっていいんではないか?ということです。

  

いいサイト見つけました

ポインタについての記事で、純プログラミングな話題はひとまず区切ろうと書いたのですが、すごくいいサイトに出会ったので紹介させてください。

というかやっぱUnityガンガン触んないと!って感じなんで後は平行して学んでいくって方針で行きたいと思います。 

  

こちらです!

Programming Room

アセンブリ言語の観点から、C言語について解説している個人の方のサイトです。

まさに2000年代初頭という感じのHTML丸出しなページですが、そこがイイ!

けっこう誤字脱字もありますが、ここら辺に興味ある人にとっては入門にふさわしいテキストなのではないかと思います!

  

 プログラミングを学び始めるなら

よく玄人の方は『アセンブリからやった方がいいよ。』みたいなことをおっしゃるようです。とはいうものの、最初からそれってなかなか難しいですよね。

なんで現実的にはC#とかで簡単なアプリを作ったりして覚えたほうが楽しいし、ハードルは低いと思います。自分もコピペでごり押しで作ってみて、でした。

 

自分もアセンブリからやった方がいい、という言葉は知っていましたが、コンピュータの基礎教養本で軽く触れた程度でしたね。

しかし、この考え方の有用性を明確に教えてくれたのが、このサイトなわけです!

  

では、なんでアセンブリ言語を学んだほうがいいのか?

それはアセンブリを通じて、コンピュータの核であるCPUメモリがどういうやり取りをして、プログラムを実行しているのか、という原始的な部分を学べるからです。

 

アセンブリとは、コンピュータに直接送られる機械語をすこし人間にも読みやすくしたものであり、アセンブリを知るということはコンピュータの生の動きを知ることができる!というのです。

プログラミング言語高級言語ということで、人間の言葉に近づくように抽象化されていますが、アセンブリはかなり具体的な、裸な姿を見ることができるというわけです。

  

人間の感覚に近づける。抽象化。

抽象化とは例えば、Console.WriteLineみたいな“コンソール画面に表示して!”

というようなことです。アレやって!みたいなことです。

 

しかし、コンピュータにこれをやらせるには、何番のポートに接続されているディスプレイの何番目の液晶の発光体をどのくらい光らせるとかそんな

クソ面倒な指示をしないとだめなわけです。

しかしプログラマがいちいちそこまで考えるのは面倒なので、あらかじめ抽象化されたConsole.WriteLineという命令が用意されているわけです。

  

Unityというゲームエンジンもそういう面倒な部分を考えずにすむように、作られているわけですが、より高度なゲームを作りたいとなったときにそういうコンピュータの仕組みそのものを避けることは出来ないと思うので、結果将来的には役立つと思いますけどね。

例えば"Destroy"というUnityのメソッドはゲームオブジェクトをシーンから完全消去する、という処理を『破壊する』という言葉で抽象化してくれています。

 

 

要は隠されているだけで、どんな言語、APIであってもその背後ではアセンブリC言語並みのめんどくさい部分がちゃんと存在している、ということのようです。 

そこらへんに興味のある方はぜひ詳しくは、このサイトを見るとなぜアセンブリからやるべきか?ということの謎がわかると思います。

  

サイトにお邪魔しよう!

こちらのサイト、HTML丸出しなのですこし読みにくいかも・・・。

でも読みやすく出来る、そうiPhoneならね。

 

f:id:miur-us:20170126165336j:plain

これが実際のページ。パソコンだとさらに横に広がるので見にくい。

 

f:id:miur-us:20170126165458j:plain

iOSのリーダー機能をオンにすると読みやすい!

 

iOSのリーダー機能は便利ですね。

これを使えば古いHTMLサイトも快適!

 

 

このサイトはC言語の解説のためにまずアセンブリの基本的な所を解説する、という体裁をとっています。

なぜならC言語高級言語とされるも、実際にはOS作成のための言語でもあるので、ハードを直接操作できるような部分があるからです。

Cの中にアセンブリを書くことも出来ますし、要は低級言語的な性質も持っているから、ということなようです。

 

そしてCの中で難関とされるポインタも低級な部分、つまり“メモリ”そのものに関することなのです。

普通の高級言語にも実はポインタに該当する部分があるのだけれど、抽象化されているので普通はプログラマが目にすることはない。

しかしC言語では丸出しになってしまっているわけです。

つまりハードに近い、低級な部分に関する知識がないとポインタは理解しにくい、ということなのだと思います。

なのでアセンブリの視点からC言語を説明する、という方法を採用した、とのことです。詳しくはサイトでどうぞ。

  

アセンブリから』の真意とは?

なのでアセンブリからやった方がいい、という言葉の真意は、

・Cをきっちり理解できれば、いろんな言語もできるようになるよね。
C言語をよく理解するにはアセンブリを学んだ方がいいよ!
・だからアセンブリから勉強しよう!

ということなのではないか?と思いました。

 

 とはいいつつも完全に理解するのは難しいと思うので、だからこそこういうサイトで軽く読んでおく位でいいんじゃないかなと思いますけどね。

というわけでそろそろゲームつくるぞ!っと。 

 

 

 

プログラミングはクソゲーなのか?洋ゲーとの類似性について!

個人的に、プログラミングはクソゲーじゃないか?疑惑がありました。そんな中で洋ゲーとの共通点に気づいた!という話です!

 

自由度が高すぎて、何をすればいいかわからない。

そんな風に言われることも多い洋ゲー

まさにプログラミングも同じだった・・・?。

 

 

洋ゲーっぽい、ということ。

このブログがUnityでゲームを作ろう!というテーマだからゲーム関連付けるというわけでもなく、ただただ単純にプログラミングって洋ゲーっぽいなと思っています。

 

今となっては一般ゲーマーもごく普通に、洋ゲーをプレイする時代になったのかもしれません。 

しかし一昔前だと洋ゲーといえば癖が強くて、一部のコアゲーマーがひっそりとやるものだという風潮があったと思います。自分は子供の頃はグロいのは嫌いだったし興味もなかったすね、たぶん出来なかったろうし。

もちろんグロくないのもありますけどね。


スーパードンキコングシリーズとかクラッシュバンディクーとかも洋ゲーといえばそうですし。ここら辺は、子供もできる優れた普遍的なゲームなわけで。

 

ただしここ数年の洋ゲーは大作系なんかも、とにかく丁寧というかプレイヤーに優しい作りになってますよね。 

しかしやはり、とっつきにくい、癖が強い異常に難易度が高い、というのが洋ゲーに対する一般?認識だと思います。

  

自由度の意味とは。

洋ゲーと言えば、自由度!みたいな風潮があります。

そもそもじゃあ、なぜ洋ゲーにおいて自由度が重視されるのか?

 

日本に最も影響与えたとされる洋ゲーのひとつにウィザードリィが挙げられると思います。これはファミコンへの移植版が有名です。ドラクエ、FFの原典の一つです。

 

基本ダンジョンにもぐって攻略を進めるだけ、という点では世界は狭いですが、キャラ作成に関しては自由度が高いです。


ファミコンへの移植の際にグラフィックや音楽面、システム面に関する調整を日本人によって行われていますので、かなりやりやすくなってるらしいです。

この辺はもうチョイ個人的に調べたいところですけどね。ファミコン版については、ここにかなり詳しい解説が!

ファミコン版ウィザードリィのすすめ

 

しかしオリジナルのウィザードリィはやはり癖が強いわけです。

そもそも論で言えば、テーブルトークRPGをコンピュータ上で再現するっというものですから。(なお日本ではウィザードリィは元祖RPGと位置づけられますが、本国アメリカではこれより先にいくつかのRPGゲームは作られていたようです)

 

テーブルトークRPGは会話とサイコロ、GMとのやり取りで進行していくもののようなので(すいません、素人なんでこんくらいの認識です。)もともとのルーツを辿れば、RPGゲームにおいて自由度というのは切っても切れないものなのだなぁと感じます。

 


あと洋ゲーRPGは、オブリビオン等とにかくパラメータが多いですよね。あと重量制限など無駄にリアルというかストレスになりかねない要素も多いです。これは洋ゲーの場合、多分にシミュレーションとしての側面もあるのでしょう。

 

なおオリジナルのウィザードリィに関して呪文はキーボードを使って手打ちですよ!しかもスペルを間違えたら、詠唱失敗するという!めんどくせえ!でもプログラミングも同じく、一文字でも違えばコンパイラが許してくれませんからね。(Visual Studioでいえばインテリセンスが指摘してくれますが)

 

ここらへんの無駄に面倒な部分もプログラミングっぽいですね。

 

自由度の高さとは、つまりどういうことか?プレイヤーは自分で考えて世界を旅しなければいけません。自分で楽しむ術を見つけなくてはいけません。


ここら辺をうまく日本人に受け入れさせてくれたのは、最近だとオブリビオンとかスカイリムとかですかね?自分なんかスカイリムとかまともにメインやりませんからね。好きにそこらへんぶらつくのが楽しいんで。


とにかくそういう洋ゲーが持つ性質をプログラミングも持っているなとすごく思います。

  

何でも自分で作れる。いや作らねばならぬ。

さてプログラミングに話を移します。プログラミングにおける自由度とは、制約さえなければ自分で解決法を生み出せるという部分でしょうか。と同時に自分自身で考えないといけない部分も多いわけです。 

 

コンピュータがデータを記憶するのに使う器をプレイヤーが用意しなければなりません。そして名前も付けなればなりません。
<変数の宣言。>

 

問題を解決するための必殺技を作れます。というか自分で作らないといけません。
これもやはり名前は自由に決められます。発動するのに必要な道具も決められますし、無くてもいいです。(引数)
<関数をつくる>

 

ただあらゆること全部決めるのは大変でしょうから、ある程度の基本的なものは用意してあります!どうぞご活用して自由に世界を旅してください!。

<ライブラリ、APIの存在。>

 

この共通点に気付いた時ちょっと楽しくなりました!自由度が高くて、癖の強い洋ゲーと思えばいいんじゃん!と。

といっても実際の作業においては、状況に応じて様々な制約が課されている場合がほとんどだと思いますので、まぁそこまで自由というわけではないとは思います。

 

しかし可能な限り、動きさえすればプレイヤーの思いつくままに組み立てることができるということです。そこらへんを多くの教則本で強調してほしいなぁ。目的地にたどり着くまでには、様々なルートがあり、そのどれを選んでも良いということなのです。 


じゃあ例えばどういうことなのか?ということを実際のコードを見ながら考えてみたいと思います。

 

 

1から100までの自然数すべての合計を求めよう!

 この問題は次のように言い換えることができると思います。

 

最小値の自然数minから、最大値maxまでの自然数の合計を計算するプログラムとは?

 

1から100の場合で言えば1,2,3,4,5,6,7,8… 96,97,98,99,100という自然数列を全部足してその合計ですね。

この問題に関しては公式があります。
(min + max) × (max - min + 1) ÷ 2

1から100なら
101 × 100 ÷ 2 = 5050という具合です。
この公式を利用して関数を作るのが手段として正しいのかもしれません。

しかし他の方法もあります。whileループ文を使うことをによって同様の結果を得ることができます。 

f:id:miur-us:20170127230218p:plain

 合計を入れるためのバケツ"sum"を用意します。何も入ってないといけないので0を代入しつつ宣言します(初期化)。

 

そこにmaxの値を投げ入れては、1引いていきます。100でしたらまず100を次に99を98を!という風にドンドン入れていきます。これをminよりひとつ大きい値まで繰り返すわけです。(ここでは2まで)

 

while文が終了したら、最後にminの値を加えて終わりです。 

公式を使う方がよりスマートなのかもしれませんが、よりコンピュータらしいこの方法が好きですね。この方法を思いついたときは、わりとプログラムできるようになったな!と自画自賛しましたね。

 

 

ただし範囲が大きくなると処理時間に差が出てくるかもしれません。公式を使えば計算自体は一瞬(4回の計算)に対し、この方法だと計算をその数の範囲分の加算を繰り返しているわけですからね。でもコンピュータの計算能力はもはや一秒間に数十億回レベルですからね。どうでしょうね。 

もし差が出るのであれば、より安定し、速い方を選ぶということになります。

 

しかし特に制約がないような場合においては、いかなる方法をとっても良いのプログラミングなのだろうなと思います。

 

自由度の高さを楽しむ!

よく日本人は自由度の高いオープンワールドRPGが苦手、というような風潮があります。何をしていいのかわからない困る、というものです。別に何してもいいんだよ!と言われても・・・。という人が多いのが現状でしょう。

 

プログラミングも近い部分があると思います。プログラミング言語の文法を覚えたとて、プログラミングを出来るようにはならないからです。

 

プログラミングに関する最初の罠は、プログラミング言語は道具にすぎず、設計図(解決法)を作るのは、プレイヤー次第ということです。言語だけだとホントに文法というか単純な道具だけなので、APIとかフレームワークも使わなきゃいけない、ということもあります。

  

でもレゴブロックでは自分の好きなもの勝手に作ってましたよね?あるいはマインクラフトなどのクラフトゲームはどうでしょうか?フォールアウト4でも街作りなど自由にすることができます。それのちょっとめんどくさいヴァージョンだと思えば・・・。

 

こう考えることでまだ楽しくプログラミングできています。最初はクソゲーだと思いましたけどね。クソゲーではなく、ちょっと癖の強い洋ゲーということで。 

 

なんで洋ゲーが好きな人はプログラミングの適正がある?

ということは言えなくもない!?

 

自分で引き続き検証してみます!

 

 

 

海外のYoutuberに“支援”した話。まとめサイトが嫌なら個人に明確な賞賛を。

 

大層な話ではなく、1,000円振り込んでみた、というだけの話です。

 

 

f:id:miur-us:20170119024914p:plain

寄付についての御礼カード

 

自分も考えてみればそうなんですが、ネット上の情報に対して

誰が発しているのか?ということにはかなり無頓着ですよね。

 

まぁ自分に都合良い情報を崇めますしね。

自分が満足できるかが先で、

内容がよほど良いと、この人なんだろうと初めて

その発言者に目が向くという感じだと思います。

ただしネット上では匿名であったり、ペンネームだったりするんですけど。

 

ネットの良くも悪くも共産主義的な部分でしょうか?

ネット上のものはみんなのもの、という。

 

 

しかしそういう性質が過剰に悪用されてしまって、昨今の

キュレーションサイト問題のような事態になってしまったのだと思います。

 

いわゆるまとめサイトというもの自体が悪いとは思いません。

きちんと存在意義はあるはずなわけで。

 

しかし、やはり元の発信者が存在するのならば、ないがしろには出来ないと思います。

情報をわかりやすくまとめる、整理するのも大事ですけど、

発信者に対するリスペクトというか賞賛があってしかるべきではないかと。

 

金ではないとは思います。

しかし、やはり面白いことをやっている人に対して

我々が明確なコミットメントをしていかねば、

今後ネット上のコンテンツが発展することはないと思うんですよね。

 

 

www.youtube.com

今回、The 8-Bit Guyというアメリカのyoutuber、

わりと大手だと思うんですが、こちらのチャンネルに“支援”したわけです。

 

unity-indie-dou.hatenablog.com

 この記事でも、少し触れてました。

 

取り扱ってるレトロネタは、かなり面白いし、参考になりましたね。

あと現在の支援システムが2月で終わりになるので、

その前にやってみたかった、というのもあります。

 

金額は100円,500円,それ以上って感じで、見栄をはって

きりのいい1000円にしました。500円でよかったかな?

とか少し思ったりもしましたが、それ以上のものをこのチャンネルか得ているわけですから、そこはドンと構えないと。

 

 

ほんの気持ちで良いと思うんです。

 

はてなブログでも、ああ100円ぐらいなら全然払えるな!

って記事あるじゃないですか?

 

払えばいいんですよ。

100円は決して低くもないですから。10円でも良いんじゃないですか?

技術的にはそんな難しいことだとは思いませんがどうでしょう?

 

金じゃないけど、です。

正直、PV数だけなら稼ごうと思えば、稼げると思うんですよね。

自分は出来ませんけど。

 

でもそれは表層的な評価指標にすぎないんじゃないだろうか?と思うし、

ちゃんと面白い人を評価することが大事なのではないかと思う今日この頃です。

 

というわけで意識高めの記事でした!m(_ _)m

 

 

ブログのデザインを変更してみた。

 

 

CSSを使って、ブログのデザインを変更してみました。

※PCからの閲覧のみでケータイ版は変わりありません

 

www.yukihy.com

 

こちらのページが大変参考になりました。

 

あと色の指定についてはココ!

www.colordic.org

 

 

 

まぁプログラミングできればCSSは何とかなりますよね。

プロパティ名とかはわからなくてイライラしましたけど。

 

一応、公式テーマの"Solid"というものを最初から

使わせていただいてました。

 

黒背景に白文字が好きなんですよね。

目に優しいし、地球にも優しい。

 

ただ"Solid"の場合は微妙に緑がかった背景と灰色気味の

白文字だったので、そこがちょっとイヤでした。

 

今回、全体的な見易さを考慮して変更出来たと思うのですが、

いかがでしょうか?

 

今後は内容ももちろん見やすさにも配慮した

ブログ更新を心がけたいと思います!

では!!

 

C言語の『ポインタ』について。わかりやすい説明を試みる!

C言語『ポインタ』について、自分なりの説明というものに挑戦してみました。プログラム初心者によるものなので、内容の保証は出来ません。"ポインタ"(Pointer)の名の通り、"指し示すもの"であり、何を指すかといえばハードメモリ上に置かれている変数のアドレスになります。  

はじめに

新年も迎えて、Unityを触っているとやはりまだまだ勉強しなければならないことが
いっぱいあるなと改めて思った次第です。プログラミング自体にはだいぶ慣れてきました。簡単なものであれば、自分で考えてスクラッチからコードを書く、ということも幾分か出来るようになりました。


それで去年の秋以降、本ブログではプログラミング自体についていろいろ書いてみましたが、そろそろいいかな、と思ってきました。というのもそもそもUnityを使いたいけど、とりあえずプログラミングはプログラミングで勉強した方がいいだろう。というのがここ数ヶ月の課題でした。それがひと段落したので後はUnity上でやりながら勉強する、という段階に移ろう!ということです。

 
ということでプログラミング自体も楽しいのですが、ここらで1つ区切りをつけるという意味で、C言語における『ポインタ』というものについての個人的見解をまとめたいと思います。なんで今回こそUnityには全く関係ないです。これ以降はUnityに集中します。


まだまだ初心者ですので、C言語における最難関とされるポインタについて、はてなのような、かなり人目に触れるこのような場所で書くのはどうかとは思います。
しかし論理的な説明として、なるべくわかりやすいような形にまとめられるかも?
と思ったのでちょっと書いてみたいと思います。

  

ポインタとは?結局何? 

ポインタ、ないしポインタ変数は結局どういうものかといえば、 

ある変数の代役として使うことのできる変数です。

 ここで疑問なのが、まずそもそもポインタは何のためにあるのか?
そしてなんで代役が必要なのか?ということです。
その変数を直接使えばいいじゃん?って思いますよね。
そこをどう説明できるか、考えてみよう!というのがここでの試みです。


ポインタはC言語の学ぶ上で初心者にとって、大きな障壁として語られます。ここで挫折してしまうという人がかなり多いようです。
C#の事前学習のためだからと最初は無視しましたが、確かに意味不明でした。

 

ポインタというものを理解するためには、コンピュータのハード的な構造、そしてC言語というものの特性、プログラミングにおける変数のスコープや関数の独立性などをロジカルに理解していくことが必要なのかなと思います。

ということで、順に説明していきます。

 

ハードとしてのコンピュータ

ざっくりと捉えます。ハードとして見たコンピューターというものは、

・メモリ     長期記憶用のHDD,SSD、と短期記憶用のRAMメモリ
・CPU     計算、演算装置
・入力出力装置 ディスプレイ、キーボード、などのインターフェイス

が組み合わさったもの、と解することが出来ます。
メモリはここでは“短期メモリ”の方を指し、全てに番号が割り振られた連続した作業台、と考えることとします。

 

そして実際のプログラミングが起動されると、ハードディスク上に保管されていたそのプログラムコード、OS上ではダブルクリックされるexeファイルなわけですが、

それがメモリ上にロード、つまりコピーされ展開されます。

f:id:miur-us:20170111233518p:plain

ポインタをデスクトップ上のショートカットに例える方もいます。ショートカットをダブルクリックするということは、本体のexeファイルをダブルクリックしていることと同じです。デスクトップ上のショートカットに実体はなく、ハードディスク上のどこに.exeがあるか?という位置情報のみを持っています。

 

計算機であるCPUと、作業台であるメモリがやり取りすることで、
コンピュータとしての処理、計算というものが行われることになるわけです。

 

その際、そもそものプログラミングの中身は、データであったり処理の手順であったり
要は変数であったり関数の集合体なわけです。(ザックリ言うと)

ポインタについてなので変数に絞ります。
変数というのは数字だったり、文字だったりのデータ、値を格納するためのものです。
そして変数の宣言というのはメモリ上において、そのタイプのデータのための場所に名前をつけて確保するということです。
(言い換えれば、メモリ上のある一定のスペースに名前を付けたものが変数)

  

メモリの上の住所、転勤多し。

メモリのその全てに番号が振り分けられているので、変数はその番号をそれぞれ持っていることになります。
その番号というのが『アドレス』というものになります。

ここで重要なのは、そのアドレスというものは、実際にプログラムが起動されるまでは
どんな値があるのかというのはわからないことです。そのプログラム自体、あるいはそのプログラムの中における関数が呼び出される毎に変わります。

変数が作り出される際にメモリのどこに作るかはコンピュータ(正確にはコンパイラ)に任されているからです。という事は仮にもしそのアドレスが何かの際に必要になる場合には、その都度きちんとそれを保管するようなものが必要になる、と考えるのが自然です。つまり、アドレスを格納することができる変数こそがポインタ(ポインタ変数)です。ということで、とりあえず次に移ります。

  

関数の独立性。

C言語、あるいはその影響を受けたプログラミング言語『関数の独立性』というものが確保されています。それはその関数の中で宣言された変数は、その関数の中でしか効力を持たないということです。


これは関数の中でしか使わない変数は、その関数の中で宣言するのが、リーダブルなコードとしていいんですが、もし関数の中で宣言された変数の適用範囲が、その外にまで行ってしまうと、誤って他の変数と混同してしまう恐れがあるのでそれを避けるためです。同様にその関数の外で宣言された変数は、その関数内部に効力をもたらしません。

  

Cは『値渡し』だけ

そしてC言語における大きな特徴が、関数に値渡ししかできないということです。値渡し、というのは変数という器のメーターに表示された数値を関数という機械に手打ちで入力する、というイメージで説明できます。変数そのものは関数に入ってません。変数の中に入っていたデータを読み取って、写しているだけです。

つまり変数それ自体を関数の中に入れることはできないというわけです。


では逆に関数に変数それ自体を入れなければいけないという状況はどういうものがあるのか。(別にreturnでその変数に返せばいいじゃないか?という疑問もありますね。)


変数に直接何かを入力したい、
1つの変数を複数の関数間で使いまわしたい。
とにかく変数を直接弄りたい!まぁいろいろあるみたいです。

 

scanf("%d", &num);
scanf関数は変数の中にキーボードから入力された値を代入する、という機能を持った関数です。でも変数の頭に付いてる&の記号はなんだろう?と思いますよね?
はい、あともう少しです!

  

変数を直接操作するための裏技

じゃあ、どうすればいいのか?とここで先ほどのアドレスが出てきます。 

f:id:miur-us:20170111234508p:plain

f:id:miur-us:20170111234519p:plain

f:id:miur-us:20170111234527p:plain

paizaのブラウザエディタにて。変数numのアドレスを表示させています。三回とも違いますね。 実行ごとにアドレスは変わるということです。

 

メモリにおけるアドレスは16進数で書かれた数値です。見慣れない形での表記になりますが、数は数に変わりありません。数値であるならば関数に入力することができるわけです。これを使えばいいんじゃね?となりますよね?ポインタはアドレスを代入することが出来るんでした。ということは・・・?

  

ポインタは代理人

つまりは、ポインタを使うということはこういうことです。

 

&はアドレス演算子といって頭に付けるとその変数のアドレスを表すことが出来ます。

(上記の写真によるコードはそれを利用してnumのアドレスを表示させました。)
それを使い、その変数のメモリ上のアドレスを関数に引数として入力し、
一方でその関数の中で宣言されたポインタ変数がそれを受け取る。

ポインタ変数は通常変数モードに切り替えることで、
格納されているアドレスにある変数の代わりを務めることが出来る。(間接参照できる。)そのポインタに関数の中で行われたことは、その外にある変数にも連動して反映される。よって関数に変数が入力する、ということを代替的に実行することができる。


これがC言語におけるポインタ、というものへの
現時点での自分なりの論理的な説明です。

そもそも値渡ししか出来ない、というのがC#からすれば不便そのものなんですが、
しかしポインタがないとされる言語も内部的にはポインタ機能はあるようで、
C言語学習は将来的には役立ってくれるだろうと思います。