Is this engine is built around ECS or OOP?

[Lekret]

Hi, discovered this engine just today and looked a bit at workflow and C++ docs. 
In steam page it says "Entity Component System" and I found some probably outdated discussions about ECS and OOP mode, when in reality it was just both OOP with EC (Entity-Component/GameObject-Component) approach. I found no "System" part anywhere.

I'm a bit confused, will this engine support ECS later?

[Josh]

The short answer to your question is yes. 

The engine is design as an object-oriented C++ framework. If you wish to use it, you have full control over the program at the very base level. This is also nice for documentation because it allows us to demonstrate how a command works in a very simple program:

#include "UltraEngine.h"

using namespace UltraEngine;

int main(int argc, const char* argv[])
{
    //Get the displays
    auto displays = GetDisplays();

    //Create window
    auto window = CreateWindow("Ultra Engine", 0, 0, 800, 600, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR);

    //Create world
    auto world = CreateWorld();

    //Create framebuffer
    auto framebuffer = CreateFramebuffer(window);

    //Create a camera
    auto camera = CreateCamera(world);

    //Main loop
    while (not window->Closed() and not window->KeyDown(KEY_ESCAPE))
    {
        world->Update();
        world->Render(framebuffer);
    }
    return 0;
}

An entity component system is also available, which is particularly useful for setting up object properties in the editor and then accessing them in component code in your game:
https://www.ultraengine.com/learn/Component

Someone who is making something like a space game with all procedurally placed content would not need the editor, and might not need the ECS at all. Someone else who is using the editor a lot for level design will probably want to rely on the ECS in order to set up properties in the editor and access them in the game.

The ECS is also good for user-created modular code that can be reused in many projects.

You don't have to choose between one or the other. You can use the ECS and you still have access to the main function in case you want to do something special there. I like to use the OOP approach for documentation examples because the user can just copy and paste one block of code into any project, without a lot of complicated setup, but the functionality demonstrated can be implemented in any entity component.

[Dreikblack]

14 hours ago, Josh said:

An entity component system is also available, which is particularly useful for setting up object properties in the editor and then accessing them in component code in your game:
https://www.ultraengine.com/learn/Component

Pretty sure OP meant that https://en.m.wikipedia.org/wiki/Entity_component_system

[Lekret]

1 hour ago, Dreikblack said:

Pretty sure OP meant that https://en.m.wikipedia.org/wiki/Entity_component_system

Yeah, I meant exactly that, but it seems that Josh don't see the difference or just ignores that, even though I said "I found no System part in the engine", so... whatever.

[Josh]

9 hours ago, Dreikblack said:

Pretty sure OP meant that https://en.m.wikipedia.org/wiki/Entity_component_system

Thanks for clarifying that. On the same page, there is even a section called "Debate" in which people argue about exact definitions:
https://en.m.wikipedia.org/wiki/Entity_component_system#Debate

To me, ECS means components attached to entities that add characteristics or behavior. Let's look at the page's definition of "system":

Quote

System: A system is a process which acts on all entities with the desired components. For example, a physics system may query for entities having mass, velocity and position components, and iterate over the results doing physics calculations on the sets of components for each entity.

The core engine is an OOP hierarchy, so this example probably does not apply. The physics system internally does the same thing, but that's more about syncing data across multiple threads and is not part of the user-facing API.

The user-exposed component system does not currently have the ability to query a list of entities that have a specified component type attached to them, but I can see how this could be very useful:

void Player::Respawn()
{
	auto spawnpoints = world->GetEntitiesWithComponent<SpawnPoint>();
	if (spawnpoints.empty()) return;
	int n = Random(0, spawnpoints.size() - 1);
	GetEntity()->SetPosition(spawnpoints[n]->position);
}

If people would find this useful it would not be difficult for me to add. Is this more along the lines of what you were thinking?

[IceBurger]

9 hours ago, Josh said:

Thanks for clarifying that. On the same page, there is even a section called "Debate" in which people argue about exact definitions:
https://en.m.wikipedia.org/wiki/Entity_component_system#Debate

To me, ECS means components attached to entities that add characteristics or behavior. Let's look at the page's definition of "system":

The core engine is an OOP hierarchy, so this example probably does not apply. The physics system internally does the same thing, but that's more about syncing data across multiple threads and is not part of the user-facing API.

The user-exposed component system does not currently have the ability to query a list of entities that have a specified component type attached to them, but I can see how this could be very useful:

void Player::Respawn()
{
	auto spawnpoints = world->GetEntitiesWithComponent<SpawnPoint>();
	if (spawnpoints.empty()) return;
	int n = Random(0, spawnpoints.size() - 1);
	GetEntity()->SetPosition(spawnpoints[n]->position);
}

If people would find this useful it would not be difficult for me to add. Is this more along the lines of what you were thinking?

I think that would be useful.