Edition
What you are using to create new entities, preferably outside the code ? pros and cons? I plan to create some kind of deserializable entity blueprint, composed with components and other blueprints as children. Any adice on this particular approach?
Script
I’ve read about system that where user’s scripts, javascript or else, for more expandability outside the code. Does any one as tested it? do you have an exemple of implementation with Zay?
Inspector
For debug purpose, I would like to click on an entity and explore all its components and the inner values. Scince Zay forbid blind components retrieving with only entity ID, is there a trick to achieve that?
Not zay es related but you are pretty free to choose between hundreds of scripting languages but personally I prefer Java dynamic compilation which means you basically Script in Java.
I don’t like the typelessness of Java Script and it’s more hacky to me. Also you need wrappers for Scripts (possibly automatically done but you might need them), with Java the Code is integrated seamless.
The downside is ofcourse the loading speed anf you can’t really isolate dangerous (io, execute etc) functions as you could in lua for example, which means the Code can do anything.
On the contrary this is very much possible to limit accessibility using the SecurityManager. However for scripting we use Javascript but not together with Zay-Es so can’t help you there.
I use Groovy with Zay-ES all the time. I love Groovy as Groovy is Java. A groovy class is a Java class so you can pass it to Java code, etc… Most other scripting implementations require some translation.
As to the other, I create most of my entities with scripts… didn’t really need an editor.
As to the “enumerate all components”, you’ll have to hack the core code for that as it’s entirely anti-ES right at it’s fundamentals. I guess you want to use this for debugging… but frankly that’s what a debugger is for and then you can look at everything anyway.
I still work with Unity at the same time with JME so somehow I want to migrate my workflow there to JME3. And I create an Editor for that purpose!
Overall, The Editor will let you :organize Component into Entity, tag Entity and specify the orders of Processor. After that, you can choose to export to Bytecode, Java, Groovy or Xml to use in specific game.
In detail, it use a dynamic facade system call MetaWidget to generate UI for Pojo. So you can working with your java code or use the editor to edit that pojo, back and forth. To optimize more, the Processor, AI and StateMachine are crafted for Entity. This means they are generated on the fly with ASM, to be specific ByteBuddy http://bytebuddy.net/.
I have an Editor for Ashley, Artemis and Zay-ES. They have different constraints. But pretty much alike. I sure will open source this editor (like I did before) or corporate if anyone interested.
Yes, it’s only for debugging and inspecting entities. I would like to create an object containing all components of an entity for the debugger to let me inspect the whole state of my entity at a time. But It’s less relevant now, since I’m changing my ES approach.
+1 for the dynamic pojo editor ^^
About the “create your entity with a script” thing, could you point me to a specific implementation? I guess it is a builder that call other builders for childdren entities. But it’s a bit confusing to me : since entities are pure data, I’ve always considered the bulding processus as a prototype or deserialization pattern.
For my first try, I’ve intended to create some “blueprint” class, containing a list of components and other blueprints, and a blueprint editor. But now I doubt
I use a modified (fortified) luaj for my game, as it executes user code on the server. With a fully interpreted language, it is very easy to secure it, as it cannot simply break out of the luavm due to a single missing securitymanager part, also it is pretty simple to limit the cpu useage it can eat.
However I kinda have a special use case, the scripts in my game are for programming your shipcomputer/ customizing it, and since this is targeted to be a larger multiplayer gamen, someone will most likly try to sabotage it at some point.
Groovy is often a very good choice for this, if you do not have these security concerns, it integrates perfectly with all java librarys, and vice vesa.
The “blueprint” system or “presets” are good ideas picked from OOP. Note they should be “good” or “helpful” feature only (minimum of them), or you again managed to escape the bad-effect of it, like you did before to go to COP. Anyway, I have some insights for this problem my self:
I have 4 types of blueprints: Aspect-based, Category-based, Case-based, Type-based in my libraries. I can drag a BluePrint from a Pallete of a Library to build a new Entity with that Parameters (Components and settings).
Aspect-based Component are like PointCut in Aspect programming.For ex: Entity can be build as a Header-Main-Footer bags of Components. You insert one in to Header or Main or Footer, as long as that Aspect is for initialize, operate or tagging.
Category-based Component are like module of one feature like Mesh, AI, Effect, what ever you choose as it depends in Game genre.
Case-based Components by context-aware. It’s a way to let your editor aware of depedencies Component exitsed in the Entity. Component are enabled or disabled if there is not enough requirement for it to run. Case-based are usually belong to AI stuffs.
Type-based are very OOP-alike. In simple case, you can drag in a class of GenericHouse or GenericCharacter without be promted anything. Another complex scenario, called “Split the list”: A Car type will have 4 Wheels, So the editor will generate an Entity and 4 components with name (Wheel1,2,3,4)… Or generate 4 entities with Wheel component and a ReferenceList in the said Car Entity. This will open a wizard for you to do so.
The system usually linked the generated Entity to its “original version” or “prototype”. This help sometime. But don’t think like it a class, that instance will be updated if the class updated. It can be a big headeach to solve such problem. As my experience, Aspect-base work great for updating. That’s why in first phase we usually try Aspect-base blue print!
Other things can be concerned along making this Editor:
Use json (or plantext) as medium to save arbitrary structure of components and entity data. Never use XML.
Namespace of Blueprint (like my.com.hell.ass.) can be a pretty bad hell also. Use folder directory as namespace to reduce headache. Library and BluePrint should has Tag (text label) to be more organized. Use a version system to vesionize those files. It will help in case your libraries become big and complex.
The MMO we working on have 18 types of characters and 15 types of item. Its result in over 200 composable ways which we did try, and thousand more we didn’t (I don’t do the math, sorry). So big and complex thing are bad… Hope this help.
Here is an early implementation of the entity editor. It explore the components by reflexion and inject a new imutable component when values are changed. Usable at runtime.
To get all components of a single entity, I plan to do the following :
annotate all “editable” components type
create a list of annotated class
when an entity is inspected, ask EntityData for each annotated component.
It’s not pure ES but do you see another option?
My components are not encapsulated but imutable. Fields can be annotated for convinence in the editor.
public class PlanarStance implements EntityComponent {
@EditorInfo(UIname="Coordinate", info="Actual coordinate of the entity.")
public final Point2D coord;
@EditorInfo(UIname="orientation", tooltip="The orientation in radians.")
public final double orientation;
public final double elevation;
public final Point3D upVector;
public PlanarStance(@JsonProperty("coord")Point2D coord,
@JsonProperty("orientation")double orientation,
@JsonProperty("elevation")double elevation,
@JsonProperty("upVector")Point3D upVector) {
this.coord = coord;
this.orientation = orientation;
this.upVector = upVector;
this.elevation = elevation;
}
}
This is nice overall I think, but that’s quite a lot of configurations you tie to your pojo Component… This depend on how you want to code your game I know but I recommend You should take a look at MetaWidget to see if it can make “convention over configuration” to let you reuse more, if that’s your ultimate goal. For example:
@EditorInfo, UIname should not be there in the Component definition. The info are actually javadoc and also should be removed. Param namer are actually good for editing facility but you can also use a very wellcraft bean accesor creator from google named AutoValue, along with other from GitHub - google/auto: A collection of source code generators for Java.
I really want to see the result of your process. You seems to have rapid developing skill… I means crazy!
It’s there because I want to as few code as possible to write for each component. So I mix the logic with the view and yes, it’s bad design. How would you do instead? Some kind of definition file like :
Yeah, javadoc is removed or being deliver separately if you have integrate a javadoc task somewhere (Ant or gradle). You have to link they together again via something like jsoup or jdom (more works) , I did this because I want almost zero annotations in my bean classes, I have an util to lookup javadoc facilities of that specific jar, usually at the same folder and grab needed text… If it sound too much work so just use an annotation never mind.
Google AutoValue:
No, it’s not like that. Say if you have a Component and you want to make a Creator for it, that mean another class can create a pojo for you, which dont make your bean look stupid with a lot of getter and setter or a lot of params in construtor. auto/value at master · google/auto · GitHub
It sounds like a good long time goal issue to add to my repository
BeanInfo is certainly usefull for JavaBean, but how would you use it for imutable object, without any getters and setters? I’m not very confortable with JavaBeans so I would appreciate an exemple stiched to the PlanarStance component pasted earlier
I can’t imagine a way to create generic builder, and I would like to avoid to have one builder per component, to keep the component creation as simple as possible. Do you see a way?
(Note that’s I still assume you working with ZayES)
For Component, I recommend to use AutoValue since PositionComponent is extractly PositionValue which is an immutable object that only be create once. Google AutoValue will apply best practice to make its truely only immutable value under the hood (Yes, its a generated Builder as said in its wiki).
For Entity, you can make any EntityCreator as you like. One that usually being used it’s Builder from Prefab and the create Entity from Set of Components (with no order). I have used Builder a lot… with Groovy if you don’t mind its elegant syntax. Groovy Builder can build anything which its a Tree. For Prefab creating, I actually use Groovy to make a very simple Json like syntax that immediate create object. I also have dynamic SpatialBuilder in case of “Split the list” wizard needed (said above).
I will update my Editor in AtomSDK soonish, then you can take references from there. It’s a lot of codes… I want to keep my self from troubles since i’m not good at handling complains…
Well, you can use the provided properties (fields (ugh) in this case)… and make a generic builder. I’m pretty sure you can set public fields at runtime with reflection as long as you change their reflection accessibility like you would for private fields.
If it were me, I’d use setters and getters where the setters emulated the builder pattern. ie: something like:
public MyComponent setValue( Object someValue ) {
return new MyComponent(field1, field2, field3, someValue);
}
Since it’s for an editor it doesn’t matter too much that you will create a new object for each set. I end up adding similar methods to me components anyway though I call them changeFoo instead of setFoo.
Either way, a little reflection can find them from the bean info.
public final fields basically give you no control over them in the future. With getters at least you can transition code more easily to new forms. Maybe someday you break a field into three fields but still provide a combining getter for convenience to all the callers or whatever. Public fields lock you into always supporting them without major changes. I consider it a bad practice, personally.
This is very nice. I’m curious about the relationship of entities represent in the left tree. Is that exactly spatial parent-child relationship? So is there any entity that don’t have spatial representive in your ES framework?
The tree is made from the existence of the Parenting component on an entity, containing a single entityId as a parent.
This relation ship has no effect on its own. But there are processors sensible on combinations like Parenting & SpatialStance or Parenting & Triggering for exemple.
So much bean property related stuff is already built into Java.
never mind.
