I've selected system_manager.go for refactoring, which is a module of 17 lines of code that couples the top-level components tightly. Addressing this will make our codebase more maintainable and improve Better Code Hub's Couple Architecture Components Loosely guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Minimize the amount of interface code; that is, code in modules that are both called from and call modules of other components ("throughput"), and code in modules that are called from modules of other components ("incoming").
• Why❓
  Having loose coupling between top-level components makes it easier to maintain them in isolation.
• How 🔧
  You can hide a component's implementation details through various means, e.g. using the "abstract factory" design pattern.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

I've selected entity.go for refactoring, which is a module of 65 lines of code that couples the top-level components tightly. Addressing this will make our codebase more maintainable and improve Better Code Hub's Couple Architecture Components Loosely guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Minimize the amount of interface code; that is, code in modules that are both called from and call modules of other components ("throughput"), and code in modules that are called from modules of other components ("incoming").
• Why❓
  Having loose coupling between top-level components makes it easier to maintain them in isolation.
• How 🔧
  You can hide a component's implementation details through various means, e.g. using the "abstract factory" design pattern.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

Can you explain what their purpose Run(), Setup(), Teardown(), Tick(), Setup(), Process(), Teardown() for beginners?

type Engine interface {
        // ???
	Run() 
        // ???
	Setup()
        // ???
	Teardown()
        // ???
	Tick()
}

type System interface {
        // ???
	Setup()
        // ???
        Process(entityManager EntityManager) (state int)
        // ???
	Teardown()
}

Refactoring + braking API changes!

I've selected run.go for refactoring, which is a module of 33 lines of code that couples the top-level components tightly. Addressing this will make our codebase more maintainable and improve Better Code Hub's Couple Architecture Components Loosely guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Minimize the amount of interface code; that is, code in modules that are both called from and call modules of other components ("throughput"), and code in modules that are called from modules of other components ("incoming").
• Why❓
  Having loose coupling between top-level components makes it easier to maintain them in isolation.
• How 🔧
  You can hide a component's implementation details through various means, e.g. using the "abstract factory" design pattern.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

It seems like that is the limit correct me if I’m wrong. Will it be supported in the future?

This looks like its a pretty comprehensive ECS, but I'm kinda struggling to make heads and tails of it (I'm fairly new to Go).

Any chance for some documentation for this little guy?

Cheers.

I've selected entity_manager.go for refactoring, which is a module of 67 lines of code that couples the top-level components tightly. Addressing this will make our codebase more maintainable and improve Better Code Hub's Couple Architecture Components Loosely guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Minimize the amount of interface code; that is, code in modules that are both called from and call modules of other components ("throughput"), and code in modules that are called from modules of other components ("incoming").
• Why❓
  Having loose coupling between top-level components makes it easier to maintain them in isolation.
• How 🔧
  You can hide a component's implementation details through various means, e.g. using the "abstract factory" design pattern.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

Hello! Along time ago I forked this library to work on it with some added changes, I stopped work on it. I noticed that there is no longer a entity.Has(componentType) method? What's the preferred way of doing this? For example:

	for _, entity := range entityManager.FilterByNames("StaticModelComponent", "TransformComponent", "PositionComponent") {
		model := entity.Get(components.MaskStaticModel).(*components.StaticModelComponent)
		transform := entity.Get(components.MaskTransform).(*components.TransformComponent)
		position := entity.Get(components.MaskPosition).(*components.PositionComponent)

		translation := raylib.NewMatrixTranslate(transform.Position.X, transform.Position.Y, transform.Position.Z)
		model.Model.Model.Transform = model.Model.Model.Transform.Multiply(translation)
		if entity.Has(MaskBoundingBox) {
			bb := entity.Get(MaskBoundingBox).(*components.BoundingBoxComponent)
			bb.BoundingBox.Min = bb.BoundingBox.Min.Add(transform.Position)
			bb.BoundingBox.Max = bb.BoundingBox.Max.Add(transform.Position)
		}
		position.Vector3 = transform.Position.Add(position.Vector3)
		entity.Remove(MaskTransform)
	}

Would something like this be added? Or would it be better to have another system that filters based on all four of them instead of having an if for one case?