Advertisement

Nested components within ECS? Good idea?

Started by October 10, 2018 07:23 PM
12 comments, last by CrazyCdn 5 years, 10 months ago
1 hour ago, zuhane said:

Thanks for the reply. I like the analogy too haha! I do have to ask, though, is there a specific resource you could recommend to help with this? I'd say that at this point I have quite a lot of experience with using XNA and C#, a degree in comp science, and I'm always reading up on programming patterns and paradigms, but even after all of these years, I find it nearly impossible to make anything more complex than a very simple arcade game. As soon the the code starts to expand, it becomes too much for me to store in my brain at any given time, and the smallest changes require so much paper-trailing that by the time I find the source I've forgotten the problem. It's very frustrating, as every time I start a project I can code very quickly, then I start to lose steam and eventually grind to a halt. I can create all the individual components, but tying them all together eventually leads to this huge stressful problem where I can't even begin to modify features or fix bugs without creating more.

I was hoping that ECS would help with my specific style of game (a separate one I've worked on for years), but I feel like there are so many factors involved, such as ordering, inter-dependencies, nested objects, etc. Is it commonplace to simply keep refactoring? I feel like I've got so far (and been through 2 prototypes) and that throwing it away and starting again would be a pretty big deal at this point.

Have you read http://gameprogrammingpatterns.com/ ? From listening to that author talk and reading his book, as well as reading Hodgmans excellent article, the solution appears to be to use a wide hierarchy and not a deep one, and to decouple components that don't make sense to be tightly coupled. (In short, as Hodgman points out, this is proper oop) The author of that book gave a talk on twitch you can view here https://www.twitch.tv/videos/319209508?t=30m32s talking about how he designs his rougelike using some basic patterns (all discussed in the book, which is free) to help keep things decoupled and strutctured.

>Is it commonplace to simply keep refactoring?

Yes! Uncle Bob (Robert Martin) tells us that our code should be refactored constantly. If you leave code stale, and not update it's structure and patterns as it grows, you will always end up with a giant plate of spaghetti. Every time. He likens software development to writing an essay in college. You don't write a first draft and turn it in, no you go through multiple drafts refining it until it is ready. I see no reason why we shouldn't do the same in Game Development. If you haven't read his book Clean Code I highly recommend it.

Thanks for all the replies.

Anarcho, these certainly seem very helpful and I'm going to have a look through all of them. I started reading the Game Programming Patterns book, and it was brilliant and articulately written. The problem was that it used C++ in the examples, which I'm not too familiar with! Nevertheless, I'll have a pour through these recommendations and see if any of them help.

Advertisement
3 hours ago, zuhane said:

Thanks for all the replies.

Anarcho, these certainly seem very helpful and I'm going to have a look through all of them. I started reading the Game Programming Patterns book, and it was brilliant and articulately written. The problem was that it used C++ in the examples, which I'm not too familiar with! Nevertheless, I'll have a pour through these recommendations and see if any of them help.

Honestly C# and C++ are fairly similar.  The concepts should transfer fairly easily from one to the other.  C++ just doesn't have reflection built in.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

This topic is closed to new replies.

Advertisement