With exams
coming up, I will be devoting this blog to briefly review and refresh a few
topics learned earlier this course.
To begin,
one of the new concepts is the idea of a smart pointer. Essential a smart
pointer is a special object that contains a pointer along with the additional
of potential data members and functions. A smart pointer is able to do what a
regular pointer cannot natively. An example of this is storing a reference
count to ensure that there are no dangling pointers with zero references, causing
a potential memory leak. A smart pointer
will intelligently know to destroy itself if the situation ever arises. This is just one of the examples of a smart
pointer, for instance a weak pointer will still contain some additional
functions but will not automatically destroy itself if reference count reaches zero.
The major disadvantage with a smart pointer is based around implementation. It
is very difficult to implement a good smart pointer. Thankfully it is already
implemented in 2loc.
Moving away
from the traditional object orient design that we have all been familiar with,
we look to a new concept of entity component systems. In the entity component
system, each element of entity, component and system serve unique purposes.
The entity itself
is nothing more of a container for data and its unique id. An entity has
multiple components attached to it. It is important to remember that the
components and the entity are just data. A good example to think about this, especially
if you have used unity is that each object has sub-components that are added to
it. These objects or data can be for instance components that describe the
object - a material with data such as the diffuse, normal, specular maps ; a
bounding box, with a vector for each pointer or perhaps a radius; a
transformation, perhaps divided into rotation, position, scale; a mesh
describing the objects; containing arrays of vertex data. Each of these
components are attached to the entity and make up the entity, these components
are attachable and detachable - the entity itself does not matter what or how
many components are attached. The most
important aspect of the entity in this case is being modular.
When it
comes to functionality, it is up to the systems to perform the task given an
entity. In order for a given system to perform its function on an entity, the
entity must have the required components attached; again it does not matter if
the entity has more components than the system needs. If the entity indicated
above were to be fed to say a render system, the relevant components – the mesh
and the material and perhaps the transformation components will be used by the
system to perform the operation of rendering. If the same entity were to be passed
to physics system, than the relevant components would be transformation and
bounding box components. This is just a trivial example of how the entity
component system works. The systems themselves do not store data but access it
through entities and uses it to perform calculations. These systems operate
sequentially – you can have for example an AI system to determine an entity’s
movement than have a physics system go and compute afterwards.
To further illustrate
the entity component system using an example. Take for instance a generic
entity with no components attached to it other than its name (id). To make this
entity do something we can attach a transformation component to it. Now we can
move it around the world, however there will likely be almost no systems that
will be able to use it. If we were to add a light component to it – for instance
a component that can make the entity a light source, describing its light
color, range, attenuation and direction. The system can thus perform
appropriate calculations using this entity to light other entities.
Byte56. (2012, July
2). Role of systems in entity systems architecture. [Reply Post]. Retrieved from http://gamedev.stackexchange.com/questions/31473/role-of-systems-in-entity-systems-architecture
Gregory, J. (2009). Runtime Gameplay
Foundation Systems. Game engine architecture. Wellesley, Mass.: A K Peters
No comments:
Post a Comment