(ドワーフ要塞のような)ブラウザでアスキーマップとキャラクターを移動するための優れた技術的ソリューション?[閉まっている]


10

私のゲームのWebサイト用に、テキスト文字を使用して動物と人を表すWebアプリケーションを作成し、独立した(サーバー主導の)AIを使用してマップスクエア上を移動させたいと思います。

つまり、基本的には、ブラウザ内の小人-要塞マップです。 ドワーフ要塞の例 移動する生き物、mob、npcs、およびpcsがあります。私がこの規模を達成するつもりはないというわけではありませんが、いつでもこのコンテンツの4分の1程度を表示し始めるでしょう。

おそらく一部の背景/固定タイルが静的に読み込まれる可能性があります。しかし、生き物/動物や動くことができるものについては、どのテクノロジーソリューションが最も効果的であるかわかりません。

<canvas>その機能がこのユースケースに適合するかどうかはわかりませんが、私は知っています。確かに、ある程度のJavaScriptが必要になるでしょう。

このユースケースに適合するJavaScriptライブラリまたはキャンバスライブラリはありますか?私が気づいていない別のテクノロジー?これに類似したことをしたウェブサイトの例を知っている人がいるので、私はそれらからアイデアを集めることができますか?


1
rot.jsを見てみましょうondras.github.com/rot.js/hp
Alayric

まあ、rot.jsはまさに私が探していたものかもしれませんが、それを知りませんでした。
Kzqai 2013年

回答:


5

私は実際にWeb用の文字表示ライブラリUnicodetiles.jsを作成しました。これは、最適化に時間を費やしただけでなく、テキストを表示するさまざまな方法も検討しています。3つのレンダラーがあります。

  1. <div>要素のマトリックスを使用して、各グリフをカスタマイズ可能な前景色と背景色でレンダリングするDOM 。
  2. <canvas>要素を使用して文字を描画するキャンバス。これははるかに高速であり、それをバックアップするパフォーマンステストがあります:http : //tapiov.net/unicodetiles.js/tests/
  3. WebGL。canvas-elementを使用してフォントテクスチャを作成し、WebGLを使用してレンダリングします。WebGLはさらに高速で、大きなビューポートサイズに非常にスケーラブルですが、ブラウザーではサポートされていません。

リンクされたパフォーマンステストはかなり極端な場合があり、フレームごとにすべてのキャラクターを変更することに注意してください。実際には、DOMレンダラーでさえ、ほとんどの目的で十分高速です。

独自のライブラリを作成することを決定した場合でも、キャンバスの使用が推奨されます。これは、パフォーマンスが向上し、より大きなシーンを許可するためです。WebGLのみを使用すると、ユーザーベースが制限され、実装が複雑になります(Unicodetilesには自動フォールバックメカニズムがあります)。


最近よく聞いた別のライブラリーはrot.jsです。たとえばFOVシステムやダンジョンジェネレーターが付属しているため、特にローグライクを対象としています。完全なパッケージが必要な場合は、これで十分です。


いいね。使用できます。あるいは、少なくともローグライクのようにではなく、ローグライクのようにしたいので、誰かが自分のアプローチを知らせるためにそれを行った方法から学びます。:D
Kzqai

@Tapioユニコードタイルでパックマンを実装しようとしていますが、問題はプレイヤーが常にマップの中央にあることです。パックマンにとっては望ましくありません。何らかの方法でそれを無効にできるか、またはプレイヤーを指定せずに回避できます。
user3995789 2014年

6

最も効果的な方法は、それを偽造することだと思います。通常の2D画面をレンダリングする場合と同じように、独自の組み込みスプライトフォントを使用してターゲット要素にレンダリングします。このアプローチにより、フォントが見つからない場合や非常に異なる言語(中国語、ロシア語)を使用している場合に、奇妙なことが起こりません。

フォントとテキストは、すべてのブラウザーのすべてのロケールでピクセルを完璧にするのが最も難しいものの1つです。フォントを埋め込み、CSSマジックブラウザーを使用している場合でも、使いやすさの設定によってフォントが上書きおよび変更される可能性があります。通常のウェブサイトの場合、ピクセルパーフェクトテキストは問題ではありませんが、ドワーフフォートレスなどのゲームでは、いくつかのピクセルが非常に一貫性のないビューにつながる可能性があります。ブラウザではなく通常のアプリケーションを使用している場合でも、テキストのレンダリングに問題があります。したがって、ドワーフフォートレス自体も、私が説明したアプローチを使用しています。

http://en.wikipedia.org/wiki/Dwarf_Fortress

画面上のディスプレイは、ビットマップとして実装された16の異なる色でコードページ437の文字をわずかに変更して、OpenGLでレンダリングします。

編集:私はいくつかのコメントを得たので、私は答えを少し拡張しました


他の言語は、ASCIIの置き換えではなく、拡張ではありませんか?通常のテキストを含むWebサイトが「偽物」にならないのはなぜですか?
Anko

1
ほとんどの文字エンコーディングの問題は、UTF-8エンコーディングを使用することで防ぐことができます。
フィリップ

ロシア語のフォントはASCIIとは異なり、中国語はさらに異なります。通常のWebサイトは、可変サイズのグリフ、カーニング、テキストの適切な「フロー」などを含む美学を重視しています。DFのようなゲームは、Webブラウザーで確実に実行できない文字の定期的な配置を重視しています。
Liosan 2013年

1
@Liosan確かにできる。CSS宣言font-family:monospace;を使用するだけで、Webブラウザーはデフォルトの等幅フォントを使用します。
フィリップ

これが組み込みのCSSモノスペースファミリWebフォントと比べてどのように役立つか、実際にはわかりませんか?つまり、レンダリングに時間がかかりますが、間隔の問題をより確実に解決できるようになりますが、CSSフォントが埋め込まれているので、ユーザーがフォントを見逃したり、別の言語を使用したりしても問題はありませんか?埋め込みWebフォントの文字セット、hmmmだけに操作が制限されると思いますが。
Kzqai 2013年

3

出力する必要がある行と列の数を見つけるには、ウィンドウの幅と高さを確認し、それに応じて変更する必要があります。onResizeイベントをリッスンし、それに応じて幅と高さを変更することを忘れないでください。

あなたはこのテキストの方法をしたい場合は、各セルは一つの文字が含まれている場合は、あなたは、モノスペースフォントとテーブルと、この使用してテキストを行うことができます。

個々の文字をアドレス指定するに<table>は、正しい数の行と列を使用してを作成します。それぞれに<td>は、x座標とy座標で構成されるIDがあります。このようにして、IDで個々のセルをアドレス指定し、innerHTMLを変更して文字を変更し、cssクラスを変更して色を変更できます。

ただし、置き換える必要のある文字ごとに大きなDOMツリーを操作する必要がないため、キャンバスを使用した方が高速になる場合があります。ちなみにドワーフフォートレスも同じようなことをしています。オブジェクトを表すために使用される文字は、実際のテキスト出力ではなく、実際にはビットマップであり、2DグラフィックAPIを使用して描画されます。HTML5キャンバスは、これを十分に備えています。それは持っていcontext.fillTextのキャンバスの上にテキストを描画することを可能にする方法を。これは、個々の文字を描くために使用できます。あなたは、変数の操作によってサイズやフォントの顔を変更することができますcontext.font呼び出すことで、それぞれの文字の色をcontext.fillStyleを

フォントのラスタライズは高価であり、私が知っているどのブラウザもキャッシュを使用していないため、フレームごとに数百回fillTextを呼び出すと遅くなる可能性があることに注意してください。つまり、同じ文字を同じ設定で100回レンダリングすると、100回再ラスタライズされます。パフォーマンスを向上させるには、非表示のキャンバスに各色で各文字のラスタライズされた外観をキャッシュし、context.drawImageを使用してこれらの非表示のキャンバスを描画します。あるキャンバスから別のキャンバスへのコピーは、通常、フォントのラスタライズよりもはるかに高速です。

私は現在キャンバスを使用して2Dゲームを開発していますが、最大のFPSイーターがフォントの描画であることに気付きました。ラスタライズされたテキストのキャッシュを追加すると、パフォーマンスが大幅に向上しました。


ビットマップフォントも真のテキスト出力です!いつもターミナルで使っています。また、キャンバスの方が速い場合、StackExchangeのテキストレンダリングはキャンバスベースではないのはなぜですか?
Anko

いまいましい、そのためのライブラリを書いてみたい。
フィリップ

@Ankoターミナル!= Webブラウザ。正確にどのテキストレンダリングを参照していますか?
フィリップ

1
Ankoは、ビットマップフォントはTrue-Textであるため、ターミナルで使用できると述べています。これにより、ビットマップフォントがTrue-Textであることが証明されます。
Polar

0

わかりました、これは暗闇の中での刺しであり、それがどのようにレンダリングされるのかわかりません。

基本的には、昔と同じトリックコンソール(別名ターミナル)を使用します。最初に、等幅フォントから始めます。N文字のM行があります。したがって、テキストを十分な幅のdiv(幅:N em?)にダンプし、N文字ごとに改行を入れます。この場合、の<br/>代わりに\n

トリックは、バッファを文字ごとに、またはコンテンツ全体を一度にJavaスクリプトで置き換えることです。

本当に具体的にしたい場合は、@ font-faceを使用して、すべての場所で同じ等幅フォントを使用できます。


私もそうすることを考えましたが、個々のキャラクターの色と背景色を制御したい場合、それは良いアーキテクチャではないことに気付きました。
フィリップ

0

グリフの観点から考えます。テキストの表示をその背後にある意味から切り離します。例えば:

(疑似コード)

if (display.hitGlyph)
    glyph = Glyph.Asterisk;

display(glyph);

そして、グリフアトラスを定義するための基礎となるコードで、次のようにします。

Glyph.Asterisk = "*";

グリフアトラスは、実際にはさまざまなエンコーディングを使用したASCIIテーブルへのルックアップです。ここでのポイントは、何を表示するか、何を表示するかを区別することだけです。最初からフレームワークを作成することをお勧めします。それはあなたにもっと自由を与えるでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.