3

私は、ユーザーが可能な限り変更およびカスタマイズできるようにするプロジェクトに取り組んでいます。

オープンソースは良い選択かもしれませんが、いくつかの内部クラスを閉じたままにしておきたいという事実のためではありません。

私が考えた他の2つのオプションは、外部ライブラリとしてのプラグインとLuaスクリプトです。

ライブラリ（DLL）の問題は、クロスプラットフォームの互換性が必須であるということです。これは、ある種のゲームサーバーであり、主に専用サーバー（多くの場合、Linux）で使用するように設計されていますが、多くの人がローカルマシン（主にWindows）。

ゲームのパフォーマンスに関連する多くの接続とアクションを処理できる必要があるのはゲームサーバーアプリケーションであるため、Luaスクリプトには疑問があります。

私の疑問は合理的ですか、それともLuaは良い解決策でしょうか？また、私の懸念のためにもっと良い/他のオプションを考えることができますか？

重要な側面を要約すると：

  • クロスプラットフォームの互換性
  • 良いパフォーマンス（->オンラインゲーム）
  • 言語について知っている限り誰でも作成できるプラグイン/スクリプト、Lua、Cなど
  • クローズドソースプラグイン/スクリプトのオプション（それほど重要ではありませんが、問題ありません:)
4

3 に答える 3

5

Luaがあなたにとって十分に速いかどうか答えることができるのは、あなただけだと思います。正確に何をしているのか、どのように実装しているのかわかりません。私の提案は、プロトタイプを作成して測定することです。LuaとC/C ++の両方でシステムの小さいが関連性のある部分を記述し、両方のパフォーマンスを測定して、Luaが十分に高速であるかどうかを判断します。ケーススタディとしてWoWを使用すると、Luaはゲームのクライアント/ UI部分に対して十分に高速であるように見えますが、サーバーについては何も言えません。しかし、とにかく、Luaと比較してより速く簡単に埋め込むことができる言語があるとは思えません（免責事項：Luaのパフォーマンスを自分で測定したことはありません。特に、他の同様の言語に対しては測定していません。したがって、これを一粒の塩で取ってください）

クロスプラットフォームではないDLLについて何かおっしゃっていますが、参考までに、プラグインにDLLを使用して動的にロードする場合は、Linuxにも同じ機能があります。「DLL」は「共有ライブラリ」または「共有オブジェクト」と呼ばれ、通常は.soの拡張子が付いています。また、WindowsのLoadLibrary、GetProcAddress、およびFreeLibraryの代わりに、 dlopen、dlsym、およびdlcloseがあります。

于 2009-10-23T08:40:55.697 に答える
2

アプリケーション内のさまざまなモジュールにさまざまなライセンスを提供することを止めるものは何もありません。明らかに、GPL 3を使用すると、すぐにすべてがカバーされるため、使用できなくなります。

于 2009-10-21T15:14:48.080 に答える
1

AngelScriptについて考えたことはありますか？私もそれについてはよくわかりませんが、C ++のような構文を持っているようで、かなり柔軟性があり、非常にクロスプラットフォームです。

于 2009-12-06T22:59:06.883 に答える