Issues/Questions for Scala Port

[markusmo3]

Well hello there,

i recently found scala and i must say i am in big love with it. So of course i want to create dem gamez with it in an ECS style. So i want to port artemis odb with some tweaks to it to scala. What could go wrong ?

Well first of all, am i restricted to something, e.g. do i have to take the same license? Even though only the general idea is taken ? Because the implementation will differ quite a bit i think, ofcourse it will also have ECS stuff but i recon alot of stuff gets obsolete / can be changed when dealing with scala.

And are there any lessons learned, stuff i should avoid doing, any ideas/suggestions, basically anything to say about this? :smiley:

[marad]

@noobxgockel This is actually funny that you ask this. I've stumbled upon Artemis (predecessor for artemis-odb) a while ago and implemented it in Scala (still missing some small bits like entity tagging, but it's totally usable now). This resulted with scalartemis: https://github.com/marad/scalartemis with the docs here http://scalartemis.readthedocs.org/en/latest/.

As of now the jars are in JCenter repository: https://bintray.com/moriturius/maven/scalartmis/view

Maybe this is all you need to create all dem gamez with Scala :) Your support would be also great!

[Namek]

I believe it's worth to first play with artemis-odb in current state with Scala before totally rewriting it. Functional approach isn't probably as efficient as mutable arrays access. @junkdog made a lot of optimizations in there. I would recommend to just import artemis-odb into your project. You can mix Java classes with Scala classes. The only drawback I've seen is casting collections. Some people join libgdx with Scala and it's still satisfiable.

Note: I have not tried Scala with artemis-odb but I did with libgdx. There's too much needed mutable state in gamedev to receive any benefits from functional approach. And syntax is syntax.

[junkdog]

Well first of all, am i restricted to something, e.g. do i have to take the same license?

I haven't really acquainted myself with the license, I inherited it when I forked vanilla artemis, but it's a pretty permissive license overall.

If you intend to reimplement the whole thing, taking implementation cues from artemis-odb, I'd hardly call it a fork (maybe a derivative work, but I don't speak legalese). A lot of other artemis implementations/ports have different licenses, so go with whatever you're comfortable with.

And are there any lessons learned, stuff i should avoid doing, any ideas/suggestions, basically anything to say about this? :smiley:

Been meaning to write a couiple of blog posts about performance optimizations in artemis, because a lot of them are rather basic, but I've rarely seen them elsewhere. But the short list:

• Go with recycled, zero-based int:s for entity ids; same goes for component types (this was already present in vanilla artemis, and is a straight-forward and efficient solution).
• Inserting/removing entities to/from systems should happen between every processed system and at the beginning of process: saves yourself from having to worry about systems not having an up-to-date list of active entities.
• If you care about performance, bitsets are your friend: as mostly all artemis types can be represented by an integer id. bitsets can serve as a very fast/efficient lookup cache. On a similar note, avoid Map/Dictionary types - slot everything into arrays instead (Bag).
• If I'd rebuild artemis from scratch in java, Entity wouldn't be a class, but a simple int. Pet-peeve performance issue.
• There's nothing in artemis wrt multi-threading.

This resulted with scalartemis

Cool!

Note: I have not tried Scala with artemis-odb but I did with libgdx. There's too much needed mutable state in gamedev to receive any benefits from functional approach. And syntax is syntax.

I haven't used scala myself, only debugged it occasionally (shivers). I also thea feeling a functional approach would be tricky to pull off, at least if you want to run it on mobiles - but it's a hunch, not really sure what's going on in scalaland.

[markusmo3]

Wow thanks for the responses! Helped me make up my mind quite a bit.

@marad Yep your lib looks, its somewhat different from artemis-odb and slightly more scala oriented, but not exactly what i imagined. I love the Idea of the World just being a container of Management Traits tho. All in all your library looks a lot like java code written in scala. No implicits, no use of caseclasses, no operator overload in Bag, no TypeTag and/or Runtime Generic usage, ... So i'd rather ramp up my own design :P

@Namek yea i tried using, but i am that kind of person that if i do something i do it properly and to be honest a simple version of an ECS isnt much writing (compared to porting libgdx to scala for example). The Reasons why i'd go with writing something myself is mainly because i havent done that yet, so i want to get experience with everything that is connected to hosting, publishing and writing a library and then also some Reason mentioned in marads answer

@junkdog yeah i saw you do some bytecode weaving and stuffs but didnt quite understand why and how. A proper blogpost would be reeeaaally nice, i'd read it definitly! Thanks for the short list of optimizations, if i write a lib i'll incorperate all of em, they sound very good. Except the one about multi threading. IIRC all systems in artemis-odb are called on a single Thread, thus breaking a rule of ECS (under system the bolded). Most System dont care about order of execution or other systems, some can handle immutability really well and for the other stuff i found this presentation really interesting. Even though its not about ECS i recon some stuff can be applied to it.

And lasty, junkdog, just try scala! Syntax might be a bit wierd at the start but after understand the basic concepts it really does look like "a better java". I have yet to find a valid argument against that viewpoint :D

Thanks again :+1:

[marad]

@noobxgockel Keep in mind that it was designed with speed in mind (at least where I could see oportunity to optimize it). Of course using vals and case classes can be fun, but can also cost our valuable time :)

When it comes to implicits - please be VERY carefull with them. The rule of thumb is: the user of your API should know NOTHING about implicits. As for TypeTags and ClassTags - they are usefull and I wanted to use them, but unfortunately they had "issues" (they work only in certain cases - otherwise you could get the generic type tag).

I'm not sure what do you mean by operator overloading in Bag. What operators you suggest to overload?

Anyway - I'm curious what will you come up with so I'd be grateful if you notify me when you put something together :)

PS.: I'm planning to research some idea of mine - Event Driven Component Entity Framework - in foreseeable future. The idea is based on the very presentation you linked in your post :)

@junkdog Please write the posts! :+1: I would read the hell out of them :)

[junkdog]

IIRC all systems in artemis-odb are called on a single Thread, thus breaking a rule of ECS (under system the bolded). Most System dont care about order of execution or other systems

Ah, I think it's an unfortunate phrasing - the series describes ECS:s on a more conceptual level. I don't think Adam Martin meant an actual thread/co-routine, but rather that systems are self-contained and autonomous. The way it is now, the World is a system executor, processing each system sequentially.

You could resolve the dependencies between systems and components automatically (at least when supplied with some metadata), but you'd still need benchmarks and tooling/means of introspecting what's going on under the hood. Once you go multithreaded, the risk of false sharing means you have to worry a lot more about memory and ownership - and this burden will extend to the end user as well. So, proper support tools are essential here.

In my experience, most systems actually do care about execution order:

• There might be several systems updating certain components, Position being one such
• If the positon data is copied to the Sprite, this depends on position being fully updated.
• All render systems tend to rely on a strict order of execution

While you could run all systems dealing with, say, Position on a single thread, that means you need to create a set of all component types making up the aspect of affected systems. Several of these systems, in turn reference a lot of other components, so we'd need to pull in those systems on this thread too. And then we have to repeat the process until no more systems are added (would prob require segmenting the processing round into distinct synchronization steps, to avoid having all systems on a single thread).

That said, I''d love to see an open source ECS with a working multithreading model. If I sound pessimistic above, I'm not trying to dissuade you - it's more a reflection of my brooding on the subject over the past few months. I don't have much experience with threaded code, and no experience writing such code in order to optimize general gameplay.

And lasty, junkdog, just try scala! Syntax might be a bit wierd at the start but after understand the basic concepts it really does look like "a better java". I have yet to find a valid argument against that viewpoint :D

I chickened out of scala when I heard of kotlin :)

PS.: I'm planning to research some idea of mine - Event Driven Component Entity Framework - in foreseeable future. The idea is based on the very presentation you linked in your post :)

Report your findings, it was regarded as sub-optimal in the past, but there might be clever tricks to go about it. Just make sure to limit throughput, and pool or flyweight over your events. (100% event driven would probably still scale poorly).

@junkdog Please write the posts! :+1: I would read the hell out of them :)

Thanks :) I'd like to release 1.0.0 first, but I'll try to put together a short series during summer/end of summer. Spread too thin atm.

[DaanVanYperen]

@junkdog we should write a book! ;) If you do the performance bits, I'll do leveraging ECS for Jam games and Enterprising your ECS. ;) Wheee.

Scala is a lot of fun. Feels like a kid in a candy store. Never pursued it due to cross platform limitations. With teavm, perhaps.? You'd have ignore most functional features to get anywhere near odb's performance on mobile platforms, but you could still leverage Scala surpass it in other areas, like ease of use and lack of boilerplate.

odb's design is not very conductive of threading, but I'd love to see your incarnation of Artemis get it right!

[junkdog]

@junkdog we should write a book! ;)

Now, now - there's nothing wrong with a blog - think about all the pain and suffering that a book would bring! Sometimes, it's best to step away from the money (authors still get filthy rich, right?).

Have you looked at teavm recently? Would be lovely to dump gwt - it should give a slightly more flexible lowest common denominator.

[DaanVanYperen]

(authors still get filthy rich, right?).

261

Have you looked at teavm recently? Would be lovely to dump gwt - it should give a slightly more flexible lowest common denominator.

230

[DaanVanYperen]

Answered! No obvious remaining actions.