Utility library for an entity system

[nanodeath]

Are you interested in adding helpers for Ashley? I have a few that might be a good fit for ktx.

[czyzby]

I never used Ashley, to be honest, and it seems that Artemis ODB is a much better performing alternative. (This is what VisEditor runtime seems to be using, for example.) I'd probably go with Artemis extension when starting from scratch with an entity system utility library.

That said, if you already have some working code and willing to write a few unit tests for that, I could certainly create another KTX module.

I'm wondering if fully Kotlin-based entity system could potentially benefit from features like inlined methods or reified generics in terms of performance and readability. Writing an entity system seems like a fun side project.

[nanodeath]

True, Artemis ODB does seem to have better benchmarks, BUT they're benchmarking and older version of Ashley (1.6.0) than the current version (1.7.3). 1.6.0 was released in July 2015, while 1.7.3 was released in September 2016, and there were 55 commits between them. Plus, this gem:

Things that might concern

• Overall, ashley-realted benchmarks may be improved; I'm not very familiar with the framework.

Anywho, I'm mainly vested in Ashley because it's what I happened to be using 😄

I actually did experiment in creating my own entity system as well, and supports "must have", "must not have", and "has at least one of" entity queries. Unlike Ashely, it uses the regular JDK types except for ObjectIntMap, which was too good to pass up. It's under 200 lines of code, too, so in terms of size, it wasn't too much work 😉 Not sure how it performs,

[czyzby]

I see. Creating a new KTX module is a matter of adding a new directory, including its name in settings.gradle file, adding build.gradle with listed dependencies (if any) and gradle.properties with module data. It should eventually look somewhat like this:

> ashley/
  > src/
    > main/kotlin/ktx/ashley/
      > ashley.kt
    > test/kotlin/ktx/ashley/
      > ashleyTest.kt
  > build.gradle
  > gradle.properties
  > README.md

Even though we compile against a specific dependency version, we usually include most dependencies in provided scope to avoid jar hell in client applications and let the users choose their preferred library version (even though using a different version is somewhat risky - fortunately, VisUI and LibGDX rarely break their API).

Looking forward to your pull request. ;)

[Jkly]

@czyby I have some extension functions and a builder DSL for Ashley entites that I'd like to open-source - is it something that you'd be interested in if I create a PR?

[czyzby]

@Jkly Sure, go ahead. Make sure to use develop branch and add some documentation (README, CHANGELOG, code docs of public API).

[Jkly]

Thanks @czyzby, I'll check out the contribution docs too. I normally use Spek for unit tests, but should I stick to Junit here?

[czyzby]

Well, it's a new module and it's not like forcing some third-party library on the KTX users. If Spek is fully compatible with IntelliJ and Gradle, I don't see why you would have to use JUnit instead. I wanted to look into Spek for quite some time, seems like a good opportunity for that.

[czyzby]

@Jkly Thanks for the implementation of ktx-ashley - much appreciated. Can you go through my latest commits and see if it's OK? I'm going to close this issue if you think the module is ready.

[Jkly]

@czyzby The changes look good, thanks!

[czyzby]

The ktx-ashley module should already be available as a snapshot release (1.9.6-SNAPSHOT). Thanks again.