At the end of last week’s article, we signed off mentioning the possibility of providing two component APIs for the Entity Component System of the Vortex Editor. Although I’m still very much in line with this idea, the more I lean towards a scripting language, the more I am concerned about performance.
I am worried that scripted components might not be able to meet the quota of updating in less that 16.6 ms once we have a few of them in any given scene. 16.6 ms is the time slice we have to update all components and render the scene on the screen in order to achieve 60 FPS.
A native component, on the other hand, could benefit from all the advantages of going through an optimizer compiler and requiring no parameter marshaling when interfacing with Vortex’s C++ API.
In the light of this, what I’ve been considering is providing a rich set of native components that are part of the Vortex API and that a script can attach to Entities. This would provide the advantage of being able to dynamically add and remove behavior to Entities, while still hitting native performance during the update-render loop.
Of course, I’m still very interested in providing a means to create components through scripts, but perhaps these can be used mostly for exploring ideas, and if performance becomes a problem, then the best practice would be to move to a native implementation of the component.
This week, as a dry-run of the Component API, I’ve implemented a simple Rotation Component that will make any Entity spin on its local axes. A custom UI widget in the Vortex Editor allows configuring the speed and rotation axis of the component in realtime, while visualizing the animation in the 3D view.
I’m pretty happy with the results, and I believe this is the way to move forward with the Entity Component System of the Engine.
Next week I will continue working on the Editor and Engine, trying to maximize what you can do out of the box. Stay tuned for more!