ゲーム開発チームにおけるスクリプトライターの位置





こんにちは、私の名前はマリア・コチャコバです。私はアロッズ・チームのSkyforgeプロジェクトの脚本家です。 この記事では、ゲームライターとしての2年間の仕事をまとめています。 これらはすべて、コンピューターゲームライターの生活の厳しい現実であり、私たちが日々直面していることです。 カテゴリー形式は、コンテンツの重要性によって決まります。



コンピューターゲームスクリプト


ゲームの物語(物語)の部分は、設定、プロット、テキストで構成されています。



設定とは、ゲームの世界、その法律と現実です。 設定の例:ポスト黙示録、ファンタジー、中世、サイバーパンク...



プロットは、ストーリーに追加される一連のイベントです。 同じプロットが異なる設定で通知されることがあります。 設定がプロットに劇的に影響することが起こります。 プロットの必要性は、ゲームのジャンルに最も依存します。 一部のジャンルでは、プロットはオプションです。



スクリプトは、プロットが表現される形式です。 通常、スクリプトは、何が起こっているのかを説明するシーンとダイアログのリストのように見えます。 スクリプト作成者は、スクリプトの形でストーリーを伝える方法を知っている人々です。これは、チームの他のメンバーがすぐに使用できるドキュメントです。



テキストは、設定とゲームのプロットの最適な表示形式ではありません。 テキストは補助ツールです。 テキストは読めない場合があることに注意してください。 プロット付きでテキストなしのゲームがあります(Machinarium)。 しかし、テキストはファンやUSP (Deponia、Bard's Tale)のソースとすることもできます。







コンピュータゲームのプロットは必要ではありませんが、関与、雰囲気を追加します。



プロットはゲームのUSPであるか、干渉する可能性があります。



プロットは、ゲームの成功の構成要素の1つにすぎません。 過大評価しないでください。 しかし、プロットの力を過小評価する価値はありません。



ゲームにプロットが必要かどうか、必要な場合はどの程度かについての決定は、開発を開始する前に慎重に行う必要があります。 ストーリーを伝えたい場合は、プロットが必要です。 サービスを提供したい場合は、おそらくプロットを必要としないか、ゲームの他のコンポーネントと同じサービスになります。



一部のプレイヤーはゲーム内のプロットを見たいと思っていますが、ほとんどの場合、プレイヤーは読みたくないでしょう。



物語の問題は、次の2つの場合に発生します。



  1. 脚本家が作品の詳細を理解していないとき-経験不足または誤ったインストールのため。 この場合、脚本家は不適切に行動します。彼はフィードバックを知覚し、生のシナリオ決定を下し、怠け者であり、プロジェクトでの彼の役割を過大評価します。
  2. チームが脚本家の詳細を理解していないとき-偏見と協力の否定的な経験のため。 この場合、チームは不適切なフィードバックを与え、スクリプトに不当に介入し、不可能を要求し、スクリプトライターの役割を過小評価します。


問題を扱うことは、啓発の魔法の力-脚本家とチームの両方に従います。



コンピューター脚本家








脚本家は職業です。 他の職業と同様に、特別な理論的知識と実践的スキルのセットがあります。



コンピューターゲームの脚本家の知識とスキルは、特別なトレーニングと実務経験の結果として得られます。



プロフェッショナリズムには、一連のスキルだけでなく、プロとしての倫理、つまり自分の仕事、プロジェクト、同僚、仕事の状況に対する態度も含まれます。



プロジェクトでは、脚本家が物語とゲームのビジョンと物語の対応に責任を負います。



私たちが思い出すように、物語は設定、プロット、テキストです。



ビジョン(ビジョン)-これはプロジェクトの本質、上部のバー、出口でゲームがどうあるべきかのアイデアです。 脚本家はビジョンの作成者ではありませんが、関節炎と一緒にその管理者です。 理想的には、脚本家とアーティストが一緒になって、ビジョンとゲームの一貫性を監視します。



脚本家の仕事の責任はプロジェクトに依存します。 プロジェクトが大きくなると、責任が狭くなり、専門性が高まります。 小さなチームでは、1人で脚本家、文学編集者、さらにはコミュニティマネージャーの両方の機能(ニュースの執筆、発表、コンテストの実施など)を実行できます。 それはすべてあなたの能力に依存します。 それには何の問題もありません。 追加の作業スキルで死亡した人はまだいません。



コンピューターゲームの脚本家の職業倫理には、仕事に対する態度、プロジェクトに対する態度、チームに対する態度が含まれます。



働く態度


フィードバック知覚



脚本家にとっての大きな危険は、彼自身の一部としての彼の作品の認識です。 作品を評価するとき、脚本家はそれを人として評価しているようです。 したがって、脚本家は感情的にも否定的にも反応しすぎて、すぐに死者の防衛に向かわなければなりません。



  1. フィードバックが適切(丁寧)で、味覚的ではないが、プロジェクトの現実を反映している場合(必要なメカニックがなく、利用可能な手段でプロットコースを表示することなどが不可能な場合)、脚本家は、フィードバックを作業ステートメントの明確化として認識し、必要な修正を冷静に行う必要があります。
  2. フィードバックが評価者の好みと意見のみを反映している場合、評価者は仕事とは関係がないため、森に行くことができます(顧客のフィードバックでない限り、これはフィードバックではなく、仕事の声明の仕様です。段落1を参照)。
  3. フィードバックが不適切(不適切)である場合、顧客のフィードバックであっても、森を通り抜けることができます。 お互いを尊重しましょう。




脚本家がアイデアに恋をする厄介な瞬間



  1. コンピュータゲームの脚本家の作品にはお気に入りのアイデアはありませんし、ありません。最適なシナリオソリューションがあります。 ソリューションがニーズを満たすのをやめた場合、より最適なソリューションに置き換えられます。 ヘミングウェイが言ったように:「あなたはあなたの愛する人を殺す必要があります。」 言い換えれば、「このように見える」という立場は、脚本家に関するものではありません。 私たちのすべては明確です。 実用的な数学。
  2. アイデアに恋をするリスクは常にあります。 あなたはただ誰も安全ではないことを理解し、これを愛の失敗として扱う必要があります-あなたは少し泣いて合格します。 新しいものが表示されます。
  3. 残念ながら、お気に入りのアイデアは脚本家だけでなく、顧客からも寄せられています。 顧客のアイデアを殺すには、正当な理由が必要です。 アイデアが時代遅れになり、もはや最適ではなくなったことをしっかりと確信する必要があります。 可能な限り慎重かつ正確に殺害にアプローチしてください。 春に出現しないように、プロジェクトの現実にある矢印を回し、死体を慎重に隠すことを強くお勧めします。




シナリオソリューション







スクリプトソリューションは、スクリプト作成者のメインツールです。 これは、プロジェクトの要件を最適に満たす最適なプロット移動です。



  1. 必要に応じて「正当化」するために、シナリオの決定を慎重に確認する必要があります。そのような決定が行われた理由と理由、プロジェクトに与えるもの、削除する問題。
  2. 適切なシナリオを見つけることは、沼地を通る道です。 一歩間違えると、ストーリー全体が崩れます。 どのような場合でも、重みのないシナリオ決定、いわゆるsoげた決定を行うことはできません。 怠azineは、プロットとあなたの評判の両方で沼にinれます。
  3. 沼地(プロジェクト)についての情報が多いほど、より成功する方法(ソリューション)を見つけることができます。 したがって、他のチームメンバーに指示(情報とフィードバック)を求めることを強くお勧めします。 多くの目標は1つよりも優れています。 しかし、選択は脚本家です。 これが彼の責任範囲です。
  4. スクリプト作成者にスクリプト化されたソリューションが与えられるコストをチームが理解することは素晴らしいことです(もちろん、スクリーンライターではなく真のスクリーンライターである場合)。 物語の沼地には、脚本家の白髪が散らばっています。 彼らの仕事を尊重してください!




耳鼻咽喉科での警戒



脚本家の肩には、ゲームのすべての要素(場合によっては純粋にゲームプレイの慣習でさえ)を論理的で首尾一貫した伝承に結び付けることがあります。



  1. 楽しみのためだけでなく、「エルディシア」のスキルを高めるためにも、たくさんの本を読んで、見て、プレイすることをお勧めします。 最も興味深い設定の決定のいくつかは、100万人の信じられないほどクールなSF作家によってすでに行われています。 私たちのタスクは、新しいものを作成することに加えて、先祖の知識を失い、それらを次の世代に引き継ぐことではありません。 また、脚本家が世界文化の同様のシナリオソリューションの例を2つ挙げることができれば、上司に自分のアイデアを「販売」することが容易になります。 「Startrekで機能した場合、それは私たちのために機能します。」
  2. プロットの作成が沼地を通る経路である場合、設定の作成はLernean hydraとの戦いです。 世界秩序に関するそれぞれの答えられた質問で、2つの新しいものが出てきます。 ロジックをトレーニングし、エンティティを生成しない-首の切り株を結び付けます。




プロジェクトに対する態度


プロジェクトを知る必要があります。



  1. 使用して再利用するコンテンツを知る必要があります。 脚本家は、アーティスト、モデラー、アニメーターの作業時間の合計が脚本家の時間よりも高いことを覚えておくことが推奨されます。 シナリオの決定を下すと、脚本家はプロジェクトのお金を使います。 これが創造性の代価です。
  2. ゲームプレイとメカニズムを知る必要があります。 スクリプトとゲームプレイは、リングの異なる端からゲームに参加してお互いを殺そうとするのではなく、プロジェクトをより面白くするために一緒に行動するのは正しいことです。 ストーリーはテキストでしか語れないという誤解です。 プロットゲームプレイは、コンピューターゲームに最適な脚本家です。
  3. 品質管理。 スクリプト作成者は、スクリプトを「作成」するだけでなく、開発のすべての段階でスクリプトがゲームにどのように適合するかを監視します。 すべてが計画通りですか? プレイヤーは、プロットに従ってゲームで何が起こっているかを理解していますか? 脚本家以外の誰も、彼が意図したプロットがゲームでどのように見えるべきかを知りません。 自分が飼育したスクリプト化されたバグをキャッチできるのはスクリプト作成者だけです。他のチームメンバーは、これらがバグであることを単に知らないかもしれません。




結論:脚本家、ゲームをプレイしてください!







チームの態度


チームは知る必要があり、可能であれば愛する必要があります。



  1. 脚本家がチームメンバーの長所を想像し、それを使用してプロットを作成できると便利です。 アーティストがポニーを最もよく描く場合、ポニーをプロットに合わせるのが理にかなっているかもしれません。 レベル設計者がラビリンスを最適化する場合、プロットにラビリンスを追加することは理にかなっています。 そうしないと、脚本家は彼の助けなしに迷路がプロットに追加される危険性があります。 麻酔なしで足を顔に縫い付けるようなものです。
  2. 脚本家がチームメンバーの弱点を想像するのは良いことです。 おそらく、レベル設計者がラビリンスに慣れていない場合、プロットにラビリンスを導入する価値はありません。 他の誰かの無能さを克服できなかった運命は、あなたの好きなアイデアの葬式に涙を流しています。
  3. スクリプトライター、チームに適応します。 これらは、あなたがゲームにプロットを紹介する人たちです。 私たちは同時に行動する必要があり、プロジェクトを犠牲にして自分自身を主張しないでください。
  4. まだ微妙な点があります。 チームメンバーが脚本家よりも優れたソリューションを提供する場合があります。 ここで、脚本家は、プライドについて続けて、何であれ彼の決定の採用を求めるべきではありません。 脚本家の仕事は、たとえそれが彼のソリューションでなくても、最適なソリューションを選択することです。 これはプロフェッショナリズムと呼ばれます。




脚本家は、エゴではなくプロジェクトが主なものであることを忘れないでください。 他の人々とのコラボレーションには、興味深いアイデアと独自の解決策の深hiddenが隠されています。

脚本家は、チームを彼の創造的な天才の車輪に棒を入れる敵として知覚すべきではありません。 ライブコミュニケーションはフィードバックであるだけでなく、意思決定の正しさを納得させる機会でもあります。



プロットに対するチームの関心と、その作成に参加したいという願望(常に適切とは限りませんが)を評価する価値があります。 彼らが気にしない場合-あなたは心配する必要があります。



おわりに


私には夢があります-コンピューターゲームの脚本家のプロのコミュニティです。







専門家コミュニティは、主に経験と訓練の移転、そして次に、お互いのコミュニケーションと支援です。 成功する解決策を見つけ、参考文献を見つけ、さまざまな宇宙の知識をサポートするのに役立ちます。 1人ですべてのテーマコンテンツを把握することはできませんが、興味深い高品質のゲームシナリオを作成できる基本的な基盤を一緒に作成できます。



この記事の目的は、ゲームでのプロットの必要性について議論することではありません。 脚本家の特定の作業問題についてお話したいと思います。



たとえば、私の実践では、実際にビジョンに追い込まずにプロジェクトを始めたときに苦痛なケースがありました。 ターゲットオーディエンス、リファレンスゲーム、および出先で何が起こるべきかについて何も知らないので、私はスクリプトを非常に喜んでスパイしました。 その結果、ゲームは中央アジアの期待に正確に従って沈みました(古典的な間違い!)。 設定は焦点を失い、ぼやけて曖昧になり、時には強すぎ、時には幼稚になりました。 チームを費やして恥ずかしい時間をin辱した。 プロジェクトへの損害は、モバイルドックに没頭し、当局と慎重に議論することで回避できます。



経験を共有しましょう。 ディスカッションへようこそ。脚本家としてのあなたの作品、または脚本家との仕事についてのコメントで教えてください。 ネガティブな経験は、前任者の間違いを繰り返さないようにするのに役立ち、ポジティブな経験は従うべき例を提供します。



これは、予定されている2つのスクリプトに関する記事の最初の記事です。 次回は、Skyforgeスクリプトでの作業方法を説明します(もちろん、ネタバレなし)。



その他の資料は Skyforge 開発者のWebサイトVkontakteコミュニティで見ることができます。



All Articles