ZSliceプロジェクトについて長い間話したいと思っていました。
エディターは約5年間開発され、2つのプロトタイプと完全な書き直しを乗り切りました...
そしてまだ活発に開発中です。
おそらく、エディターが100％なめられて機能するようになるまで、私はこの記事をもう何年も書くために熟成していなかっただろう。 しかし、私の同僚が正しく指摘しているように、これは決して起こりません。 したがって、内部の理想主義者はわずかに息苦しくなり、この記事の執筆に至りました。
過去数年間でゲーム開発は劇的に変化しました。 ゲームコード自体の価値は大幅に低下し、逆にコンテンツの価値は大きくなりました。 現代の世界では、ゲームを書くことは問題ではありません。 問題は、十分な品質のコンテンツを作成することです。
2007年、偶然、私はラリーシミュレーターのリチャードバーンズラリーのファンの会社に参加しました。
約1年の作業で、単純なラリーエンジンを作成しました。 コンテンツから、ノヴォロシースクに1台の車とトラックがありました。
このトラックは約3か月間行われました。
開発が遅すぎるとやがて熱意に影響を与え、おろし金はチーム内に入りました...一般的に、プロジェクトは光を目にすることはありませんでしたが、私が知る限り、そのイデオロギーのインスピレーションはそれを完了する方法を探しています。
ほぼ同時期に、モデラーに3ds MaxまたはBlenderでトラックを作成させることは非人道的であるという理解が得られました。 ツールはそのようなタスクのために研ぎ澄まされておらず、道路の作成に関する簡単なチュートリアルでさえ、かなり複雑で労働集約的なアクションのセットです。
エディターのゆったりとした検索が始まりました。 パブリックドメインには、ランドスケープを作成できる多くの編集者がいますが、その中の舗装道路は完全に存在しないか、非常に欠陥のあるレベルであることが判明しました。
例を挙げましょう。風景は道路の下で、そこから少し離れたところにあります。 そして、道路はデカールの形で上に置かれます。 最新のJust Cause 2でさえこれに罪があります（道路の隣の風景は常に道路の形状に厳密に対応していることに気付くでしょう）。
私はこの状況に満足せず、ランドスケープを編集するツールを作成し始めました。 高さマップの既存の編集者と競合するためではなく（少なくとも
World Machineを使用して競合することはほとんど不可能です）、唯一の問題を解決するために-道路の高速で便利で高品質の舗装。
エディターの最初のバージョンは、アイデアをテストするために設計されたプロトタイプです。
しかし、プロトタイプでも、制限はありますが、かなりまともな風景を作成できました。
これが、エディターの最初のプロトタイプが彼の「死」の直前に見えたものです。
スクリーンショットは、
gamedev.ruの戦略コンテストに参加したゲーム「Storm：Line of Defense」用に作成されたランドスケープを示してい
ます誰かが興味を持っている場合、Storm：Defense Lineに関する情報
1位を獲得したゲームのビデオ。 私はただこのプロジェクトに言及するのを助けることができません。
ビデオを見るとき、ゲームが1人で6か月も経たないうちに作成されたという感覚はありません。 そのようなプロジェクトを失うことは恥ではありませんでした。
しかし、このコンペティションでは、この地域で10位になり、多くのプロジェクトで負けたのは残念です。
プロトタイプにより、ランドスケープ管理プロセスの理解を深めることができました。 たとえば、実装前には目立たなかった明らかな問題が表面化しました。2つのランドスケープブロックのジャンクションは、フィルタリングの影響を大きく受けます。 隣接するブロックのピクセルを複製するだけでなく、境界線は2ピクセルの厚さにする必要があります。そうしないと、線形フィルタリングの結果としてこの線形の迷惑が発生します。
戦略はあまり目立ちませんが、シューティングゲームのランドスケープを作成する場合、これはすでに非常に重要なアーティファクトです。
また、2番目のバージョンを開発する際には、APIを介して外部から最大のアクションにアクセスできるようにする必要があることを考慮しました。 ユーザーが必要とする機能を正確に予測することは不可能です。 しかし、これは必要ありません。 APIへのアクセスを許可すれば十分であり、ユーザー自身が必要なツールを作成します。
そのため、ハードコードのエディター内のすべてのブラシが外部プラグインに移動しました。
残念ながら、これも些細な問題ではありません。
そして、ここでの問題は、ブロックのジャンクションでの通常のフィルタリング操作のために作成された境界にあります。
実際、ジャンクションで1つのポイントを編集すると、最大4ポイントの編集になります（4つのブロックのアングルジョイントの場合）。 同時に、処理プロセスが不必要に複雑にならないように、外部からは1つのポイントを編集するように見えるはずです。
その結果、ツールのAPIは私たちが望むよりも少し複雑になり、速度が遅くなりました。
最初のプロトタイプは、ストリーミングを介してランドスケープで機能しました。 タスクの1つは巨大な領域を処理できるエディターを作成することだったので、そのようなランドスケープを変更できるソリューションを探す必要がありました。 そして、ストリーミングは適切なオプションのように思えました。 ストリーミングは完全に実装されましたが、使用の実践により、これによりいくつかの困難が生じることが示されています。 それは非常に迷惑なことではありませんでした...しかし、現代の現実では、メモリ容量が絶えず増加し、ブラウザでさえ数ギガバイトを食べるのが恥ずかしくないとき、メモリを節約するためにツールを複雑にし、利便性を減らすことは正当化されません。 そのため、新しいバージョンのエディターは64ビットコンパイラーに移行し、ストリーミング機能を失いました。 非常に大きな風景でも、5ギガバイトのメモリに収まります。 そして、それはほとんどのニーズをカバーしています。 さて、100x100 kmの風景を必要とする人の1％は、ワークステーションで数個のRAMを購入する必要があります。 ただし、現時点では32ギガバイトでさえかなり許容できる費用がかかります。
エディターは進化し続けています。 今、新しい経験を考慮して、エディターの第3バージョンへの移行について話します。完全に書き直します。 書き換えの目的は、作業をマテリアルでユニバーサル化し、APIを高速化することです。
現在のバージョンは、現在それを使用しているお客様のLTSのままです。
次のリンクから最新バージョンのエディターをダウンロードできます：
www.dropbox.com/s/j08r1a2z095h9ai/ZSlice_build_2014_04_02.rarこれはベータ版ではなく、内部使用を目的としたバージョンであることに注意してください。 したがって、安定性は理想とはほど遠いものであり、追加機能の一部（植生の配置など）が示されているだけで、完全には実装されていません。
このエディターは非営利目的での使用は無料です。
ブラシとエクスポーターのAPIとソースコードは、リクエストに応じて送信されます。
PSもちろん、ラリーを作るという当初のアイデアは消えませんでした。
実際、エディターの大部分は、お客様およびもちろんSRF Rallyプロジェクトで使用されているため、作成および開発されています。
