Jump to content
  • Advertisement
  • entries
  • comments
  • views

NLE: Unnamed Engine, The start...well kind of...

Sign in to follow this  


Welcome to my n[sup]th[/sup] attempt at making a steady blog for myself and my projects!

So, to help others, and myself, I'm gonna write some snippets of stuff here, and hope the ideas, methods and over all the posts I make will help out someone smile.png

First of all, an introduction to my Unnamed engine.

The engine is built along a certain 'pattern' (as I'll call it), this pattern has 3 simple parts to it, "Entities", "Components", and "Systems".
[size=2]Now, I can see people yelling, "That's an ECS!" ... I can also see Hodgeman raging at them ... If you're curious about my last statement, don't be, I'd love to explain it but I have forgotten what Hodgeman said exactly, so I really don't want to "quote" him and get it all wrong, and have him rage at me tongue.png

Entities in this pattern is just a number, a handle, it basically there to help mapping things; though, as simple as it is, it is a very important job.
Components in this pattern is data for the entities, each entity is linked to a number of components using a [font='courier new']ComponentManager[/font] class.
Next up is the Systems, which are classes that actually contain functional code for the entities and components. All Systems have an "Attach" and "Detach" function, and most have an "Update" function;

A perfect example of how this could be used is the RenderSystem://usually in some sort of "init()" or "load()" functionrenderSystem.Attach(myEntity);//in the game looprenderSystem.Render(); //aka Update.//in a function called kill() or the likerenderSystem.Detach(enemy);
This pattern is also easy to change, or replace, as long as any future "renderSystem" has "Attach, Render, Detach" I can easily just replace one line in my project, which would be the declaration of the [font='courier new']renderSystem [/font]variable.

The goal of this pattern I'm using is that everything can be swapped out, or even completely ignored without hindering the rest of the program, and that adding new things should be very easy.

To summerize my engine, here's a list of the systems and components so far.
[font='courier new']Camera[/font]
[font='courier new']Transform[/font]
[font='courier new']Mesh_GL
[font='courier new']Camera[/font]
[font='courier new']Movement
[font='courier new']Mesh[/font]
[font='courier new']Texture[/font]

As you can see, the Components and Systems are duplicated, the reason for this is that the Components only hold the per-entity data, and the Systems "attach" components to the entities, and also work on the components that entities have.
Another way to think about this is that the Systems are the functional properties an entity has. As, an entity attached to Render, is able to be rendered, that is, as long as it has a Transformation and a Mesh, and possibly a texture.

The engine so far is very "young" but in it's current state, adding to in, updating it, and changing it isn't very hard, all parts of the pattern are separate, and because of this, they don't mess with eachother.

Now, looking at this, you may be wondering:
Why not just have a class, that has parents of which the properties I have listed? like, class Camera{public: //stuff that's in CameraSystemprivate: //stuff that's in CameraComponent}class Transform{ //movement and transform stuffs here}class PlayerCam : public Camera, public Transform{ //player stuffs here}
Well, I could, but then, as soon as I changed something in Camera, I must ensure that all my code has that change. Also, if someone else is using this engine, they must know about this change; but, thats not the biggest issue, that's just a minor annoyance. (To me, that is)
The bigger issue is:
What if I want to dynamically add a feature to an entity? It's of class "Flying" and in the game, I've told it that it's now explosive? I can't do that with classes, I'd need to have a list of all "types" it could be, and see if it's that type. That carries the problem that some objects may just be static, and always static, and the player may not change the type at all.

This dynamic, on the fly, ability is useful for other things as well, like allowing users to mod the program using files. We can't tell what the user will make an object, and if we can't tell, then we can't make a class for it. We could limit the user, but that isn't nice now is it?
This is just a small example of why this is useful.

Anyhow, in the next posts, hopefully next week, will be an update on the engine, showing (maybe) the new features, sharing what has changed, and why I changed it.

If you want to know more about "Entity Component Systems", here's a good link: http://gameprogrammingpatterns.com/component.html

Until Next time!
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!