Robloxオビーの作り方｜初心者向け手順

Roblox Studioで最初のオビーを作るなら、テンプレート任せではなくBaseplateから組むほうが、足場の置き方からチェックポイントの仕組みまで一気に腹落ちします。
この記事は、PCでRoblox Studioを使い始めた初心者に向けて、コード不要で作る範囲と、最小限のLuauで足す範囲を分けながら、完成までを短い手順で案内します。

初心者ワークショップでは、ブロックのAnchored忘れやSpawnLocationの設定違いで手が止まりがちなので、その2つを先に潰せる順序に組み替えています。
親子講座で実際に使っているCP_01Goalの命名ルールや、「落ちたあとにどこへ戻る？」「今の足場、止まって見える？」というテストの声かけも入れてあるので、読み終えた時点ですぐに遊べるオビーの形まで持っていけます。

Robloxオビーとは？初心者が最初の作品に選びやすい理由

RobloxのオビーはObstacle Courseの略で、走る、ジャンプする、落ちないというシンプルなルールで進む障害物コース系のジャンルです。
少ないPartでも成立し、足場の間隔やチェックポイントの置き方だけで遊びの手触りを調整できるので、最初の1本として形にしやすい題材でもあります。
2025年Q4のRobloxはDAUが1.44億、四半期の滞在時間が35億時間に達しており、その中で短時間でも遊びの核が伝わるオビーを作れるようになると、ゲーム制作の基本を密度高く学べます。

検索まわりでは「obby」だけでなく「parkour」「escape」も近い文脈で使われますが、制作の出発点として押さえたいのは名前より構造です。
スタート地点から3つほど障害を並べ、その先にゴールを置く俯瞰図を思い浮かべると、必要な要素が一気に整理できます。
講座でもこの形から始めることが多く、最初の1本は見た目の派手さより、きちんと完走できることを狙ったほうが達成感が残ります。

なぜ“難しすぎない設計”が重要か

初心者向けのオビーでまず効くのは、失敗の原因が読める設計です。
足場の幅が狭すぎる、ジャンプ間隔が急に広がる、落下後に最初からやり直しになる、といった要素が重なると、プレイヤーは「自分のミスで落ちたのか」「コース側の調整不足なのか」を判断しにくくなります。
オビーはルールが単純なぶん、不満も手応えもそのまま設計に返ってきます。

そのため、最初の作品ではシンプル足場を中心に組み、危険ブロックを少し足すくらいがちょうどいい配分です。
動く足場まで入れると、見た目は一気にオビーらしくなりますが、スクリプトの同期やタイミング調整まで考える必要が出てきます。
最初の段階では、足場の距離、着地点の見え方、落ちたときの復帰位置といった基本のほうが、完成度に直結します。

チェックポイントが学びと遊びをつなぐ点にも注目したいところです。
オビーでは途中再開できるだけで、プレイヤーは同じ難所を繰り返し試せます。
制作者側から見ると、どこで失敗が多いかを把握しやすくなり、難所の置き方を見直す材料にもなります。
親子講座でも、難しい障害を増やすより先にチェックポイントを1つ入れるだけで、コース全体の印象が安定します。

完成を最優先にする進め方

最初の作品で得るべきものは、豪華な見た目より「公開できる1本を最後まで作った感覚」です。
Baseplateに足場を置き、色を変え、1か所だけ失敗ポイントを作り、途中にチェックポイントを入れてゴールを置く。
この流れだけでも、Roblox Studioの基本操作とオビー設計の芯がひと通り入ります。

実際、講座で見ていても、途中で装飾や演出に広げた人より、完走できる短いコースを先に閉じた人のほうが、次の1本で伸びます。
理由は明快で、完成まで行った人は「どこで手が止まるか」を自分で把握できるからです。
見た目はまだ素朴でも、スタートからゴールまで破綻なくつながったコースには、未完成の大作より強い学習価値があります。

進め方としては、コース全長を伸ばすより、短い区間を磨くほうが効果的です。
たとえば、スタート、ジャンプ足場、危険ブロック、チェックポイント、ゴールの順に置けば、プレイヤーの移動、失敗、再挑戦、達成までの流れが一通り確認できます。
ここまでできれば、2本目でLuauを使ったチェックポイントや動く足場に広げる意味も見えてきます。
最初から全部入りを狙うより、1本目は「見た目より完走できること」に軸を置くほうが、作る側の手応えもはっきり残ります。

作り始める前の準備：Roblox Studioのインストールと画面の見方

オビー作りはコース設計に入る前の準備でつまずくと、その先の理解まで止まりやすくなります。
Roblox Studioは無料で使える制作ツールですが、制作はPC専用で、WindowsまたはmacOSの環境とRobloxアカウントでのログインが前提です。
この段階で画面のどこに何があるかをつかんでおくと、後の「Partを置く」「設定を変える」「テストプレイする」が一気につながります。

環境要件とログイン

Roblox Studioは無料で利用できますが、制作そのものはPC専用です。
対応環境はWindowsとmacOSで、スマホやタブレットではゲームを遊べても、Studioを使った制作はできません。
ここを最初に整理しておくと、「アプリは入れたのに作れない」という混乱を避けられます。

導入の流れはシンプルで、まずブラウザでRobloxにログインし、そのままRoblox Studioを入手して初回起動します。
アカウントに入っていない状態だと保存や公開の流れもつながらないので、インストールとログインはセットで考えるのが自然です。
制作講座でも、この段階でブラウザ側のログインが切れているだけで作業が止まる場面をよく見ます。

表示言語を日本語に寄せたい場合は、起動後にFileからStudio Settingsを開き、Languageを変更します。
メニュー構成の理解を優先するなら英語のままでも進められますが、初回はラベルの意味を追いやすい言語にそろえておくと、次の操作で迷いにくくなります。

新規作成ではテンプレートがいくつか並びますが、本記事ではClassic Baseplateから始めます。
画面や案内によってはBaseplate表記になっていることもありますが、選ぶ基準は同じで、何もない平らな土台から組み始めるタイプです。
最初からオビー用の構成が入ったテンプレートより、足場を自分で置く意味が見えやすく、後でチェックポイントや危険ブロックを足すときも構造を追いやすくなります。

UIの基本

起動直後のRoblox Studioは、見えているパネルの数で理解の速さが変わります。
授業では最初の15分でExplorerとPropertiesが見えているかだけを必ず確認しますが、それだけで詰まる人が目に見えて減ります。
オブジェクトの一覧と設定欄が開いていないと、「何を選んだのか」「どこを変えたのか」が切れてしまうからです。

まず上部にはHomeタブがあります。
ここが基本操作の起点で、Partの追加や各種ツールへの入口がまとまっています。
オビー制作では最初に触る頻度が高いタブなので、画面上端にあることだけ先に覚えておくと流れが止まりません。

画面の横にはExplorer、その近くにPropertiesを表示します。
Explorerはゲーム内の要素が階層で並ぶ場所で、Workspaceや配置したPart、スポーン地点などを一覧で確認できます。
Propertiesは、選択したオブジェクトの色、サイズ、名前、Anchoredなどの設定を変える場所です。
たとえば足場をクリックしても何が起きているのかわからないときは、だいたいこの2つのどちらかが閉じています。

テストプレイ関連は上部の再生系ボタンにまとまっており、Playで実行し、必要に応じて停止します。
案内によってはRunやStopも並んで見えるので、上のバーにある再生・停止の並びをひとかたまりで覚えると把握しやすくなります。
オビーは置いた足場をその場で走って確認する回数が多いので、ここを探さず押せるだけで作業のテンポが変わります。

文字だけだと位置関係をつかみにくいので、最初は次のような見取り図で把握すると頭に入りやすくなります。

スクリーンショットを入れるなら、1枚はStudio起動直後の全体画面、もう1枚はExplorerとPropertiesを有効にした状態が向いています。
初学者は「ボタンの名前」より「どのあたりに出るか」で覚えることが多いので、この2枚があるだけで操作説明の伝わり方が安定します。

作り方の選択肢の比較

オビーを作り始める方法はひとつではありません。
Classic Baseplateから自分で積み上げる方法、最初からオビー寄りのテンプレートを使う方法、Obby Creatorの中で手軽に組む方法があります。
どれも入口として成立しますが、Studioの基礎を身につけたいなら、本記事との相性が最もよいのはBaseplate開始です。

Baseplate開始の強みは、足場を1つ置くところから全部見えることです。
ExplorerでPartが増え、Propertiesでサイズや色が変わり、Playで走って確認するという制作の基本動線が、そのまま身につきます。
オビー系テンプレートは出発が速い反面、最初から入っている要素を「なぜそうなっているか」まで追わずに進みやすく、2本目で自作しようとしたときに手が止まりやすくなります。

一方で、Obby Creatorのようにゲーム内で組める方法は、発想を形にする速さでは魅力があります。
PCがなくても触れる入口としては成立しますが、Studioでの本格的な制作、公開後の拡張、後からLuauを足す流れまで考えると、土台になるのはやはりRoblox Studioです。
このあと進めるオビー制作も、その土台に乗せていく形が最も無理なくつながります。

手順1：Baseplateから足場とスタート地点を作る

Roblox Studioで最初の一歩として効果が高いのは、広いBaseplateの上に自分の足場を1つ置き、そこへプレイヤーが立てる状態まで持っていくことです。
ここで触るのはPartAnchoredCanCollideSpawnLocationという、オビー制作の土台になる要素ばかりなので、この段階で手と目を慣らしておくと次の工程がつながりやすくなります。
新規作成はホーム画面のNewからClassic BaseplateまたはBaseplateを選び、作業を始めたら早い段階でFileからSave to Fileでローカル保存しておくと、試行錯誤の途中でも戻れる状態を保てます。

Partを置く

まずはBaseplateを開いた直後の空間に、立てる足場を1つ追加します。
上部のHomeタブからPartを開き、Blockを選ぶと四角いパーツが配置されます。
これがオビーの最小単位になるので、最初は凝った形よりも、四角い足場を置いてサイズを整えるところに集中すると流れがつかめます。

配置したPartはMoveで位置を動かし、Scaleで横幅や厚みを調整します。
プレイヤーがスタートしてすぐ落ちないように、最初の1枚は余裕のある広さにしておくと、その後のテストで「操作が悪いのか、配置が悪いのか」が切り分けやすくなります。
オビーは細い足場ほどそれらしく見えますが、最初の成功体験を作る段階では、まず立てる、走れる、落ちないの3点がそろうことを優先したほうが前に進めます。

見た目もこの時点で軽く整えておくと、後で安全地帯と危険地帯を作るときに混乱しません。
たとえば安全な足場は緑、危険ブロックは赤というように、PropertiesのColorやMaterialを変えて役割を分けておくと、画面を見ただけで意味が通る配置になります。
最初から全部を装飾する必要はありませんが、色のルールだけ決めておくと、作っている本人も構造を見失いにくくなります。

Anchored/CanCollideの初歩設定

足場を置いたら、すぐにPropertiesでAnchoredをオンにします（詳細は公式ドキュメント: developer.roblox.com/en-us/api-reference/property/BasePart/Anchored を参照）。
ここを入れ忘れると、テストプレイを始めた瞬間に足場が落ちていきます。
これは初心者の定番トラブルで、実際のワークショップでも最初に止まりやすい場所です。
だからこそ、Partを置いたら形を整える前でもAnchoredをオンにする、という順番を早い段階で固定してしまうと手戻りが減ります。

SpawnLocationの基本配置

足場ができたら、プレイヤーの開始地点になるSpawnLocationを置きます。
右側のExplorerでWorkspaceを右クリックし、Insert ObjectからSpawnLocationを追加します。
追加後はMoveで足場の上に運び、プレイヤーが安全に立てる位置へ合わせます。
スタート地点が床からずれていたり、端に寄りすぎていたりすると、ゲーム開始直後の印象が崩れるので、ここは見た目以上に効いてきます。

SpawnLocationを置くと、テストプレイで毎回その場所から始められるようになります。
オビー制作では配置して走る、止めて動かす、また走るという往復が多いので、開始位置が整っているだけで検証のテンポが安定します。
最初の1本では、凝ったリスポーン処理やチェックポイントよりも、まず「ここから始まる」が明確なことに価値があります。

この段階でもスクリーンショットがあると伝わりやすいのは、SpawnLocationを足場の中央付近に置いた配置例です。
床の上に対してどう重ねるのかが見えるだけで、初めて触る人でも再現しやすくなります。
ここまでできれば、広いBaseplateの上にただ立っていた状態から、自分で作ったスタート地点に立てる状態へ進めたことになります。
これは小さく見えて、オビー制作では最初の達成感になりやすい一歩です。

手順2：オビーらしい障害物を3種類作る

ここでは、プレイヤーが「ただ歩くだけ」から「オビーを遊んでいる」と感じられる最低限の障害をそろえます。
最初の段階では難しさを盛りすぎず、序盤は簡単に抜けられる配置に寄せると、テスト時に失敗の原因を見つけやすくなります。
安全な足場は緑から青、危険な床や落下を誘う場所は赤やオレンジ、ネオン系で統一しておくと、説明がなくても役割が伝わります。

ジャンプ足場

最初に置きたいのは、オビーの基本になるジャンプ足場です。
Partを複数コピーして前方へ並べ、1枚ずつ少しだけ間を空けると、それだけで最小限のコースになります。
序盤は簡単にする前提で、ジャンプ間隔は最初に4〜6スタッドを目安に置き、広すぎたら1〜2スタッド刻みで詰める、狭すぎたら少し広げるという調整が安定します。

この工程では、足場の幅もいっしょに見ておくと失敗が減ります。
スマホ操作では空中で向きを修正しにくい場面が多いので、最初の数枚は幅広めにして、慣れてきたところから少しずつ細くしたほうが離脱が目立って減ります。
いきなり細い足場を連続させるより、「飛べた」という感覚を先に作ったほうが、その先まで試してもらいやすくなります。

色もこの段階でそろえておくと、後の追加がぶれません。
たとえば通常の足場を緑や青にしておけば、プレイヤーはそこを安全地帯だと自然に認識できます。
スクリーンショットを入れるなら、ジャンプ足場、細い通路、危険床の3種類を横並びにした構図にすると、コース全体の設計意図が一目で伝わります。

細い通路

次に、まっすぐ歩くだけでも緊張感が出る細い通路を作ります。
1本の長いPartを置いて横幅を絞るだけで成立するので、作業量のわりにオビーらしさが出やすい障害です。
ジャンプの直後に置くと操作の切り替えが生まれ、コースに単調さが残りません。

序盤は優しさを残す

ただし、ここでも序盤向けのやさしさは残したほうが流れが整います。
通路を細くするにしても、最初は少し余裕を持たせて、後ろの区間で徐々に難しくする構成のほうが、どこで落ちたのかを把握しやすくなります。

見た目の工夫としては、通路そのものを青系、両脇の落下側を赤やオレンジ寄りの色にしておくと、進む場所と危ない場所の境目がはっきりします。
コースを自分でテストするときも、色が役割ごとに分かれているだけで、配置ミスなのか操作難度なのかを切り分けやすくなります。

落下エリア or 危険色の床

オビーらしさを一段引き上げるのが、触れると危険だと見てわかる床です。
作り方は大きく2つで、足場の下にそのまま落ちる空間を作るか、赤やオレンジ、ネオン系の床を置いて「ここは危険」と示す形にします。
最初の1本では、落下エリアだけでも十分に成立しますし、見た目の説得力を出したいなら危険色の床を組み合わせると伝わりやすくなります。

危険ブロックを置く場合は、安全な足場との色分けを徹底するのがポイントです。
安全が緑から青、危険が赤やオレンジというルールを崩さなければ、初見でも進行方向を読み取りやすくなります。
ネオン系の色は視認性が高いので、危険床の存在をはっきり見せたい場面と相性が良いです。

落下エリアを使う構成には、失敗が直感的に伝わる強みがあります。
危険床を踏んだ時の処理は次の工程で加えられますが、この段階ではまず「安全地帯から外れるとミスになる」という感覚が伝われば十分です。
ジャンプ足場、細い通路、危険エリアの3種類が並ぶだけで、コースとしての輪郭がはっきり見えてきます。

手順3：チェックポイントを実装する

チェックポイントを入れると、失敗しても直前の到達地点から再開できるようになり、コース全体の手触りが一気に整います。
最初の1本ではSpawnLocationをそのまま活用する方法が最も扱いやすく、仕組みを理解したあとにLuauで RespawnLocation を書き換える形へ広げる流れが素直です。
名称と色の対応だけ最初に決めておくと、あとで数が増えても崩れません。

コードなし：Teams＋SpawnLocation方式

初心者向けでまず試したいのは、TeamsとSpawnLocationだけで作る方式です。
考え方はシンプルで、各チェックポイントに対応するチームを1つずつ用意し、その地点に触れたプレイヤーのチームを切り替えることで、次回の復活位置をその場所へ移します。
スクリプトを書かずに進められるので、オビーの最初の作品と相性が良い構成です。

作業はExplorerから始めます。
空いている場所を右クリックしてInsert Objectを開き、Teamsを追加します。
その下にチェックポイントの数だけTeamを作成し、それぞれに別の TeamColor を割り当てます。
たとえば序盤、中間、ゴール前で分けるなら、3つのTeamを用意して色を個別に持たせる形です。

次に、各チェックポイントとして置いたSpawnLocationの設定を対応させます。
チェックポイント用のSpawnLocationは Neutral=false にし、AllowTeamChangeOnTouch=true にします。
そのうえで TeamColor を、対応するTeamと同じ色にそろえます。
スタート地点だけは Neutral=true にして全員が最初に出現できるようにしておくと組みやすく、スタート専用のTeamを切って管理する方法でも構いません。

ここで地味に効くのが命名ルールです。
SpawnLocation.Nameを CP_01、CP_02、Goal のようにそろえておくと、あとでExplorerを見たときに順番が崩れません。
コースが長くなるほど「どのスポーンがどの区間か」を目で追う時間が増えるので、名前を先に整えておくほうが後工程で詰まりません。
制作ではこの命名が曖昧なまま複数置き、似た色のSpawnLocationを見失って修正に時間を取られる場面がよくあります。

この方式で最も起きやすい誤作動は、TeamColor の不一致です。
Team側とSpawnLocation側で色が1つでもずれると、触れたはずの地点ではなく別の場所に復活することがあります。
見た目では同じ系統の色に見えても内部では別色になっていることがあるので、チェックポイントを1つ追加するたびに、対応するTeamとSpawnLocationの色をその場で見比べる運用にすると安定します。
スクリーンショットを入れるなら、Teamsサービス配下のTeam一覧と、SpawnLocationの Neutral、AllowTeamChangeOnTouch、TeamColor が見えている状態が伝わりやすい構図です。

Luau最小サンプル：RespawnLocationを書き換える

コードで仕組みを理解したいなら、プレイヤーがチェックポイントに触れたとき player.RespawnLocation をそのSpawnLocationへ切り替える方法があります。
こちらは応用の幅が広く、特定条件で有効化するチェックポイントや、順番どおりにしか解放されない再開地点にもつなげられます。

まずこれを書いてみてください。チェックポイントに使うSpawnLocationの子にScriptを入れると動かせます。

local checkpoint = script.Parent

checkpoint.Touched:Connect(function(hit)
	local character = hit.Parent
	if not character then
		return
	end

	local humanoid = character:FindFirstChild("Humanoid")
	if not humanoid then
		return
	end

	local player = game.Players:GetPlayerFromCharacter(character)
	if not player then
		return
	end

	player.RespawnLocation = checkpoint
end)

役割は短く区切ると追いやすくなります。
local checkpoint = script.Parent は、このスクリプトが入っているSpawnLocation自体を参照しています。
checkpoint.Touched は、その地点に何かが触れた瞬間を受け取ります。
hit.Parent で触れたパーツの持ち主をたどり、Humanoid があるかを見てプレイヤーのキャラクターかどうかを判定しています。
game.Players:GetPlayerFromCharacter(character) で該当プレイヤーを取り出し、player.RespawnLocation = checkpoint で次回の復活位置を今触れたSpawnLocationに更新します。

注意: 複数の SpawnLocation が存在する環境や Team／Neutral の設定によっては、必ずしも期待どおりの復活位置が選ばれないことがあります。実運用では Team の割当や AllowTeamChangeOnTouch の併用などを確認してください（参考: developer.roblox.com/en-us/api-reference/property/Player/RespawnLocation）。

手順4：危険ブロックを追加する

危険ブロックは、オビーに「失敗したらやり直す」という緊張感を入れるための基本要素です。
見た目で危険だと伝わり、触れた瞬間に倒れる仕組みまでつながると、ジャンプの意味が一気に出てきます。
最初の1本ではダメージを少しずつ減らすより、触れたらその場で Health を 0 にする形のほうが挙動を読み取りやすく、復活の流れも短いのでコース全体のテンポが崩れません。

見た目（危険色/素材）の設定ポイント

まずHomeからPartのBlockを追加し、足場の近くやジャンプの着地点の下に置きます。
これを溶岩のような危険ブロックに見せるには、Color を赤やオレンジ系に変え、Material を Neon にすると意図が伝わりやすくなります。
普通の灰色ブロックのままだと、ただの床なのか触れてはいけない場所なのかが見分けにくく、失敗したときに納得感が薄れます。

名前もそのまま Part にせず、Lava のように役割が分かるものへ変えておくと、Explorerで探す手間が減ります。
危険ブロックが増えてくると、どれが装飾用でどれが当たり判定付きなのかを名前で判別できるだけで管理が楽になります。
前の手順でチェックポイント名をそろえたのと同じで、ここでも命名が後から効いてきます。

設定では CanTouch がオンになっているかを見ておきます。
Touched イベントは、ほかのパーツがそのブロックに接触したときに発火する仕組みなので、ここがオフだとスクリプトを書いても反応しません。
なお、危険ブロックは床としてぶつからせたい場面もあれば、見た目だけの炎として使いたい場面もありますが、触れた判定そのものは CanTouch が前提になります。

スクリーンショットを入れるなら、赤い Neon のブロックがコース内に置かれている画面と、そのブロックの子にScriptが入っているExplorerを並べると伝わりやすくなります。
見た目と仕組みの位置関係が一枚で分かる構図だと、初心者が迷うポイントをまとめて潰せます。

Luau：Touchedで倒す最小スクリプト

危険ブロックの中にScriptを1つ入れ、まずは最小構成で動かします。
ここでは、ブロックに触れた相手がプレイヤーのキャラクターだったら、その Humanoid の Health を 0 にして即リトライさせます。

local danger = script.Parent

danger.Touched:Connect(function(hit)
	local character = hit.Parent
	if not character then
		return
	end

	local humanoid = character:FindFirstChild("Humanoid")
	if not humanoid then
		return
	end

	humanoid.Health = 0
end)

local danger = script.Parent は、このスクリプトが入っている危険ブロック自身を参照しています。
danger.Touched:Connect(function(hit) は、そのブロックに何かが触れた瞬間に処理を始める行です。
hit には触れたパーツが入るので、hit.Parent でその持ち主をたどり、キャラクターモデルかどうかを見ています。

humanoid.Health = 0 が、倒れる処理の本体です。
体力を少し減らす形にもできますが、最初のオビーでは即座に 0 にしたほうが「ここは触ってはいけない場所だ」とプレイヤーに伝わります。
制作でもこの形から始めることが多く、慣れてきた段階で持続ダメージ床や一定間隔で減るトラップへ広げる流れのほうが、挙動の違いを理解しやすくなります。

この最小例だけでも、オビーらしい失敗と再挑戦のループは十分に作れます。
足場、チェックポイント、危険ブロックがそろうと、ただ並んだパーツが「越えていくコース」に変わります。

Playテストで確認するポイント

公開前のPlayテストは、見た目が整っていても実際には進行不能になる初歩ミスを見つける工程です。
オビーは1つの設定漏れで印象が崩れやすく、足場が落ちる、床をすり抜ける、復活地点が戻らないといった不具合は、作り手が思う以上に離脱につながります。
短い確認を何回か回すだけでも完成度は大きく変わり、調整では“3回連続で成功するか”を基準に置くと、友だちに触ってもらったときの詰まり方が目に見えて減ります。

操作チェック

テストの流れはシンプルで、HomeからPlay（▶）を押して実行し、気になる点が出たらStop（□）で止めて直し、またPlayで入り直します。
この切り替えを長く引っ張らず、1回の再生ごとに「足場は固定されているか」「当たり判定はあるか」「チェックポイントから復活するか」だけを短く見る進め方だと、原因を見失いません。

まず見たいのは、置いた足場が勝手に落ちないことです。
Anchored を入れ忘れると、スタート直後は問題なさそうに見えても、プレイヤーが触れた瞬間に床がずれたり傾いたりしてコース全体が崩れます。
最初の1本では演出よりも安定優先で、通常の足場はその場に留まり続ける状態を基準にしておくと、異常の切り分けが早くなります。

次に、キャラが床や着地点をすり抜けないかを見ます。
ここは CanCollide がオフになっていないかが要点で、見た目としてはブロックが置かれていても、衝突判定がなければジャンプ成功のつもりで落下します。
透明な床や装飾パーツを混ぜたときほど起きやすいミスなので、失敗した場所では見た目ではなくプロパティを見直すほうが早道です。

チェックポイントの確認では、到達したあとにわざと落ちて、そこから復活地点が更新されているかまでを1セットで見ます。
触れた直後は通過できても、実際の復活が前の地点に戻ることがあり、これを見逃すと公開後にストレスの強いコースになります。
Play中の画面を残すなら、チェックポイント到達から落下、復活までの流れが1枚か数枚でつながる場面がいちばん伝わります。

難易度の微調整

操作が成立していても、ジャンプ距離が極端だと遊び心地は急に荒れます。
届くか届かないかが毎回ぶれる間隔は、上達の余地より運の要素が強くなりやすく、初心者向けの最初のオビーでは避けたい配置です。
調整するときは、自分で3回連続で通れるかをまず見て、その後で少し慣れていない人にも触ってもらうと、狙いすぎた幅や間隔がすぐ表に出ます。

このとき意識したいのが、PCだけでなくスマホ操作でも成立するかという視点です。
スマホでは移動と視点操作が同時に忙しくなるので、細い足場の連続や、空中で細かくカメラを回さないと次が見えない配置は、それだけで難度が跳ね上がります。
幅は少し広めに取り、進行方向が自然に見えるレイアウトに寄せると、入力の忙しさが減ってコースの意図が伝わります。

特に序盤は、難しさをジャンプ精度だけに寄せないほうが流れが良くなります。
着地点が見える、次の足場の位置が読める、失敗しても直前のチェックポイントからすぐ再開できる、この3つが揃うだけで挑戦のテンポが保てます。
友だちテストでも、3回続けて越えられる配置を基準にしたコースは途中離脱が減り、逆に一度しか通れない絶妙すぎる間隔は、作り手には気持ちよくても遊ぶ側には理不尽に映りがちです。

難易度を上げたい場面でも、幅を削るより順番の設計で調整したほうが破綻しにくいです。
たとえば、広い足場から少しだけ長いジャンプへ進み、その後に危険ブロックを絡める流れなら、プレイヤーは何を求められているかを理解しながら進めます。
公開前のテストでは、失敗回数そのものより「失敗理由が自分で説明できるか」を見ると、単なる高難度と分かりにくさを切り分けやすくなります。

よくある失敗と直し方

オビー制作で止まりやすいのは、難しいコードよりも、1つのプロパティ違いや配置場所の取り違えです。
見た目が合っていても Anchored、CanCollide、Neutral などの基本設定がずれると、足場が崩れたり復活地点が乱れたりして、一気に進行不能に見えます。
詰まったときは一度に全部を疑うのではなく、パーツの設定とスクリプトの置き場所を順番に切り分けると、原因は短時間で見つかります。

プロパティ再点検の手順

まず疑いたいのは、足場そのものの設定です。
スタート地点や通常の足場が落ちるときは、対象のパーツを選択してPropertiesを開き、Anchored が true になっているかを見ます。
授業でも最初はここで止まることが多く、固定したつもりでチェックが外れたままだと、ジャンプ調整以前にコースが崩れます。

床の上に乗れず、そのまますり抜けるときは CanCollide を見直します。
足場を選択してPropertiesで CanCollide を true に戻すだけで直るケースが多く、透明パーツや装飾を複製したあとにそのまま流用したときに起こりがちです。
見た目が床でも、当たり判定が切れていれば着地判定は成立しません。

チェックポイントまわりでは、SpawnLocationが複数スタート地点のように振る舞う問題が定番です。
ここは Neutral の混在で崩れることが多く、スタート用だけを Neutral=true にして、Team方式で進めるチェックポイントは Neutral=false にそろえると整理できます。
授業ではこの混在がいちばん多く、「最初の1個だけ Neutral=true」を口頭で繰り返すだけで、その場で復活地点が整うことが多くあります。

Teamsを使っているのにチェックポイントが効かないときは、Explorer にTeamsが存在するかを見て、その中の TeamColor と各SpawnLocationの TeamColor が一致しているかを確認します。
Neutral=false にしても色がずれていれば、想定した地点で復活しません。
色の設定は似た名前でも別物として扱われるので、片方だけ変えた状態で止まっていないかを見るのが近道です。

見た目のちらつきも、初心者が不具合と勘違いしやすいポイントです。
床と床がぴったり同じ位置に重なっていると、表示が細かく揺れて見えることがあります。
これはパーツの重なりによるもので、少しだけ高さをずらすか、不要な片方を削除すると収まります。
複製を繰り返してコースを伸ばした場面で出やすく、障害物を足したつもりが同じ場所に2枚置かれていた、という形がよくあります。

編集できなくなったように見える場面では、実際にはテストモードが続いていることがあります。
Playのまま操作していると、パーツを触っているつもりでも編集状態には戻っていません。
Homeの Stop を押して通常の編集画面に戻すと、そのまま修正できます。

スクリプト配置ミスの見抜き方

スクリプトが動かないときは、文法より先に「どこに置いたか」と「何の種類か」を見ます。
たとえばパーツに触れたら反応する処理なのに、置いてあるのが LocalScript だったり、サーバー側で動かしたい処理をプレイヤー側の場所に入れていたりすると、見た目には何も起きません。
危険ブロックやチェックポイント補助のような処理では、Script を使ってPartの中かServerScriptServiceに置く形が基準になります。

逆に LocalScript は、プレイヤー関連の場所で動く前提です。
これをServerScriptServiceに入れても実行されないので、「コードは書いたのに反応しない」という状態になります。
初心者のトラブルではここが最頻出で、アイコンだけ見て Script だと思い込んでいた、というケースも珍しくありません。
まずスクリプトの名前より種類を見て、その次に親オブジェクトを確認すると切り分けが進みます。

ServerScriptServiceに置いたコードが反応しない場合は、その処理がワークスペース内のどのパーツを対象にしているかも確認したいところです。
対象のPartの中に入れるべき処理をサービス側に移して、参照先を書き換えていないまま止まっていることがあります。
反対に、ステージ全体をまとめて管理する処理なのに各パーツへ分散して置くと、どこが本体かわからなくなります。
小さなオビーでは、触れた反応ならPartの中、全体管理ならServerScriptServiceという分け方にしておくと、後から見返したときにも崩れません。

チェックポイントでチーム管理を使っている場合は、スクリプトだけでなくTeamsの有無も動作条件に入ります。
コード側でチーム色を切り替えるつもりでも、ExplorerにTeamsがなければ成立しませんし、作成済みでも TeamColor とSpawnLocation側の色が一致していなければ期待した復活地点に結びつきません。
スクリプトの中身だけを追いかけるより、関連するオブジェクトがそろっているかを見るほうが、原因に早く届きます。

完成後の次のステップ：公開前の調整と発展案

ここまで形になったら、公開前に見るべき点は多くありません。
難易度、見た目、復活の流れを短く整えるだけで、遊んだときの印象は一段上がります。
とくにテーマを1個決めるだけでコース全体のまとまりが出るので、ただブロックを並べた段階から「遊びたくなるオビー」へ変わっていきます。

公開前チェックリスト

公開前は、まず自分で最初からゴールまで通しで確認します。
基準はシンプルで、同じルートを連続成功3回できるかです。
1回だけクリアできた場所は、偶然で抜けただけのことがあり、公開後に詰まりやすいポイントとして残ります。
ジャンプ間隔、回転障害、危険ブロックの置き方は、この3回テストで精度が見えてきます。

見た目では、テーマ色をそろえるだけで完成度が上がります。
空中庭園なら白と緑、溶岩洞窟なら黒と赤のように、色と素材の方向を決めておくとコース全体が散らかりません。
制作の現場でも、テーマを1個に絞ったオビーは世界観が締まり、同じ障害でも体感の面白さが伸びます。
装飾もそのテーマに合わせて追加すると効果的で、柱、看板、ゴール周辺の発光パーツなどを少し入れるだけで「作りかけ感」が抜けます。

動作面では、やられたあとにどこへ戻るかを必ず確かめます。
復活地点が意図したチェックポイントにつながっているか、スタート地点へ巻き戻されていないかを見るだけで十分です。
前述の通り、復活動線が崩れると遊びのテンポが止まります。
名前もこの段階で整理しておくと後から迷いません。
チェックポイントなら CP_01、CP_02 のように連番にしておくと、修正箇所をすぐ見つけられます。

自分の確認が終わったら、友だちや家族に一度だけ遊んでもらう流れが有効です。
見てほしいのは上手さではなく、どこで止まるかです。
最初に落ちる場所、進み方が伝わらない場所、見た目で安全そうに見える危険ブロックは、作り手ほど気づきにくい部分です。
その反応を見たうえで、難しい箇所を1回だけ調整して公開に進むと、手直しが終わらなくなる状態を防げます。

発展案アイデア

完成した最初のオビーは、少し要素を足すだけで次の作品につながります。
追加候補として扱いやすいのは、動く足場、消える床、簡単なUI、音まわりの4つです。
どれもコースの骨組みを壊さずに入れられるので、学習の延長線上で試せます。

動く足場は、止まった足場だけのコースに変化を作る定番です。
TweenServiceで位置をなめらかに動かす形なら、往復する床や横移動する足場を作れます。
物理ベースで試したいならConstraintを使う方法もあり、吊り橋のような揺れや回転ギミックへ広げられます。
最初の1本では固定足場が土台ですが、2本目ではこの動きが入るだけでオビーらしさが一気に増します。

消える床も相性のいい発展案です。
床に触れたあと、少し待ってから落ちる仕組みにすると、止まるか進むかの判断が生まれます。
実装は Transparency で見た目を消し、タイマーと当たり判定の切り替えを組み合わせる形が基本になります。
透明になっても当たり判定は別管理なので、見た目と挙動を分けて設計できるのが。

簡単なUIを付けると、遊んでいる側の目標が見えます。
たとえば画面にタイマーを出してクリア時間を表示したり、到達したチェックポイント数を表示したりするだけでも、プレイの意味が伝わります。
最初は凝った画面でなくて構いません。
数字と短いラベルだけのUIでも、遊び手には十分な導線になります。

BGMやSEの追加も効果が大きい要素です。
スタート時に軽いBGMを流し、チェックポイント通過やゴール到達に短いSEを入れるだけで、達成感がはっきりします。
見た目を整えて、動く足場やタイマーを足し、音で反応を返す。
この流れがそろうと、最初の作品でも「次も遊んでみたい」と感じるコースになります。

Publishの基本導線

公開の入口はシンプルで、Roblox Studioの File → Publish to Roblox から進めます。
ここで作品の公開ページにつながる設定へ入れるので、仕上げの段階ではまずこの導線だけ覚えておけば十分です。
詳しい公開設定や公開範囲の詰め方は別の機会に深掘りできますが、最初の1本では「テストで整える」「1回だけ他人に遊んでもらう」「Publishへ進む」の流れが止まらないことのほうが価値があります。

公開前には、完成図のスクリーンショットも1枚残しておきたいところです。
おすすめはゴール到達の瞬間で、プレイヤーが最後の足場を越えた場面やゴール装飾が見える角度が向いています。
サムネイル候補として使えるだけでなく、次の作品を作るときに「どこまで仕上げると公開できるか」の基準にもなります。

作ったら出す、出したら1つ伸ばす、この循環が上達を早めます。
最初のオビーは完璧に仕上げるより、テーマ付け、装飾、復活の流れ、そして小さな発展案まで触れて公開ラインを越えることに意味があります。
そこで得た感覚が、次の動く足場やタイマー付きコースづくりへそのままつながります。