So Comet is now in its third version.
Like many systems, ECS work okay in theory but there are often problems in practice. One of the problems is the conceptual idea that components should be very basic, data only.
The problem with this sort of concept is it works okay up to a point, but if you want something as a dedicated component which does a lot you end up with umpteen systems to handle it.
I experimented with this in v2, which had a joystick control component (touch one), that you could just plug in and it worked as if it was (say) a square in Corona. All you had to do was something like:
spriteEntity:addC("joypad")
But what it did do was operate on the components that do work as very simple ones - coordinate pairs, velocities and so on. I had this very simple demo which was a couple of sprites with coordinate positions, velocities and sizes. You could then add the joystick component and it would update the velocities and so on automatically, which propagated into the positions, which meant in practice that you controlled the sprite with the joystick automatically.
This is, I think, the way forward, having code not so much in the components as associated with it. So your component members might be a joystickReference only, but the component has an associated constructor and destructor that create and delete it as you add or remove the component.
It seems to work quite well, though v3 (again, learning from mistakes and better engineered - I've never written an ECS framework before) doesn't do this yet it probably will soon.
In many ways, what I'm creating is a 2D Lua based version of Unity3D without the GUI interface (and without the enormous price tag)
This is what Unity does pretty much, taking components that do stuff and sticking them together. But it does it at a higher level than classic ECS systems do. All Unity really does is operate on the properties directly via the GUI, which looks very clever but actually isn't that difficult to do, it is like Visual Studio, you just expose properties of objects that you can then manipulate via a slider or checkbox or whatever. There are javascript and QT systems that do the same sort of thing.
It is a pragmatic ECS (sometimes known as a hybrid). You say, well, there are some things the model just doesn't fit, so try to use the best of both worlds. But you try to keep, as far as possible, the data driven idea - v3 does this, when you create an entity you give it a pile of data for its components (and this could be extended to tell it what components as well) but you allow simplifications like having a singleton map which you can access directly.
If you think in terms of say, Pacman, you can see how the various items in the game might be entities - ghosts, pacman, fruit, score, power pills and so on. The collisions you can do. You can control them , none of this is difficult.
The odd thing is the map. Is it one entity; or lots of entities (are all the dots entities, if so is this workable ?). All the other entities access it all the time, do you really want to put all that through a message system ?
The answer - pragmatically - is like the joystick. The map is a single entity which you can put things on, and interrogate to find out which way you can go (say). The individual dots in the maze are managed by the one entity.
If you didn't do that, and had 200 of the dots or something as individual entities, you'd have to render them all individually, you'd process them in your systems, and you'd have to check collision for all of them (or write special collision systems).
In other news (?) the font library does seem to be fairly stable, but we do seem to be having problems with BmGlyph.
No comments:
Post a Comment