できることが非常に限られ、テキスト表示とごく簡単なパラメータ操作程度しかできないもの。
プランナーやスクリプターのスキルがプログラマー側にあまり信用されていないとき、よく見かける状況です。

あるいは、セリフ表示用、キャラクター操作用、パラメータ操作用などとファイルを分け、それぞれ別フォーマットで記述したものを、セリフ番号などで同期させるなど、面倒な手順が多いケースもあります。
この場合、理論的にはそれなりに機能はありますが、実際には少し複雑な演出をしようとする対処できない事態に陥ります。

どちらにせよ、これではスクリプトとしてあまり役に立たず、最終的にプログラマーの作業負担が増えるだけです。

自由度はかなり高いが、難易度もとても高いもの。
要求される表現が複雑な３Ｄアクションゲームなどでよくあるシステムです。
Ｃ言語なみに関数や変数の定義・宣言やメモリー確保まで行えてしまうシステムを見ることもあります。

しかし、これでは注意しないとシステム全体を破壊してしまう可能性があり、実際にはプログラマーでなければ扱いきれません。

ある程度は自由度を維持しつつ、どこまで簡素化するか、という点に注意が必要です。

システム立案者がスクリプトの記述を楽にしようと意図するあまり、記述の微妙なバラつきを許してしまうようなシステムになっている場合があります。
また、プログラマー主導の３Ｄアクションゲームなどでは、ゲーム本体に匹敵する、まるでパッケージソフトのような高機能スクリプトツールを開発していることもあります。

どちらの場合も後々、ちょっとした修正が出たときにも一括置換をしにくくなり、非常に不効率です。
高機能すぎず、またきちんとルール化されたシステムにしておけば、フットワーク軽く修正に対応できるようになります。

個々の機能のまとめ方に無駄が多いもの。
単一の機能、たとえば画面をフェードアウトさせる表現のためだけに何行もの命令を記述するシステムを見かけます。

この例の場合、色違いやスピード違いなどフェードアウトにもいろいろあり、自由度を高めるために、命令文を別々にパーツ分けしておこうと意図してのことですが、後々の保守性が悪く、全体的な変更をするときなど担当者が悲鳴を上げることになります。

このような場合は、命令はひとつにまとめ、パラメータ指定でバリエーション対応する方がスマートです。