What kind of language should I design for a particle engine scriptable engine?

Question

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)

Answer 1

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!-)