In the same manner, most game developers would not particularly mind whether an engine uses inheritance or composition for the model of game entities, provided that their game was not hindered by the approach (neglecting personal preference).
I agree here!
Oh dear. No.
Let’s try to put this in more familiar terms for you: Assume you’re developing a network multiplayer server, and you have version 0.1. You call your program a “server”, because it provides a certain set of features that are typical of a server. For v0.2, you change the implementation drastically, but the interface remains the same, and the server still provides that crucial set of features, without which the system couldn’t function in a server role.
So, how can details of implementation define the overall concept of a particular system, if any one system type can have a wide variety of implementations?
Entities (or game objects) need to have an implementation, but that doesn’t make the notion itself an implementation.
Specific types express specific capabilities (and properties) of a particular object idea; those capabilities are not reflective of any one specific implementation, because any one capability can be implemented in a number of different ways.
I would argue that yes, there is nothing stopping you, but that does not mean it’s sensible. Otherwise, we wouldn’t bother with the notion of a particle.
I don’t see how “the notion of a particle” relates to the sensibility of my particular implementation.
You have yet to explain that.
I suspect in part that this derives from the fact that most are more concerned with the implementation and [or] what particles provide rather than the philosophical argument of what they represent.
People who actually have to implement features are concerned with the implementation, of course, but I’ve never heard any of them claim that particles are defined by the details of their implementation.
I suspect in part that this derives from the fact that they are sensible people.
Also, I feel it’s relevant to note: You started the “philosophical argument”, by claiming, essentially, that an entity can not really be a particle … even though it can be … but not really … but it is … but not truly … even though there’s nothing stopping you … but it wouldn’t be sensible … because particles …
It’s entertaining (for me at least) to watch someone struggle to bake that pretzel, but it’s certainly not something that I placed in the oven. 
In the same manner, most game developers would not particularly mind whether an engine uses inheritance or composition for the model of game entities, provided that their game was not hindered by the approach
And that’s exactly why they wouldn’t mind if particles are implemented as entities, provided they can be used to produce the desired effects, at the target framerate.
You would be the only person to argue something like: “Well, even though they look and behave exactly like particles, these are not really particles, because they’re implemented as entities, and not in the specific way that I think defines particles … because I feel strongly about this”.
In this example, we’re considering implementation details as part of a provided API, i.e the getter methods for positioning, which may use different transformation libraries etc. That is indeed the whole point of providing an interface, and yes, that’s not a cause for concern.
I refer to implementation details in the sense that the entire game-engine design is fundamentally based upon separating what we consider at a higher level as “an object” into constituent sub-objects. In real terms, a lamp is no different from a book, except that it has different properties, but these are not discrete as they are represented in the game engine world. So, indeed “Oh dear, no” would be a correct response to misunderstanding of the very point of “implementation details” and their higher-level irrelevance, but not in this case.
Entities (or game objects) need to have an implementation, but that doesn’t make the notion itself an implementation.
Specific types express specific capabilities (and properties) of a particular object idea; those capabilities are not reflective of any one specific implementation, because any one capability can be implemented in a number of different ways.
I don’t see how “the notion of a particle” relates to the sensibility of my particular implementation.
You have yet to explain that.
The notion of a particle is a purposeful one, as a lamp or a camera is. In simple terms, a particle is distinct from an entity because it does not require the more “complex” components such as mesh deformation, physics processing (beyond simple newtonian), parenting relationships, input handling …, that entities are typically demanding of. A particle exists within a particle system, which bypasses the majority of entity domain-specific systems.
You can manually deform a mesh by moving individual vertices, but it doesn’t mean that we choose to do so, one uses armatures.
Also, I feel it’s relevant to note: You started the “philosophical argument”, by claiming, essentially, that an entity can not really be a particle … even though it can be … but not really … but it is … but not truly … even though there’s nothing stopping you … but it wouldn’t be sensible … because particles …
It’s entertaining (for me at least) to watch someone struggle to bake that pretzel, but it’s certainly not something that I placed in the oven.
Indeed, the philosophical argument is interesting. I attempt to stress the fact that no level of separation denies the fact that one thing may be like another if you look hard enough. It doesn’t mean we should consider them alike by such efforts.
An entity certainly cannot be a particle, but the notion of a particle may be mimicked using entities. This does not, however, make it so.
And that’s exactly why they wouldn’t mind if particles are implemented as entities, provided they can be used to produce the desired effects, at the target framerate.
You would be the only person to argue something like: “Well, even though they look and behave exactly like particles, these are not really particles, because they’re implemented as entities, and not in the specific way that I think defines particles … because I feel strongly about this”.
In cruder terms, the situation is thus; A wolf in sheep’s clothing is still, unfortunately for the rest of the flock, a sheep. However, as long as it behaves as the others do, neither the shepherd nor the flock need believe there is a difference. But, to say that that wolf would be a sheep, would be a falsification.
I don’t particularly care/mind about the implementation of particle systems at this point, given that I’ve yet to examine the API and performance of Entity-based particles and particle systems. I’m guessing there’s some things you can assume with particles that you can’t assume with standard entities that would net you a performance gain when rendering a large number of them. These are things like all particles of an overall system sharing the same texture, shape, and behavior, or particles always facing the active camera. I’m guessing, again, that there’s a reason why handling thousands of particles is something certain engines can do, while it’s not really an option in Blender using Python to script the particles’ behaviors (for example).
If these particle-friendly options can be implemented at no speed drop as standard Entity options, then the implementation doesn’t really matter to me at the moment. AFAICT, the only things a developer cares about when dealing with how something runs under the hood would be convenience and optimization. So on the subject of convenience, what do you think about implementing particle systems that can be customized through Blender? Do you consider it worth it?
In “real terms”, only one can be turned on, to illuminate nearby geometry.
The notion of a particle is a purposeful one, as a lamp or a camera is.
And just like the notion of a lamp, or a camera, the notion of a particle is not defined by details of implementation.
because it does not require
It is also not defined by requirements, because those can vary, based on the goals of the project.
A particle exists within a particle system, which bypasses the majority of entity domain-specific systems.
Where and how a particle exists in the system, and which subsystems it is set to leverage, are details of implementation.
It doesn’t mean we should consider them alike by such efforts.
I didn’t argue that particles are exactly the same as, or even similar to generic entities. I argued that they could be implemented as entities.
An entity certainly cannot be a particle
Yes, it can, because the concept is not defined by details of implementation.
but the notion of a particle may be mimicked using entities
By your reasoning, your idea of a “real particle” can also be labeled as mimickry, simply by comparing its implementation with a lower-level, and better performing implementation, that has even fewer base requirements.
One could always cut down to something smaller/faster, and label everything above as “not quite real”.
to say that that wolf would be a sheep, would be a falsification.
Fat sheep are not wolves.
Customized in which way?
Just like how you can create meshes in Blender and press P to have them display in BDX, you could create particle systems in Blender and press P to have them display (or have them in memory to load and start via code or something) in BDX.
I have nothing against a built-in particle system, but I probably wouldn’t be using it myself for the same reason mentioned here. If I were Goran and would eventually decide to add a built-in particle system for BDX, then I would have to make sure it’s a standard model so users wouldn’t generally have the desire not to use it. I think you could compare it with the Vehicle Wrapper of the BGE. It’s good that it is implemented, and also it’s not. Because for some users it’s missing some basic features, for others it’s to complex. Anyway, if most users would decide to make their own implementation of an entity, that would mean the built-in feature is incomplete/unsatisfactory. And no BGE/BDX/… developer wants that. So I can understand Goran completely why he’s opposed to the idea of adding a built-in particle system to BDX.
What a strange discussion! Instead of the upcoming BDX engine… But a feature yet to come.
EDIT: Never mind.
As I mentioned earlier, you can write an efficient particle system in libGDX (instanced, camera aligned quads), and that would get drawn within the scene geometry that BDX draws.
I doubt it’s on Goran’s list of features, but in the future I could see someone extending BDX to take relevant properties from Blender’s particle system and export that into the scene file to be set up in libGDX.
I think the important thing to understand is that libGDX lets you work pretty ‘close to the metal’ with openGL and java, and BDX’s source will be open. 
Absolutely.
However, until there is a significantly large group of BDX users, who are having performance issues, I don’t think there’s a need to complicate the system.
I doubt it’s on Goran’s list of features, but in the future I could see someone extending BDX to take relevant properties from Blender’s particle system and export that into the scene file to be set up in libGDX.
Right, I don’t think it’s really that crucial at this point.
For now, one could simply write some logic for an empty, to emit various particles along a particular axis, or something like that.
Well, it’s not so much about usability, as it is about overall system complexity, and being able to keep it under control while still providing the most essential features.
… I think a lot of people have very inflated notions about what they actually need, which are in pretty stark contrast to what they’re actually able to utilize.
Well, to be more correct, agoose77 is trying to argue that, unless implemented in some specific way, particles are not really particles … “Strange” is certainly one way to describe that. 
I apologize. I may have understood it differently, but for what it’s worth, I can see your argument about complexity just the same.
And in the future if someone would want to take the challenge of developing a well-designed built-in particle system for BDX I’m also glad you’re not against that.
So, any progress?
I wonder if your goals overlap with blend for web. It seems like HTML five is becoming (or has become) essentially the cross platform way of writing programs for mobile.
So how’s development going on this, Goran? Make any headway?
There were some setbacks.
I wrote BDX to use Ant for desktop builds, because, at the time, the existing libgdx Gradle setup was far too slow. There was some trouble in getting that to work reliably, cross-platform, so it took more time than I expected. Eventually, I managed to make it work, but then, after updating my packages to the latest version of libgdx, the build broke. It was something that I could have fixed, but while testing the new libgdx version, I discovered that Gradle builds were now actually decent, in terms of build-speed, so at that point, all my previous Ant work was essentially for nothing.
After that, I couldn’t bring myself to work on BDX for a while.
I just started getting back into it this week, and I made some decent progress on the blender add-on, but there’s still a whole lot of work to do in BDX itself.
… I’ll probably have to cut down on my original vision for v0.1, but either way, I intend to push through.
^ Aw, that’s unfortunate. I know it can be annoying when your tools don’t work effectively for you when you’re already trying to deal with the process of creation itself. It’s great that you’re willing to keep up development, though! Gotta keep that determination up and not work too hard and get burnt out.
Awesome work so far, however I have some questions:
Did you read through the thread and watch the first video?
BDX uses LibGDX to render and is written in Java. The Java source files seem to be external to Blender. The blend file doesn’t seem to be “exported”; pressing a specific keypress / choosing to start the engine seems to read the blend file in to BDX and start the engine (like how the BGE starts with a keypress).
I would assume so, as it doesn’t appear anything to do with the engine actually works in Blender. The engine appears to appear in a separate window, so I’m sure there will be a method to export it to an executable / set of files that you can run separate from Blender once you finish a game project.
I believe so. Otherwise, what logic was he talking about? He mentioned the logic brick system is deeply flawed, so I’d assume no logic bricks are going to be passed through to BDX. So, this would be a purely Java code-based engine until someone chooses to add the ability for nodes or logic bricks to be read (assuming someone wants that).
Just to clear up the relationship between Blender and BDX:
The BDX blender add-on will provide you with the means to create a BDX project, which is just a modified LibGDX project, which is completely independent from blender (in terms of what’s actually required to program, build, and subsequently run the project on a supported platform).
As part of the creation process, the add-on will create a blender directory in the BDX project root. If a .blend is opened from that directory, the add-on will present the following:
In detecting the previously created project, it will offer the option to export and run, which you can activate by clicking the button, or by mapping the desired shortcut key to that operator, and pressing that.
The export process creates .bdx files for relevant blender scenes (SceneName -> SceneName.bdx), and those files define all data that BDX will be able to access at run time.
In short: blender is just a generation tool for data used by an external engine (BDX in this case).