実装予定

（始めに）

エンジニアの皆さんこんにちは！Space Engineersで惑星の開発を行っているメインプログラマーのDusan Andrasです。
そう、惑星です……思い返せば惑星はこのゲームをアーリーアクセスで公開したときからずっと要望されていた要素でした。
ずっと熱望されてきた機能ですから、私たちは実装することを約束したのです。
私の同僚のOndrej Petrzilkaが以前このブログで惑星の情報第一弾を公開しましたが、あの時よりも開発がかなり進みました。
惑星の公開までかなり近づいてきていますよ！

ただ、私たちはまだ「惑星を公開しても100％大丈夫だ」という確信を持ててはいません――スクリーンショットの写りは本当に完璧に見えるんですけどね。
というのも惑星は私たちが今まで開発したことのない巨大な要素であるため、公開する前に十分テストする必要があるのです。どうかご理解下さい。
今回はこっそりと惑星とその開発についてお話ししようと思います、いくつかのスクリーンショットも添えてね。

惑星の大きさについて

これは常に『面白さ VS リアリティ』の問題に頭を抱えさせられます。
多くのプレーヤーがリアルサイズの惑星を望んでいる事は分かっているのですが、ごめんなさい！ゲームプレイとプレイ時間、エンジンの関係で惑星の直径は30-50km、衛星の大きさは8-10kmにします。
はい、惑星は0-3個の衛星を持って生成される事になりました。

（画像）
直径50kmの惑星を50km離れた地点から見たところです。
（画像）
直径8kmの衛星を惑星地表から見たところです。地平線の彼方には別の惑星も見えています。
（画像）
惑星は複数ありますよ！

重力について

惑星と衛星は"自然な"重力を持ちます。この重力は船を含めプレーヤーやアイテムなど全てに影響し、強さは惑星の大きさに見合った強さになり、距離により減衰します。

大気について

今のところは2種類の大気を持つ惑星が予定されています。一つは"不適"で、一切の植物や生命は存在しません。もう一つは"有機的"で植物相があります。
有機的な惑星は大気に酸素を持ち、プレーヤーは呼吸したり船に酸素を蓄えさせたりすることができます。
有機的な惑星は地球の様な青い大気を持っていて、不適な惑星は無酸素で大気の色も異なります。

植生（木々や低木、草地など）について

新たに惑星用の"有機的(organic)"マテリアルを追加しました。
これは酸素や植生のある惑星にのみ存在します。
将来的にはこうした場所から有機的な素材を収穫することができます――ただし最初の惑星アップデート時にあるかは分かりません。
植生はMedieval Engineersから借用してきた物になります。宇宙空間から見ることはできませんが、プレーヤーか船が十分に近づけば表示されます。またワールド設定から有効・無効の切り替えが可能です。

（画像）
有機惑星を宇宙から見たところです。
（画像）
日没時の植生です。
（画像）
日中の植生です。

恒星について

昼夜をシミュレーションするため惑星/ワールドの周りを恒星が回るようにしました。
プレーヤーは一日の長さを1分から24時間の範囲で自由に設定することができますし、また公転を無効にして現状と同じ動かない太陽にすることもできます。
恒星の位置によって惑星の見た目が変化するのが分かる画像も用意しました。

（画像x3）

ボクセルによるステーションのサポート

惑星の自然重力のために、私たちはステーションにオプションを増やすことにしました。
これを有効にすると、ステーションはボクセル（惑星や小惑星）に触れている間のみ静的なもの（動かない状態）になります（ブロックの一つが"内部に"建造されている時）
例えば静的なステーションを切断すると、ボクセルに触れていない部分は動的な状態（ラージシップと同様）に戻り、落下したり動いたりするのです。

注意：この記事で紹介された内容は公開時には変更されている可能性がありますのでご注意下さい。

ここまで読んでくれてありがとう！公開した内容を楽しんでくれたなら私たちも嬉しいです。
私たちとしても惑星を早く公開して遊んでもらう事が楽しみでなりません！
Dusan Andras

Space Engineersに関するアンケート
プライスレスなユーザーの意見が欲しいからアンケートに答えてね！（暴訳）

• 性別
• 年齢
• 生息地

• どちらのモードをよく遊んでいますか？ / Which mode do you play the most?

• あなたはどんなタイプのゲーマーですか？ / What type of player are you?
  • 創造することが好き / Creative
  • 競争することが好き / Competitive
  • 冒険することが好き / Explorer
  • コミュニケーションが好き / Social

• どんなものを作るのが好きですか？ / What type of creations do you like to build in the game?
  • 軍艦 / Warships
  • 大型母艦 / Huge motherships
  • 宇宙ステーション / Space Station
  • 小型船 / Small ships
  • 無人機 / Drones
  • ギミック / Mechanisms

• マルチとシングルどちらをよく遊んでいますか？ / Do you play Multiplayer or Single Player the most?
  • シングルプレイヤー / Single player
  • マルチプレイヤー / Multiplayer
  • どちらも同じ程度 / Approximately equal

• マルチプレーヤーで遊ぶとき、大体何人くらいが接続していますか？ / If you play multiplayer, how many people usually join the server?
  • 3人以下
  • 4～7人
  • 7～最大人数

• 公開サーバーと身内サーバーのどちらで遊んでいますか？ / Do you play on public or private servers?
  • 公開サーバー / Public
  • 身内サーバー / Private
  • どちらでも / Both
  • シングルプレイ専門です / None (I prefer single-player)

• どのサーバーを使っていますか？ / What servers do you use?
  • 公式専用サーバー / Official dedicated servers
  • 専用サーバー / Dedicated servers
  • 自分でホストしている / I host games myself
  • サーバーは使っていない / None

• サバイバルモードのリアリズム設定はどのようにしていますか？（大体の場合で） / Which Survival realism setting do you use? (most often)
  • デフォルト / Default – realistic
  • 3x
  • 10x
  • どれでも（サーバーによる/変更してない） / All of them (depends on server, I do not have preference)

• MODを使用していますか？ / Are you using mods in your game?

• いくつMODを使用していますか？ / How many mods do you use? *
  • 使っていない / None
  • 10個未満 / Less than 10
  • 10～69個 / More than 10 but less than 70
  • 70個以上 / More than 70

• どんなMODをよく使用していますか？（複数回答） / What kinds of mods do you usually use? (check all that apply)
  • 設計図 / Blueprints
  • プログラム / Scripts
  • ブロック / Modded blocks
  • キャラクター / Character modifications
  • ミッション / Player created missions
  • 小惑星 / Modded asteroids
  • 効果音など / Modded sounds
  • LCDブロック用のテクスチャ / Modded textures for LCD blocks

• 新しいアップデートを追い続けるのは苦痛ですか？ / Is it difficult for you to keep up with new updates?

• 有用なチュートリアル動画を見たことがありますか？ / Do you find tutorial videos useful?

• どこでSpace Engineersを知りましたか？（複数回答） / How did you find out about Space Engineers (check all that apply)?
  • Steam
  • ゲーム関係のサイトや雑誌で / Game website/magazine
  • 友人や家族からの紹介 / A friend / family member
  • フォーラムで / Internet forum
  • 広告で / Advertisement
  • その他 / Other

• Space Engineersの購入の決め手になったのはなんですか？ / What made you buy Space Engineers (check all that apply)?
  • クリエイティブモード / Creative mode
  • サバイバルモード / Survival mode
  • SFというテーマ / Sci-fi theme
  • マルチプレイ対応だから / Multiplayer
  • 自由にものを作れるから / Creative freedom
  • 友人の勧めで / My friends recommended it

• ゲーム内のサウンド設定はどのようにしていますか？ / What is your in-game sound option?
  • 効果音あり＆ゲーム内BGMあり / In-game Sounds; In-game Music;
  • 効果音あり＆他のBGMを自分でかけている / In-game Sounds; Other/My Music
  • 効果音あり＆BGMなし / In-game Sounds; No Music;
  • 効果音なし＆ゲーム内BGMあり / No sounds; In-game Music;
  • 効果音なし＆他のBGMを自分でかけている / No sounds; Other/My Music;
  • 効果音＆BGM共になし / No sounds; No Music;

Submit（送信）ボタンを押して『Your response has been recorded.（あなたの回答は記録されました）』と表示されれば完了です。

R:Marek Rosa氏
P:Ondrej Petrzilka氏
H:Cestmir Houska氏

• Q:なんでオブジェクトの名前にみんな"My"が付いてるの？
• R:私(Marek Rosa)のプログラミング上の慣習です。サードパーティのライブラリと区別しやすくするためです

• Q:惑星の画像いいね！ところで大気圏突入の時にダメージを受けたり、MEみたいに構造的な強度計算がされたりする？
• H:最初のリリース時にはどちらもないと思います

• Q:野菜を育てて食料にしたり酸素を作ったりする予定はない？宇宙映画だと欠かせない物だからさ
• R:約束することはできませんが、そういうのいいですよね！

• Q:ステーションに人が欲しいんだけどAIとかNPC追加する予定はある？
• R:ありますよ
• H:色々プランはありますがはっきりした物はまだできていないので、今のところそれは内緒

• Q:惑星に動物を追加する予定はある？あとどんな乗り物を予定してる？
• R:鹿がいますよ 乗り物は車をもう少し使いやすくするつもりです

• Q:ネットコードとかのアップデートいつ？
• R:2～3ヶ月以内くらいですね

• Q:惑星は回るかい？
• R:残念ながら、Noです。惑星は静的な物にしないとPCが死にます。
  • Q:Noooo....でも太陽とか背景を回したりはできるよね？
  • P:今その辺りの問題を解決しようとしてるところです
• H:ボクセルシステムの関係で無理なんです。でも惑星の周囲を太陽が回るようにするつもりです

• Q:一番「やってやったぜ！」って思ってる要素って何？
• R:SEだと装甲の変形、MEだと構造的強度計算でしょうか、あと10個くらいありますけどね

• Q:海洋惑星を追加する予定はある？
• P:シンプルな水なら恐らく大丈夫ですが、容量を持った水だと難しいですね

• Q:星雲を追加する予定はある？ 小惑星帯を追加する予定はある？ KSPのwingsみたいに大気をシミュレーションする予定はある？
• P:今のところはNoですね

• Q:惑星の追加っていつ頃くるの？
• P:数週間から数ヶ月以内です

• Q:DirectX 11が使えるようになったらどのくらい早くなる？パーセントで教えて！
• H:DX11を追加するのはグラフィックをよくするためなんですよね
• P:でも最初にやったテストだと10～20％は早くなりそうな感じでした

• Q:マルチでランディングギアが突然爆発したりするけどこういうものの改善は期待していいの？
• P:Yes、私たちは1つのグリッドに"マージ"する方法を考えています。でもかなり大きな変更なので簡単ではないですね

• Q:構造的強度計算(structural integrity)の機能は惑星にも来るの？
• R:Yes...構造的強度計算はSEにもいつか来ますよ

• Q:食料や空腹システムについては何か計画が立ってる？
• R:少しは考えています、私たちの次の開発目標はサバイバル要素の拡充です。"身体(body)"を重視したものになりそうです……

• Q:VRAGEエンジンもUnreal EngineとかUnityみたいに手頃な価格のビジネスモデルを計画してるの？
• R:その通りです。ソースコードを公開した目的の一つはこれなんですよ

• Q:もっとハードコアなサバイバルモードが欲しいんだけどジェットパックを無効にするモードとか考えてる？
• H:ジェットパックを無効にすると穴に落ちた時とか大変ですからね……考えてないです

• Q:はしごは戻ってこないの？
• H:はしごはキャラクターの挙動に大きな影響を与えるので難しいです。復活させるに当たって本当に必要なのかどうかよくよく考え直す必要があるのですが、とりあえず今は他の要素が優先ですね

• Q:公開されてるMODをバニラに取り込むつもりはある？
• R:実はこれやりたいんですよね……
• P:個人的にこれはやりたいです。新しい探索要素の追加とか、でもまずはチームで話し合わないとですね

• Q:ガス惑星を追加する予定はある？
• R:すみませんがありません。普通の地球に似た惑星を予定しています

• Q:強いエンジンを積んだ船じゃないと惑星に墜落したりするのかな？
• R:もちろんです。惑星の重力を振り切るには現実世界と同様かなり強いエンジンが必要ですよ
• H:試しに初期配置の赤い宇宙船で0.5Gの重力を振り切れるか試してみたところ、脱出には12個のラージスラスターが必要でした。重力の井戸から抜け出すのは簡単にはいきませんね

• Q:容量を持った水（流れる水）をSEに追加する予定はある？あるならいつくる？
• P:これ本当にやりたいんですがかなり難しいです。恐らく水は追加されますが海面の高さが固定されたシンプルな球面になると思います。水の追加はまだ計画してはいません。惑星をリリースしてからになります

• Q:高さの固定された水ってのは地下を掘っていってもやっぱり出てくるの？
• P:そうなります。最善の解決方法ではないんですが、海を追加するためにはやむを得ないんです

• Q:惑星やDirectX11への対応はいつ頃になりそう？
• P:惑星は数週間～数ヶ月以内。DX11はそれよりは早いです

• Q:SEは何を最終目標にしてるんだい？大規模MMO？
• P:僕にはちょっと分からないです。というか誰か知ってるのかな？

• Q:惑星はランダムに作成されるの？あと惑星の画像凄く綺麗だけどDX11はいつ来るの？
• R:惑星ジェネレーターはシード値から惑星を生成するのですが、コンフィグもあるので性能の低いPCでも遊べるはずです。DX11は2～3週間以内ですね

• Q:宇宙を場所によって背景画像や小惑星の種類を変えたりするとよりバラエティが増えて面白いと思うんだけどどうだろう？
• H:そういう風にバラエティを増やすことには真剣に取り組んでいます。今はとりあえず他のプレーヤーの作った船が現れるようにして、バラエティを増やしています

• Q:リアルサイズの恒星系や軌道力学的な挙動を追加する予定はある？
• H:今はまだ軌道などについて考えてはいません

• Q:ネットコードはどう変わるの？UIは変わる？
• P:サーバーが全ての権限を持つようになり、クライアント同士の通信は廃止されます。必要な情報以外は送信しなくなるためラグが減ります。UIは変わりません

• Q:専用サーバー（Dedicated Server）にクラッシュ後のリブート機能とか追加できない？ あとLinuxサーバーはまだ？
• P:できますね Linuxサーバーの追加はまだ後のことになると思います（Xbox版の発売前後だと思います）

• Q:またバグ修正に専念する期間とか予定してる？
• P:ネットコードを更新したらやりますよ！

• Q:船やステーションの気密ドッキングシステムとか追加する予定ない？気密ピストンドアとか追加する予定ある？
• P:ないですが面白い案ですね。後者については私はわかりません

• Q:小惑星を与圧することはできる？
• P:計算するのが大変そうですが、可能ではあります

• Q:ケーブルとかゆるい接続方法を追加する予定はある？物を引っ張ったり、位置合わせしないで船を接続して充電したりアイテム輸送したりしたい！
• P:位置の合わないステーション同士（惑星上のとか）を接続する方法について話し合っているところです。多分ケーブル上の物になって電気もアイテムも輸送できるでしょう

• Q:無限のサイズのワールドで惑星の数とか変更できる？
• P:多分できるようになります

• Q:低スペックのPC向けにもっと低い設定を増やすつもりはない？
• P:まずは全てのプレーヤーに影響する物理演算やゲームのロジックを最適化しています。またDX11になれば設定項目が増えます

• Q:スモールシップとラージシップをマージすることはできるようにならないの？
• P:できます。これは技術的にかなり大きな挑戦になるでしょう。しかしやらなくてはならないことです

• Q:ローターやピストンが震えたり勝手に壊れたりするのは改善されない？
• P:かなり難しい問題です。プレーヤー側に制限を設けない限り改善は困難です

• Q:DX12に対応させる予定はある？もちろん直ぐのことではないだろうけれども
• P:まだ予定はしていません（DX11への対応が終わったら考えるつもりです）

• Q:他の形式のゲームも予定してる？
• R:はい、キャンペーンやストーリーをベースにしたゲームも面白いですからね

• Q:なんで毎週アップデートできるの？ゲームの要素って7日間で作れるものなの？
• R:数週間で作れる要素や数ヶ月かかる要素を幾つも平行して開発していて、それぞれ開発した内容を共有できることもあるから毎週できているんです。中には数日で作れる要素もありますけどね
• H:ちなみにアップデートの内容は公開の数日前には完成してます。テストグループに渡してしっかりテストしてから公開してるんですよ。ドナルド・クヌースさんも言ってますからね、『早すぎた最適化は諸悪の根源である』って

• Q:GitHub上で開発状況を公開したりすることはあるの？あるいは内部バージョンのミラーとして使うとか
• P:現在は社内の内部バージョン管理システムを使っていますが、将来的にはGitHubを使う予定です

• Q:工作船に建材とかを自動で補給できるリストやシステムがあれば便利だと思うんだけどどう？
• P:とりあえず協議しないとですね、ModAPIを拡張すれば実装できるようになるのでMODで対応してもらうことになるかもしれません

• Q:チャットで相談に乗る、ってブログ記事に載ってたけどどこでやるの？IRCとか？
• P:フォーラムを使う事を考えていますが、グループチャットもよさそうですね

• Q:惑星やAI、DX11が追加されたら新しいワールドを作らないと適応されない？
• H:惑星は新しいワールド生成方式を使わないといけないので新しいセーブデータが必要です。DX11とAIについては今までのデータでも全く問題ありませんよ

• Q:前回のAmAで建造が完了する前のブロックが建造後のブロックと同じ質量を持つバグを直してくれるって言ってくれたけどどうなったの？
• H:ああ今思い出しました！後で見ておきます！

• Q:サバイバルモードでできることが少ないんだけどどうにかならないの？
• H:できることが少ないのは把握しています。数週間以内に新しいミッションを追加するからそれまで我慢してください！

• Q:ログアウトしてる間に建造物が破壊されるのが怖くてマルチプレーヤーがサツバツとした事になってるんだけどなんとかならない？
• H:悲しい問題ですよね。対処するのが難しい問題でもあります。サーバー側でログアウトした人の船を保護するMODがあるのでそれを使う方法もあります

• Q:空気抵抗を追加する予定はある？あと月や星（恒星？）を追加する予定はある？
• H:現在の最大速度では空気抵抗は微々たる物なので恐らく追加する事はないでしょう。月は追加する事を考え始めたところですが、星（恒星？）についてはまだわかりません

• Q:惑星が追加されたら重くなりそうだけど大丈夫？
• H:惑星は小惑星と同様に近づいた時にだけ描画されるのでパフォーマンスにはあまり影響しません。動的生成は少し特殊ですができる限りそうならないよう頑張っていますよ

• Q:UIをオーバーホールする予定はある？
• H:改良する予定はありますよ！でも優先順位はまだ高くはないのでもう少し後のことになりそうです

• Q:惑星の地表はMEの地表みたいに滑らかになるの？それともSEの小惑星みたいにでこぼこになるの？
• R:惑星の地表は現実の惑星に似たものになりますよ。地形や植物相、動物相などもです

今日はコミュニティとMOD職人の皆様に重要なお知らせがあります。私たちはSpace Engineersのソースコードの100％を公開することを決定しました。
これは私たちのMOD職人とコミュニティに、より自由な環境を提供するというコンセプトの元に行う事です。

これは「オープンソース化」とか「フリーゲーム化」という意味ではありません。
私たちがSpace EngineersとVRAGE*1のソースコードを公開しアクセス可能にしても、Space EngineersやVRAGEは無料にはなりません。

実は似たようなことを以前のブログ記事で言っていました。
当時の私たちはゲームの一部分しか公開するつもりがありませんでしたが、この後に皆の為にはコード全体を公開するのがよいという結論に達しました。
これによりMOD職人は私たちKeen Software Houseと同じ環境で開発することが出来るようになりました（私たちがゲーム開発を止めるという意味ではありませんよ）
この数ヶ月の間私たちはSpace Engineersの開発者を混乱させそうな部分やライブラリを削除していました。
私たちはGitHubにSpace EngineersとVRAGEのコードをプライベートリポジトリとしてアップロードし、数人のMOD職人達にコードを見てもらっていました。
そしてフィードバックを受けて修正し、今日リポジトリを公開できる状態に至ったのです。
これはほんの僅かなゲームスタジオしか実行した試しのない事です。恐らくアーリーアクセス中に行った例は皆無でしょう。
これはいつか誰かがやらなければいけない実験だと思います。そして大きなチャンスなのです。当然リスクも伴いますが、Space Engineersが受け取るメリットはもっと大きいはずです。

メリット

• 全ての要素が変更可能になります。
• 今までよりも高品質なMODを作成する事ができるようになります。
• 私たちは今まで通りゲームのコア部分のアップデート続け、プレーヤーはゲームを改造することでゲームをより面白くすることができます。
• MOD職人がサーバー側のMODを作成しやすくなります。
• MOD職人もゲームのコア部分の開発に貢献(contribute)することができます。
• MOD職人は公式のModAPIインターフェイスを拡張したり、そうした変更を私たちが取り込むこともできます。

リスク

• "同業者達"に私たちのアイディアやアルゴリズムを真似されてしまうかもしれません。
  私たちとしては、ゲームや開発手法が簡単に真似されたとしても、特に行動を起こすつもりはありません。
  私たちには"先駆者でいること"という強みがあると確信しているからです。真似する側ではないのです。

• ハッカーがより簡単にマルチプレイでチートを使う事ができるようになる可能性があります。
  これはその通りだと思います、しかし新しいネットコードではサーバーは権限を持ち、またクライアントから送られてきた情報を検証するようになる予定です。
  もし私たちの実装に欠陥があっても、ソースコードがオープンアクセスの状態にあることで欠陥が見つけやすくなり修正をより素早く行う事ができるはずです。

• 私たちがSpace Engineersをオープンソース化して開発を放棄しようとしているようにみなされるかもしれません。
  これについては明確にNOと言っておきます。前述の通り、今回の決定はMOD作成の自由度を高める事が主目的であり、開発については変更無く今まで通り続けていくものです（毎週のアップデートや以前のブログ記事で紹介したプランの開発なども続いています）
  Space Engineersの販売はとても好調に続いていますし、ゲームを放棄しようとしているのは一部のアレな人だけでしょう！
  私たちは私たちが開発を続けている間にも、プレーヤーがゲームを全体にわたって改造して楽しめるようにしたいと考えているだけです。

最悪の場合を想定してみても、私たちはソースコードを難読化したものに戻すだけです。毎週行っている更新が反映されない分、公開したコードはすぐに古く役に立たないものになるでしょう（？）

使い方について

GitHubにアクセスし、ソースコードをダウンロード＆解凍してください。解凍したファイルをVisual Studio Community Edition（フリーソフト）などで開いて、ソースコードを改変して、ゲームを起動するだけです！
詳しくはビデオガイドを参照してください。

こうして作った新しいタイプのMODはSteamワークショップからは（ModAPIを使ったMODのようには）公開できません。セキュリティ上の問題があるためです。
ただMOD職人達はまた別の方法でMODをプレーヤーと共有してくれるでしょう。サーバー側のMODはサーバー管理者がインストールするものであり、クライアントはインストールする必要はありません。
MOD職人はバニラのModAPIに貢献（contribute）することもできます。これは作りたいMODがModAPIの制限に引っかかってしまった時などに発生するでしょう。
こういった場合は単にそのAPIをサポートするだけでいいでしょう（既存の要素などのために小さなパブリックインターフェイスを作るということです）（？）
私たちはこうした変更はクオリティやセキュリティ上の安全性を検討したうえで、ゲームに統合するつもりです。
総合的な議論や提案、質問はサブフォーラムのソースコードでお願いします。

どんなMODが作れるようになるのかについて

• ワークショップのMODについて
  ワークショップのMODについては一切変更ありません。ただModAPIに関しては拡張するチャンスが生まれましたよ。

• ゲーム自体を作り替えるMOD
  これらのMODはModAPIの制限を無視し、ゲームのあらゆる要素を変更する事ができます。つまりCounter-StrikeやDOTA、DayZ等のようなMODを作成できるということです。
  安全性を確保するためにこれらのMODはSteamワークショップにはアップロードすることはできません。公開するには他の方法でアップロードする必要があります。
  制作者がこうしたMODをSteamで公開したいと考えている時は（独立したゲームとして公開したい場合もSpace EngineersのDLC/Modとして公開したい場合も）私たちがチャットで協力できると思います。連絡先はinfo☆keenswh.comです。

• 別個のゲームを作成する
  上記の通りSpace Engineersをベースにしてスタンドアローンのゲームを作ることも可能です。もしSpace EngineersやVRAGE、アセットを利用した新たなブランドのゲームを作って公開したい時は、遠慮無く私たちに相談してください。

改良に参加したMOD職人から一言

• Digi：これはゲームとModAPIの可能性をこれでもかと広げるものですよ。参加したいと思っていたファンにはたまりません。
  Digi氏はHelmet 3D hudやGravity collectorなど有名なMODをいくつも作ったMOD職人です。ModAPIの拡張に貢献してくれました。
  http://steamcommunity.com/id/hunterdigi/myworkshopfiles/?appid=244850

• Tysis：個人的な話になりますが、私は何かを改造することが大好きです。そんなわけで私はクライアント側で起こった出来事の送受信を制限する変更を行いました。ソースレベルでの改造というのは面白い物でした。
  Tyrsis氏はSEServerExtenderやAutomated inventory sorting、GPS and waypointsなど数々の有名なMODを作成したMOD職人です。
  http://steamcommunity.com/profiles/76561198023356762/myworkshopfiles/?appid=244850

• Malware（訳注：ニックネームです）：個人的にはソースコードにアクセスできる今回の変更は大満足です。ですが全員に公開するとなるといくらか不安もありますね。
  Malware氏はGitHubで精力的に活動しており、既にいくつかのModAPIの要素について貢献してくれています。
  http://steamcommunity.com/id/mal-ware/myworkshopfiles/?appid=244850

100,000ドルの投資について

MOD作成コミュニティのさらなる活性化のため、私たちはSpace EngineersやVRAGEエンジンをベースに新しいゲーム(total conversion mods)を作成したいと思っている人たちに100,000ドル出資する用意があります。
私たちはこの資金を使って何ができるかを色々と考えています。（Epic社がUDKでやっている事のように）無条件で投資するとか、無利子での貸し付け、Kickstarterでのサポートなどです。
私たちの方でPRする事もできます。私たちのソーシャルメディア上でマーケティングやプロモーションをするのです。

何故私たちがこのような事をするのかと言えば、VRAGEがユニークなエンジンであり、他の人々もこれを使ってすばらしい作品を作ることができると確信しているからです。
VRAGEエンジンは完全に動的であり、プレーヤーが周囲の物全てを作ったり破壊したりする、体積と環境の表現（volumetric environments）が可能です。またワールドの大きさに制限が無く、無限のサイズを動的に生成することができます。
VRAGEエンジンについての詳細はこちらのページをご覧ください。

私たちが探しているのは、VRAGEエンジンやSpace Engineersなど私たちの作ったテクノロジーに興味があり、新しいゲームや全体を変更するMODを作りたいと思っている人です。
つまり私たちと同じように、ゲーム開発やサンドボックスゲーム、破壊可能な環境やゲームの楽しさを際限なく追求する事が、病的に好きな人を探しているのです。

利用許諾契約について

EULAについてはこちらを参照してください。
こんな訳の分からない文章読みたくないよ、という方の為に要約も用意しました。これだけは守ってくださいね。

（訳注：EULAや下記の要約についてはかならず自身で原文を確認し自己責任の上で変更などを行ってください。翻訳の正確性については一切保証できません！）

• ソースコード及び画像アセットは断じてフリーソフトではありません。フリーソフト至上主義者の思い描くようなオープンソースでもありませんし、コピーレフトでもパブリックドメインでもありません。
  ソースコードと画像アセットの著作権やライセンスは全てKEEN SWH LTD.に帰属します。私たちは改変や調整、派生作品を作ったりする事を許可しているだけです。なのでルールは守ってくださいね。
• ソースコードや全体改変MOD及び派生作品はSpace EngineersのMODとして公開することを目的とした場合にのみ配信することができます。
  この制限を無視することや、単体で動作する作品を作り公開すること、私たちの作成したコードをあなたのプロジェクトに流用することは許可されません。
• つまり、私たちのソースコードを使ってMODを開発したいと思っている人は、正規のSteam版Space Engineersを購入している必要があります。
  Space Engineers以外のアプリケーションに私たちのソースコードを使用することは許可されません。またSteamと連携している部分のコードを削除することも許可されません。
• オリジナルの画像アセット（テクスチャ、モデル、フォントなど）は、あなたのMODに必要不可欠な場合
  （例えば宇宙飛行士のテクスチャに口ひげを描き足してSpace EngineersのMODとしてのみ公開するつもりである時など）を除いて配信することは許可されません。
• ソースファイルについてあなたに許可されているのは、他の開発者と（正当な理由があるときにクレジットされている人と）と共有すること、ダウンロードしローカルな環境でのみコンパイルすること、
  ローカルな環境で改変すること、GitHub上でフォーク・改変することです。
• このソフトウェアの起源を主張してはなりません。自分がオリジナルの作者であるという主張は禁止します。
• ソースの改変版は明確にそう表記しなければなりません。またオリジナル版であるように見せかけてはいけません。
  この表記はどんな頒布形態であれ削除・変更してはなりません。
• GitHubのリポジトリにプルリクエストを作成したとき、あなたはその変更点の作者であるとか、あなた自身が作成した変更点であり権利を所有しているという事を認め、私たちに使用する権利を与えるものとします（？）
• 商業的な利用を行うときは私たちから許可を得ている必要があります。連絡先はinfo☆keenswh.comです。
• 私たちはこれらの条件を事前通知あり/なしに関わらずいつでも変更でき、変更した部分は即座に遡及的な効力を持つものとします。
  私たちはこうしたお願い（？）(ask)は合理的な物になると確信しています。ですから変更点を無視しないでください。私たちはオープンかつ信頼できる存在でありたいと思っていますし、皆さんも同様にしてくれる事を望んでいます。
• ソースコードを弄ることを怖れないでください。どこかおかしくしてしまってもダウンロードし直せば元通りなのですから。
• もし規約についてよく分からないところや説明されていない事があれば、とりあえず実行せずに保留して私たちに問い合わせてください。
  もしよく分からないとか紛らわしいと思った部分があって、「こうした方がいい」と思う部分があればメールしてください。info☆keenswh.com

以上です！これ以上はありません。上記を一言でまとめるとこういうことです。
「ソースコードはSpace EngineersのMOD作成の為だけに使ってくださいね」

まとめ

そろそろ繰り返し言うのも最後にしようと思いますが、私たちはSpace Engineersの開発を放棄することはありません。ご安心ください。
私たちはプレーヤーからの提案を聞き入れたりゲームを開発することに集中しています。
私たちは今まで2年間行ってきた通りのペースで開発を続けること、全てのプレーヤーが好きになってくれるようなゲームを提供することを約束します！
もし私たちの主張をちゃんと理解できていない人を見かけたなら、このブログ記事を引用して教えてあげてください！よろしくね！
もし他に疑問点があったり、十分に説明されていない事があれば、これからRedditでIAmAを開くのでそこで質問してくださいね（訳注：終了しています）
それと、何か質問があれば下のコメント欄にもどんどん送ってきてください。あとでFAQにします。

特記事項：惑星の情報を待ちきれない、という声が多いので今回はほんの少し開発中の画像を持ってきました。
惑星は宇宙空間とシームレスに繋がっており、100kmより大きく、動的に生成され、変形/破壊可能で、ほぼ無尽蔵の容量をもち、重力や大気もあります……木々や草地はもう少しお待ちください

（訳注：ブログ記事の下部に開発中の惑星の画像が5枚貼られています）

ここまで読んでくれてありがとう！
Marek Rosa

（はじめに）

こんにちは、Space EngineersとMedieval Engineersでリードデベロッパーを務めているOndrej Petrzilka（オンドルジェイ・ペトルズルカ*2）です。
私がKeen Software Houseに入社したのは2011年、Miner Wars 2081のゲームプログラマーとしてでした。それから様々なプロジェクトを担当していますが、最近はもっぱらSpace Engineersに注力しています。
この記事ではSpace Engineersの現在の開発状況と将来のプランについて説明していくつもりです。

現在私たちは3つの大きな仕事に取り組んでいます。つまり惑星、シナリオ、新しいネットコードの3つです。

惑星について

惑星については何度も議論を重ねており、プレーヤーの皆さんを長くお待たせしてしまっています。今回は情報と私たちの考えや、まだ決まっていないアイディアなどを公開していきたいと思います。
Space Engineersがアーリーアクセスで公開された時、私たちは惑星の追加は不可能な事だと考えていました。しかし2014年の終わりに小惑星の動的生成ができるようになった事で、考えは変わりました。
私たちは――直径8km程度の――より大きな小惑星を生成することもできると確信しました。
こうして惑星の追加について話し合いが始まり、私たちが本当に欲しいのは巨大小惑星ではなく、"何もかも"を備えた惑星であるという結論に達したのです。

• 惑星に予定されている要素
  • 惑星の名に相応しい大きさ
  • 自然重力（可能であれば船にも影響するもの）
  • 大気
  • 地形（山岳や峡谷など）
  • 植物（木々や低木、草地など）
  • 超遠距離からでも見える事（1000km以上）

では惑星の大きさはどのくらいになるのでしょうか？現時点で私たちは20～50km程度の大きさの"惑星"を作成することができます。
これは地球と比べれば小さすぎ、また専門的にも"惑星"ではありません。"準惑星"である冥王星でも半径1184kmあるのです。
私たちが初期プロトタイプの（直径8kmの）巨大小惑星を作ってみた時、見るからに大変大きく、ゲームプレイに支障が出ることが明らかになりました。
半径100kmの惑星をイメージしてみてください。画面の上から下まで一杯にその惑星が表示される時、デフォルトのFOV（視野角）の場合まだ地表まで73kmもあるのです！
最大速度が104m/sの場合、地表に到達するまでに12分もかかってしまうのです。これは長すぎです。
では100kmの小惑星を1周するのにはどのくらい時間がかかるのでしょう。100kmの小惑星の円周は628kmです。これは最大速度で移動し続けても1周するのに90分もかかってしまう距離です。

解決策

解決策の一つは最大速度を変更する事です。しかし私たちは物理演算を安定させるために速度を制限しているのですから、これはかなりの問題を起こしそうです。bullet-through-paper（すり抜け）など沢山の問題が起きるでしょう。
結局私たちは惑星の大きさをワールドオプションから変更可能にすることにしました（惑星の最小～最大サイズ）

こうすることで私たちは惑星を早くリリースすることができ、小さい惑星でも満足できるプレーヤーから、巨大な惑星を望むプレーヤーまで対応できるはずです。また最大速度についてはその内見直すかもしれません。

重力について

惑星は地球の重力と似た重力を持ちます。惑星からの距離に応じて重力は徐々に弱まり、また大きな惑星はより大きな重力を持ちます。惑星の重力は船にも適応されるよう予定しています。

大気について

いくつかの惑星には大気を持たせる予定です。大気があるなら、植生もあるでしょう。大気のない惑星には不毛地帯が広がるでしょう。
植生はMedieval Engineersのものとかなり似たものになる予定です。大気によるエフェクト、つまり太陽の方向や空気の密度、光が直進する大気の厚さなどを表現するため、私たちは特殊なシェーダーを採用することを予定しています。

視認距離について

Space Engineersのデフォルトの視認距離は20kmになっています。
このまま30km先の小惑星や惑星に直進していった場合、あなたが経験するのは「前方に異常なし……異常なし……異常なし……」ときて、突然巨大な惑星が目の前に現れる事でしょう。
これは極めて不自然ですし雰囲気も何もかも台無しにしてしまいます。そこで私たちは解決策を考えました。

視認距離を広げるというのも一つの方法でした、しかしこれはZ軸のバッファの正確性を保つためには50～70kmが限度になります。
私たちは1,000km以上の距離から惑星が見える様にしたいのです。そこで私たちは惑星の描画を"分けて"行う事にしました。
これによりプレーヤーは10,000km以上遠くから惑星を視認できるようになりました。その他船や小さな小惑星などのオブジェクトは20kmのままです。

シナリオについて

この15ヶ月の間、私たちはゲームに大量の要素を詰め込んできました。しかしゲームプレイに関する要素は大して追加してきませんでした。Space Engineersは現時点ではサンドボックスゲームです。そのためどんな狂気じみた発想も実現することができますが……ゴールはありません。
私たちはゴールを直ぐ近いうちに追加する予定です。1週間前に最初のシナリオを公開しましたが、これはテスト用のシナリオです。もっと沢山のシングル・マルチプレーヤーのシナリオが追って追加されます。
シナリオの第一の目的はプレーヤーを楽しませることです。ゴールを目指したりゲーム内の実績を解除したり……
第二の目的は新規のプレーヤーにゲームの遊び方と、様々なブロックなどの機能をゆっくりと教えることです。現状のように一度にできる事が多すぎると新しいプレーヤーは混乱してしまいます。

シングルプレーヤー用シナリオについて

シングルプレーヤー用シナリオはオブジェクティブ（達成目標）をこなしていく構成になるでしょう。分岐することもあります（時にはプレーヤーはルートを選べるということです）
シナリオは既に実装されているゲーム要素にも利点があります。最初のシナリオはとても簡単な物になるでしょう、採掘やステーションの修理などプレーヤーにブロックの機能を教えるものです。
高度なシナリオではゴールに辿り着く為の方法は幾つも用意されるでしょう。例えば"軍需工場*3を破壊しろ"というシナリオの場合を想定してみましょう。
この場合プレーヤーは重装甲の宇宙船にミサイルランチャーを満載して突撃してもいいですし、デコイを量産して欺瞞するとか、1つのターレットをウォーヘッドで吹き飛ばし、残りをハッキングしてしまうという事もできるでしょう。
シングルプレーヤー用シナリオをCOOPモードで遊べる様にするかはまだ決まっていません。

マルチプレーヤー用シナリオについて

マルチプレーヤー用シナリオはSpace Engineersに競争をもたらす様デザインされています。これらのシナリオデザインはチームで議論を交わしているところです。
案にはよくある"基地防衛"や"キャプチャーザフラッグ"、"デスマッチ"の他、他では見ないようなシナリオもあります。
例えば商人に一番多くの金鉱石を売却するために巨大な金小惑星の争奪戦を繰り広げるようなものです。シナリオはチームをベースにしたものも、自分以外全員が競争相手になるものもあるでしょう。

MODについて

私たちはシナリオは完全にMODで変更できる様にしたいと考えています。つまりMOD職人はシングルプレーヤー用もマルチプレーヤー用もスクリプトを書く事ができるということです
またゲーム内にもシンプルなシナリオエディターを追加する予定です。MOD職人はワールドで下準備を整えたり、UIに勝利条件を設定する事ができます。
MOD職人は予め用意された機能を使ってシナリオを作る事ができます、例えばクリア/ゲームオーバー画面やスコア画面、チーム選択、プレーヤーインベントリーの制限、リスポーン可能回数の設定などです。

新しいネットコードについて

マルチプレーヤーが追加されたのは1年以上前の2014年1月16日、Update 01.015での事です。
このマルチプレーヤーのコード（ネットコード）は5週間で書かれた物で、完璧とは程遠いものでした。接続の問題、ラグ、同期ズレ、オブジェクトの震え、ハッキング耐性その他様々な問題を抱えていました。
しかし1から書き直すには2ヶ月も要することがわかり、私たちは"より良い"ネットコードの作成は後回しにして問題点を修正・保守していく事を決めたのです。
私たちが後に「無限の大きさのワールド」を追加したとき、もしかするとネットコードを再び作り直さなければいけないかもしれないという懸念もありました。

最近になって私たちはネットコードを1から作り直す準備ができました。ゲームに多数の新要素が盛り込まれこれら（特に無限のワールドサイズと小惑星の動的生成）を参考・考慮しながら書き直す事ができるようになったからです。
開発チームが大規模になったため、新しい要素を追加しつつネットコードの改善を進める事ができるようになったという事情もあります。
現在のバージョンのマルチプレーヤーでは、全てのクライアントが全ての事象を把握しています。10万kmの彼方で誰かが小惑星を掘削している情報すらサーバーから受け取っているのです。
この情報はクライアントには必要ありません。クライアントは自身の近くの小惑星が掘削された情報だけ受け取れば十分なのです。
新しいネットコードでは、クライアントは必要性があり自身の近くで起こった情報のみを受け取ります（遠隔でカメラを視ている時はカメラの周囲の情報を受け取ります）
これにより必要になる回線の帯域は大きく減り、より多くのプレーヤーが同時に接続できるようになるでしょう（サーバーの設定次第ではありますが）
クライアントに送信される情報にも優先順位が付けられます。位置情報などの重要なものは優先して、バッテリーの容量やインベントリの変更などの重要性の薄いものは後回しに送信されます。
こうすることでラグが小さくなり、マルチプレーヤーがよりスムーズに動くようになるでしょう。

また現在は全てのクライアントが自身の位置情報を他のクライアントに直接送信するようになっています（サーバーを介しません）
この仕様はラグを少し小さくする効果がありますが、代わりに太い上りの帯域を要求します。というのも他の全クライアントに情報を送信する必要があるからです（サーバー以外とも通信するということ）
これは接続の安定性に悪影響を及ぼします。全てのクライアントがお互いに通信し合う必要があるからです。より沢山のプレーヤーがサーバーに接続したとき、この問題はより深刻になるでしょう。

新しいネットコードではクライアントはお互いに接続することは無くなり、サーバーとのみ接続するようになります。
サーバーは正確なデータ（位置情報など）をクライアントから受信し、この情報を必要としている他のクライアントのみに送信します（送信元のクライアントAを目視しているクライアントBなどに）
これにより接続の問題が防止され、通信帯域も削減する事ができます。これはサーバーの最大収容人数を増やすためには重要なことです。
現在のネットコードではSteamのネットワークレイヤーを使用しています。これはプレーヤーとの間の通信をとても簡単にすることができますが、一方で高度な機能を持っていないという短所もあります。
より高度な機能を盛り込むため、私たちはRakNetに変更する事を決めました。RakNetはポピュラーなネットワークレイヤーでとても安定しており、またXboxをはじめプレイステーション、Linux、Androidやその他様々なプラットフォームに対応しているからです。
あたらしいネットコードは専門的にはHalo Reachとかthe Tribeシリーズに似たものになるでしょう（オブジェクトやパラメータの同期方法が）
私たちはこの新しいネットコードの開発をひと月前から始めています。もう数週間から1～2ヶ月もすれば開発は完了するはずです。

これからも船用AIやXbox、ゲームコントローラーへの対応やMedieval Engineersの更新予定など、様々な情報を発信していきます。お楽しみに！

お知らせ：この記事に掲載した全ての画像はパブリックドメインです。

ここまで読んでくれてありがとう！
Ondrej Petrzilka

今回追加した蛮族は「エンジニア」シリーズに初めて搭載されたAIのプロトタイプです。
ただしこれは「秘密のAIプロジェクト」とは無関係の物ですので混同しないようにしてください。「秘密のAIプロジェクト」は根底から異なるもので、開発チーム自体違います。これについては今年中に発表するつもりです。

今の蛮族のAIはあまり高度な物ではなく、まだ基本的な部分を実装しただけの段階です。
「道を探し出す機能」はまだ複雑な道を見つけることができません（例えば今は1マスに複数のブロックが置かれている場所は迂回するようになっています。通常のブロックよりも幾何学的に難度が高いのです）

そしてこの機能は地形のLODアルゴリズムの影響を受けるためあまりに遠い場所は探すことができません（計算のためマップ全体の高レベルなLODモデルを必要とします）
これらの問題は2週間程度で解決する予定です。

Space Engineersにも後でこのAIシステムを導入します。Space EngineersのAI導入が遅れるのは宇宙という環境がかなり複雑だからです。
恐らく想像し得る範囲で最もAIに不向きな環境でしょう（完全に動的であり、重力のベクトルも位置や時間によって可変であり、AIに歩行するかジェットパックで飛行するかの判断を迫り、船の廊下をくぐり抜けた後に他の船に飛び移る状況などもあり、船の操縦を迫り……まだあります）
上記の例はAIの実装の難しさを説明するために挙げたものであり、「実装する」と約束するものではありません。ご注意ください。

現在、Medieval Engineersの開発は主としてハードウェアの互換性の問題を解決する事にフォーカスしています。
私たちはできる限り多くのハードウェア構成でテストを行いましたが、それでも残念ながら最初のバージョンは完璧な物にはなりませんでした。
そこでより多くのハードウェア構成でテストするために、"βテスト"という形で24時間限定の先行販売を行い*4、プレーヤーに協力してもらったのです。

上記の問題が解決したら、私たちは最も重要な2つの機能の実装に取りかかる予定です。即ち、マルチプレイヤーとサバイバルモードです。
ところで、ちゃんとしたサバイバルモードの前に、簡略化したサバイバルモードをリリースする予定です。
シンプルサバイバルモードには「死亡とリスポーン」「時間のかかる建造」「飛行モードなし」が盛り込まれます。
将来的には「資源の管理とインベントリ」「資源の獲得と加工」「道具の使用」などの要素を盛り込んだちゃんとしたサバイバルモードにする予定です。

• Q：何でもいいからSpace Engineersの惑星の情報ちょうだい！
• A：惑星は山や海溝（谷？）のある概ね球形の物になると思います。技術的に可能なら全ての船に作用する重力も追加するつもりです。ですが私たちチームはまだテラフォーミングについて議論しているところで、確約できることはありません。

• Q：水に関する要素に何か進展やニュースはありますか？
• A：私たちの予備的な案に水も含まれています。案が通ったら水の実装もすると思います。色んな人が水を掘ってるのを見ますし（？）

• Q：Keen Software House自体がサーバーを運営する予定はある？もっと安定したサーバーを公式が運用してくれれば、頑張って作った船がサーバー毎消えてなくなる心配とかしなくてもいいんだけど。
• A：公式サーバーはいいアイディアですね。SEのMMO版も考えたことはありますがじっくり検討したことはありません。公式サーバーが欲しいのかそうじゃないのか、プレーヤーの皆さんが教えてくれると嬉しいです。

• Q：MEで色んな環境（砂漠とかツンドラとか）を追加したり、雨とか雪とかの天気を追加する予定はある？あと昼と夜はどうなの？
• A：クールな案ですね。雨と雪は中々難しい問題になりそうです（レンダリングの観点から）ですが昼夜はちゃんと追加します。

• Q：Space Engineersのアイディアは何から得てる？
• A：大体はLEGOと今までの経験からです。実は私たちは宇宙飛行士ではないのです。

• Q：Medieval Engineersにマルチプレイが追加されるのはいつになる？
• A：恐らくですが近く数ヶ月先の事になると思います。Space Engineersで使っているネットコードを流用すればいいのですが、現在このネットコードを他のライブラリ向けに大幅に書き換えている所なのです。MEにマルチプレイを追加すること自体はSEにマルチプレイを追加するよりは簡単です。既にインフラとGUIが作成済みだからです。

• Q：なんで僕たちの時間をこんなに盗んでいくの！？
• A：それが私たちもSEの開発に時間を盗まれてるんですよね。

• Q：マルチプレイで同期ズレが見られるけどこれを解消する予定はある？
• A：現在、私たちはSteam networkingからRakNet network libraryに変える作業を行っています。これが完了したらマルチプレイの同期など最適化を行う予定です。

• Q：巨大な建造物が原因で起こるパフォーマンス上の問題を解消する予定はある？
• A：私たちはパフォーマンスを向上させることはできますが全てを直す事はできません。ハードウェアの性能と物理エンジンに依存する所はどうしようもないのです。

• Q：Space Engineersで遊べるのはどんな場所までになる？惑星まで？恒星系まで？まさか宇宙全体までプレイできるの？
• A：今は惑星の開発を開始したところで、まだ恒星系や宇宙についてまでは検討していません。

• Q：酸素はどういう風に追加する予定になっている？どうやって回収するの？プレーヤーにどういう影響が出るの？宇宙服はまだ必要？
• A：私たちは氷（Ice）を単純に処理することで酸素を生成する事を予定しています。宇宙服と酸素の補充についてはまだ何も決まっていません。

• Q：液晶ディスプレイブロックにカメラの映像を映すことはできるようになる？
• A：私たちも追加したいのですが、パフォーマンスが損なわれると思います（特に2つ以上のカメラを表示させた場合）

• Q：惑星の追加はSpace Engineersにどんな利点があると思う？どうやって探したり突入したりしたらいい？酸素とリソースは？
• A：惑星には基地を作成することができます。開発チームはまだテラフォーミングについて話し合っている最中です。惑星からは大量の資源を見つけることができるでしょう。

• Q：惑星に着陸することはできる？人工重力とは違う重力が追加されるの？人工質量ブロック（artificial mass）のない船にも影響する？大型船で簡単に着陸することはできないよね？スペースシャトルとか必要になる？
• A：惑星には球形の重力を追加します。技術的に可能であれば、全ての種類の船に影響するはずです。

• Q：惑星はパフォーマンスにどれくらい影響しますか？
• A：これを今述べるのは難しいです。おそらく最適化に相当な努力が必要となるでしょう。惑星は木々や植物など膨大なボクセルデータを内包するからです。

• Q：テクスチャ（ブロックのモデル）を刷新していくとの事ですがパフォーマンスに影響はありますか？
• A：いくつかの状況では悪化しますし、いくつかの状況では改善します。というのもLODモデルを現在よりも増やすため、遠くにあるモデルはポリゴン数が少なくなるためです。

• Q：現在の古いテクスチャを保存することはできますか？（新しいモデルが追加されたときに古いモデルに切り替える設定は追加されますか？）
• A：切り替えできるようにする予定はありません。デザインが変更された場合は当たり判定も変化するからです。

• Q：なぜ無限のワールドサイズを追加したのですか？有限のワールドを連結できるようにするのじゃダメ？
• A：無限のワールドサイズって響きが好きだからです。それにワールドの連結はマルチプレイヤーのアーキテクチャを変更しなければいけなくなってしまいます。

• Q：Linux用の専用サーバーは追加されますか？
• A：そうしたいのですが、いくつか問題があって実現していません。

• Q：なぜパフォーマンスの最適化よりも酸素や惑星、グラフィックスの向上に力を入れるのですか？結構な人が重さを不満に思ってるんですけど。
• A：より多くのプレーヤーが新しい要素を望んでいるからです。サンドボックスゲームで何もかもを最適化するのはとても難しいのです。

• Q：将来何を見据えて開発していますか？もっとマルチプレイのサポートを拡充する予定はありますか？例えばチャンク/セクターシステムとか。
• A：私たちはセクターシステムは"一切"予定していません。ですがマルチプレイを変更する予定はあります。クライアントは必要なデータのみを同期するようになります。

• Q：APIの詳細を書いた書類とかサンプルを追加する案はありませんか？
• A：ModAPIの詳細はModding SDKに入っています。サンプルを追加する予定はありませんでしたが、いいアイディアですね。

• Q：MOD用APIを拡張する予定はありますか？
• A：はい、Mod職人のためにもできることをもっど増やしたいと思っています。

• Q：レベルデザインの進捗状況はどうですか？（お手伝いいる？）
• A：何人かのレベルデザイナーを雇って、作業を開始してもらっている所です。

• Q：キャンペーンモードやチャレンジモードを追加する予定はある？
• A：もちろんです。私（※Rosa氏）のブログ記事にも書いたので見てください（※下記）。

• Q：キャラクターアニメーションの機能強化は期待していいの？エイプリルフールでやってたみたいなNPCってもうすぐ追加できる？
• A：キャラクターアニメーションは私たちがこっそり進めてる大きな機能の一つなのです……基本的にいくつかの逆運動学とラグドールが追加され、将来的にはもっと高度な要素も来るでしょう。NPCに付いては……MEの方はそろそろカウントダウンを初めてくれてもいいですよ……うふふ

• Q：レールブロックってまだ追加されないの？
• A：これは難しい質問です 物理オブジェクトの種類によっては、オブジェクトの重さが大きく異なる場合リアルタイムに計算するのがとても難しいことを、ローターとピストンが教えてくれましたので……今はこれを直すよりもむしろ他の事に注力しています。レールはまたいつかの機会に。

• Q：SF小説はお好き？
• A：（Cestmir Houska氏（プログラマー））アーサー・C・クラークさんの小説と映画、ドラマが好きだよ。『Star Trek: The Next Generation』も好き。

• Q：フォーラムからの色んな意見を取り入れてるけどずっと望まれてるレーザーとかワープとかは追加しないの？
• A：概して私たちはSEをリアルにしたいと思っています（重力発生装置など一部は別として）。なので現実的で追加が難しくない要望は実装しています。実装が難しいものでも、要望が多く良いアイディアなら実装することもあります（惑星はこちらの例ですね）。　（追加するメリット） / （実装の難易度） の式で拾い上げる要望を選んでいると思ってもOKです。加えて私たち自身のアイディアや長期目標なども追加している感じです。

• Q：バーバリアンとか、MEでの戦闘についてどういうのを想定してる？
• A：これらは現在全力で開発している部分です。バーバリアンとかはSEの小惑星（※隕石の誤植？）の様な災害として追加すればいいと考えています。

• Q：SEやMEをRiftとかのVRに対応させる予定はある？コックピットモードとかに向くと思うんだけど
• A：今のところVR（Oculus社の物にもそれ以外にも）に対応させる予定はありません。これらの技術はもっと成熟する必要があると思っているからです。

• Q：酸素や惑星が追加されるのはいつ頃？大体でいいから教えて！
• A：私たちのルールで「いつ来るか」は教えてはいけない事になっているのです。ごめんね！でも恐らく皆が考えているよりは早く来ると思いますよ！

• Q：MEの更新は毎週火曜日ってことでいいのかな？
• A：Yes。できる範囲で、ですが

• Q：MEの1マスに複数のブロックを設置できるシステムはSEにも追加される？
• A：追加する予定です。

• Q：MEみたいにSmallブロックとLargeブロックをくっつけることはできる？
• A：MEはSEよりもグリッドシステムが簡単なためできている事です。SEに追加できるかどうかは実現性次第です（？）

• Q：（MEで）今は壁に柱を埋めても強度が上がったりしないけれど、いつか補強できるようになる？
• A：将来的には可能になると思いますが、今「できます」と明言するには少し早いですね。

• Q：戦闘用のシステムとか追加される？
• A：戦闘システムの追加は少し延期したいと考えています。もう少し内容を検討したいのです。

• Q：どんな資源をサバイバルモードに追加する予定？
• A：Wood、Stone、Ironは確定しています。

• Q：馬を追加する予定はある？
• A：いいですねそれ。

• Q：水について一言。Yes？No?
• A：Yes！いつになるかとか、方法とかはまだ未定ですけどね！

• Q：サバイバルモードまだー？
• A：まだです。十分に検討が終わったら直ぐに追加を始めるつもりですが、それまでにはかなり時間がかかります。

• Q：異なるサイズの船をくっつけられたら面白いんだけど予定してる？
• A：今でもローターを使えば可能ですが、ぴったりくっつけるのは今は無理ですね。現在どうしたらこれが可能になるか話し合っているところです。MEで必要になりそうなので。

• Q：SEとME、Linuxに対応する予定はある？
• A：残念ながらLinuxとMacバージョンは今は予定していません。

• Q：滑車とかロープに関するアップデートは予定してる？
• A：ロープはまだ開発中のもので、今はロープでどんなことができるのか調べている所です。中世に実在したプーリーやその他ロープシステムは追加したいと思っています。

• Q：SEの"秘密のAIプロジェクト"はどうなってるの？カーゴシップが賢くなるとかの機能って思ってていいの？
• A：件のAIプロジェクトはゲーム向けに開発している物ではありません。それはそれとして、もうじき公開できるはずです。

• Q：開発の中の人たちってSEやMEで遊んでるの？
• A：（Marek Rosa氏）どっちも遊んでないよ。他のゲームも含めて遊ぶ時間がないんだ。今はゲームを遊ぶよりも情熱を持って開発する方が楽しいからね。

• Q：ブロック少ないけど楽しんでるよ！何かニュースちょうだい！
• A：MEのブロックは破壊できるからSEのブロックよりも作るのが大変ですが、それでも屋根とか大きな円筒の城壁ブロックとか沢山追加する予定です。

• Q：SEとかMEとかプロジェクトどのくらいがんばってるの？
• A：みんな毎日10時間は働いていますよ！やらなくちゃいけない事が沢山です！

• Q：センサーの範囲を広くする予定はある？
• A：センサーの範囲は広くしたいと思っているのですがパフォーマンスが大きく落ちてしまうため難しいです。

• Q：MEで川や湖を追加する予定はある？
• A：開発チームは"平面の"水について議論しています。比較的簡単そうだからです。穴を掘ったとき、一定の深さで水が出てくるでしょう。体積を持った水（体積で管理する水）も追加したいとは熱烈に思っているのですが、多数の障害を取り除かねばなりません。

• Q：Xbox Oneへの移植の進捗状況はどうなってるの？
• A：作業を進めており、移植を手伝ってくれる企業にもコンタクトを取っています。進捗状況についてはコメントできません。

色んな人に「Space Engineersの次の大規模アップデートは何になるのか」と聞かれます。
現時点では、私たちが取り組んでいる目標の多くは（完了するまで数ヶ月はかかる）長期的な計画の元で動いています。
ですがプレーヤー達に内緒にし続けるのも嫌なので、今回はいくつかの予定を公開することにしました。

ですがその前に一つ注意があります。このブログ記事で言及する事は全て"変更される可能性があります"。
私たちのスタジオのゲーム開発工程はいくつかの段階に分かれていますが（着想を得て、構想を練り、開発して、フィードバックを受けて、更に開発する…）
後半の段階に入る前に、フィードバックや開発して分かったことなどを受けて前半の段階から変更されることがあるということです。

惑星と酸素について

Space Engineersの開発を開始したとき、私たちは酸素と惑星を追加する必要があるか分かりませんでした。
私たちは酸素と惑星を追加する方向で動く事が望まれているのか分かりませんでしたし、開発がどれほど難しい物になるかも見当が付かなかったのです。
しかし今は違います。酸素と惑星は今最も要望の多い要素の一つですし、私たちも成し遂げることができると確信しています。

最初に考えたのは宇宙船（Grid）の中の酸素についてです。
アルゴリズムは船内の空間を走査して（？）、その場所が解放されているのか密閉されているのか、酸素が拡散していくのか保持されるのかを確認するものになるでしょう。
これは既に開発済みであるコンベアーのアルゴリズムを流用することができるでしょう（うってつけのグラフ探索(graph traversal) /塗りつぶし(flood-fill)アルゴリズムなのです）
次の段階は惑星です、これは基本的に大きさが数百～数万kmの大きさの小惑星として考えればいいでしょう。
ここでは惑星の動的生成が重くならないように気をつける必要があります。最もシンプルな最適化は惑星の地表から遠すぎる位置の地形生成を避けることです（そういう場所は何かが詰まっているか何もないかである事が殆どなので生成する必要がないからです）
その後はテラフォーミングに関する要素をいくつか追加すれば良いでしょう：酸素の生成や樹木、草などです。

まだ解決していない問題もあります。私たちは惑星にどうやってステーションブロックを設置するかについて決めかねています。
もし私たちが今の「軸を揃える設置方法（axis-aligned）」を採り続ければ、プレーヤーが惑星のどこかでステーションの建造を開始したとき、ブロックはすぐに丸い地表から離れていってしまうでしょう。
解決策として考えられるのはベースになるブロックを回転させられるようにすることです。こうすればプレーヤーはブロックを惑星の地表に合わせる事ができます。
もう一つ、球面座標をベースにする新しいタイプのブロックを増やす選択肢もあります。
また、酸素は装飾的な機能にとどまるかもしれません。

私たちはプレーヤーがヘルメットや宇宙服を外した時にしかできないことなど何かしらのメリットも考える必要があります。
そうでなければ誰もヘルメットを取ろうとはしなくなってしまうでしょう。宇宙船からは酸素が失われる可能性もあるのですから。
一方で私たちは宇宙服に何かしらのペナルティを与えようとは思っていません。今の遊び方を否定することになってしまうからです。
自然風景や木、草や空の自動生成はもう既に完了しています。Medieval Engineersのおかげです。

DirectX 11 と 最適化について

Medieval Engineersを開発している間に私たちは新しいタイプのDirectX 11のレンダラーを作成しました。
これの目玉機能はPBR（Physically Based Rendering / 物理ベースレンダリング）です。これにより非常に写実的なサーフェステクスチャを定義できるようになりました。

追記：旧式のDX9レンダラーも残してあります（DX11対応のハードウェアを持っていない人のために）

• 他の利点
  • マルチスレッドレンダリング
  • 作成されたジオメトリのより効率的な処理（ガラスなど）
  • 画面上のオブジェクトのディザリングをベースにした滑らかなLOD（Level Of Detail）の切り替え（ポッピングも起こりません）（？）

この新しいレンダラーはもうすぐSpace Engineersにも追加されます。
私たちの開発チームのアーティストは3Dモデルを完成させ最終段階のクオリティまで引き上げる作業を開始しています（お気づきかもしれませんがSpace Engineersのモデルは間に合わせに作った物でポリゴン数が少なかったりテクスチャがなかったりする物が殆どです）
私たちは元々のアートスタイル（デザイン案？）を持っており、モデルをより綺麗に改良しています。
この間に私たちは不必要なポリゴンを削除したり、LODの最適化のためいくつかのモデルを追加する予定です（LODは遠くのオブジェクトを低画質で描画して負荷を下げる機能です）
良いことに私たちはこの作業を反復して続けることができます（？）

マルチコアでの物理演算と最適化について

HavokはIntel社が開発した物理エンジンで、私たちはSpace EngineersとMedieval Engineersに使用しています。
Havokは物理演算を行うに当たって複数のCPUコアを活用することができますが、今のところ私たちのゲームはこれをサポートしておらず、いくつかの修正が必要な状態です。
私たちはHavokが異なるスレッドからトリガされた時に問題を起こさないように、ゲームに渡されるコールバックを適切に処理する必要があります（？）
例えばHavokが二つの物体の衝突を検知した時、私たちのゲームへHavokからのメッセージが送信されることで効果音を再生したりパーティクルエフェクトを表示することができるのです。

もう一つ大仕事になりそうなのは、ボクセルのポリゴン化と動的生成に於けるスレッドの安定性の拡充でしょう。
現在はこれらは非同期で動作しているため（これにより大きな地形の生成時にゲームにラグが発生しないのですが）特定の状況で問題を起こします（？）
例えばオブジェクト同士が急激に接近する状況ではHavokが衝突の可能性を計算するために実際のジオメトリを要求するのですがこの時に問題となります（？）

• マルチコア物理演算の他の利点
  • より高速な演算 ＝ 重要な局面でのラグを減らします。
  • より多くのオブジェクトを一つのワールド上で計算できるようになります。例えばMedieval Engineersにおいて構造物が崩壊する時に大量の瓦礫を表示することができます。

マルチプレイヤーについて

私たちのネットワークエンジンの下層レイヤーはSteamのネットワークに依存しているのですが、Xbox OneにSpace Engineersを輸出した際にはこれを利用することができません。
私たちが選択した新しいネットワークライブラリは、より良いメッセージやチャンネル優先度の制御や、マルチプレイヤーのラグの低減、待機時間の減少を可能にしました。
このアップグレードは将来Space EngineersをXbox Oneに輸出するという決定のおかげで実現しました。更に私たちのゲームエンジンの独立性を高めるきっかけになりました。

ここまで読んでくれてありがとう！

補足

Marek Rosa氏がTwitterでこの記事について補足していましたので紹介します。
「前回のブログ記事（※上記の記事）でSpace Engineersに『キャンペーンとシナリオの追加』も進めている事を紹介し忘れてた」

初めに

今日という日は私の人生の中で最もすばらしい一日のひとつとなりました。私の同僚達も同じように感じていることでしょう。
私たちは大規模アップデートや新しいゲームの発表を行う日を楽しみにしてゲームを作り続けています。
今日という日も同じく楽しみな日です、私たちが何か新しい物をプレゼントして、ファンやコミュニティからの反応を待つ事で――あなたたちとの絆が深まるのを感じられるからです:)

2014年は興奮と挑戦の年でした。この組み合わせこそ私たちがKeen Software Houseで探し求めている物です。
私たちはSpace Engineersを開発し、より洗練された状態にすることができ、今日の発表に向けてMedieval Engineersのプロトタイピングを行うこともできました。
2015年はさらなる挑戦の年になるでしょう（平行して二つのゲームを開発するのですから）。私たちは挑戦が好きなのです

このブログ記事ではMedieval Engineersについて語ろうと思います。なぜMedieval Engineersを開発しようと思ったかや、開発の歴史についてを少しばかり。

Medieval Engineers（ミディーヴァル・エンジニアーズ）について

Medieval Engineersは私たちの二つ目のエンジニアリング＆建造ゲームです。一つ目のゲームはSpace Engineersで、開発は今も積極的に進められています。
Medieval Engineersは実際の中世の技術や建造物、機械設備などに着想を得たものです。
Medieval Engineersは物理法則や現実の中世の歴史などを忠実に反映したもので、5世紀～15世紀までに無かった技術は登場しません。
プレーヤーは街や城、砦、機械やエンジンの建造や地表・地下の掘削を行う事ができます。
Medieval EngineersはVRAGEエンジン*6に3つの改良点をもたらしました。
構造に基づく強度の計算（structural integrity）、自然環境の表現、物理ベースレンダリングです。

Medieval Engineers公式サイト: http://www.medievalengineers.com/

なぜSpace Engineersの開発が終わっていないのに新作を出すのか？

恐らく、多くの方が「なぜSpace Engineersがまだ完成していないのに新しいゲームを作っているんだ？」と思ったことでしょう。
まず結論として「Medieval Engineersの開発はSpace Engineersの開発速度に悪影響を与える事はない」ということをお伝えしておきます。
これは私たちが毎週のアップデートを欠かしていないことが証明になるでしょう。2014年末はスーパーラージワールドや小惑星の自動配置、探査要素やゲーム内プログラミング、SDKやAPIの追加など大規模アップデートのラッシュで締めくくることができました。

私たちは宇宙のゲームだけを作り続けようとは思っていません。むしろ私たちは生命や自然を感じられるゲームを作りたいのです。
二つ目のエンジニアリングゲームを作るに当たって、私たちは既存の技術や経験を活用することができますから、Medieval Engineersの開発を（数年）延期するという考えはありませんでした。

しかし二つのゲームを平行して開発するには何かを犠牲にする必要がありました。私たちはそれを防ぐために新たにスタッフを雇い始めたのです。
チームは既に40名を超え、まだ規模の拡大を続けています。チームはSpace EngineersとMedieval Engineers、秘密のAIプロジェクトに分けられました。

私たちはかなり初期の段階でMedieval Engineersの開発がSpace Engineersに利することに気付きました。
中世という設定では宇宙とはまた違った空間と環境の表現（volumetric environments）が要求され、私たちにエンジニアリングゲームの新たな一面を見せてくれました。
実際にMedieval Engineersで開発された内容がSpace Engineersに応用・追加された（もしくは将来的に追加される）ものを具体的に挙げてみましょう。

• 複合ブロック
  複数のブロックが一つのグリッドセルの中に位置できます。これにより船のデザイン性が向上します。
• メカニカルブロック
• いくつかのブロックにおける装飾の自動生成
  例えばMedieval Engineersのroofの端や、Space Engineersのアーマーブロックの縁など。
• ボクセルハンド
  地形や小惑星を変更するツールです。変形や材質の変更が可能です。
• 構造に基づく強度の計算
• 自然風景
• 地形の動的生成
  Space Engineersに簡単に小惑星の動的生成機能を追加できたのはこういうことだったのです。
• DirectX 11への対応
  私たちはPBR（Physically Based Rendering / 物理ベースレンダリング）を採用することを決定しました。

逆にMedieval EngineersがSpace Engineersから受け継いだ（または将来得る）ものもあります。

• マルチプレイヤー
• 物理、描画、コアエンジンなど
• Steamワークショップ
• MOD用SDKやAPI

同じテーマ（エンジニアリング）を持つ二つのゲームを同時に早期アクセスとして開発することは双方にとって有益なのです。
Space Engineersではリリースされた要素の多くがプレーヤーから着想を得たり提案を受けてできたものでした。
これからは片方のゲームに対する提案から、もう片方のゲームへの新しいアイディアを得ることもできるでしょう。
Space EngineersとMedieval Engineers、それぞれの環境（宇宙・中世）の制約により見落としてしまっていたアイディアも拾い上げることができるのです。
つまりこれからはもっと多くの選択肢と可能性が得られるようになるはずです。

ある意味では、Medieval Engineersの開発はSpace Engineersの開発よりも更に挑戦的なものでした。
Space Engineersでは様々な新しいタイプのブロックを追加できましたが、Medieval Engineersでは中世に存在しなかったものや、（シングルプレーヤーモードで）一人で動かすことができないものは追加できないからです。
逆に言えば、Medieval Engineersにおけるサバイバル/リアリスティックモードはすばらしい可能性を持っています――想像してみて下さい、最初は石器時代の技術しか無かった所から少しずつ鉄器時代まで発展させていくことができるのです。

告知用ビデオについて

今まではMedievalチームは告知用ビデオの用意を目標として準備を進めてきました。
私たちはビデオを撮る前に何を見せるかを選ぶ必要がありました。というわけで私たちはちょっとしたストーリーを書いて、見せたい工程（？）（individual section）を選んで作りました。
平行して私たちは試作版の音楽も作り始めました。これは後でオーケストラの生演奏を録音したものに差し替えるつもりです。
告知用ビデオをみてMedieval Engineersがどんなものかを感じ、楽しんで頂けたら幸いです。

この動画はクリエイティブモード（サバイバルじゃない方）で撮影されたものです。青いおじさんが城をブロックで建造したところに（もちろん大部分は省略していますが）赤いおじさんが現れ、
トレビュシェットを組み立てて攻城し始め、攻撃に耐えかねた青いおじさんが秘密の通路を通って逃げる、という流れになっています。

私たちのモチベーション：何故私たちがこんなことを続けるのか

私たちはこの宇宙で最も強い力は「創造の欲求」だと信じています。
あなたたちはいつも無から何かを造りだし、構造を持たないものに形と機構を与えます――これは奇跡のような事です。
加えて、私たちは平易な事を良しとせず、骨の折れることや不可能とされる物事に取り組む事を好む人間の集まりですから――ここまで言えば、私たちがなぜこのような事をしているのかお分かりいただけるでしょう。
私たちは創造に対する強い欲求を持っていて、そして実現不可能な目標を達成することを誇りに思っているのです。これがKeen Software Houseという会社なのです。

Medieval Engineersの開発について

私たちはできるだけ早くMedieval Engineersを紹介できる段階まで持って行きたいと思っていました（そのためいくつかの要素は犠牲になりました。公開初日に間に合わせたのは中核部分と重要な機構だけです）
最も重要視しているのはあなたたちからリアルなフィードバックを得ることです。ゲームを隠したまま開発するのは楽しくありませんし、まったくもって非効率的だからです。
現実の人々から寄せられる生の要望や声に耳を傾けるのはゲーム開発の肝になることです。

初期プロトタイプのスクリーンショットはこちら

• http://mirror.keenswh.com/Pics/04_14.jpg
• http://mirror.keenswh.com/Pics/08_14.jpg
• http://mirror.keenswh.com/Pics/09_14.jpg
• http://mirror.keenswh.com/Pics/12_14.jpg

注意：これらの画像は古いバージョンのものであり現時点のものではありません。
もっと開発中のスクリーンショットを見たい方はこちらからどうぞ（rarファイル直リン）

時系列

2013年6月

Space Engineersのトレイラーを準備し始めた辺りです。この時私たちはボクセルベース（？）（volumetric-block）のシステムが他のゲームにも応用でき、また私たちは宇宙にこだわり続ける必要がないことに気付きました。

2014年6月

新たなプログラマーがチームに加わり、Medieval Engineersの進め方について検討し始めました。山ほどの中世や中世の技術についての資料を買い込み、様々な中世マニアや専門家と議論を重ねたのです。

2014年4月

実際にブロックのデザインが開始されました。しかしSpace Engineersでやらなくてはいけない事が沢山あり進捗はゆっくりとしたものでした。

2014年9月

作曲の作業が本格的に開始されました。

2014年9月

Medieval Engineersの開発が本格的にスタートしました。新たにアーティストとプログラマーがチームに加わり、構造に基づく強度の計算や破壊の表現に関する実験を開始しました。この時に私たちは「2015年の1月13日にゲームを公開する」という目標を立てたのです。

2015年1月13日（本日）

Medieval Engineersを発表しました。

2015年（未定）

Steamの早期アクセスプログラムで配信されます。

Space EngineersとMedieval Engineersはベースになるコードを共有しています。
必要な機能を持たせつつ要求する占有エリアを正確にする作業は大変な大仕事で私たちは数ヶ月の間オプションを繰り返しました（？）

破壊と構造に基づく強度の計算を表現するため、二つの異なるアプローチが取られました。一つはHavok Destructionで、もう一つはHavokを使う事で合意する前に書いていた私たちのアルゴリズムです（リアルタイムで動作し、大半の状況を適切に処理し、将来的にボクセル/地形をサポートできるものです）（？）
私たちは今もこのアプローチを完成させようと努力しています。

Medieval Engineersの作曲を担当しているのは――Miner Warsの音楽を作曲し、Space Engineersでも楽曲が使用されている――Karel Antoninです。
私たちは幾つもの中世の楽器と多数の国々の音楽様式を調査し、現代的でありながら中世的で勇壮な音楽を作る事に活用しました。
私はこの成果に非常に満足しており、あなた方もこれらの音楽を好きになってくれる事を願っています。

これからについて

Space Engineersについて私たちはいくつかの大規模アップデートを近く数ヶ月以内に用意しています――少しばかりヒントです：AI、本格的なキャンペーン、クリア目標、さらなる最適化や修正です。
私たちの開発計画に影響が出るとか変更があるのではといった心配は無用です。
私たちはSpace Engineersの毎週木曜の更新を続けます。Medieval EngineersをSteamの早期アクセスプログラムで公開してフィードバックを受けてからは、こちらも同様にアップデートして行こうと思っています――恐らく毎週火曜日になるでしょう。
しかし確実にやる、と確約するには少しばかり厳しい状況です。1つのゲームを毎週更新するというのも中々挑戦的なことですから、同時に二つのゲームを更新していくというのはまったくもって"やり過ぎ"（overkill）なのです――とはいっても、私たちは楽な道は好きではないのですが

私たちはSpace EngineersをXbox Oneに移植する作業も続けています。

Medieval Engineersの最初のリリース内容は"恐らく"ですがこのような物になるでしょう。

• クリエイティブモード
• Steam Workshopへの対応（SDK + API）
• ハイトマップを地形に変換するツール
• Space Engineersのプレーヤーの為に用意した特別プレゼント

マルチプレイとサバイバルはアップデートで追加する事になるでしょう。

私たちはSpace EngineersのコミュニティがMedieval Engineersのコミュニティを歓迎してくれることと、二つのコミュニティが合わさって一つの"Engineers"のコミュニティになることを望んでいます。
私たちはあなたがMedieval Engineersで作ってくれる物や、私たちを驚かせてくれることをとても楽しみにしています（丁度Space Engineersで私たちを驚かせ続けている様に）
未来は明るく、私たちの目の前には仕事が山のように積み上がっています。実に良いことです
もし私たちが作っているエンジニアリングゲームに興味がありそうな友人がいれば是非教えてあげてください。よろしくお願いします！

Medieval Engineers公式サイト: http://www.medievalengineers.com/

ここまで読んでくれてありがとう！ 私たちのゲームに関する最新のニュースはFacebookやTwitterで公開しています。フォローしてね！

Medieval Engineers（フェイスブック）: https://www.facebook.com/MedievalEngineers
Medieval Engineers （ツイッター）: https://twitter.com/MedievalEng
Space Engineers （フェイスブック）: https://www.facebook.com/SpaceEngineers
Space Engineers （ツイッター）: https://twitter.com/SpaceEngineersG

（補足）

※この項はMarek Rosa氏のブログ記事とは無関係です。
新たに複数のビデオが公開されていますのでここで紹介します。

• Destruction, Structural Damage
  破壊の様子を見ることができます。
  &flash(http://www.youtube.com/v/brSJlgPn0ZM,640x360);

• Lush Woodlands & Mountain Top Castles
  自動生成される自然とキノコと告知用動画に出てきた山城を見ることができます。
  &flash(http://www.youtube.com/v/ihbVtFB4iQs,640x360);

• Catapults, Gears & Winches
  ギアを使ったメカニックや、ウィンチを使ったカタパルト（投石機）を見ることができます。
  &flash(http://www.youtube.com/v/2aJ0EStunXI,640x360);

• Voxel Terrain Sculpting, Shape Your World
  新たに開発された地形変更ツールのボクセルハンドによる地形の変更を見ることができます。
  &flash(http://www.youtube.com/v/xK-QI6jZQM8,640x360);

• Developer Interview "Amazing"
  我らがMarek Rosa氏のインタビューを聞くことができます。映像はほぼ告知用動画の繰り返しです。
  &flash(http://www.youtube.com/v/GfOtooxsBAM,640x360);

概要

以前から私はSpace Engineersに"プログラミング"の機能を組み込むにはどうしたらいいかを考えていました。
今回はその設計書を公開してみたいと思います――もちろん確定ではない初期案ですが。
以下の内容は全て試験段階のものであることに留意してください。かなり予備的な内容であり、全てが変更の対象と成り得ます。

これは最初のデザイン案であり、実行に移す際にはより詳細に清書しなければならない物です。
（例えばGUIやHUDの仕様はもっと具体的にしなければいけませんし、プログラムのコピー＆ペーストはどのように機能するかを設計する必要があります）
この要素はMODではありません。プログラミングとHUDのカスタム機能は純粋なゲーム環境として追加される予定です。

プログラムはゲームの中で編集やコピー＆ペーストができ、更にマルチプレイで他のプレーヤーと共有することもできます――
例えば、あるプレーヤーが簡単なHUDプログラムを作り、チャットにコピー＆ペーストしたなら、他のプレーヤーは自身のHUDにそのプログラムを統合することができます。
同様のアイディアは全てのプログラムにも適応できます。しかし私たちはプログラムを作った経験のない人にも扱いやすい、もっとユーザーフレンドリーなバージョンも考えなければいけません。

終わりに、この機能はプログラミングを簡単にかつ楽しく学びたいと考えている人たちにとってすばらしい物になるでしょう！

プログラミング

プレーヤーはちょっとしたプログラムをコンピューターブロックかコンピューターコンポーネントで実行することができます。
この要素はゲーム環境に統合されるものでMODではありません。

コンピューターブロックとコンピューターコンポーネントについて

私たちが"コンピューターブロック"を作るとき、コンピューターブロックがプログラムを実行できる唯一のブロックになるべきなのか、他のコンピューターコンポーネントにもプログラムの実行を許可するべきなのか、私はまだ決めかねています。
（もし後から許可した場合、プレーヤーはドアやリアクターなどにプログラムを書く事になり、面倒なことになってしまうでしょう）

プログラミング言語について

私は主にセキュリティ上の理由からコンパイルが必要な言語（DLL）よりはインタプリタ言語、特にC#インタプリタが良いと思っています。
このインタプリタはオブジェクト指向のプログラミングがされるのが望ましく、またC#の基本的な要素全てや.NET、LINQ、ガベージコレクタなどもサポートされる予定です。

エディタについて

プログラムは（ブロックの設定を変えるように）コントロールパネルから編集できます。
忘れてはいけないのはいくつかのブロックは複数のコンピューターコンポーネントを所持できる点です。
プレーヤーは複数のコンピューターコンポーネントもしっかり区別できる仕様になる予定ですし、それぞれ別にプログラミングすることもできます。
またプログラムはON/OFFを切り替える事もできます。

ダメージについて

コンピューターコンポーネントが（動作する状態から）ダメージを受けて破損してしまった場合、プログラムは完全に消去されてしまいどのような方法でも復旧できなくなります。

実行について

これらの簡単なプログラムはピクセル/頂点シェーダーのようなものです。これらは"main"関数を持ち、画面の更新（毎秒60回）ごとに実行されます、
プログラムは変数/メンバ変数を持つことができ、更新と更新の間で値は変化しません――つまり変数は内部の状態を維持することができます。
これらの変数は他のコンピューターコンポーネントからもアクセスすることができます（デフォルトのPublic設定の場合）
それぞれのコンピューターコンポーネントはインスタンスとオブジェクトで、クラスではありません。

アクセスについて

プログラムは他のブロックやコンポーネントの属性やメソッドにアクセスする事ができますが、アクセスできるのは同一の船やステーションの中の物だけとなります。
無線通信についてはまだ策定されていません。
コンピューターは同一の船の中であれば他のブロックを名前で検索可能です。（例：GetByName(“rotor_on_the_left”)）

コードエディターの機能について

• 構文のハイライト機能
• 構文のチェック機能
• 提案ウィザード（例えばwriting a dotの後で有効なメンバ（変数？）を提案します）
• テキストのコピー＆ペーストや削除
• その他一般的なコードエディターの機能
• プログラムをBlueprintとしてコピーしておく機能（プログラムは特殊なタイプのBlueprintになります）

例外やエラーのハンドリングについて

（たとえば無効な数値やゼロ除算などで）エラーが発生した場合、インタプリタはプログラムの実行を停止し更新内容をスキップしますが、更新前の状態に戻すことはしません。
プログラムは次の更新時に再び動きますが、またエラーで止まるかもしれません。
エラーの情報は"プログラムデバッグウィンドウ"（スキームの上部に表示）に書き込まれます、しかしここにはランタイムのクラッシュやassert windowsは表示されません（Visual Basicの仕様を彷彿とさせる仕様ですね）

CPUの負荷とメモリに付いて

私たちはプレーヤーが無限ループを作成することを避ける必要があります。こうなるとプログラムは大量の計算を行い、大量のメモリを消費するなどします。これは起こりえるでしょうか？
私たちはネットワーククライアントが非常に複雑なプログラムを実行することを望んでいません。

プログラムの複製について

プログラムの内部から他のコンピューターコンポーネントかコンピューターブロックにコードをコピーしたり複製することができます（コードインジェクション）
つまりプレーヤーはウイルスを作れると言うことですヾ(*´∀｀*)ﾉ
（訳注：敵の防衛システムを狂わせるウィルスなどを作れる、という意味で実際にPCに危害を加えるウィルスは作れないと思われます）

クラスと継承について

実際のところ私はこれらの小さなプログラムはクラスであると考えています、しかし同一の物ではありません。
これは例を使って説明したいと思います。Door1とDoor2の2つのドアを持つ船を思い浮かべてください。
あなたはDoor1にプログラムを書いたとします。そしてまた別のプログラムをDoor2に書きました。
まだあなたがドアで作業しているにもかかわらず、あなたが書いた2つのプログラムは別々のクラスとして扱われます――つまり異なる属性や状態、メソッドなどを持つということです。

・コードの一例

public float some_state_variable = 10;
private float some_other_private_variable = 20;
void main(void) // このmain関数は毎秒60回実行されます
{
   var rotor1 = GetByName(“rotor1”);
   rotor1.Rotate(30);
   rotor2.Stop();
   var light1 = GetByName(“light1”);
   light.SetColor(255, 255, 0);
}

オブジェクトの例（コンピューターコンポーネントや属性、メソッド）

• 全てのブロックで使える基本のクラス
  • IsPowered() // 電力が今供給されているか？
  • IsEnabled()
  • 意味があるならブロックのインベントリにアクセスすることもできます。

• ドア
  • Open()
  • Close()

• ライト
  • 色 (光の拡散や反射なども設定できるかもしれません)
  • 半径（Fallow and other range parameters）
  • タイプ

• スラスター
  • AddForce() // スラスターに推力を発生させる、あるいは似たような事ができるように。

他のゲームにおけるプログラミングの例

CodeSpells

https://sites.google.com/a/eng.ucsd.edu/codespells/
http://www.kurzweilai.net/a-video-game-that-teaches-how-to-program-in-java

Colobot

http://colobot.info/wiki/CBot:Main/EN

Botlogic

http://botlogic.us/play

Programming games

http://programminggames.org/

Possible visual/text programming language

http://vvvv.org/

Computercraft

http://www.computercraft.info/

接近センサ

接近センサは新しいタイプのブロックで、他のブロックの上に（インテリアライトのように）貼り付ける事ができ、正面方向に円錐形のスキャン範囲を持ちます。
大型のセンサも小型の物も同じ見た目で、パラメータも同じです。

スキャンについて

センサは円錐形の範囲をプログラムの更新タイミング（毎秒60回）でスキャンし続け、いつでも物体を（1つ）感知し（動体か動かない物も――感知速度の閾値次第で）
何かを感知したことをきっかけにプログラムを実行することができます（on_detect() 関数は動体感知機のコンピューターコンポーネントの中で実行されます）

感知された物体について

この近接センサはあらゆるタイプの物体を感知します――自身の所属する船のブロック、小惑星、鉱石、小さなアイテム、動いているドア、プレーヤー、ローター、有効なスラスター……もしかするとパーティクルエフェクトまで感知するかもしれません。
インスピレーション元：http://en.wikipedia.org/wiki/Proximity_sensor

パラメータについて

感知距離

0～300メートル（注記：パフォーマンスへの影響が無視できないレベルだった場合、短くなる可能性があります）

角度

最大180度（訳注：センサーを真横から見たときの平面角。実際の範囲は立体角で最大2πステラジアン（半球）になると思われます）

スキャンエリアへのレーザー照射

『Miner Wars』のscannerのように、半透明の赤いポリゴンで感知範囲をみる事ができるようになります。

速度の閾値（実装が簡単な場合のみ）

0にした場合は動かない物体が感知され、0より高い場合は閾値よりも高い速度で動く物体が感知されます。

視覚信号のtrue/false切り替え

trueの場合は何かを感知したときにセンサーが点滅します。

電力消費

スポットライトよりは少しだけ高くなります。角度や距離の設定によって変化します。

3Dモデルについて

半球状のシーリングライトから着想を得ました。

HUDのプログラミング

このアイディアは"ブロックプログラミング"ととてもよく似ています。コードを書かずに簡単なプログラムをブロックの中で動作させるものです。
HUDプログラミングは簡単なプログラムを書き、HUDの中で動作させます。プログラムはディスプレイに出力され、プレーヤーのHUDに表示されます。

HUDプログラムは以下のようなプレーヤーがアクセスできる情報のみを読み書きすることができます。

宇宙飛行士の情報

ヘルス、エネルギー、速度など。常に有効です。

船とステーションの情報

コックピットに座っている時に有効です。ターミナル/コントロールパネルにアクセスしている間も有効ですがGUIスクリーンの下に表示されてしまうためHUDを見ることはできないでしょう。

遠隔

ワイヤレス通信が追加された後の事になりますが、プレーヤーは宇宙船やステーションから離れているときも「通信」することができるようになります。

現在のHUD

これまでキャラクターや船の速度、エネルギーなどパラメータの表示について話してきましたが
私たちはまず現在のHUDをカスタマイズ可能なプログラムへと書き直す必要があります。
これは恐らく難しい仕事ではないでしょうから、この機能の使い方について説明していこうと思います。

GUIとHUD

私の考えるGUIとHUDの違いは、（セーブやメインメニュー、オプションなどを表示する）GUIはゲームの世界を構成する要素ではなく、HUDはゲームの世界の一部であるということです。

HUDプログラムの保存場所について

HUDプログラムはワールド毎のプレーヤー毎に保存されます。（つまりワールドファイルのプレーヤーデータに保管されます。もちろんマルチプレイヤーでも）
例えば、あるプレーヤーが自作のCoolなHUDを他人のDedicatedサーバーに持ち込みたいと考えた場合、
プレーヤーは新たにコードをコピー＆ペーストすることで使う事ができるようになります。

CPUとメモリについて

HUDプログラムはプログラムの更新タイミング（毎秒60回）で実行されます。プログラムの構造に制限はありませんから、ひたすら複雑に記述することもできます。
――もしプレーヤーがエラーのあるプログラムを実行してしまった場合、そのプレーヤーのPCのパフォーマンスのみが低下するでしょう。

エラーとデバッグについて

エラーが発生した場合は無視されるためクラッシュすることはありません。またエラーメッセージはHUDに表示されるため、問題があった場合プレーヤーは即座に確認することができます。

コードの一例

public float some_state_variable = 10;
private MyGuiSlider slider1;
private MyGuiLabel label1;
// init関数はHUDが読み込まれた時か、プログラムに変更があった場合のみ開始されます
void init()
{
   slider1 = new MyGuiSlider(...position...default color...etc);
   label1 = new MyGuiLabel(...position...default color...etc);
}

// main関数は毎秒60回の更新タイミングで開始されます。
void main(void)
{
   GetByName(“player character”).Color = slider1.Value * 100;
   label1.Text = MyUtils.GetFormattedFloat(slider1.value, 2);
}

編集について

HUDプログラムにはターミナル/コントロールパネルに新たに追加される「HUD」タブからアクセスすることができます。
プレーヤーはここで起動している全てのHUDを確認したり、位置を調整したり、ショートカットキー（Shift+F1など）などを設定できます。

フォーカスについて

HUDスクリーンに表示されている物はプレーヤーがショートカットキーを押すまでは、キーボードやマウスで選択することができません。
ショートカットキーを押した後はHUDスクリーン以外の全てが暗く表示され、プレーヤーはHUDスクリーン上の（スライダーなどの）GUIを操作することができるようになります。
この状態から復帰するにはショートカットキーをもう一度押すかESCキーを押します。

GUIについて

HUDプログラミングでは基本的なGUIの要素全てを使用することができます。
例えばテキストボックスやスライダー、ラベル、ボタン、コンボボックスなどが使用可能です。

終わりに

よければあなたの提案などをコメントしてください（訳注：コメントはこちらから英語でお願いします。）
全てのコメントに返信をすることはできませんが、できる限り全てのコメントに目を通し、Space Engineersの開発の参考にする事を約束します。

補足

フォーラムでも議論を行っています。参加したい方はこちらのトピックからどうぞ。

• 過去スレ
  http://forums.keenswh.com/post?id=6786260
  http://forums.keenswh.com/post?id=6925004

Thanks!
Marek Rosa