我应该为粒子引擎可编写脚本的引擎设计什么样的语言？
我想知道哪种表达方式适合用于生成粒子效果的语言。 假设希望引擎尽可能灵活，它应该具有什么样的“功能”？ （除了颜色、位置、速度、加速度等琐碎的因素）
I was wondering which kind of expressiveness fits a language used to generate particle effects..
Supposing to want an engine as flexible as possible what kind of 'features' should it have? (in addition to trivial ones like color, position, velocity, acceleration)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所以每个人都敦促你不要重新发明轮子，这是一个好主意，我对 Python 情有独钟（它允许你的脚本用户也安装和使用大量其他有用的数学库和 c），但 LUA 毫无疑问甚至更容易集成（毫无疑问，Ruby 等其他脚本语言也可以）。 不编写自己的临时脚本语言是极好的建议。
但是阅读你的问题向我表明，你的问题更多的是——我的引擎对象的哪些属性（以及哪些对象——粒子，当然，但是，除此之外还有什么）我应该暴露给我所使用的任何脚本语言（或者，比如通过 MS COM 或 .NET，到我的用户喜欢的任何脚本或非脚本语言）？
每个粒子的特定属性（例如您列出的那些）无疑是值得的。 除了点状粒子之外，您的引擎中是否还有其他东西，例如表面和其他非点状实体，粒子可能会反弹？ 吸引力或排斥力又如何呢？ 你的粒子可能有角动量/自旋吗？
一个好主意是使粒子的属性“expando”，用一个流行术语（其他对象模型以不同的方式表达相同的想法）——根据使用引擎的应用程序，其他程序员可能决定向粒子添加任何属性他们需要……也许是质量，比如说——也许是电费——也许是欧分成本，据你所知或关心；-)。 与仅提供“粒子 ID”（当然您应该这样做；-）相比，这使您的用户的生活更轻松，以便他们在哈希表等中使用以跟踪他们关心的特定属性！ 允许他们添加“方法”和“触发器”（当某些条件成立时自动调用的方法，例如两个粒子比特定距离更近）会很棒，但可能有点困难。
顺便说一句，不要忘记允许一个好的方法将粒子系统的当前状态（包括用户添加的扩展属性）“快照”到指定的流或文件并从这样的快照中恢复 - 这在许多情况下绝对是至关重要的用途。
除了特定的粒子（以及可能的其他对象，例如表面，如果有它们）之外，您可能应该拥有一个具有自己的属性（包括扩展属性）以及理想的方法和触发器的“全局环境”。 例如，力场作用于所有粒子，具体取决于它们的位置（也许还有它们的电荷、质量等……！-）……
希望其中一些想法会让您觉得有趣——我很难说，因为几乎没有您的预期应用领域的想法！-)
SO everybody's urging you not to reinvent the wheel and that's a great idea, I have a soft spot for Python (which would allow your scripting users to also install and use plenty of other useful math libs &c), but LUA's no doubt even easier to integrate (and other scripting languages such as Ruby would also no doubt be just fine). Not writing your own ad-hoc scripting language is excellent advice.
But reading your question suggests to me that your issue is more about -- what attributes of the objects of my engine (and what objects -- particles, sure, but, what else besides) should I expose to whatever scripting language I ember (or, say via MS COM or .NET, to whatever scripting or non-scripting language my users prefer)?
Specific properties of each particle such as those you list are no doubt worthwhile. Do you have anything else in your engine besides point-like particles, such as, say, surfaces and other non-pointlike entities, off which particles might bounce? What about "forces" of attraction or repulsion? Might your particles have angular momentum / spin?
A great idea would be to make your particles' properties "expando", to use a popular term (other object models express the same idea differently) -- depending on the app using your engine, other programmers may decide to add to particles whatever properties they need... maybe mass, say -- maybe electric charge -- maybe cost in eurocents, for all you know or care;-). This makes life easier for your users compared to just offering a "particle ID" (which you should anyway of course;-) for them to use in hash tables or the like to keep track of the specific attributes they care about! Allowing them to add "methods" and "triggers" (methods that you call automatically if and when certain conditions hold, e.g. two particles get closer than a certain distance) would be awesome, but maybe a bit harder.
Don't forget, BTW, to allow a good method to "snapshot" the current state of the particle system (INCLUDING user-added expando properties) to a named stream or file and restore from such a snapshot -- that's absolutely crucial in many uses.
Going beyond specific particles (and possibly other objects such as surfaces if you have them) you should probably have a "global environment" with its own properties (including expando ones) and ideally methods and triggers too. E.g., a force field acting on all particles depending on their position (and maybe their charge, mass, etc...!-)...
Hope some of these ideas strike you as interesting -- hard for me to tell, with little idea of your intended field of application!-)
不要尝试仅为您的应用程序设计一种新语言，而是在其中嵌入另一种成熟的语言。 看一下它给其他尝试实现自己的脚本语言的应用程序造成的混乱（mIRC 就是一个很好的例子）。 这意味着用户必须学习另一种语言才能编写您的应用程序脚本。 此外，如果您设计自己的语言，它最终可能不如其他语言有用。 不要尝试重新发明轮子。
你可能想将 Lua 视为它是轻量级的、流行的、成熟的、被设计用于游戏（它的用户包括 EA、暴雪、Garry's Mod 等），并且有一个非常小的核心库（它被设计为一个模块化语言）。
Don't try and design a new language just for your application, instead embed another, well-established language in there. Take a look at the mess it has caused for other applications trying to implement their own scripting language (mIRC is a good example). It will mean users will have to learn another language just to script your application. Also, if you design your own language it will probably end up not as useful as other languages. Don't try to reinvent the wheel.
You might want to look at Lua as it is light-weight, popular, well-established, and is designed to be used by games (users of it include EA, Blizzard, Garry's Mod, etc.), and has a very minimal core library (it is designed to be a modular language).
只需嵌入 Lua 即可。 它是一种很棒的语言设计，性能出色，被游戏开发者广泛使用，而且足够小，您可以在几天内掌握它。
然后你就可以继续你的游戏设计了。
Just embed Lua. It's a great language design, excellent performance, widely used by game developers, and small enough that you can master it in a few days.
Then you can get on with your game design.