Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Entreri: A new entity-component framework  (Read 5031 times)
0 Members and 1 Guest are viewing this topic.
Offline lhkbob

JGO Knight


Medals: 32



« Posted 2011-10-25 00:13:10 »

I would like to announce the completion (or at least perfectly usable state) of my entity-component framework, Entreri.  If you're a fan (or not a fan) of R.A. Salvatore, you might get the pun on the name with the existing entity framework, Artemis.

The project is hosted on Google Code here: http://entreri.googlecode.com/
It will be hosted on one of the central Maven repositories soon enough, but is otherwise fully Maven enabled.

The API was designed to be clean and simple, although defining Component types can be a little complicated (which I will go into below).  You create an EntitySystem and add Entitites to it.  You add and remove Components from Entitites.  Entities can be queried by sets of Components they must have, and by single component type.  Each Component type is assigned a so-called TypedId that functions much like a .class handle but can be used for constant-time access of an entity's components (1 if-branch and an array lookup).

Inspired by Riven's MappedObject's library, all component data is packed into primitive arrays.  The API for this is all in Java and does not use byte-code transformation.  This does make the definition of Components a little more complicated than just defining fields, getters, and setters but it has essentially the same performance benefits of using the MappedObject approach.

It also allows for dynamic decoration of new properties onto a Component type such that all components of a given type in a system can be updated to have an extra "vector" or "matrix" or "X" field.  This is primarily useful for caching internal data by each controller that processes the system.

Although it is fully java-doc'ed, it does not have any getting-started information.  I will be adding that soon, hopefully, otherwise questions can be asked here.  I hope people are able to find it a useful tool if they are interested in exploring an entity-component design in their game and are looking for an alternative to existing frameworks.

Thanks

Offline theagentd
« Reply #1 - Posted 2011-10-25 00:23:44 »

Interesting (I'm the one who made that thread about entity systems), but the "complicated" Component system scares me enough to not bother experimenting with it. Some wiki articles or a small tutorial would be awesome, or you can just give me a few days/hours until my curiosity overwhelms me. xD

Myomyomyo.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2011-10-25 00:26:30 »

Can't quite wrap my head around:
1  
2  
    @Parameter(type=int.class, value="3")
    private FloatProperty property;

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lhkbob

JGO Knight


Medals: 32



« Reply #3 - Posted 2011-10-25 05:17:16 »

Each Component type can only declare fields that extend from Property (that is how I can manage the data storage within an entity system properly).  Each instance of a Component type in a system share the same Property instances, and just have a different index into the data of the property (which grows as the number of component instances grows).

So to make that work, I decided to use reflection to assign the Property instances to the created Component's fields.  To support flexible constructor arguments, I added the @Parameter annotation and @Parameters annotation to select the constructor to use when creating the Property.

If your question is purely over why FloatProperty has a single parameter, it is so that a vector or matrix could easily enough be stored as a FloatProperty, so you could say that 3 floats make up the property.

The implementations of properties and components within the test cases aren't the best examples of what to do, but were done in haste purely to shove data around.

Offline dishmoth
« Reply #4 - Posted 2011-10-25 09:04:28 »

Although it is fully java-doc'ed, it does not have any getting-started information.  I will be adding that soon, hopefully, otherwise questions can be asked here.

I'm not sold on the idea of Component/Entity systems.

What might convince me to use such a system:  a) Seeing decent games being made with it.  b) Seeing that the source code for those games is neater than it typically is for my games.

But then maybe I'm the sort of fussy, demanding person you'd rather not have as a customer. Grin

Simon

Offline h3ckboy

JGO Coder


Medals: 5



« Reply #5 - Posted 2011-10-25 12:00:36 »

i'm with dishmoth on that point, but that is just personal preference,  I think this is a great idea, and a couple ears ago i would have jumped right on board, but now I love being able to tear all my code apart to accomplish something because I know how it all works since (for the most part) I wrote it.

but don't take what I am saying as anything negative, I am just saying that people with a little more experience will likely want to use their own stuff. However, this is probably going to be a godsend for many newer programmers!

BTW, I love Entreri, def my favorite character, and I am pissed that he isn't in the stories anymore....
Offline lhkbob

JGO Knight


Medals: 32



« Reply #6 - Posted 2011-10-25 17:21:34 »

but don't take what I am saying as anything negative, I am just saying that people with a little more experience will likely want to use their own stuff. However, this is probably going to be a godsend for many newer programmers!

I totally agree with you here, the main reason I wrote this was for my own stuff because I like the idea of entity-component systems. And instead of reusing one, I of course had to write my own (or more like 4 different ones before I settled on this one).  I'll be using it in all of my projects, but I just wanted to put it out there in case others were interested too.

The reason I decided that entity component systems would be best for me was dealing with the issue of adding and changing materials of rendered objects, and controlling said-objects (by billboarding them, or skinning them, etc.) and applying physics to the objects.  I didn't like the idea of creating a super general hierarchy for all of that, so the component system appealed to me.  Mostly this works because I am working on a game engine, and not a game.  If I was just doing a game, I would be happier to just use OO directly.

Offline theagentd
« Reply #7 - Posted 2011-10-25 18:11:50 »

Not everyone is interested in all aspects of game programming. To me entity systems are pretty annoying, because I like programming graphics things. Using somebody else's lib or framework for the things I'm not too interested in is good for keeping my motivation up. xD

Myomyomyo.
Offline Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #8 - Posted 2011-10-25 22:27:59 »

Cool, took a quick gander at the code. I'm still uneasy about game specific entity/component systems, but that's just because I've embraced component architectures whole hog and everything in my efforts utilizes the approach. I think small light weight efforts like Entreri are good to have out there though. Congrats on finally settling on an implementation approach.

@lhkbob have you tried any tests on Android?

Recently in the finalization / release engineering process of unifying my component architecture / entity system efforts I happened to roll in some annotation usage into the core architecture and immediately performance dropped off.. It appears Android API 1-13 suffers from horrible annotation support and this is for Class annotation access let alone field and method usage which there are further inefficiencies in certain methods like "equals" in Method / Field doing insane string building / string comparisons, etc.  Just a heads up that performance may suffer greatly on Android due to annotation usage.

I posted more about it here with the relevant code snippets:
https://plus.google.com/u/0/117904596907381647757/posts/WBxsvqgP4iP

Sad Very sad panda as I can't believe such inefficiency was never caught for many years. As things go there is apparently a fix for Android 4.0 / ICS, but I'll believe it when I see it at this point. However, this doesn't help usage on the hundreds of millions of existing Android devices that won't see ICS.

I got around this by implementing my own annotation caching in my component architecture. You might have to do something similar for your ES if it is annotation bound / depends on it deeply.

Offline lhkbob

JGO Knight


Medals: 32



« Reply #9 - Posted 2011-10-25 22:33:54 »

I have not done any tests with Android, although you're welcome to try Smiley

I only use annotations the first time that a type's ID is created.  After that, everything is done with pure-java code (barring the reflection to set property values on instances, and that is done using Field.set(), I don't need to scan through the Class's fields after the first check).

As a side note, I've pushed release 1.0.0 to Maven so it should be showing up soon enough for people who are into that sort of thing.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #10 - Posted 2011-10-25 22:41:15 »

I have not done any tests with Android, although you're welcome to try Smiley
I only use annotations the first time that a type's ID is created.

Not having looked too closely an Entreri are type IDs cached or is this something that gets hit every time a component or entity is created? If it's not cached you may see performance drop off considerably. Even so, something to test and keep in mind when you get a chance to looking at Android performance. I was very frustrated by yet another gaping hole in the Android API / core Java language support.

Offline lhkbob

JGO Knight


Medals: 32



« Reply #11 - Posted 2011-10-25 23:37:06 »

Yes, TypedIds are cached.  They basically wrap an int and a generic parameter so that fetches/adds/etc. of components can look a little cleaner.  After they are created the 1st time, they are stored in a thread-safe map that is checked first.  It is also recommended for Components to expose their own TypedId as a static field.

So something might look like:
1  
2  
3  
4  
5  
class Transform extends Component {
   public static final TypedId<Transform> ID = Component.getTypedId(Transform.class);

   ...
}


and then it can be used easily:
1  
2  
3  
4  
5  
EntitySystem system = new EntitySystem();

Entity e = system.addEntity();
Transform trans = e.add(Transform.ID);
// then edit trans ...



Online Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #12 - Posted 2011-10-26 03:30:57 »

After that, everything is done with pure-java code (barring the reflection to set property values on instances, and that is done using Field.set(), I don't need to scan through the Class's fields after the first check).

You might check out reflectasm if you feel like optimizing something that may not be an actual bottleneck... Wink
http://code.google.com/p/reflectasm/

Offline lhkbob

JGO Knight


Medals: 32



« Reply #13 - Posted 2011-10-26 22:22:24 »

Yeah, although it looks like a cool project, it is probably premature optimization for me, and then I would bring back in ASM generators which is why I avoided Riven's MappedObjects in the first place.

Also, I've added a couple of getting started and tutorial pages and have plans for more (so some links might not work): http://code.google.com/p/entreri/wiki/GettingStarted?tm=6

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2011-10-26 22:29:00 »

I honestly think bytecode transformation is the only way to make an entity system in Java. Without, the sourcecode just becomes too messy to work with. The Java language simply doesn't fit this non-OOP approach.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline lhkbob

JGO Knight


Medals: 32



« Reply #15 - Posted 2011-10-27 05:02:27 »

You might be right, after writing up a tutorial on all the rules you have to follow to implement a component in my system, it certainly can be a little much to keep track of.  

Being the one who wrote the library, I'm perfectly okay with it as is.  I've been leery of byte code transformations for a while because I haven't taken the time to understand them fully.   Maybe it is something I can work with in my next version. For now, the external API is stable and I want to get the chance to really use it in my own games Smiley

Offline Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #16 - Posted 2011-10-27 08:19:08 »

I honestly think bytecode transformation is the only way to make an entity system in Java. Without, the sourcecode just becomes too messy to work with. The Java language simply doesn't fit this non-OOP approach.

@Riven: Can you expand on this a little more? I may have missed earlier discussion in other posts if you shared anything before.

So far I've not seen a need for bytecode transformation in my efforts nor want to really go that way given J2SE / Android compatibility; I assume there may be some difficulty there. I admit maybe I'm missing something here. I've not pragmatically worked with bytecode transformation and things seem just fine without it for the component architecture / ES / and the whole expanded library of components with my efforts (600+ platform components!). Thanks for your thoughts. 

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (22 views)
2014-09-12 09:08:26

Norakomi (55 views)
2014-09-10 13:57:51

TehJavaDev (66 views)
2014-09-10 06:39:09

Tekkerue (33 views)
2014-09-09 02:24:56

mitcheeb (54 views)
2014-09-08 06:06:29

BurntPizza (38 views)
2014-09-07 01:13:42

Longarmx (24 views)
2014-09-07 01:12:14

Longarmx (30 views)
2014-09-07 01:11:22

Longarmx (28 views)
2014-09-07 01:10:19

mitcheeb (37 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!