After asking two questions about entity systems (1, 2), and reading some articles on them, I think that I understand them much better than before. I still have some uncertainties, mainly about building a particle emitter, an input system, and a camera. I obviously still have some problems understanding entity systems, and they might apply to a whole other range of objects, but I chose these three because they are very different concepts, should cover a pretty broad ground, and help me understand entity systems and how to handle problems like these, myself, as they come along.
I am building an engine in JavaScript, and I've implemented most of the core features, which include: input handling, flexible animation system, particle emitter, math classes and functions, scene handling, a camera and a render, and a whole bunch of other things that engines usually support. I read Byte56's answer, that got me interested into making the engine into an entity system. It would still remain a HTML5 game engine, with the basic scene philosophy, but it should support dynamic creation of entities from components.
The problem I have, now, is fitting my old engine concept into this new programming paradigm. These are some of the definitions from the previous questions, updated:
An Entity is an identifier. It doesn't have any data, it's not an object, it's a simple id that represents an index in the scenes list of all entities (which I actually plan to implement as a component matrix).
A Component is a data holder, but with methods that can operate on that data. The best example is a
Vector2D, or a "Position" component. It has data:xandy, but also some methods that make operating on the data a bit easier:add(),normalize(), and so on.A System is something that can operate on a set of entities that meet the certain requirements; usually the entities need to have a specified set of components, to be operated upon. The system is the "logic" part, the "algorithm" part, all the functionality supplied by components is purely for easier data management.
Camera
The camera has a Vector2D position property, a rotation property and some methods for centering it around a point. Each frame, it is fed to a renderer, along with a scene, and all the objects are translated according to its position. The scene is then rendered.
How could I represent this kind of an object in an entity system? Would the camera be an entity, a component, or combination (as per my answer)?
Particle Emitter
The problem I have with my particle emitter is, again, what should be what. I'm pretty sure that particles themselves shouldn't be entities, as I want to support over 10,000 of them, and I believe that creating that much entities would be a heavy blow on my performance.
How could I represent this kind of an object in an entity system?
Input Manager
The last one I want to talk about is how input should be handled. In my current version of the engine, there is a class called Input. It is a handler that subscribes to the browsers events, such as key presses and mouse position changes, and also maintains an internal state. Then, the player class has a react() method, which accepts an input object as an argument. The advantage of this is that the input object could be serialized into .JSON, and then shared over the network, allowing for smooth multiplayer simulations.
How does this translate into an entity system?
Answer
Camera: Making this a component would be pretty neat. It would just have a
isRenderingflag and depth range like Sean said. In addition to "field of view" (I guess you might call it scale in 2D?) and an output zone. The output zone could define the portion of the game window that this camera gets rendered to. It wouldn't have a separate position/rotation like you mention. The entity you create that has a camera component would use the position and rotation components of that entity. Then you'd have a camera system that looks for entities that have a camera, position and rotation components. The system takes that entity and draws all the entities it can "see" from it's position, rotation, depth of view and field of view, to the specified portion of the screen. That gives you lots of options for simulating multiple view ports, "character view" windows, local multiplayer, different layers of GUI and so on.Particle Emitter: This too should just be a component. The particle system would look for entities that have a position, rotation and particle emitter. The emitter has all the properties needed to reproduce your current emitter, I'm not sure what all those are, stuff like: rate, initial velocity, decay time and so on. You wouldn't have to make multiple passes. The particle system knows which entities have that component. I imagine you could re-use a good deal of your existing code.
Inputs: I'd have to say making this into a component makes the most sense given the suggestions I make above. Your
input systemwould get updated every frame with the current input events. Then when it's going through all it's entities that have the input component, it will apply those events. The input component would have a list of keyboard and mouse events all associated method callbacks. I'm not really sure where the method callbacks would live. Perhaps some input controller class? Whatever makes the most sense for later modification by users of your engine. But this would give you the power to easily apply input control to camera entities, player entities or whatever you needed. Want to synchronize the movement of a bunch of entities with the keyboard? Just give them all input components that respond to the same inputs and the input system applies those move events to all the components asking for them.
So most of this is just off the top of my head, so it probably won't make sense without further explanation. So just let me know what you're not clear on. Basically, I've given you a lot to work on :)
No comments:
Post a Comment