機械を使う際には構造を知らないとまともに扱うことが出来な無いわけですが、構造物を作る際には、この処理の流れを考えることになります。日常で使う機材には 【 処理の手順 】 が存在しますが、これも、設計段階で織り込んでおくものになります。人が使用する物の場合だと 【 操作手順 】 が存在しますが、これを用意する場合にはフロントエンドのレイアウトや処理の構造を考える必要があります。当然、こうしたものは、 【 どこかから部品を持ってきて並べただけというプラモデル用な構造になっているわけではない 】 ので、必要な仕組みや構造を考える必要があります。
構造物の利用については、 【 そもそも背けき段階で使用方法が確定しているもの 】 ですから、これについては、何かを作るわけではありませんから、 【 単なる定数で指定されたもの 】 ですから、コレに対処する場合には、
■ 定数のデータの記憶
■ 定数化したアルゴリズムの実行
だけで対処できます。また、製品の場合、使用する難易度の高いものだと普及しませんから、普及させるものく敵の製品であれば、 【 使用する難易度を下げて間口を広くする 】 ようにデザイン部分で設計を行うことになります。
つまり、UIとその操作部分が過度に難易度を跳ね上げないようにしてあるので、一般的には工程が少なく、処理の方法も簡素になっています。これが、製品として損刺しいているものになりますから、 【 製造と比較するとエンドユーザーの使用するデバイスの操作はかなり簡素なものになっている 】 わけです。
挙動が簡素になるほど操作の工程も減りますが、世の中で動作しているものの多くは模型を作る作業とは全く異なるので、【 推移 】 や 【 構造的な挙動 】 が存在していますから、 【 知識や能力がなくても出来る 】 というようなものではありません。その為、構造物を作る際には設計や仕組みを作る作業が常に発生するわけです。
機材についても構造物の仕様で出来ることが違ってきますが、基本的には機材に合わせた作業方法で操作を行う必要があります。これを間違うと大抵の場合結果がひどくなったり、機材を適正に使用すればまともな結果に行き着くにも関わらず、仕様者の間違った操作でその結果とは似ても似つかないものになることがあります。
この辺りは、電卓で計算をする際に発生する事象がそれに該当しますが、電卓と言うハードウェアの構造は、追加によって処理を実装していく構造になっています。つまり、
■ 数値
■ 演算記号
の順数値と演算記号の判定が行われていますが、
■ 数値
■ 演算記号（追加）
■ 数値（追加）
と言う形で数式が構築される仕組みになっています。この時の後の数値は演算記号で入力が終わる仕組みになっていますが、この数値の入力後に
■ 数値
■ 演算記号（追加）
■ 数値（追加）
■ 演算記号（追加）
となった時に計算結果がでます。そして、この後に数値を入力すると結果に対してその数値を処理する数式になるので、
■ 数値
■ 演算記号（追加）
■ 数値（追加）
■ 演算記号（追加）
■ 数値（追加）
■ 演算記号（追加）
：
：
のような流れで演算が行われる仕組みになっています。この数値を確定する場合には、
■ 数値
■ 演算記号（追加）
■ 数値（追加）
■ 演算記号（追加）
■ 数値（追加）
■ 演算記号（追加）
：
：
■ 数値（追加）
■ 等号（追加）
のように最後の数値を入力した後に等号のボタンを押すと計算結果を得ることができますが、それと同時に今までの計算の処理を終了することが出来ます。
この構造を見てもらうと、
■ A ＋ B
■ A − B
■ A × B
■ A ÷ B
のような感じで計算が進んでいるので、
【 変数 】＋【 演算記号 】＋【 変数 】
と言う式の構造になっています。この場合だと、同じ演算記号の組み合わせだと問題がないのですが、上記のものを項に置き換えてみると、
■ A ＋ B
■ A − B
■ AB
■ A/B
のように条除算はそれぞれ係数のある変数後と分数になっています。この状態で問題となるのは、
■ A ＋ B × C
■ A ＋ B ÷ C
になります。これは、項で考えると、
■ A ＋ AB
■ A ＋ A/B
になるので、式に置き換えると、
■ A ＋ （B × C）
■ A ＋ （B ÷ C）
になりますが、電卓は最初の数値から演算をする仕組みになっていますから、アルゴリズムをそのまま実行すると、
■ （A ＋ B） × C
■ （A ＋ B） ÷ C
が実行されてしまいます。その為、電卓を使って計算をしても算数がわかっていない場合には計算其の物を間違ってしまうわけです。また、算数がわかっていない場合、 【 そもそもの式の構造がわかっていない 】 ので、どういった構造の変化7日が理解できていないので、 【 間違いの確認すら行えない 】 はずですから、 【 電卓で打ち込んだのだから正しい 】 と言う良く解らない思い込みによって処理の結果を鵜呑みにすることになります。
これが、個人のお遊びの計算だと問題がありませんが、財務だと大問題ですから、責務が発生する状態だとコウイった間違いをする様な状態だと弊害しか発生しないわけです。
そもそも、電卓にはこうした特性があるので電卓検定と言う検定があったり、メーカーが使い方を消化していたりしますが、現在ではYoutubeでメーカーが電卓の使い方の説明動画を出していることもあります。
先程の特性ですが、３つの項を持つ多項式の場合、
■ A ＋ B × C
■ A ＋ B ÷ C
の場合
■ A ＋ （B × C）
■ A ＋ （B ÷ C）
にする必要がありますから、
■ A ＋ B ＝ B ＋ A
と言う形にすればいいので、
■ （B × C） ＋ A
■ （B ÷ C） ＋ A
のように式を変形すると解を導き出すことが出来ます。このように数式を変形することで電卓でも計算を行うことが出来るのですが、この条件だと、
■ A ÷ B ＋ C ÷ D
のような式も
■ （A/B ＋ C） ÷ D
になるので、本来も
■ A/B ＋ C/D
にはなりません。この場合、分数を記憶しておいてそれを呼び出して使用すればいいので、メモリー機能を使用します。まず、
■ A/B
を計算してメモリーします。次に
■ C/D ＋
を入力して、C/Dの結果を出して値を足せる状態にします。この状態で、MRでメモリーの値を代入して
■ C/D ＋ メモリーの値
とすると、A/Bの値が履いているので、
■ C/D ＋ A/B
となり解を導き出すことが出来ます。これが、機材特性に合わせた数式の変形になりますが、電卓の構造を知ると複雑な計算を分けも解らずに行うのは危険であり、算数が理解できていない状態でも電卓があれば大丈夫というのも間違いなのが確認できると思います。
電卓で複雑な数式を扱う際には関数電卓を使用しますが、この場合 【 （） 】 が使用できるので、先程の分数も
■ （C ÷ D） ＋ （A ÷ B）
の様な式にすることが出来ます。なので、
■ （（A ÷ B） ＋ （C ÷ D）） ÷ （ E ＋ F ）
のような式を作って計算をすることも出来ます。そのため、計算をする際には 【 項 】 の単位でまとめて式の構造を加減算の演算記号だけで計算できる構造にまとめることになりますが、この構造が、
■ （（sin(A) ÷ B） ＋ （cos(C) ÷ D）） ÷ （ E × tan(F) ）
となっても構造的には変わりませんから、計算をする際には 【 項 】 の単位でまとめるという中学校１年生の数学のはじめの辺りにでてくる内容を基準に式の状態をまとめることになります。
小学校だと 【 項 】 や 【 符号 】 はでてこないので、こうした構造物は、
■ 足し算
・ 増えるという状態変化
■ 引き算
・ 減るという状態変化
■ 掛け算
・ ０に対して同じ数を指定した数だけ足す
■ 割り算
・ 元の数字から指定した数を連続して引いていき、
引けなくなるまで処理をこない、その引いた回数
を求める処理
・ 元の数値を指定した数で分けた時の個数
と考えることが出来ます。この条件では、掛け算と割り算はループ処理なので、一度の処理だけで完結する足し算や引き算とは構造が異なるので、これは先に計算しておく必要があります。なので、プログラミング言語で使用するforやwhileのように【 ブロック 】で分けて式の中で独立させておくと計算間違いをしなくなります。例えば、
１ ＋ ２ × ３ ÷ ４
の場合、割り算を逆数にすればいいので、
１ ＋ ２ × ３ × 1/４
になります。そうすると、一番最後の４は分母であり、３までの計算は分子であることがわかります。では、この状態で式をまとめると
１ ＋ （２ × ３） × 1/４
になるので、7/4ということになります。コレと同様に
１ ＋ ２ × ３ ÷ ４ × ５ − ３
の場合だと、
■ 分子 ： １ ＋ ２ × ３
■ 分母 ： ４ × ５ − ３
なので、
（１ ＋ （２ × ３）） ÷ （（４ × ５） − ３）
のような形になります。
ちなみに、プログラミング言語やOSに実装されている電卓アプリについては、演算子の優先順位が指定されているので四則演算で破綻することはありません。
このように、ハードウェアには特性があるのでそれに準じた仕様をしないとおかしな結果になるわけですが、電卓に見られるように構造物には処理を行うためのアルゴリズムが実装されているのでそれに準じた処理しか出来ません。
その為、 【 機械の特性 】 以外のことは基本的には出来ないので、汎用性のないものの場合だと出来ることの上限が決まっていますし、適正な使用方法だと実装機能で用意されている手順や仕様に準じた事以外は出来ないようになっています。電卓の演算処理とそれに合わせた使用法がコレに該当しますが、どの機材を使う場合でも仕様が存在するので、そこから逸脱したような未実装な機能を使うことは出来ません。
基本的に簡素な機材はアップデートが出来ないので、実装された処理以上のことやそれ以外の使用法は基本的には出来ないのですが、ハードウェアの設計をする場合だと目的の処理を実装してそれを満たすアルゴリズムの実装をすることになりますが、操作が発生する場合にはその操作が行いやすくするためのUIを作ることになります。
ハードウェアと機能
今回は電卓の仕様について触れましたが、電卓の構造は初期の製品だと
■ ７セグメントディスプレイ
■ タクトスイッチ
で構成されたUIで、発行の制御で文字を扱うような仕組みになっています。この構造はマインクラフトで電卓を作る場合でも使用されていますが、これがデバイスの中に用意されているI/Oになります。ちなみに、電卓の祖先は計算しか出来ない時代のコンピューターですからそれが多機能になって小型化したものが後の電卓になります。
この電卓も始点を少し変えると、
■ ７セグメントディスプレイ
■ タクトスイッチ
を持つハードウェアなので、処理系統をマイコンに変えるとコードで表示などをコントロールしてゲームを作ることも出来ます。
（T）フロントエンドとゲームの設計
マイコンを使う場合には表示機材に7セグメントのLEDを使用する娘tも出来ますが、桁数を持ったものだと表示をするのに数字だけでなくアルファベットも使用できます。
この機能は電卓ではなくコンピューターで使用されていたものになりますが、こうしたデバイスで何かを作ろうと思うと、表示機材の性能を基準に造れるものを模索することになります。
この条件で考えると表示しやすいのは、 【 数字 】 になりますから、ゲームを考える場合、数字をつかたものを扱うと電卓の７セグでも動くことになります。
こうした 【 条件 】 を設けると、 【 範囲指定 】 が出来るので、作るものの絞り込みが出来るわけですが、数値を使ったゲームでだとアナログではトランプを使ったカードゲームがものすごい数ほど存在していますから、この中で容量的に大丈夫なものを作れば実装できることになります。
このような 【 電卓 】 でのゲーム機能ですが、昔はそういった製品もあったようで、 【 ゲームを実装した電卓 】 も存在したようです。
コレと同じ様な構造のものを作ろうともうと 【 マイコン 】 を用意してアプリを実装すればそれと同じことができそうですが、マイコンの利点としては、
【 GPIO経由で外部データを読み込むことが出来る 】
ことですから、外部のROMにプログラムを記録しておいて、それをGPIO経由で読み出して使用することで別のアプリケーションを実行できるようにすることが出来ます。
フラッシュメモリーの範囲内で動くものだといろいろなことが出来るのですが、そうした場合にも表示の変化を7セグメントの複数の桁の浸かるLEDで行って、判定部分をマイコンで行い、操作部をトグルスイッチで行えば、ゲームを実装することも出来ます。
この際に表示部分のコントロールなどが必要になるのですが、どういった表示でゲームプレイをするのかを可が得ることになります。この時に行う作業が画面のレイアウトになりますが、この場合だと、実装された桁数の範囲内でゲームを実行するためにはどうすればいいのか？を考えることになります。
まず、プレイ中の表示も必要になりますが、コレとは別に、勝敗の判定やゲーム中の処理の流れも実装する必要がりますから、実装するゲームではどういった状態でそれを作るのかを考えることになります。
こうした処理は 【 デバイスの制御 】 と 【 内部処理 】 が生じるので、OSの実装されたPC上でアプリケーションを作るのとは少し勝手が違ってきますが、デバイス側でOSのない環境下でハードウェアで何かをする場合だとそういった構造を考える必要があります。
このように、マイコン制御になると、表示機材がPCとは異なる状態になる場合もあるので、それに準じた表示の制御を考えることになります。
この考え方ですが、ワンボードマイコンのようにデバイスが揃った環境で何かを作る場合も同様で、表示を行うものをどういった使い方をするのかで、作れるものが変わってきます。
マイコンを購入してPCで作業押してみるというのは少しハードルが高い（のですが、現在だと学校教育でそういったものにひれる機会もあると思いますが...。）のですが、Make Codeでは、micro:bitなどのマイコンのコードをブロックを使った状態で制作し、そのコードをシミュレーター上で実行できるようになっているので、実際にデバッグを行いながら、コードを書いてマイコンを扱うことが出来るようになっています。
micro:bitではドットマトリックスディスプレイが用意されているので文字を作ることも出来ますが、スプライトを用意して接触判定なども扱えるので、発行した場所をスプライトとして使用してゲームを作ることも出来ます。
この場合も、グラフィックが使えるわけではないので仕組みを考えてドットだけでどういった作りにするのか？を考えなくてはなりませんが、コレを行うと、二次元配列の座標制御で処理を実装する時のゲームの考え方の基礎部分を学ぶことが出来ます。
micro:bitはMakecodeで使用できるのですが、Atom D510でも使用できたので、性能が低いPCでもネットに接続できれば使用できます。実際に
のようにHTOPを見ると負荷が振り切れているのでAtomD510では結構無理がある状態になっています。この状態で
のようにボタンの操作で動くものを作ってみたのですが、Scratchと同様にイベントハンドラは独立したブロックになっているので、
のように個別のボタンで反応するようなコードを実装することも出来ます。また、そのままだとすぐに消えるのでディレイを入れることで表示を継続する様な仕組みにしています。
ちなみに、このドットマトリックスティディスプレイの表示をアスキーアートに変更した処理の方法にしたものがコンソールアプリで、コレを画像にしたものがタイル制御を行っているラスターグラフィックを使った２Dのゲームになります。
ハードウェアには仕様がありますから、その仕様の中で何が出来るのか？を最初に知ることで、できることとできないことのイメージができるようになりますが、制作をする場合だと、ハードウェアを壊さないようにする必要がありますが、実際にコードで処理をした際に何が出来て何が出来ないのかを確認しながらハードウェアの能力を理科していくことになります。そうすると、
■ 快適に動作するもの
■ 動くけれど重すぎて使えないもの
が出てくるので、この中の現実的に使えそうで、処理が増えても問題がないものをピックアップしておいてそれを使って動くものを作っていくことになります。
もしくは、重たすぎるものも処理方法を変えると軽量化が出来る場合もあるので、ハードウェアの制御が出来るようになったら、そういった最適化の方法を模索することになります。
そうすると、 【 そのハードウェアで出来ることの総数が増える 】 ので作るものの選択肢が増えるわけですが、マイコン制御の場合、周辺機器のようにスタンドアローンで完結するような少電力なハードウェアの生成を考えることになる（のですが、現在のマイコンは無線プロトコルや拡張して10MbpsのLANなどに繋がるので少ないパケットのデータ送信による処理の実行だとマイコンレベルでも行えるようになっています。）のですが、こうしたハードウェアもモジュールの組み合わせやデバイスの組み合っわせでいろいろなものを作れるようになっています。
この時の考え方もコンピューターと同じなので、CPUとメモリーとI/Oでのデータのやり取りが発生するわけですが、人が使用する際にはI/Oとのやり取りが必要になるので、フロントエンド部分でどんな物を用意してUIはどうするのかなどを考えていくことになります。アプリケーションの部分はUXの部分になりますが、実装したプログラムをそのハードウェアで使用した際にどういった体験を出来るのかも考えることになります。この時の選択肢が実装するデバイスで変わってきますが、何をどういった形で処理をするのかも含めて設計を行うことになります。