Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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 ... 6
1  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-25 03: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 ::
2  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-24 21: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
3  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-24 21:18:51
BAH!! You wouldn't believe what I've seen; beautiful accelerating heuristics dynamically unfolding through time.
4  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-23 22: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.
5  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-23 01: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

6  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-21 20: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. 
7  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-21 18:30:29
And then there was Ashley...  Grin  
http://www.badlogicgames.com/wordpress/?p=3481
https://github.com/libgdx/ashley
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.
8  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-20 20:30:52
It's gold right, the toaster; no, let's make it solid platinum!  Grin
9  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-20 01: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
10  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-14 22:13:52
Greets.. Been a while...  Grin A little late to the topic here, but I'll bite...

@OrangyTang
>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."

or:
"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) http://www.infoq.com/news/2011/09/mmm-osgi 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.




11  Game Development / Shared Code / Re: Beware of Enum.values()! on: 2013-03-12 19: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:
1  
2  
3  
4  
    @Override
    public final int hashCode() {
        return ordinal + (name == null ? 0 : name.hashCode());
    }
12  Discussions / General Discussions / Re: I Switched to IDEA! on: 2013-03-12 18:55:26
I've been using Idea for over 10 years, but v12 impressed me considerably. In my efforts with TyphonRT which is composed of 700 source code modules v12 with the compilation improvements takes 23 seconds on a circa '11 MBP w/ an SSD for a fresh build. Prior to v12 9 minutes; I was definitely getting worried! I'm liking v12 a lot and very glad about the community edition being available if I initially have to depend on others who want to work with the source directly using Idea if there are any potential Eclipse issues with large amounts of modules.
13  Discussions / Miscellaneous Topics / Re: Have you ever been Jumped/Beaten up? on: 2012-01-18 14:11:32
I've been lucky to not get jumped. I live near a shady area in SF / SOMA, so this is definitely always on my mind. If you look at the crime heat maps I'm real close to a big one. It's odd how a block or two away things are much worse and I walk through that area all the time to a local bar sometimes with my pool sticks. Luckily I'm tall and reasonably fit looking, but the biggest thing is just common sense and having decent awareness when in route. I'm doubly careful walking through said shady area late at night. But seriously any fight would freak me out as well the best course of action is usually to run away. If you can't run just give up whatever they want. My friends got jumped at knife point in Oakland and they quickly emptied their wallets and were lucky thankfully. I never got into fighting, duh clackity clackity, but always stayed clear due to being reasonably strong. With someone my size some decent damage can be done. I've really been meaning to start some martial art; quite likely Brazilian Jiu Jitsu as there is a highly regarded Gracie academy half a block from me. Not that BJJ would help in a street fight all too much with multiple assailants. I'm definitely interested in getting out of "coders head" and get moving around and learn how to control ones body with the appropriate force. Hah. I went to college in San Luis Obispo, CA and that is where Chuck Liddell is based and I was like 30 feet away on a big Mardi Gras party weekend when a fight broke out. Lets just say it didn't go well for the guy that tried to hit the Iceman and it was over quick. 
14  Game Development / Newbie & Debugging Questions / Re: Abstract classes and interfaces help on: 2011-12-20 09:07:44
I suppose I do this in my efforts for the core component architecture at least since it makes things clearer. You'd have to dig around some other posts to get all the background & "razmatazz".

componentManager.getAs(IActivityLifecycle.class) by naming convention alone makes it clear that one is dealing with an interface and not expecting code completion to any public member variables... I don't prepend shared / IE cross-platform J2SE / Android classes with "Shared" or J2SE. The actual cross-platform implementation or base class is "ActivityLifecycle" which may also be dual registered and accessed as componentManager.getAs(ActivityLifecycle.class) along with the interface. Likewise with the Android specific version: componentManager.getAs(AndroidActivityLifecycle.class). However for cross-platform usage things are composed using the interface and if direct access is necessaryfor any given component they are also stored under the actual implementation type.

In my case the naming convention helps shorten cross-platform implementation class names whether they are base classes or what not.

Technically devs using my efforts can do whatever they want for naming conventions, but I've found the prepend useful for interfaces and code readability in my core component architecture work. It's not for everyone nor a rule; use when handy essentially. Before my efforts went full on cross-platform I didn't standardize on prepending "I". I'd also argue it depends on the size of the project; less than 50-100 classes and small entity hierarchy then don't bother. While the core architecture is small w/ my efforts the larger network of components / libraries is growing beyond 1600 classes now with likely ~2k by the time I fully flush things all the way out feature wise; nice thing is it's highly modularized. Prepending "I" for interfaces just helps out at a certain scale, but to each their own.
15  Game Development / Newbie & Debugging Questions / Re: Abstract classes and interfaces help on: 2011-12-19 05:14:01
An interface essentially is a public contract. In Java it's also a top level type that is referenced by it's class. IE <interface name>.class

In your case with a base NPC class consider if there were private implementation details that could differ between a conceivable second base NPC class. This could be anything really. Creating an NPC interface ("INPC") that provides the public contract allows you to use either base NPC types interchangeably. An example of this is that say you create a collection ArrayList<INPC>. Now you can put either base types into this list and iterate over the common interface.

Interface based programming is important in larger architectures and app dev. In your case you may get away with things for a while depending on the scope of your efforts.

Interfaces are useful when private internal implementations differ, but the external public contract is the same between different implementations.
16  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 20:12:31
I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all.
CS 101 shouldn't be covering software engineering. That's a completely separate discipline.

I was being a little rhetorical in that statement. It's fundamental knowledge essentially and is widely recognized as a best practice in the industry.

On whether software engineering is a separate discipline I at least do not treat it as such. The left hand must know what the right hand is doing otherwise if you just want to be a brick layer and be paid less be a programmer with little responsibility. You may eventually despise your work / job when non-software engineers / architects are calling the shots and this _will_ happen at some point if you don't demand to take control of this or keep it in mind in your career path. Besides when working as an indie one does both. There is no reason why one can't be a hands on architect especially on a small to mid sized team.

As far as teaching and degree wise I absolutely think it's a tragedy that things are being separated. After the CS 101/102/103 but before the typical data structures / algorithms course software architecture / engineering should be part of the curriculum. What are data structures other than patterns of organizing data. This is accomplished through a knowledge of the "paradigm" of implementation OO or otherwise. A course on design patterns before data structures seems appropriate in my opinion.  
17  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 19:53:03
I fully understand the need to help people understand the usage of APIs by how you expose them.

No doubt.. One can't work that long in the industry and not grok that...  Grin

I just feel that most of the time it is a major pain in the arse deciding, when you aren't making a library for the use of others but instead writing end-code, or if you're the recipient of such a library, you simply can't use the code you have executing in your own damned program the way you want to have it executing if you don't have the source to hand.

I think there must be a better way.

Then don't criticize those looking towards entity systems and by general extension component architectures as wasting time or that they suck as the handful of us that are doing this are searching and some of us have found what we consider a better way. Searching and experimenting takes time and most definitely it takes an immense amount of time to convert a significant existing OO framework to a very granular component oriented one. I only did so after I saw the writing on the wall and pushed the older way to the limits. The inflexibility that you speak of above was obvious in my efforts with traditional Java / OOP mechanisms and I tried everything before going whole hog toward component architectures. Almost everything in my efforts now can be replaced or substituted fairly easily from external configuration files. A great deal of time was spent minimizing dependencies between components and related groupings so this is possible.

Beside the scenario above as you describe is just a poor API / framework that didn't do what it is intended to accomplish and I believe someone above commented on this sentiment in a reply above. I'm aware there may be times when a dev desires to mod a perfectly working API to do something slightly different as well, but usually that is an exceptional case as OOP in itself doesn't disable extension.

And that's how all new languages are born........

It can be, but I'm not ready to give up on Java yet. Though I certainly keep in mind how the CA can be leveraged from Scala and other JVM languages. In fact I certainly posit that it's a much better way to integrate Java w/ Scala or other JVM languages as opposed to extension of Java classes. I still need to experimentally validate this, but I put a lot of thought into it. A simple shift in perspective and coding practice is what I'm really trying to get at and while it works for me it may not work for everyone. The only downside so far is increased verbosity at the Java layer. There should be some ways with Scala for instance to reduce the verbosity in practice.

Now, I'm certainly not saying anyone has to follow me down the path I'm heading, but I do believe it will benefit any project small to large. It's not "f**king insane" as a poster above claimed. I have a large body of code that has only seen a benefit and things still chug along nicely in a reasonably complex 3D demo case. There will be early adopters and the typical bell curve of adoption. I most definitely have an up hill battle to fight, but it's an pedagogical one that can be overcome with good documentation, lots of clear tutorials, and perhaps a hit app or game + outside success stories. All that takes time...

To continue I would posit further that yet again this is a dirty mark on OOP and the is-a and explicit has-a relationship. It doesn't lend to flexible APIs / frameworks that can be easily extended or reconfigured and only truly works well for small to mid (at the most) sized projects in terms of maintenance unless there is someone full time working as a "cleaner / hands on architect" that can see the forest from the trees and has authority to refactor and uphold whatever standards that are set up. Code reviews are not enough in this regard as it's really an active full time position for a larger project with one or more folks involved day to day. Most small to mid sized projects with various devs involved benefit from a dedicated hands on architect.

Again a clarification, in my experience standard OOP as implemented in status quo Java projects doesn't work well as the central organizing mechanism, but is less of a deadly force in the leaves of any API / framework. Thus while my new efforts are component oriented they are partially still OO in the leaves which means some of the components / systems themselves. As a framework dev it's impossible to limit OOP in the leaves since OO is baked into Java. This is not necessarily the case for the entity system where it is recommended to minimize OO in the leaves, but for the runtime layer of my efforts it makes sense where there are component peers w/ a base cross-platform implementation + J2SE and Android peer extensions. Mind you the interface based programming aspect comes in because one stores the given platform implementation by the common interface / contract in the CA thus on any platform the dev just retrieves the particular platform implementation component by its common interface and bam easy cross-platform support w/ ease of adding more platform support on an as needed basis.

A simple shift of perspective to promoting the implicit has-a relationship as foundational and minimizing the explicit form and is-a relationship is not crazy. It's just a different approach. This is also fairly "CS 103" Cheesy material and shouldn't be strange language per se. It is a shift of perspective nonetheless though. It's true power is not realized until a significant amount of code is converted to this mechanism.

I know the "AbstractComponentManagerControl" thing may be hard to follow from a previous post as that is an implementation detail specific to my efforts, but I'll show it in psuedocode below (just a snippet mind you and not using best practices / IE never use foreach loop in near realtime bound code). It basically is an internally used component that can extend and change the behavior of the manager itself. It is what allows vetoing and encapsulation back that otherwise would be lost by the implicit has-a relationship. If you wanted to make a particular compound component final you'd first composite all the desired included components then add an ACMC that vetoes further set / unset actions.

This code is not the exciting part per se, but defines the bread and butter implicit has-a relationship. The exciting part is building a larger framework around a few essential new patterns that come from all of this.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
public class ComponentManager
{
   HashMap<Class<IComponent>, IComponent>  components
   HashMap<Class<IComponent>, Collection<IComponent>>  componentCollections

   public <C extends IComponent> C getAs(Class<C> componentType)
   {
      return components != null ? components.get(componentType) : null;
   }

   public <C extends IComponent> Collection<C> getCollection(Class<C> componentType)
   {
      return componentCollections != null ? componentCollections.get(componentType) : null;
   }

   // Sets a component adding it to this component manager
  public <C extends IComponent> boolean set(Class<C> componentType, C component)
   {
      Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
       AbstractComponentManagerControl.class);
     
      if (controlCollection != null)
      {
         // Iterate through ACMCs to perform extra control actions or potentially veto set altogether if a control returns true.
        for (AbstractComponentManagerControl control : controlCollection)
         {
             if (control.set(this, componentType, component)
             {
                // control vetoed set action
               return false;
             }
         }
      }

      return components.put(componentType, component);
   }

   public <C extends IComponent> IComponent unset(Class<C> componentType)
   {
      Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
       AbstractComponentManagerControl.class);
     
      if (controlCollection != null)
      {
         // Iterate through ACMCs to perform extra control actions or potentially veto unset altogether if a control returns true
        for (AbstractComponentManagerControl control : controlCollection)
         {
             if (control.unset(this, componentType)
             {
                // control vetoed unset action
               return null;
             }
         }
      }

      return components.remove(componentType);
   }
}
18  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 05:01:30
It's about defining an API. *I* define what you access in my API. We have a contract. Anything I don't provide to you is none of your damned business and I am free to change without breaking you. There are plenty of scenarios where this makes sense. Everything *could* be public, but then I would have to assume any change I make will break all clients, and that is shit. If you want to access something that isn't exposed, you aren't using the API as intended and it is supposed to be a PITA. Blame the poorly designed API.

^ this; I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all. Interface based programming is one of the industries best practices and is core to API / framework creation in Java. It's central to my efforts with component architecture development and separating things modularly. I think interface based programming is likely the most important best practice that can be objectively discussed as such without a question of whom it might benefit.

Still going to try and post a bit of a response to various replies in this thread likely on Sat when I'm on a plane again.
19  Discussions / General Discussions / Re: Releasing a small library on: 2011-11-24 19:41:59
So Google Code is asking me for a license? Gah, so much bureaucracy! Which one means "Here's the code, do what you want with it, give me cred if you feel like it"?

MIT, BSD, Apache are of this nature.
20  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-24 19:36:21
Yeah.. I'm not really into checked exceptions especially for any performance bound code, but handle unchecked exceptions intelligently from the clocking threads (potentially end the clocked runtime item silently, w/ a warning, log it, or if it is marked as a fatal error stop entirely) and via a default uncaught exception handler as to not crash the runtime, but provide some sort of reasonable response to the user, logging, or possible recovery if applicable. Any custom exceptions that are thrown in my efforts are all unchecked / runtime oriented.

As you say Sproingie if checked exceptions created a warning instead of an error if not handled I suppose there could also be an annotation that promoted it to an error state or could provide an IDE the ability to mark it visually instead of just a runtime JVM flag.
21  Game Development / Game Play & Game Design / Re: Executing Threads in a queue on: 2011-11-24 18:40:31
As others have commented on it, but not knowing more on your particular use case you likely don't need threads. As Sproingie mentioned you'll want to check out ExecutorService and the related APIs. You can build up your own API around it to control how things get run. I have a custom API built on it in my efforts that allows (of course in a component oriented fashion) to feed one thread pool in several different manners. Basic (one or more threads run immediately depending on available slots in the thread pool), Single (all threads submitted run single file), Pending (a runnable is submitted and will run as soon as a slot is open, if a new runnable is submitted it will wait in a pending state and run after any currently active runnable. If a new runnable is submitted while a pending one is waiting the pending one is replaced; good for long running GUI actions connected to something the user can press many times repeatedly. Such that the first and last button press will only potentially trigger execution). One can add a new custom scheduling mechanism too and have it share a thread pool.

I used a custom executor service when rewriting the download queue of the Amazon MP3 Android app that when the current download is paused it pushes the current download to the front of a custom BlockingQueue thus when the user resumes it pulls the previously downloading item and makes it active again. So you can certainly control the way runnables are scheduled and even service multiple ways of scheduling them from one thread pool. ExecutorService is also cross-platform between J2SE and Android. There really is no reason to use AsyncTask on Android when you can accomplish things in a cross-platform way via ExecutorService.
22  Game Development / Newbie & Debugging Questions / Re: Making color "see-thru" without changing it's color? on: 2011-11-24 11:15:09
Yeah.. taking into account a background as others have mentioned I don't think you'll reach a satisfactory result per se with color modification or saturation. You might get close I suppose. Also it will help to know if you want to work with a 2D API IE Java2D / Android 2D API or GL. Off the top of my head thinking aloud could you have too buffers and do some minor compositing. IE have an RGBA image you draw the text and your translucent shapes into then have a separate image as your background then do a Porter-Duff replace op when blending the text/shape image on top of the background image. Could that possibly work out?
23  Game Development / Game Mechanics / Re: 2D rotational velocity on: 2011-11-24 02:53:39
Check these tutorials. Demo code is in Flash, but can easily be ported:
http://www.wildbunny.co.uk/blog/2011/04/20/collision-detection-for-dummies/
http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/

OBB vs OBB is covered above. Other interesting posts on this fellows blog too.
24  Game Development / Newbie & Debugging Questions / Re: Making color "see-thru" without changing it's color? on: 2011-11-23 20:40:37
Is there some mathematical formula to do that?

Not that I've played around with this, but I believe it's easier to modify saturation with HSV vs RGB.

http://en.wikipedia.org/wiki/HSL_and_HSV
http://en.literateprograms.org/RGB_to_HSV_color_space_conversion_(C)

25  Game Development / Newbie & Debugging Questions / Re: Making color "see-thru" without changing it's color? on: 2011-11-23 20:32:21
Hrm.. Of course when you are overlapping one or more translucent colors / shapes intensity will be modified, but are you commenting say compositing a translucent object on a white background where the background itself affects the color intensity. I suppose if you could work out some way to composite a scene without taking into account the background you'd accomplish this. Perhaps modifying directly a BufferedImage. This seems more like a compositing problem. I can't off the top of my head think of a non-custom way to accomplish this.  
26  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-23 08:22:39
I'm pretty sure it'll misbehave on a couple of devices out there but it's really so brain dead simple, this code, it really shouldn't misbehave. The code itself is near as dammit identical to the code I've used for the last however many years on the desktop too - it's had a lot of lovely testing.

Very cool. Android caused me to step up my game as things go too. Testing never hurts.

Some of the silliness on Android is well just blatant lack of testing on big G's part. I'll throw out some stuff starting with Froyo though it goes back to the beginning; the "official" Java GL/ES 2.0 bindings in API level 8 are incomplete as code gen was used to create it, but it was never tested thus wrong signatures on some methods preventing some VBO usage. Gingerbread for the most part had no new problems as far as I'm aware for game dev. Honeycomb (3.0 / 3.1) had a major Java NIO regression where calling duplicate on a non ByteBuffer caused an _immutable_ endian swap on the buffer! Way non-kosher there and it broke all my GL code as I have a little extended NIO API that used duplicate on a FloatBuffer; that took me 45 hours of debugging to find and then provide big G a test case; I bitched them out over that though. ;P Only time I've seen the Android team fix a major regression in ~3 hours after test case was provided. Most items in the bug tracker languish forever. Last big thing to cause a ~4 day workaround in my efforts, IE 2 to fix, 2 to make clean, is the piss poor annotation support in Class likely taken from Harmony; horrible GC triggering code. All API levels affected up to Ice Cream Sandwich; had to implement caching myself. MotionEvent and such is an abortion of a proper API. So yeah.. There is always another big bomb shell awaiting around the corner.  Not exactly an exhaustive list and of course off topic.    

You should be able to get far more than 500 sprites on screen w/ mid level hardware. I'm sure the OG droid can pull that off. Fill rate / overdraw is the biggest issue, etc. Err.. this is not about threading anymore.. ;P

@Nate libgdx still require ~6 lines of code changes to configure between desktop & Android usage?  I'm aiming at no code changes.
27  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-22 17:26:59
... that may have been the case but it turns out I've solved them all on my own in 3 weeks

Or so you may think until you run your code on a different device / API level than the one you have in your hands...  Wink
28  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-22 16:34:35
The whole notion of encapsulation has proved to be a complete waste of time over the last 20 years anyway. Of course I care about how something's implemented! I might want to bloody change it, whether I wrote it or not. Or even debug it. Ridiculous.

Eh heh heh.. So now you are implicitly for composition declaratively or otherwise / component architectures (CA) / entity systems (ES) as this is exactly what the "has a" relationship addresses. Your complaint is a valid one against OOP as "is a" encapsulation doesn't lead to easy code reuse, maintenance, or modification and is precisely why I moved on from that sinking ship.

As Java is an OO language through and through you can't stop anyone from using "is a" inheritance / encapsulation, but through careful construction of the CA one can force this to the leaves and prevent it overtaking the core at least as the central organizational construct.

Encapsulation as a concept in and of itself is not the enemy. I've mentioned this before, but in my particular efforts one can still achieve refined encapsulation by adding an internal control system component (AbstractComponentManagerControl / ACMC) to a component manager (may be an entity or whatever) that may veto or transform components or systems added / removed. If this control vetoes all additions / removals you just made that component manager final, etc. Want to change how it works then compose the component manager / entity with a different ACMC and series of components / systems. Potentially you may achieve your modification through composition (very quick) or you'll be able to just modify the smallest amount of components necessary to realize the change then swap out the offending ones. This also aids in debugging as with declarative composition w/ a little control flow especially on Android being able to filter with device and family names one could branch and load the old and new composition on two different devices testing both at the same time, but on different devices from one build.

Folks should realize that creating a CA and validating its performance characteristics for near real time usage is a difficult task. In my case the ES part is just an extension of a more generalized CA. Since my effort is a runtime middleware layer converting and granularly separating this runtime from its prior OOP configuration so that it runs well over J2SE, Android, <fill in next Java environment / GL binding / etc> is what has taken 99.5% of the time. Not everyone should create their own CA, but those who do will also become better developers and fully use and understand all the advanced language constructs of Java 5.

Conceivably using a well constructed CA / ES once one wraps their head around it and understands how things work together makes coding and prototyping faster and efficient in addition to flexibility through the entire design and implementation process to make quick changes vs massive refactoring.

Ack now to respond to all the good comments since my last post... erg.. will take a bit, but I'm on it... My initial verbosity was due to being on a plane with free provided chrome book and wifi... This next one due to good / interesting comments on the forums!  Cheesy


Edit: I suppose to make things more clear as of course in OO design the "has a" relationship is available as any member field fits this description. What component oriented programming in an OO language like Java changes from normal OO is that the "has a" relationship becomes implicit rather than explicit for component managers, entities, etc.
29  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-22 08:24:03
Why do people have so much trouble with multithreading? It's not hard to implement at all.

Uh, I highly doubt you have an efficient and general purpose framework for separating various logic oriented sub systems from rendering. Working with threads is not difficult on the surface and of course is the essential approach with networking, I/O, or long running processes that can easily be separated from the main update / render loop.

As I mentioned in the particular example case of glow ball NVidia has great multithreading here because the separate cloth / tapestries _do not_ interact with each other. I just recently attended an NVidia presentation at AnDevCon where they showed some very fancy tools for debugging GLES on Android and such; I do believe they will be public soon and are amazing for seeing thread / core utilization and debugging shaders and frame by frame rendering by each step / GL call.

What this example translates too is that it's easy to implement a trivial example in a multithreaded context if you know exactly how things will interact and they don't overlap. It's much harder to create a general purpose framework where there isn't advance knowledge of the task at hand which can scale from one to X processors.

There is absolutely a reason why Carmack stuck with the single threaded approach until Rage. Even at that if wikipedia is to be believed it only was likely in the last ~3-4 years that the switch got traction w/ id tech 5 given the WWDC '07 anecdote. http://en.wikipedia.org/wiki/Id_Tech_5 Even with all the neat potential cool stuff id Tech 5 does it still is a relatively closed system with 100% known sub systems thus the multithreading could be relatively baked in a specialized manner into the engine.

30  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-21 00:55:12
Yeah.. I'm still on the fence with multiple threads. I know I got to get there, but for now it seems like a specialized case. For instance in the NVidia glow ball demo which looks great they are spawning separate threads to deal with the cloth / physics simulation, but that is possible because in the demo each tapestry / cloth does not interact with each other. http://www.youtube.com/watch?v=eBvaDtshLY8 I'm first going to take a look at Scala, actors, message passing in Scala and evaluate on how to proceed. Haven't had a chance to dig into Scala yet, but I'm gathering the favor of immutable message passing won't be efficient per se on Android. So I foresee some sort of generalized COP (component oriented) message system similar to how I handle input events.

That being said I don't know how much one can get out of basic / general logic + render threads separated. It doesn't help much since in the general case as unless the rendering thread gets updates it's just duplicate frames being rendered. There is much to do in this area especially for Java oriented frameworks.
Pages: [1] 2 3 ... 6
 

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

The first screenshot will be displayed as a thumbnail.

pw (21 views)
2014-07-24 01:59:36

Riven (19 views)
2014-07-23 21:16:32

Riven (16 views)
2014-07-23 21:07:15

Riven (19 views)
2014-07-23 20:56:16

ctomni231 (47 views)
2014-07-18 06:55:21

Zero Volt (43 views)
2014-07-17 23:47:54

danieldean (34 views)
2014-07-17 23:41:23

MustardPeter (38 views)
2014-07-16 23:30:00

Cero (53 views)
2014-07-16 00:42:17

Riven (52 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

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