As a quick note before I make the next dev log, I just want to say that in practise, you usually don't want to store the animation map in the AnimationComponent itself (Was just for demo purposes) Instead, store a string or enum in the component to index a map holding every available animation in some kind of Asset manager class so you don't store identical animations across different components!
There are so many engines now that make it so accessible, you don't have to do what I'm doing here! Toby Fox claims to know very little about coding and he went ahead and made Undertale in GameMaker studio
Awesome! Love to see ECS stuff, though I do wonder, as I work on my own ECS engine too, would it help to have the entities and their component data be serializable? I was thinking of a JSON-style format, so that someone could simply make a new component with something like: "CollisionComponent { Width: 10 Height: 12 }" I figured it may be an easier implementation than a whole game editor as larger game engines like Unreal and Godog have, yet I can't figure how to do it. Thoughts??
Honestly I haven't really played with serialization much in the context of an ECS, but having it could definitely be helpful (especially with state) and there are some libraries I've encountered that can dump simple structs like components into a JSON from within the code to handle serialization. But if you want to avoid hardcoding components and just have your own JSON-esque component ecosystem, maybe just have a Component class with a name and map, like struct Component { string name; map properties; } And you could parse the JSON file into this general struct, so that 'name' would be assigned as 'CollisionComponent' and properties would contain 'width: int(10)' and 'height: int(12)'. Then you simply just retrieve a desired component by name, and can get it's values using the properties map, like if (component.name == 'CollisionComponent') { int width = std::any_cast(component.properties["width"]); } Not sure if that's the most efficient solution but that's what I'd do if I went with JSON approach
Good question! You can definitely just provide 2 corners and derive the rest from it in RenderSprite, I just personally find it more readable for RenderSprite to take in 4 UVs without having to do any of the derivation logic within the function (Separation of concerns I guess); And the Renderer::Sprite struct is just a way to wrap parameters to send to the function so it's more readable, it's a stack allocation and is destroyed at the end of the call so added memory isn't really an issue.
Hello, I am trying to make an engine with ECS, I wanted to ask if you followed any class design or sequence for your engine. Currently I have been trying to apply it to a Java game but I always have the same problem regarding its architecture.
I don't follow a specific architecture for the engine, but try to follow design patterns that I've picked up over time when they're helpful. Reading game programming patterns by Robert Nystrom is a good start, and if you'd like to see how some games implement an ECS, check out some games that use EnTT (an ECS library) here github.com/skypjack/entt/wiki/EnTT-in-Action
@@cient_dev I recommend some Sanders Mertens articles like 'Why its time to start thinking games as databases' and others, even if you don't use flecs, it is very inspiring, and the articles have a high quality.
As a quick note before I make the next dev log, I just want to say that in practise, you usually don't want to store the animation map in the AnimationComponent itself (Was just for demo purposes) Instead, store a string or enum in the component to index a map holding every available animation in some kind of Asset manager class so you don't store identical animations across different components!
0:09 I felt that
i want to get into game development but then i realise how complex coding languages look to me and i get super overwhelmed lol
There are so many engines now that make it so accessible, you don't have to do what I'm doing here! Toby Fox claims to know very little about coding and he went ahead and made Undertale in GameMaker studio
@@cient_dev oh i see, thank you!
Bro please keep making videos
Working on a new one!
@@cient_dev nice, I saw all of them were from a month ago and got worried you’d quit
Subbed! Keep up the good work
Will try and make you proud
Nice video. Would love to see a deep dive of your ECS
You'll probably enjoy the next dev log
Awesome! Looking forward to it 😁
Awesome! Love to see ECS stuff, though I do wonder, as I work on my own ECS engine too, would it help to have the entities and their component data be serializable? I was thinking of a JSON-style format, so that someone could simply make a new component with something like:
"CollisionComponent {
Width: 10
Height: 12
}"
I figured it may be an easier implementation than a whole game editor as larger game engines like Unreal and Godog have, yet I can't figure how to do it. Thoughts??
Honestly I haven't really played with serialization much in the context of an ECS, but having it could definitely be helpful (especially with state) and there are some libraries I've encountered that can dump simple structs like components into a JSON from within the code to handle serialization.
But if you want to avoid hardcoding components and just have your own JSON-esque component ecosystem, maybe just have a Component class with a name and map, like
struct Component {
string name;
map properties;
}
And you could parse the JSON file into this general struct, so that 'name' would be assigned as 'CollisionComponent' and properties would contain 'width: int(10)' and 'height: int(12)'.
Then you simply just retrieve a desired component by name, and can get it's values using the properties map, like
if (component.name == 'CollisionComponent') {
int width = std::any_cast(component.properties["width"]);
}
Not sure if that's the most efficient solution but that's what I'd do if I went with JSON approach
3:22 very random and probably doesnt matter but why 4? why not 2? top left and bottom right is all you need no?
Good question! You can definitely just provide 2 corners and derive the rest from it in RenderSprite, I just personally find it more readable for RenderSprite to take in 4 UVs without having to do any of the derivation logic within the function (Separation of concerns I guess); And the Renderer::Sprite struct is just a way to wrap parameters to send to the function so it's more readable, it's a stack allocation and is destroyed at the end of the call so added memory isn't really an issue.
Hello, I am trying to make an engine with ECS, I wanted to ask if you followed any class design or sequence for your engine. Currently I have been trying to apply it to a Java game but I always have the same problem regarding its architecture.
I don't follow a specific architecture for the engine, but try to follow design patterns that I've picked up over time when they're helpful. Reading game programming patterns by Robert Nystrom is a good start, and if you'd like to see how some games implement an ECS, check out some games that use EnTT (an ECS library) here github.com/skypjack/entt/wiki/EnTT-in-Action
@@cient_dev
I recommend some Sanders Mertens articles like 'Why its time to start thinking games as databases' and others, even if you don't use flecs, it is very inspiring, and the articles have a high quality.