Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (113)
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   
  Show Posts
Pages: [1] 2 3 ... 7
1  Game Development / Newbie & Debugging Questions / Re: Libgdx - Tiled Map object properties on: 2014-09-15 02:16:12
getKeys() returns an iterator which you need to use to access the collection. In the code you posted every call to getKeys() is returning a new iterator and is why you are only getting the first key and why that loop won't terminate.
for (String key : o.getProperties().getKeys())


for (Iterator<String> iter = o.getProperties().getKeys(); iter.hasNext();)

Since it's a java.util.Iterator returned you can use the top enhanced for loop.
2  Game Development / Newbie & Debugging Questions / Re: Best practices for passing variables around on: 2014-09-15 00:23:48
IMHO composition is the answer. I assume you may have some sort of update / game tick callback from your "Game" class which each entity receives. For a more traditional OOP / explicit composition approach I'd make a ResourceHandler that can be added to the entity which gets triggered with that update tick / callback. The Entity class itself doesn't know anything about Game or ResourceManager, but ResourceHandler does have a reference to ResourceManager (passed into it via constructor or other method). All you have to do at minimum is figure out how you can add a ResourceHandler to an Entity perhaps under an "IClockTick" interface or whatever defines your update method as an interface. This way internally your Entity class also knows nothing about ResourceHander and simply finds all the IClockTick objects and calls the associated update method when the entity gets the update callback.

As far as the ResourceManager goes I'm a big fan of generics and generic methods. Let's say your tiles are integer X / Y based. Potentially you could have a method in ResourceManager like:

public <T> int getCount(int x, int y, Class<T> resourceType)
   // find tile x / y however you have it stored
  Tile tile = findTile(x, y);
   return tile != null ? tile.getCount(resourceType) : 0;

resourceManager.getCount(20, 20, Tree.class);

... Your Tile class can have the same getCount method as above without the X/Y variables.

I'd start to try and figure out how to remove the Game reference from every single class if you can spare the time. The less each aspect of your game knows about the game and other sections of your code the better. At minimum you can use constructor injection (manually). I'd also start figuring out common interfaces for major sections of your game code such that if necessary you can swap out implementations for testing or developing new game mechanics / features, etc.
3  Game Development / Game Mechanics / Re: Entity Component Manager on: 2014-09-12 09:06:46
final does mean "const" when applied to variables, but is even stricter than C++.

final on a method or class prevents further modification by subclasses which is important for consistency of a component architecture.

I noticed you are probably new to Java with naming "add_comp" method as typical Java style is "addComp"..

Welcome!  Grin
4  Game Development / Game Mechanics / Re: Entity Component Manager on: 2014-09-12 02:00:10
Handling the unchecked cast how you are doing currently is fine as long as the "store" Map is encapsulated such that components of a different type can't be added to it surreptitiously. An example of that could be a child class of the "manager" class having access to the collections. In the code you listed below you didn't mark add_comp final for instance, so a child class could change the behavior if access to the collections were possible.

If add_comp and comp methods are the only way to access those internal implementation collections then you are guaranteeing type safety by the method definition / class type for external use of your API.
5  Game Development / Game Mechanics / Re: Entity Component Manager on: 2014-09-10 22:11:14
You also should use generic methods. Following you manager -> comp method example:

public final <T extends IComponent> T comp(IEntity entity, Class<T> compType) {}

IComponent being whatever your base component interface type may be. I suppose you could just leave it T and be able to stuff any objects into it. I've found in my ES efforts that there is a benefit to having a base component interface with a few extra utility methods useful for a component architecture defined over just Object.

IEntity can be your base entity interface. You could also pass in any other ID (integers have been popular in various blog posts on ES). In my ES efforts I actually store the components internally to an entity or "component manager" and don't have a separate entity object really.

The nice thing about the above is that it provides for a generic, but explicit return type based on the Class provided when calling the method.

Postion p = manager.comp(entity, Position.class);

Another nice thing is that you can have wildcard / generic collections backing the internal implementation of "manager" such that if you only have typed getters / setters like the above "comp" method then you can do generic type casts safely in the "comp" method

You can also use the compType as an key into any backing collection (HashMap, etc.)

ES / component architectures are definitely possible in Java.
6  Discussions / Miscellaneous Topics / Re: HighSchool classes on: 2014-08-09 01:24:28
Since you are going to take Algebra you'll be inundated with solving systems of equations from the implicit angle where your variables x, y, & z are in the same equation. That is one way to structure equations. There is also the explicit form called parametric equations which provide separate equations for each parameter which achieve the same result as the implicit form except is much easier to manipulate because the one variable usually is (t == time).

Example for a circle...
Implicit form:
x^2 + y^2 = r^2

Explicit / parametric form (t == time):
x = sin(t)
y = cos(t)

Which one do you think is easier to manipulate programmatically?

Want to create a circle moving through a cylindrical motion moving forward in time... Guess what...

z = t

As time moves forward you move in the z-axis making a circle...

Parametric math is extremely helpful for creating patterns, paths, and working with projectiles or particle systems.

The above also defines the unit circle which is something you should internalize along with the unit sphere in terms of rotations and other fun stuff that will be rather handy for 2D and 3D game dev.


I was pissed that in all the math classes I took in high school it wasn't until I was in a calculus class in college that offhand one exercise set had a few problems doing calculus on parametric equations which were not introduced as something unique; just more problem sets to plug through. I immediately saw the independent variable (t) and saw how it related to all sorts of useful graphics use cases. This could be taught to 9th graders yet for whatever reason unless you have a savvy teacher or good math book that relates to computer graphics concepts most highschool algebra is plugging through exercise sets with implicit / systems of equations busy work.
7  Discussions / Miscellaneous Topics / Re: I once was a DJ (~50 hours on SoundCloud) on: 2014-08-04 22:23:17
No way, I've listened to your music before! I really like the music from that 2002 event, really wanted to go there and dance Grin

Right on.. That is actually pretty cool especially since I haven't put anything out since '07. I wouldn't expect anyone I meet today that is into electronic music to know anything I've done in the past, etc. With the SoundCloud account I just uploaded everything I had including many mixes that weren't officially released like the early trance stuff and some in between that for one reason or another didn't make the cut. I know downloads for the sets from my server was in the tens of thousands ~50k at least directly and that they were on plenty of resharing mp3 sites.

I don't think I mentioned much about the music stuff directly on JGO though I might have in the past. I started lurking on JGO in '02 and joined a couple years later. 

I like the live mixes at bad monkeys  Grin
I see that you have multiple talents.

Thanks, Julien! The Bad Monkey mixes were from the club night I ran in San Luis Obispo during college. It was a pretty wild time and scene that got started up was vibrant for being in the middle of nowhere effectively. We had 200-300 people of all types showing up weekly for about a year straight which was a trip because doing that in San Francisco or any big city would be super hard. The 6th week into it all we had the first international DJ (Chris Liberator) perform and it just blew up from there and regularly hosted performers from SF, Sac, LA (state wide).

Hah, if anyone is following the US scene today. There was this kid that showed up to my club night and DJed house who now goes by Wolfgang Gartner. I always knew he was going to be a success even from his early production days because he was in tune with what was popular and had no qualms about following that. I attended a house party at his parents house and listened to the then house music he was producing in his bedroom knowing that if anyone was to break through from the SLO scene at the time he had a chance.

Pretty much anyone that made it from my generation (in San Francisco as well) more or less followed popular trends to make a buck and turned their back on more original angles if they pursued them at all. You gotta do what you gotta do, but I could never stomach that. As things go though I always had an outsider perspective on music and preferred the experimental side of things. For me that mainly was and still is large scale spatial audio from a tech angle. After working reasonably hard for 10 years on the music tip I realized I wasn't going to break through locally or otherwise (got plenty of angst against the local SF scene).

I produced, engineered (mastering / recording), paid for, and pressed my own record to attempt to start an industrial-techno label from the US / west coast in '03... No US distributors out of 9 accepted the record and I still have 400 of them in storage. I faced setback after setback until it wasn't worth continuing at least from a DJ, producer, promoter side of things. I could have tapped producers from the London acid techno scene to do a remix for the record and it would have then likely been picked up (another SF producer did this shortly afterward), but I wanted my first release to be my own... and I sure did get to keep a lot of copies...  I'll be back at it in one form or another at some point with a vengeance.

Basically I was in the wrong part of the world for the stuff I was trying to do and wasn't in the environment where anything I'd do would make a difference. After performing at Defcon in '06 which is a moderate national event a couple of German fellows came over and congratulated me on the set and mentioned that I sounded just as good or better than all the big German hard techno producer / DJs they were used to. I thought it was funny because they mentioned that they didn't think there was anyone in the US doing what I was doing. ;P

I always was geared toward pushing things forward and actually innovate and for me because I can this includes the tech side of things which also means the best is to come. The most interesting thing when dealing with producers like Amok and Natus was that both of them had their own stroke of luck that propelled them into the spotlight. Natus had a really good head on his shoulders about it all. I was nicknamed "the brain" and was actually surprised how much more I knew about audio engineering / tech / etc.. Alas out in the ass end / wilds of the electronic music world.

Putting all of this in perspective and the time it'll take to get large scale spatial audio to something that is consumer friendly does frame things on why I was open to going down the coding hole I dug with the component architecture / experimental route that I'm just wrangling myself back around on after ~5 years... I had the time to experiment given the economics of large scale spatial audio. I'm still pretty stoked that something is going to come of it. I plan to get back to working on music too when the rent spectre is vanquished. Sadly picking SoMa / SF for the studio location means big rent spectre.

With perfect hindsight I could have done things differently, but am not disappointed thus far as all the really bright things are to come still and I think they will be much brighter than just a music career.  Grin

I started TyphonRT back in April '03 and it was immediately useful. It started as a 3rd party client to SuperCollider (real time audio synthesis framework) and provided OSC communication with a Java 2D GUI. The only live performance I did with it occurred in June '03 (more info at the link):

And that would be the experimental side of things from a music perspective.  Cheesy

8  Discussions / Miscellaneous Topics / Re: I once was a DJ (~50 hours on SoundCloud) on: 2014-08-02 19:36:19
Speaking of acid techno.... I just saw that ShaderToy added audio support with shaders... Check out this acid techno shader jam:
9  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-08-02 19:18:16
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.

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. ;P 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.
10  Discussions / Miscellaneous Topics / I once was a DJ (~50 hours on SoundCloud) on: 2014-08-02 18:52:20
Well, I once was an active DJ and promoter of underground electronic music. Mostly "industrial-techno" or the cross section of powernoise, hard techno, and non-cheesy hardcore (there's a difference!). As things go when things got serious with building my R&D music studio (see for picts) I had to pull back from my music endeavors, especially promoting events, at the time '08. Still don't have time for it and well the stuff I'm into still isn't exactly popular out here in the US / west coast / San Francisco. Early on I hosted many London acid techno producers such as Chris Liberator, DDR, D.A.V.E. the Drummer, so definitely was inspired by acid techno back in the day. Here is a video of the last event I hosted in San Luis Obispo before getting out of college... DDR rocking a hardware set... ;P

Back in SF I did host luminaries in the hard techno scene toward the end of my run including ArkusP, Robert Natus, and DJ Amok from Germany. I guess the tag team set I did with DJ Amok at Stanford radio KZSU was the widest listened one.

Last year I posted all my live and studio DJ mixes from vinyl on SoundCloud and some early production work too along with a live experimental performance. There is ~50 hours of music up there for anyone here that likes this kind of stuff. Check it out if it's your thing and you need some tunes to code to... all night...  Cool
11  Discussions / General Discussions / Re: So... state of the art 3D "engines" in Java on: 2014-08-01 21:15:02
To get anything close to Unity functionality from the tooling perspective and runtime flexibility a component architecture is pertinent.

Unity itself licenses and integrates various 3rd party middleware. SpeedTree being an example. If your effort was commercial I'd look at various 3rd party industry standard middleware to integrate. Sundog's SilverLining (sky rendering) and Triton (ocean / wave rendering) could be good additions to SpeedTree.

For indoors I'd do a patchwork of separate BSPs (to my understanding this is what the Unreal engine does; haven't looked at Unreal 4 / recent source) which can be streamed.

Outdoors indeed would be Octree plus heavy streaming.. Try and work out an editor like Grome ( Don't know if that company would license editor code.

Pulling together an editor for outdoor / indoor would be a challenge.

12  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-08-01 20:21:22
What Riven said of course... and..

Does it actually need any particular use case?

Performance would be one. I mentioned other reasons / answers to your question prior why I'd prefer the CA / query mechanism to be Java code. Some of them:

- 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!)

Looking at the classes of "problem" solved by CAs and entity systems here what I see is just basically set operations on relational data.

That is an aspect to it all, but one of many concerns. The runtime aspects of being able to store components by extensible enum and use that same enum as data defining a category implicitly for event distribution in the EventBus is super powerful use case. 

I'd be down to see someone experiment in that direction, but not for me..  Grin
13  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-31 20:17:38
I spent a great deal of time profiling Artemis to ensure its design wasn't bottlenecking the performance, and I did not find it lagging behind its OOP alternatives, e.g. dozens of thousands of entities.

What you did with Artemis especially considering the experimental / trailblazing aspect is a complete success. For the type of games (2D / platform) created with Artemis it works well. I was very impressed when I checked out Naturally Selected 2D running on an iPad2 which is the lowest specced device I've tested with so far.

Any discussion I'm contributing to here is more or less aimed at floating ideas around future directions. Saying that Artemis is a really good "type I" ES does not detract from what was accomplished.

If you have more than a dozens of thousands of entities, hundreds of thousands, then you're doing something terribly wrong. No game should have that number of entities active in its world at a given time.

All I wanted was a easy design, where I wasn't schizophrenically dependent upon some hierarchical OOP structure and was fast enough.
But that doesn't mean Artemis-design is suited for all. It's quite rigid when it comes to how entities are composed.

I think you could say.. No 2D game should have that number of entities active in most usual game play scenarios. All of the Artemis related games I got to compile surely fit those assumptions.

For a 3D game that is partitioning a larger world including partitioning the ES then entity counts could be in the hundreds of thousands (let's say ~15-20k per region), but of course in most situations only updated for regions near the player(s). The design I'm working toward is meant to support a larger general use case, so the additional data oriented packing and efficiency will make a difference. I'd say a fair assumption about "type II" ES is that new architectures are less rigid and increase the throughput and conceivable data parallel aspects of the ES out of the box. In the case of my efforts integration into the larger engine architecture is much easier since the CA relationship is inverted with the CA being a superset of the ES.
14  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-31 19:51:09
You're thinking about it the traditional way.. ;P
Yeap.  And so are the majority of game industry leads & technical directors.  It's significantly less work, complexity and is significantly faster (for the statistically significant..otherwise who cares).

You are basing your arguments on conjecture at best. There are several high profile AAA game studios that are using CA techniques. There is no basis to the "significantly less work, complexity, and speed" comment. The CA approach is crossing the chasm in most new engine development with a reasonable percentage of game studios.

I think you may be complaining that historically the "best practices / design pattern"
No. I'm complaining that CS has a whole has stepped way from problem solving and into reusable massively complex systems and generations of programmer understand very little about programming in the pure sense. As an example around 2000ish I asked new grads from highly reputable universities questions like:  "Visitor and command patterns are the same.  What's the mechanism?"  I think one 1% could give an answer.

Your anecdotal evidence or point has no connection to CA or the original discussion and attempting to connect it to "best practices / design pattern" related thinking.

I can tell you this much though since I was finishing my CS degree around that time at a reasonably reputable university. Design patterns weren't taught in the CS curriculum outside of perhaps a few professors making references here and there. Only those who had the motivation to learn outside the curriculum had a solid clue. There was no course dedicated to design patterns though I do agree that more or less undergrad programs at universities are not exactly graduating highly competent developers.

More or less I had to cut short our discussion because your replies are divergent from the original topics at hand.
15  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-30 23:11:57
What exactly do you mean by processing of entities in a "fully composed state"? In both artemis and ashley, entities are only a little more than glorified integers (entityId - and some additional metadata, not necessarily stored by the entity itself). 

EntitySystem and EntityProcessingSystem which forms the basis for a lot of Artemis system usage from examples I've seen (the best being Naturally Selected 2D) iterate over entities sequentially and retrieves individual components to complete the logic at hand. Regardless of where the components are stored this general approach will have limits in speed especially considering the case where when one wants to broad phase process. In this case with Artemis each separate phase iterates over all entities multiple times while potentially needing to retrieve multiple components at each stage. The only thing that makes this a problem with Artemis / Ashley is that it's baked into the architecture and is the enforced way of doing things. At least it looks inflexible from just reviewing the code.

I really do need to get more of an intuitive usage understanding of Artemis particularly your "odb" effort. I'm doing this right now actually in converting NS2D to Android / iOS builds for some demo work for a client while integrating their custom game controller (a touch screen on the back of a tablet). It's kind of neat. Touch on the back controls the jet pack / movement and touch on the front anywhere controls the gun. I'm doing the modifications in the coming couple of days, so hopefully I'll gain better visibility working with a good example, etc.

Or is the hint in your definition of "Type II Es", being "fully generic" and having "self-modifying capabilities" (components as more than data-holders, I guess) - not entirely sure what either implies.

In my efforts the self-modifying behaviour is achieved by systems that are potentially activated when the CA API is invoked on a component manager. This allows entity management and classification to be done in a more dynamic fashion than baking these patterns into the ES API (type I). In the case of packing components for more efficient traversal what I'm aiming to do is when an entity is added to a manager the dynamic classification / packing system is run and stores the packed content in a _different_ component of all combined & relevant entities added to the manager. When processing a frame a system can then just retrieve that one packed component and work over the packed data (ideally a primitive array). Remove the entity from the manager then it removes the tracking from the packed component and stores the packed data back into the original component.

You are brave with integrating byte code weaving and such. I've steered clear of that approach for developer setup / ease of use. The efficiency you are trying to achieve with PackedComponent is an interesting attempt. I'm just referencing this link ( for reference. The problem is not so much storing packed data, but making sure systems can iterate over the packed data and not make a bunch of method calls or component retrievals. This doesn't seem possible currently with your efforts. I'd also generally be concerned about storing the packed data as a static array / ByteBuffer in the component class itself. This will not play nice with partitioning an ES. - Nothing complete, but it's a start.

Thanks for doing this... I'll take a look and maybe one day have some time to do some comparisons with my efforts.
16  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-30 21:44:08
Quote from: Roquen link=topic=33652.msg319819#msg319819
I'd say data oriented is a cache oblivious (or conscientious) approach to data layout based on how data is transformed (access patterns).  It also pretty much independent of other design choices..likewise for data driven.  ....   Sure, nothing to do with component based.

We'll go with "conscientious"..  Cheesy It can be independent, but if the larger architecture naturally supports data oriented concepts it's easier to apply them broadly.

Quote from: Roquen link=topic=33652.msg319819#msg319819
It allows one to query a component manager (CM) / container and get back an iterator over all components stored by their meta-type (all data, all systems).
...and store it in a tightly packed array or perhaps byte buffer or whatever data structure that is the low level DOD form.
Performing a query for something you know. (again ignoring middleware).

You're thinking about it the traditional way.. ;P

While I'm still adding stream / filtering type mechanisms into the CA. The idea is to be able to do a query like "give me all the data components that also have the @SerializeMeOnNetwork annotation" in order to serialize an entity or whatever and send it over the wire. This implementation is a little less general purpose than the java 8 streaming API. I'll probably limit it to type and annotation based queries. Maybe some bespoke processing though I'm keen to keep things fast on Android.

It makes possible generalized systems of a larger architecture while maintaining reasonable speed. Serialization is one of the larger use cases from a design perspective. On my side.

Quote from: Roquen link=topic=33652.msg319819#msg319819
The whole component based thing is really rooted in modern "best practices/design pattern-y" think...
Is that a bad thing? For JGO it seems like a poison pill for more than a few.
Yes it's a insanely bad thing.  I'm not sure what you're referring to as a poison pill however.

I get a ton of knowledge through following general thought leaders. Most recently in the past ~3 years the whole mechanical sympathy scene / re: Martin Thompson  and co. Turns out a lot of what the HFT community is doing has applications to the game dev / interactive media scene.

I think you may be complaining that historically the "best practices / design pattern" scene for Java has been rooted in the enterprise side of things where there is mostly dubious value to game dev, etc.

Quote from: Roquen link=topic=33652.msg319819#msg319819
Isn't that the promise, traditional OOP in the 90's included, that is sold to management regarding adopting new principles and technology.

The big difference is that the traditional OOP direction didn't deliver on this promise. Implicit CA + EventBus does.
Yeah and the goal of that promise it to service the bulk of programming jobs which is for project with much longer lifetimes than engineer turnover rate.  It the most expensive method in terms of both engineering and CPU time but the reduction in risk makes it worthwhile from a business standpoint.  But this isn't something to focus on in education or literature because it's roughly the equivant to coding conventions.  Anybody that can program can pick it up in approaching zero time.

What you just recounted above is the myth of the false promise of OOP.  OOP has not reduced project failures.  Attention to detail and rigorous application of such is what succeeds and sadly anybody picking up programming categorically lacks this and most never achieve it.

I can refer you to many other debates online, but kind of feel we don't need to have one here on the matter..  Grin

Err... Actually to stop spinning the wheels here on the rest of this particular post, so I'll end my reply here.. It seems we have differing opinions and continuing will dilute the larger topic.

Well yeah... and this
I keep forgetting.  The argument "OO isn't good enough so I use component based" is flawed.  Component based is OO.

No one is saying it's not OOP at least for Java, but by adding a CA API that is well defined and generic this unlocks implicit composition which is something stock Java / re traditional OOP doesn't provide.. It's such a big game changer that it warrants being called COP (component oriented programming) versus OOP so folks don't get it confused with inheritance / or explicit composition re traditional OOP.
17  Discussions / General Discussions / Re: So... state of the art 3D "engines" in Java on: 2014-07-30 19:20:22
I was wondering what the current thinking is on 3D engines' design might be these days.

I'd say there are many dimensions to this and I'll answer from the perspective of what I'd build..

For outdoor environments I'd focus on octree partitioning with an emphasis on texture / geometry streaming and further tessellation for enhanced detail. For indoors / non-destructive you simply can't do better than portal/bsp/pvs to my knowledge. One could still support some level of streaming & dynamically loading BSP and other data for expansive indoors environments.

Technologically speaking especially for outdoor and streaming data parallelism is crucial. This means supporting multi-threaded GL and CPU side architecture. From a Java perspective I personally would really like to start using the Disruptor on the CPU side of things which would handle anything routing between the disk and the network to threads streaming through to GL. I am bit sad though that the Disruptor doesn't work on Android due to its reliance on sun.misc.Unsafe. If Android is a target and it should be this means sticking to OpenGL ES for the time being though that could be different a couple years from now and things may properly converge to just OpenGL across all mobile SoC/GPU vendors. This means though supporting OpenGL ES 3.0 and the GL threading API and while one is at it all the other goodness 3.0 brings.

OpenGL AZDO is important of course. There are many aspects there that support texture streaming / binding concerns. I'd figure out the limitations of MultiDrawIndirect. I really wished that the first Android Extension Pack covered AZDO extensions. I'll be able get started with them on the K1 though since it supports OpenGL 4.x too. Though I'll have to think about how the majority of the engine work must remain compatible with GLES 3.0 right now.

Compute shaders and OpenCL is very important. Particle engines will all be compute based. In fact the first demo I'm going to port to Java is this one:

For other modern GL demos check out all of them:

To have any chance at maintaining an engine now and into the future modularity must be a concern from the get go or go the way of all past Java engines. Component architectures (CA) are key in this direction IMHO. If you don't think so, well, I can't help you there much. Wink A CA is flexible to support structuring both the engine subsystems at a high level that is compatible with data parallelism in addition to other aspects like entity systems. It also happens that it supports various rendering paths and hardware diversification concerns which is quite important for long term evolution of an engine. It is what is going to make relatively painless my efforts to support OpenGL ES 3.0 for the majority of Android devices and have a GL 4.x path compatible path with the K1. It also makes tooling possible hence the nice user experience Cas also mentions when he speaks favorably of Unity.

I'm so excited that I get to start down parts of the rabbit hole above tomorrow when my Shield Tabby arrives.. Cheesy

The only real shortcut is picking a specific visual style and focus on gameplay...

Gameplay is king at the end of the day. From an indie perspective one could consider procedural content generation and have great gameplay.

The first example that pops to mind in regard to picking a specific visual style and procedural content is Love:

I never have gotten around to checking it out though so, I'm not sure about game play.

What I think would really benefit the larger Java game dev community is as many folks as possible getting their hands some of the leading tech today (Right at this moment on Android that is the Tegra Shield Tabby, desktop there are various high end GPUs to pick) and start building new engines that may not be compatible with the wider ecosystem. OpenGL ES 3.0 should be the absolute minimum supported for new engine development right now and experiments with OpenGL 4.x should occur on mobile and if you are on the desktop only ignore anything that isn't the latest GL 4.x point releases.

18  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-26 10:50:14
It doesn't half sound like using Java for this is like whacking a round peg into a square hole with a sledgehammer. ... All the complexity and cognitive blocking appears to stem from the problem that Java, the language, is totally unsuitable.

Except that it is and has been for almost 10 years. Generics pushed to the edges via generic methods provides the language mechanism and is supported everywhere Java is these days.

It's crying out for a DSL.

I'm actually quite excited to one day getting around to combining my Java CA w/ Scala. DSLs being driven from the Scala side of things.

Trivial example - runtime composition. There is simply no way to express this in Java at compile time let alone an easy way to compose things from separate classes.

In my efforts there is a well defined CA API that can be used programmatically. Annotations are used at the class meta-data level for specifying certain constraints as necessary. For runtime loading I use XML since it's available everywhere with a basic key value organization along with conditional directives (IE Android OS version, device family, screen size, etc. etc). This allows the runtime and all conditional variations to be defined clearly externally thereby a uniform runtime. This loading mechanism could be driven by anything including a DSL via Scala or whatever is clever.

Furthermore there appears to be considerable emphasis on what amounts to manual memory layout in certain circles; again the sort of things a machine should be best placed to figure out at runtime.

Let's consider preparing workloads for OpenCL. One would transform the data from high level components into whatever is appropriate for the characteristics of the hardware one is running on after one queries the hardware. In the graphics case perhaps it's slotting all relevant data from an entity into a UBO (& other buffer objects) friendly data structure spanning all entities.

Java was designed to do small-scale problems in the OOP domain efficiently;

Then the language evolved. It took 5 years for me to realize the possibilities and travel down this path. Generics as things go was slowly adopted in its most basic form (parameterized types) and generic method use is still not prevelent in many projects. With Java 8 we are now seeing many of the new APIs use generics in advanced ways. For 10 years though it's been possible to do some pretty advanced stuff. 

The language is evolving once again, but sadly not available on Android nor will it likely be. This is particularly even why it's super important to pull as much from generics / annotations as possible since it runs everywhere.

you really need something completely different to express what you're trying to do in a way that is a) efficient and b) comprehensible and c) better than the OOP paradigm

It's all there and A, B, C is well covered..  Cheesy Technically, I still consider what I'm doing as still OOP, but kind of more like OOPs last stand. In some ways connecting the dots from the past with an eye toward the future.

In fact the more I look at the problem the more it becomes apparent that SQL would probably have been a better place to start from.

Perhaps, but the CA is a basic database. In my case a Map of Maps. One for single component storage and another that resolves to a list of components stored by type. There is a consistent query API and its fast. The CA is an in memory structure and while there may be in memory runtimes for SQL the data still needs to be transformed to the hardware one is using. It's best to use the in memory Map of Maps in Java. The ComponentManager implementation is ~3.5k lines of code and runs everywhere Java does.

Another big win for Java and splitting out data components is that by doing this one creates schema and storage that can be versioned as necessary.

Let me count the ways...
SQL gives us:
The ability to specify the data but hides the actual implementation of its storage and access away
The ability to specify how the data relate to each other in the form of relations
The ability to relatively quickly and easily rearrange data*
The ability to select arbitrary subsets of that data and process it in parallel
and so on. Win.

These basically ring true with a proper CA too.

* Occurs to me that no modern SQL engine currently has any serious refactoring support. There's an opportunity...

And this is the big win for Java regarding the tooling available.
19  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-26 08:35:36
Component based and Data oriented are independent.  Data oriented is pretty much required for high performance for anything over modest data sets.

Actually when I mentioned "data oriented" above in regard to blog posts on ES what I meant was a metrics based approach. IE actually measuring the efficiency of various designs.

Regarding your comment above I'm sure you will not like my answer as I don't agree with your conclusion. A component architecture (CA  persecutioncomplex) at least in how I've gone about it is high level data oriented design. I'm not the only one mentioning this:

Splitting data from logic at any level of an architecture allows one to focus on how to access it and better organize it for processing. In my efforts I actually store components via meta-type and type. This allows all data components to differentiate themselves even though this is manually enforced in component design. It allows one to query a component manager (CM) / container and get back an iterator over all components stored by their meta-type (all data, all systems).

The new ES implementation in my efforts splits apart entities (which are just a CM; there is no "Entity") and indexes all components from all entities added to the entity manager CM. This allows traversal over a particular component type for all entities directly instead of processing each fully composed entity sequentially. As previously mentioned there is also the opportunity when adding an entity to an entity manager to transform the data stored in one or more independent components and store it in a tightly packed array or perhaps byte buffer or whatever data structure that is the low level DOD form.

Basically a CA provides a high level / human accessible form to organize and manipulate data. It also can also deliver plenty of performance without transforming anything to a low level format.


I suppose that brings up an interesting distinction in classifying ES. None of this is rock solid terminology, so I'm curious if folks have any input. I'll classify Artemis / Ashley as type I ES. Type I basically lending themselves to having distinct structure such as having specific classes like "EntityManager", "Entity", "EntitySystem" where processing of entities occurs sequentially in a fully composed state. A type I ES often has hard coded classification schemes baked into the API that can't be altered. This is the aspect / family classification in Artemis / Ashley. In this case the CA elements that may be marginally present are hampered by a hard coded relationship to the classification scheme.

Type II ES are fully generic and are based on an implicit CA that has self-modifying capabilities. There is no "EntityManager" or "Entity" class that contains specialized logic or any hard coded classification scheme. The potential self-modifying behavior of the CA itself provides dynamic classification of entities along with an optional transform of high level data components to an optimized format automatically when an entity is added to the CM which is extended by its own internal system component that activates in this process. This allows for bespoke system components of the entity manager CM to work over this optimized data set of all entities at once.

In my efforts my first stab creating an ES ended in a type I ES (sequential processing of fully composed entities).  Since I saw the usefulness of the approach for proper modularization I promoted the CA to be a superset of the ES implementation. I added the self-modifying aspect to the CA for other purposes not directly ES specific. In that case a way to inject a parent CM into children components without hard coding that into the CA implementation itself; IE it can be turned off by excluding the injection self modifying system from a CM. It turns out this is useful for a lot of things and definitely comes into play for a type II ES which is where I'm headed when I get back to working on the game engine aspects of my efforts.

The whole component based thing is really rooted in modern "best practices/design pattern-y" think...

Is that a bad thing? For JGO it seems like a poison pill for more than a few.

It's not like we are "gleaming the _scale_ cube" and microservicing our way to valhalla.

Technically though yeah... The implicit CA + EventBus route is similar to the microservice architecture in purpose except in process oriented.  Grin

aka every thing you write is a nice reusable generic mini-library. That's the only situation where it makes sense.

Isn't that the promise, traditional OOP in the 90's included, that is sold to management regarding adopting new principles and technology.

The big difference is that the traditional OOP direction didn't deliver on this promise. Implicit CA + EventBus does.

Message passing between functional groups / modules is best followed by only passing around a generic container interface (IE in my efforts IComponentManager). This way you can pass structures implicitly between modules without leaking a ton of concrete types and poisoning the larger codebase through unchecked dependencies.

Flip it around into type-think.  When in a specific game do you need a type which can contain an arbitrary number of arbitrary types?  Answer: never.

! When an artist is in control and not a coder.

- Makes advanced tooling possible / easy

- It's useful when you don't know exactly what you are building and the design may change.

- It's handy for event / message distribution where one message type can hold any data.

- If your goal is to not to make a big ball of mud SDK, engine, or project / source code effort it makes a difference; supports modularity, clean code / single responsibility principle, etc.

- It also supports high level DOD where data can be queried to be transformed into a low level representation. Hence a type II ES.

- It also supports naturally DAO / serialization, etc. etc.

For example I frequently have an entity type which can logically contain an arbitrary number of (by name) variables where are logically typeless but are concretely one of a very small number of types (like entity, int, float, string).  Data segregation (for data oriented) might be handled by monomorphic access to hide implementation details at the scripting level.

Type safety is handy for many reasons. I'm curious about the last sentence though regarding data segregation and "monomorphic access" in regard to a scripting interface because the latter is not clearly defined. "Monomorphic access" brings up connotations of immutability or marking classes or accessor methods final. Could you explain this more?

Don't write middleware if that isn't your product.

Phew, glad this is what I'm doing and is an approved machination.  Wink
20  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-25 01:47:36
I think it's fair to say most ES tutorials barely contain interesting information. They talk about Components and Systems for: position, velocity, sprite, health, and that's about the depth of the article.

Indeed it's a bummer that most ES articles are so basic. The ones that are out there for Java at least are far more speculative than data oriented in benefits and lack implementation details.

The problem is that these things are no problem whatsoever in OO, when using encapsulation/composition, where you can toggle functionality at will (using inheritance is a rookie mistake). This approach obviously doesn't scale with the number of components, but... does it need to scale in this manner?

We agree that composition is the bees knees so to speak. A CA and thus ES brings implicit composition to the table and there are benefits to having this in the toolbox in addition to normal explicit composition and even a touch of inheritance, but not as a central organizational mechanism. The current Java ES implementations more or less have very limited CA features.

You get this sort of scaling for free built into a proper CA.

What would be a simple use case for a game with limited scope, where an ES clearly excels over proper OO? Given your lengthy posts, ESs are clearly saving you enough time to elaborate, yet again Smiley

The chitchat monster is a demanding beast. As mentioned a limited scope game where no design changes are expected OO design is perfectly suited for the task.

The CA aspects are what really make things a pleasure during development. I'm not necessarily speaking about the currently available Java ES implementations. A lot of the killer use cases for me are modularization at the SDK / engine level which goes beyond the game focused limited CA ES implementations available.

In my efforts these are the things I like:

- Similar to Spring and such TyphonRT features a declarative loading mechanism to load up the runtime from external configuration files. This is great because conditional dependencies are externalized and not peppered through the codebase. System components can self-wire themselves and traverse implicitly the entire runtime environment let alone ES specific use cases.

- I use XML for the config files since it's available everywhere, but really it can be replaced with anything including a binary format. The really cool thing especially considering Android Studio Gradle integration in regard to build flavors is that it's super simple to provide just one XML file defining the app and completely load different functionality for product versions or any other mutation in development via providing a new flavor that simply has a different app XML config file rather than duplicating a code base. This is also very useful for multiple developers working on a shared codebase since new development can occur in parallel with less disruptions or requirements to embed factories and nasty other hacks to not disrupt developers depending on the old codebase while the new one is in progress.

- In combination with implicit message passing it's possible to completely separate dependencies between system components while maintaining functional connections. This isn't new and aligns more closely with Alan Kay's original ideas on what constitutes OO design if anything. Getting away from the listener pattern is key in conjunction with a CA / ES. This is something that bums me out when I look at Ashley since it uses the listener pattern which reduces flexibility considerably.

- Velocity of development is much faster with a proper CA and code changes don't require large refactorings. It's great for rapid development where data can be implicitly passed around.

- It makes large codebases manageable along with providing the basis for explicitly knowing dependencies of code at hand and being able to limit side effects. This valuable in testing and multi-developer environments. Get something working 100% correct and know with certainty that there are no unintended side effects with code changes not linked to the modules at hand. This includes keeping individual classes small and understandable.

- A CA provides dynamic / functional like characteristics that run on all Java platforms maintaining type safety which is a huge boon over scripting languages in general.

- The CA provides a standard API for accessing logic and data and there is far less method based boilerplate creation. While the concepts need to be grokked by devs it is consistent.

- As mentioned by others data components are DAO and facilitate journalling, serialization, and concurrency concerns.

- CA supports tooling better than rigid OOP code bases.

- A proper CA provides the magic sauce to implement runtime modularization that goes beyond the service pattern (re OSGi). A fast / dynamic CA implementation plays nice with OSGi and other future modularization frameworks.

--- I can go on, but indeed I procrastinate and have some work to get back to.. ;P

I think it's something that once you really need it and give it a go it's hard to return to old development practices when possible. I constantly get bummed out when I do any client work as most of it is very bottom basement regarding OO design. Re: 90's are calling and they want their design patterns back.

The "classic" use case in games is particles. There are usually a lot of them.

Modeling particles as objects is obviously not the proper way to handle things nor is it appropriate with ES on a per particle basis.

Being able to attach to any entity a single data component with an array of particles being tracked is nice without having to add accessor methods / explicit composition.


Building a next-gen CA / ES is not easy and very time consuming... Using a well constructed one for dev for games or otherwise is liberating.  A lot of this is still forthcoming for Java. I'm an early adopter so to speak. I look forward to getting my CA / ES efforts out in the wild.

The chitchat monster says I'm being baited.. ;P again... :: sigh ::
21  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-24 19:47:32
Technically what I've done is taking stock Java 5 language level features and inverting OOP on its head to make Java as functional like as possible without requiring taking the step of moving to a JVM based language to achieve this level of dynamic behavior. Runs everywhere including all versions of Android. The problem, having a large differentiated OOP SDK to deploy across the Android ecosystem, existed before the solution. It's nice that this direction also fully supports a fully dynamic CA based ES too without hard locking the API to one particular use case allowing dynamic optimization possibilities. I tried everything OOP (well except dependency injection; shudder / eh! We can at least agree DI reeks and is of the devil right?) under the sun to ease the pain before finding something that significantly eased the pain and brought joy to coding again. You too will have your pain eased in time.. ES4L!  Pointing ES 4 Life, Yo...  Cool
22  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-24 19:18:51
BAH!! You wouldn't believe what I've seen; beautiful accelerating heuristics dynamically unfolding through time.
23  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-23 20:46:45
It's a pretty ambitious free-to-play MMOG in which literally thousands of battledroids try to kill each other.

Right on.. I'll be in line to pick up a copy when you get it out there. For a moment there I wondered if you were being facetious to back up a point...  Grin

From what I can see in the readme, Ashley looks like 99% Artemis. Only it uses different names for things? Where is the big difference here? Nice that it's on gradle but we have an ArtemisGDX (or whatever it is called) there too. So, hmm, not sure why one should use Ashley now?

The potential benefit for Ashley is libgdx integration with an expanded set of standard components that work with other areas of libgdx out of the box. The libgdx collections backing the ES implementation may be slightly faster as well.
24  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-22 23:11:28
Years of work, 3K classes and only 750 module names to remember, effectively supporting video engine tech, which would otherwise have been a nightmare to maintain.
Surely this is a misleading conclusion, but this seems to be a lot of bootstrapping, creating this elaborate foundation, that has the potential to be awesome, yet the only outcome is a product that didn't warrant this huge investment in time and effort. It seems like this Hollywood style Transformer washing the dishes.

"Surely this is a misleading conclusion" -> it is the one produced by the JGO / indie wisdom grinder.  Wink

For better or worse I started in this direction from a long term "blue sky" goal and adapted what I developed to try to move toward something of more immediate value which still is quite illusive in general, but close at this point or at least closer than the past. The bootstrapping part especially living in San Francisco has been arduous; behind on rent currently. Knowing that I passed on at least ~$2MM of income to this point if I simply took a traditional career path is more concerning than it ever has been...

Regarding the video engine / middleware it's more like I had the right tools at the right time to start rapidly producing something of complexity the moment it was possible on Android that normally would be prohibitive from a traditional OOP perspective let alone a team of one. Not that having more devs reduces complexity / time to market especially considering OOP trappings. What I actually created is a solid middleware layer for advanced media handling on Android that is not available in the stock SDK. This is just one of many configurations of the tech involved and many apps can be created as a result in regard to product. I'm focusing initially on a prosumer video recording / editing product, but plan to release a suite of apps with some of them being more consumer friendly than others. 

I also got through the tech evaluation process recently for licensing the video engine tech for streaming use cases with a company most have heard of alas they wanted the middleware tech, but didn't actually want to pay for the requested SLA and other requirements like sublicensing. Boutique middleware development is not a good place to be in general and seemingly less so in the future in general. I'd really like to make the transition to being a product oriented company.

Besides expanded / final QA, packaging, and IAP / user extension testing things are ready to launch for the video editor. A final go to market goal is to enable users to buy a feature once and have it accessible across multiple apps in the suite. IE buy some presets or specific functionality like image stabilization or time lapse recording for the consumer app and you can use it in the prosumer / pro version, etc.  I'm moving towards launching a Kickstarter since I'm 95% of the way done.

I guess one more offhand comment the chitchat monster compels me to tell is that even though I haven't got a product to market the efforts I've done has always gotten me a job / client when I need one. These days I just have to pull out my phone and say, ever see that before?

I firmly believe generalization to this extent is counter productive. I can see the potential of Entity Systems, I just haven't seen a use case, only people describing them as the ultimate answer to customizable Entities, while hardly any game ever created requires, or benefits from this complete lack of restrictions.

As I mentioned generalization to this extent is counter productive until it isn't.. There is wider applicability of CA beyond ES use cases. In my case I had a large Java 5 codebase I immediately started porting to Android when the G1 hit my hands and rather quickly it became obvious the traditional OOP mechanisms that were marginally tenable at the time on the desktop with just a couple of variations between OSes simply did not map well onto supporting the larger Android ecosystem especially with how things proceeded and the aspect of integrating with the Android runtime.

The biggest problem with current available Java ES implementations is that they were created in the blind without an existing large scale game or codebase to test against for performance or actual flexibility. It would be much better if a high performance game rendering a lot of entities was created first then work backward to a more flexible structure while maintaining performance.

My CA efforts benefited greatly from having a large codebase to refine how it all fit together including performance concerns which were important to take into consideration given Android.

I totally get it that I need to release the framework or provide a knock out app to prove the case... Almost there...  Though I'd like to defer as much as possible the chitchat monster on what I'm doing and move the discussion forward regarding CA / ES in general. I hope to participate with the larger community in a less anecdotal manner "soonish".. ;P

In return we get significant code overhead, memory overhead and performance overhead, to achieve this pinnacle that nobody really gets that excited about, while actually developing a game. People fall in love with the potential of clean code, but so far every game ever developed is a tangled mess, regardless of the framework it was built on.

Not sure where the code overhead is coming from as CA / ES not only allow smaller more intelligible Class / file sizes, but significantly reduces code duplication inherent to traditional OOP... Memory overhead is not much different than traditional OOP ES with existing available Java ES. The same general techniques to improve this from the OOP side of things can be applied to CA / ES, but with the benefit of CA doing these optimizations in a more dynamic manner. The performance faults of current ES implementations can be improved and what is currently publicly available should not deter anyone from working on a new design.

Well... that.
The game I'm making at the moment is far more complex than anything ever produced here on JGO. Or for that matter more complex than any game I've ever yet seen made in Java, ever. Still doesn't.....

For a moment there I thought maybe you might be working on something ambitious.. <New York Accent>No disrespect...</NYA>  Roll Eyes   Shocked

25  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-21 18:02:43
Java is a very cumbersome language when dealing with inherently dynamic nature of ES. Probably 90% of the overhead and complexity is the ES implemention for Java (Artemis) stems from the rigidness of the Java language. If you were writing in JavaScript, it would be almost effortless and natural to go the ES way.

There is a bit more flexibility regarding Java when it comes to supporting dynamic nature of component architectures. Seemingly focusing on the component architecture first and then extending it to build an ES versus wrapping basic CA techniques around a purpose built ES is a step to unlock a different design and more performance.

What I mean by that is the aspect, heh, of tying the CA to the notion of "aspects" or "family" as an organizational pattern impacts the flexibility of the CA API itself. In this case systems in Artemis and Ashley are organized as broad phase processing, but are limited to processing fully composed entities sequentially. 
26  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-21 16:30:29
And then there was Ashley...  Grin
After a quick code review though it looks like it borrows the design completely from Artemis and will have the similar performance bottlenecks and general rigidity. It will be interesting if any additional performance can be squeezed out of it and where the folks behind it will take it given that it is tied to libgdx.
27  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-20 18:30:52
It's gold right, the toaster; no, let's make it solid platinum!  Grin
28  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-19 23:54:38
...most especially not in Java where you just don't have the available syntactical constructs to help you, not even structs.

The tools regarding Java are generics (more specifically generic methods) and extensible enums. It took me ~4 years to finally get a grasp on advanced generic method usage after Java 5 dropped to move toward an implicit component architecture with Java. Extensible enums were the key for generic state handling along with extending the ability of storing multiple components in a manager of the same type while retaining type safety. Java doesn't have built in ways to necessarily bake into an ES framework super efficiency (structs or the memory / Object[] matters), but the syntactical constructs do exist for modularity which provides an improvement over traditional OOP IMHO.

The performance trick as I described in the last post is more akin to creating an implicit system that can serialize disparate data components into the most efficient form for the moment.

I spent a great amount of time grinding my teeth over hierarchical inheritance in game programming. I ended up creating a Unit, then a ShootingUnit...

That doesn't necessarily lead to entity systems. I have a completely normal sort of game object hierarchy here, but all the behaviours of things are governed by sub-objects...

*An anecdotal account on how things at least for me led to a component architecture oriented entity system.*

What Cas mentions is explicit composition of course, but even that direction breaks down eventually at least when considering a generic entity system or a game that is evolving. With a well defined and limited game mechanics explicit composition makes a more traditional OOP ES tenable up to a point. Outside of having a tendency to still have a god object base that potentially aggregates explicit composition aspects that may not be shared by all entities (say "Movement" for instance including accessor and manipulation methods in the parent object when some entities don't move at all; then AI, then action / state handling etc.) this can still lead to inheritance with further explicit composition at various children levels unless one pushes all explicit composition up into the parent object expanding the bloat. The next gotcha that really made things untenable for me was state / input / control handling. Pushing this up to the parent object hard connects different areas and dependencies between explicitly composed subsystems can occur. Not so bad in a well defined game per se, but for a generic ES this causes consternation eventually. Using the movement example one then tends to push state handling just for movement into the Movement object. This also generally becomes untenable after various state handling is separated into unconnected areas. Even just separation of state handling between movement and some sort of action handler (shoot, jump, duck, etc.) can lead to general difficulties.

Implicit composition / component architectures just makes it possible via a consistent API to store / retrieve dynamically composed subsystems. On my side the "state handling Renaissance" came when I fully grasped extensible enums and by extension creation of new collections (extensible enum map & set) which basically is an EnumMap/Set that efficiently packs extensible enums. Extensible enums are great because state can be well defined within separate source code modules and shared between modules without hard dependencies via a common interface. There may be standard state for the engine / provided such as movement, but specific game state like (FLOATING, TOUCHING_NOSE, EATING_CUPCAKE) defined at the game / app level can be combined with unrelated engine state (MOVING_LEFT) accessible from one location. I suppose one could also employ this mechanism in an explicitly composed ES, but I made the jump to the component architecture approach along with moving to this state handling mechanism. I have a generic input handling mechanism that can define which keys / input sets / unsets which state extensible enums such that the input systems are not hard coded.

Another gotcha with traditional OOP ES is compound entities. Now this isn't exactly addressed well at all with the initial Java component ES implementations (Artemis included), but is addressed in my efforts as one can nest components to any depth desired. Unified state handling becomes really awkward with compound entities in regard to the traditional OOP approach which is already strained between just explicit composition state handling of the parent and quite likely hacks / workarounds are involved that end in hard dependencies between sub-entities. How I get around this in my efforts is that the root entity has its own EventBus (In my efforts an EventBus is a system component and can be added to any component manager) and parent / child entities communicate to each other and other compound entities over the parent entities EventBus.

A further benefit of extensible enums is that I figured out a clever way of using them to store components implicitly while retaining type safety for the object type with the additional benefit of even being able to capture and ensure parameterized type safety for components (IE List<String>). This gets around several problems including being able to store an infinite amount of the same component in a component manager by enum name instead of just being able to store a single component by class / interface type. In regard to compound entity state handling this is great because my EventBus works by a series of categories defined by extensible enums. A concrete example is lets say the player entity has left and right weapons which are sub-entites that can fire and potentially may be holding or not holding a weapon in either hand. When a weapon entity is added to the player entity it is stored under "LEFT_WEAPON" or "RIGHT_WEAPON" extensible enum. The weapon entity understands the "SHOOT" extensible enum, but has no idea directly about the "LEFT_WEAPON" type ID. On the EventBus thus the category for event distribution to the weapon becomes LEFT_WEAPON->SHOOT and on addition to the parent entity the weapon entity registers with the parent EventBus for the "LEFT_WEAPON" category which it can retrieve from the component architecture API since it is the type the sub-entity / component is stored under and the SHOOT sub category which is understood by the entity.

Now there is some sort of action handler at the parent entity level and it could be hard coded or more generic which can be accomplished in various manners. Let's just say it's hard coded (so I can stop adding words to this post!) and examines the extensible enum set for compound entity state. LEFT_WEAPON & SHOOT is defined so an event is created and fired over the EventBus to the LEFT_WEAPON->SHOOT category which the sub-entity receives as it implicitly registered for this category.

All this above is anecdotal experiences on how I moved to a component architecture ES.


It should be noted though that a lot of this applies more to generic engine / SDK development or an expansive / evolving game where the design is not finalized (which is most games right?). At a certain point even with explicit composition a rigid hierarchy and dependencies between composed components arise which make further modification / extension untenable and that only complicates things as this tends to occur toward the end of the project when there are a lot of late breaking changes in design. Whereas an implicitly composed ES does not face these problems especially if inter component / entity communication is handled in a generic manner and is much more flexible to changes in design later in the development cycle.

This may all seem like crazy specialization for an ES until one realizes that the above event distribution aspects and sub-component storage works for any sort of app / SDK development as well and applies architecture wide for the entire engine / framework beyond just an ES use case. I'd love to make a game with this tech or have the funding to do so at some point. In the meantime I'm focusing on mobile media / video engine tech as this is an underserved niche especially on Android whereas game engines especially now with bottom basement subscription model ala Crytek / Unreal Engine let alone Unity have gone the way of the dodo regarding any hope for monetization. I can't imagine making the video engine tech and recording / editing app which is completely generic between GUI and GL post processing functionality without the techniques described above. It'd be a maintenance nightmare w/ traditional OOP.

While touched upon previously modularity is really key especially when creating testable larger SDK / frameworks / engines. By being able to only depend on a few core modules for the component architecture it's possible to separate dependencies between modules quite finely. There is rarely any Class in my efforts that approaches 1k lines of code (if I had to guess ~5% of them) and modules often aren't larger than ~5-10 components. This makes code understandable and by limiting the access / dependencies between modules it's very possible to get things right and not have side effects / regressions occur with future development. I also like that the module gets a specific name and package thus while there are over ~3k classes in the larger TyphonRT effort (most not directly game oriented) there are only ~750 module names to remember and they are named very descriptively and form functional groupings which there are around ~80 of those.

Another massive benefit which I have yet to build from a tools perspective, but is something that I find very exciting is to be able to instrument the component architecture API and EventBus such that one can create a runtime viewer of the framework / engine and have all component architecture API calls and EventBus messages be sent over the network to a monitoring tool that visualizes the runtime and inter-module communication over various EventBus configurations. Instrumenting a component architecture is easily accomplished versus a traditional OOP engine.

Damn chitchat monster.. back to work here.. ;P
29  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-14 20:13:52
Greets.. Been a while...  Grin A little late to the topic here, but I'll bite...

>I'd like to start a discussion on how people are currently using entity systems, and how they're structuring them.

I can give my recent insights over the past couple of years. I've been fully invested in the component architecture approach _for everything_ including game ES usage since '10 with development primarily on Android since the get go; my larger effort is middleware oriented and is called TyphonRT. In the past year or so since Android 4.3 I've been focused on building next-gen hardware accelerated video engine / streaming middleware modules on top of the not always stable MediaCodec API. This includes an extensive GL based 2D post processing pipeline for compound effects / presets for video recording / editing; IE the post processing could easily be used in a game too along with the video recording capability to record game play directly in an app. That being said I haven't gotten to apply some of my more recent thinking towards game ES use cases specifically, but do have some thoughts in that direction as well.

Cas, is always going to come back with the same line of reasoning re:
"...but the hypothesis you're testing with your experimentation is fatally flawed: you don't have a system anywhere near remotely complex enough to justify the current implementation and design - so you have actually deliberately created complexity here to make it harder for yourself... to self-justify the original hypothesis that ECS make things easier for you."

"I suppose it depends why you're using an entity system... if it's to make your code more readable and understandable and easy to maintain... then that's a fail, as it doesn't really do any of that at all"

Indeed, if one wants to release a simple to medium complexity game where all game mechanics are reasonably known in advance then plow ahead with traditional OOP and ship your game. This being JGO and indie game dev oriented that is indeed the general focus of most on this forum and the traditional wisdom. IE working on game dev / shipping games / who cares about experimentation.

Experiments are good though and one can become a better developer by experimenting; will it help ship games immediately, no... Until it does... but there is a valley to cross there.

In my case with creating general purpose performance middleware that runs across OSes (desktop / Android) I've found the component architecture direction really important and born out of necessity. It started in transitioning the generic traditional OOP entity system I had then I made the component architecture part a superset and applied it across the larger SDK.

I definitely disagree with the readable / understandable / easy to maintain angle. Of course I only have anecdotal evidence. One nice thing is a reduction of method proliferation since the core component architecture API provides a standard way to access data, etc.

The benefits of implicit composition greatly aids in modularity and code reuse in combination with runtime mechanisms that allow components to self wire themselves. Along the way I also adopted the EventBus pattern, but my own implementation different than Guava / Otto. It works with extensible enums to define a series of categories. Since in my component architecture API I can store components by extensible enums this works really well with the event bus since the same extensible enum storing a component can define its category in an EventBus implicitly, etc. This further helps separating communication between functional groups of components / modules without direct dependencies.

A big experiment of mine has been judiciously breaking up my middleware into very granular IDE modules / projects and I spent a lot of time doing this and minimizing the dependencies across all of them. It's now up to about ~750 modules. The flexibility this brings is that I can configure different runtimes for specific purposes. IE a video recording / GL image post processing runtime vs a game development one. Maybe you want to combine both of them, etc. TyphonRT also declaratively loads the runtime from external configuration files. On Android this is pertinent because the config files can store conditional logic like load this component on OS < v4 otherwise load newer component > v4, etc. which is a lot better than embedding it all over a code base. One can even get down to device granularity and load potential workarounds for specific problem devices.

Again I'm talking about general purpose, but high performance middleware here and not a specific one off small to medium game.

The component architecture approach was the only way forward as traditional OOP buckled at its seams for me at least especially considering stability across the larger Android ecosystem.

I'm a fan of the MMM (modularity maturity model) and am working my way up the model and am roughly at stage 4.

Where is the launch? yeah yeah yeah... I get it... All of this has taken a while especially since I'm bootstrapping / have a day job at times. I'm actually quite excited to be moving toward launching the next-gen video engine for Android soon. I certainly could not have built it or had a chance to maintain it with traditional OOP as it would have been very difficult.

Regarding launching TyphonRT as a development framework I'm really trying to reach level 5 of the MMM before launching as it's a difficult thing to organize otherwise. Hopefully time will make itself available and next year is the year.. ;P


Now regarding game development specifically. As mentioned I haven't been working with game demos for the past couple of years, so I have only prototyped what I mention below. As OrangyTang mentioned there are issues with Artemis and most ES implementations regarding performance in general. I haven't had a chance to look at artemis-odb yet..

As things go most of the ES implementations out there for Java have been very narrowly focused on game dev and IMHO attempt optimizations at the framework level which make them rather rigid.
Often this leads to a global component pool which I believe is a big no no...

In the new ES efforts I will get around to sooner or later I use a built in extension mechanism of TyphonRT. I even described it here on JGO almost 3 years ago. That is a special system component that potentially executes when the component architecture API is invoked. This allows a basic component manager to modify its capabilities when components are added / removed. In my new ES efforts an "EntityManager" is just a "ComponentManager" with a special "EntityManagerController" which controls what is done when entities are added. Basically it splits up all of the child components and independently indexes them. At this point in time and this is rather dependent on the types of components it's quite possible to pack all of the really important data (position / health / etc.) for all entities added to the manager into the most efficient data structure necessary to iterate over all entities from a packed array for instance versus calling an update method per entity with the downside of typical object / memory / cache issues. Remove an entity from the manager and the related EntityManagerController unpacks the entity and stores data in individual data components again. I guess you could say this could be called a JIT entity system.. Wink The nice thing is that if you don't like the standard game dev components I provide or the way I pack / unpack the data one is 100% free to replace EntityManagerController with a custom implementation. IE all of this is not baked into the generic component architecture framework itself which is the most important part.

In short this is the direction I'm headed regarding ES design which was the original question.

30  Game Development / Shared Code / Re: Beware of Enum.values()! on: 2013-03-12 18:11:29
Since we're expanding on various oddities.. With J2SE Enum hashCode() returns the identity hash code on Android hashCode() returns the ordinal + hash code of the String name of the enum. Doh! If you try and mix a lot of Enum with other objects returning the identity hash code on Android collisions potentially occur. Also if you have two Enum classes with a duplicate name in the same position the hash codes collide. Doh!

On Android:
    public final int hashCode() {
        return ordinal + (name == null ? 0 : name.hashCode());
Pages: [1] 2 3 ... 7

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 (16 views)
2014-09-12 09:08:26

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

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

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

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

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

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

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

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

mitcheeb (31 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 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‑
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!