Closed calclavia closed 9 years ago
To develop with it you need annotation processor which has to be set-up manually (there is no other way to set-up it from gradle and keep classes in sync while debugging).
Its entities are created via special factory and I don't know if we can integrate that with DI.
I would keep our current entity system.
I don't want to remove comments but keep it civilized and a bit professional. Some might have it bound to an email.
Might brighten up their inbox on a Tuesday morning.
Or not.
Those last 2 senteces sounded SO abstract, i dont even.. :+1: - as soon as this is programmed not by me =P
PS: Mojang needs to hire @calclavia to fix minecraft
I think it's better to use another system made by someone focusing on it, as long as it's still being updated (isn't dead).
As to gradle not supporting stuff - keep in mind that it's based on groovy which is based on java. So as long as one of those three can handle it, you're fine.
(I have this repository bound to my email, but I don't mind you chatting - it's just unprofessional, use a TS, IRC or something... )
@Caellian problem is that Annotation Processor isn't java supported feature. It is one big cheat to hookup into Java Compiler.
Main problem is that gradle is not providing support to hook Annotation Processor to IDEA. This means class reloading feature will be useless as classes from IDEA will be unprocessed. It will cause confusion and require one additional step to setup workspace.
Can't you access the annotations at run time using Reflection API?
It is something completely different. It is only called Annotation Processor (it was supposed to be its function) but it is used for compile-time code generation and modification using JavaCompiler internal methods.
I wish I understood this matter better and was actually helpful... Maybe copying and editing classes before compiling? You cab also create an issue on junkdogs issues page asking him what to do.
@Kubuxu It looks like annotation processing is optional? I'll have to read more carefully.
We don't really HAVE to use their library, I'm just saying it's nice to take it as an inspiration (even if we don't use it) for our own factory patterns as well as the entity structure. There are also other libraries out there we can look at. It seems ideal to have everything that's in-world extend one thing, and use the component system to a greater extent.
In other words, we embrace ECS more. Block would be a component of Entity (that requires World and Position components). Item would be a component of Entity. Everything that exists in-world is build on a central ECS, similar to how Unity 3D has done it in their engine.
Using it as inspiration is great, but I think using the library directly will be a failure. I think our needs are unique enough that we should keep our own ECS.
@RX14 That's true. This library might be a bit too heavy weight for us.
Should we consider using an external Entity-Component system like this or taking it as an inspiration to improve our own factory and component syntax? https://github.com/junkdog/artemis-odb
https://github.com/junkdog/artemis-odb/wiki/Entity
It might have higher performance. I think essentially Block/Item/Entity are all "ComponentProviders" in a sense that they hold components in the same way.
This will probably solve some of our current design problems with factories and modularize code even more.
Factory syntax: https://github.com/junkdog/artemis-odb/wiki/EntityFactory
Basically, BLOCK is a type of Entity with fixed integer position values. In fact, Block itself can be a sort of component, if you think about it...