【学習】実行モデルで見る WinForms と Unity（つまずきの正体）
C# を学び、WinForms でアプリを作れるようになったあとに Unity に入ると、多くの人がこう感じます。
「文法は分かるのに、何をしているのか分からない」
これは能力の問題ではありません。「実行モデル（時間の扱い）」が違うことが原因です。
この記事で扱うこと: WinForms と Unity の違いを、比喩や雑な比較ではなく 時間の流れ方 に統一して説明します。全体の動機づけやカリキュラムの意味は 第1回：カリキュラムの流れと、WinForms と Unity はつながっている を参照してください。
目次
前提：両者は同じ仕組みを持っている
まず重要な事実です。
- オブジェクト
- イベント
- 状態
どちらもこの3つで構成されています。できることはほぼ同じです。
決定的な違い：実行モデル（時間の流れ）
ここだけが本質です。
WinForms
- 基本は待機している
- イベントが来たときだけ処理が動く
イメージ
止まっている
↓
クリック
↓
動く
↓
また止まるUnity
- 常に時間が進み続けている
- 毎フレーム処理が呼ばれる
イメージ
ずっと動いている
↓
その中で処理を書く一行でまとめる
| 環境 | 実行モデル |
|---|---|
| WinForms | イベント時だけ動く（待機が基本） |
| Unity | 常に動き続ける（ゲームループ） |
この違いがすべてにつながる
なぜ Update があるのか
void Update()
{
}毎フレーム呼ばれる前提だからです。
なぜ Time.deltaTime があるのか
フレームごとに経過時間が違うからです。
なぜ Rigidbody があるのか
物理が継続して計算されているからです。
WinForms でも同じことはできる
重要な補足です。
timer.Tick += Update;WinForms でもタイマーでゲームに近い処理は作れます。
違いは次のとおりです。
| 環境 | 違い |
|---|---|
| WinForms | 必要ならループ（タイマー等）を自分で足す |
| Unity | ループが最初から存在する |
設計が変わる理由
この違いにより、設計も変わります。
WinForms
入力 → 処理 → 出力
（単発処理が中心になりやすい）Unity
状態を持つ
↓
毎フレーム更新
↓
状態が変化し続けるUnity では 「処理を一度だけ書く」 より 「状態を持ち、継続的に更新する」 という考え方が中心になりやすいです。
よくある混乱
| 状況 | 起きがちなこと |
|---|---|
Update を書かない | 毎フレーム動かす処理が動かない |
| 状態を持たない | 挙動を表現しにくい |
| 1回で終わる処理だけ書く | 常時進行の世界に合わせにくい |
正しい入り方（例）
① まず動かす
void Update()
{
transform.position += new Vector3(1f * Time.deltaTime, 0, 0);
}② 状態を持つ
float speed = 3f;③ その状態を使って継続的に変化させる
今の皆さんへのメッセージ
皆さんはすでに次のようなものを使えます。
- 変数
- 条件分岐
- ループ
- クラス
書く力はあります。
Unity で新しく学ぶことの核心
時間が流れ続ける前提で書くこと
これが、WinForms 中心の感覚から最もズレる点です。
最後に
Unity が難しいのは、新しい言語だからではありません。止まっている世界ではなく 動き続ける世界 を扱うからです。
WinForms：止まっている中でイベントが起きる
Unity：動き続ける中で状態を変えるこの違いを実行モデルとして理解したとき、Unity の説明の多くが一本につながります。
前の記事
第1回：カリキュラムの流れと、WinForms と Unity はつながっている
関連リンク
訪問数 18 回, 今日の訪問数 18回