Component Systems: Artemis style systems vs. traditional fat entities

[Roquen]

If you know how to use a rel. db, a rough clue of the performance it provides and your use-case won’t cause queries to be statistically significant (with your educated guess)…then why the hell not. Get it done the fastest way possible and move on to the next problem.

[princec]

@Catharsis

• Runs anywhere w/ no dependencies and small code footprint
• Data is stored naturally in the format most useful to send to the hardware at hand.
• Logic is not far removed from the data and directly acts upon it
• All code and data can be versioned, modularized, and deployed with one tool chain.
• Refactoring support is super strong for pure Java.
• Cross-compile to iOS via RoboVM (been really impressed w/ LibGDX in this regard lately!)

Hmm well that’s where HSQLDB comes in, so you’ve got runs anywhere, small code footprint and cross-compile to iOS via RoboVM sorted.

The data is stored in whatever method HSQLDB seems to think is most efficient for storing it, so that’s something you don’t need to think about. You just say what the data is, and how to index it.

I’ve seen some interesting tools for versioning and refactoring database just lately since I started doing lots of database work again, and it seems it’s come a long way.

Now… about logic and data being removed from each other. That’s a bit hand-wavy isn’t it? By what measurement?

I absolutely think that of anyone here tinkering with CAs that you should be one of the people giving it a whirl to see how it works out for you as you’ve got direct experience of the “other” way. Failing that I wonder if we could set up a little pseudo-competition here to solve some small, complete, tangible computing problem using trad. OOP, Artemis, and SQL and see what it all looks like and properly critique it. Whaddya say?

Cas

[Catharsis]

@princec

The data is stored in whatever method HSQLDB seems to think is most efficient for storing it, so that’s something you don’t need to think about. You just say what the data is, and how to index it.
Now… about logic and data being removed from each other. That’s a bit hand-wavy isn’t it? By what measurement?

What is efficient for HSQLDB is likely not efficient for the hardware (GPU) or even optimized CPU usage and still needs to be transformed. The data component / POD approach allows the data to be stored locally in the efficient form for the hardware.

If folks think CA is not appropriate for client side development I don’t think involving a database approach is appropriate for the client.

@princec

I absolutely think that of anyone here tinkering with CAs that you should be one of the people giving it a whirl to see how it works out for you as you’ve got direct experience of the “other” way.

Personally, I’m trying to get back to earth again after embarking on the last major round of experimentation! I’ve got my gravity boots on and your rocket fuel will be passed on to the next astronaut. The CA route is more encompassing than just usage for ES. The database approach and application is limited in scope to a subset of ES activities.

I think someone should give it a go, but that’s not me. I am all for comparisons and building up a test suite between different CA and ES implementations including further experimental approaches.