

== Well defined Cycles

Cycle are ordered activities which repeat over and over during the entire application life time. It's usually referred as game loop. 


If you see a cycle as a list (ordered collection) of actions that the application does one at a time. You will see the application Iterate over them. In the opposite view (or in the action body), a traveller (usually data) seen it drag from one to the next one, so call pull to next step.


As Atom also support reactive programming, it's essential that developer should understand clearly what is the benefit of program with this direction or other. To get (Between) BEST OF BOTH WORLD! 



=== Why 6?

Game programmer usually stick with 3 steps execution


.  init 
.  update
.  destroy

Instead of that, Atom use 6 steps execution cycle:


.  init
.  start
.  load
.  config
.  update
.  finish

These 6, I carefully learnt from other “good module and component framework I 've use: Wicket, OSGi,Spring…they have different steps number! 


link:http://wicketguide.comsysto.com/guide/chapter6.html#chapter6_1[http://wicketguide.comsysto.com/guide/chapter6.html#chapter6_1]


link:http://en.wikipedia.org/wiki/OSGi#Life-cycle[http://en.wikipedia.org/wiki/OSGi#Life-cycle]


link:http://www.tutorialspoint.com/spring/spring_bean_life_cycle.htm[http://www.tutorialspoint.com/spring/spring_bean_life_cycle.htm]


The reason of these 6 step routine compare to 2,3,4,5.. or any other division is to support lazy loading, heavy task, gabage collection wise, much more…


So we usually have these 3 main methods:


....
init , start , end
....

For a real-time game, we need 2 more:


....
load, update
 
....

“Config method is kind of a replicate of “init or “load, or confusion of these two, even can be done in “update somehow but in fact, it's worth to be separated. The config step will help you gain a lot in the way to extend the frameworks or to adapt/scale  your game to smaller or bigger usecase, anyway 6 “is not too much but enough !


Anyway this is a common cycle and compromise between ICycle who join the Atom conversations; that's hook in methods (classic style isn't it?). Beside of that, you can define your own routines through safe tasks and channels which provided by AtomMain. Though this tunnels, all your operations are guarantee to be not conflict in concurrent term with any other jobs of Managers, actors or helpers. So the Data is for you until you end the tasks (or be shut by forced because timeout for ex)!!



=== Pull or push?

As said in the analysis about JME3's patterns, especially rendering and update loop, it's pull and push at the same time. Confused? Yes it's… Why is so confused?


Java developers are “toooo familiar with MVC architecture that bring to us by Swing and all classic sun solutions. That's why we find them in every programming books and every beginner's articles, especially if you develops game in desktop, (obviously in swing also). OpenGL and LWJGL also start as window based solution. So that we get “used to it… Latter, a lot of web frameworks also make tanged mess of push &amp; pull concepts?


Swing-MVC concepts are embeded in a event-driven enviroment… and it's actually pull.


Real-time application can be event-driven or not. As my exprience, apply this Swing-MVC to real-time application not usually help greatly but sounds very confused and blury. It can help if you too familiar with it anyway, but be careful or you break the MVC contracts easily and make it not useful. You can blindy apply it without concerning of consequence, but that don’t make any sense.


The solid and only reason to say JME3 is pull and push, and why we still has to stop once for a while because of OpenGL via LWJGL is still monotholic! Not the GPU processing or GPU-CPU data exchange. So we still have to stop at the renderer's door, knock and wait until its done, then go to next step? Umh not quite. 


But to do this, we have to not depend in the update() and render() methods to get to total freedom. 



==== Concurrent / Parallel world

Welcome to the parallel world which some time the well-defined cycle not even exist.


But the routine or the flow does exist indeed!


Just look at how your “data or “signal actually run through your systems, though “node and “stages as a network of roads &amp; cars. This actually a well-study area known as data flow analysis. In a perspective, data seem to be “pushed from sources to targets. Some may also view its as data are “requested by some nodes and “pulled by those nodes.


link:https://github.com/Netflix/RxJava/wiki[https://github.com/Netflix/RxJava/wiki]



==== What is the new routines options?

Even if “Cycle- which we used to known is just a conceptual view of points, my solution for this problem is to declare several new kinds of well-defined “Cycle :


.  Push cycle 
.  Pull cycle 
.  Non-cycle

… because defining routines in Atom is not only free but also helps in a lot of situations like when you interact with GUIs, networks or webs.



===== Pull cycle

To connect to Swing MVC (also a pull cycle) with events, you can wrap them in Actors and let events send as messages between actors. The Swing actor in the EDT act as the brigde here. 



===== Push cycle

As in functional reactive programming and flow based programming, functions (small piece of jobs) are flow with their data. A flow is not a well defined cycle but a routine and can be monitored.



===== Non-cycle

A serial of Tasks can also form atribinary routines ( non-cycle) and be coordinated together via Data they exchange. 






== Customable cycles


==== Customable routines

Via tasks and workers, you can atribinary make your own cycle that do anything around and later participate in the rendering stage and JME logic stage (if they want).


This freedom of doing things (in parallel if you want) is thanks to lock-free concurrent algorimths and data structure that Atom use. In other hand, the synchonizing problem is under research!


Read: <<jme3/advanced/atom_framework/atomcore/concurrent#, AtomPar>>



==== Customable (rendering) bucket

Bucket is a way to layered your rendering queue into layers or separate them into different categories (aka buckets) to handle differently.


With a composable comperator, a sub-list from a list, or a sub-tree from a tree, even a sub-graph from a entire scene graph can be extracted, or the whole collection can be sorted arcordingly. Custom bucket in Atom framework is implemented in AtomLight package to extend JME3 rendering pipeline. 


Note that a custom bucket is not very efficient! Even though if you enable a setting, Atom will take care of its render order and the update will be “IO wise with special indexing structure call B-Tree. If you use it without cautions it can require a lot of memory and make your rendering suffer. 



== Cycle & Scale

You can see there is a trend for networks call non blocking IO, which Node.js is the first most and remarkable success. In that world, there is actually not a wellform cycle or turn at all. Because if there is a Queue or a lock, a insist port holder or an strict order (like a cycle), it can not scale at all!!


In fact the atribinary networks and async data signals have a lot more problems than we can possible imagine. Not everything can be fast and precise…Some parts (services) may be slow by intend, some parts cause errors frequently. 


The fault torrent architecture of AtomEx make sure some sercurity and transactional problems are shielded. AtomDust in another hand focus in highly loose mobile devices and atribinay short range connections. Those carefully design systems for usecases actually make Atom suitable even without a real Cycle.






== Technical reviews


==== Cycle (or ring)


==== Cicular (or ring) buffer

Ring buffer is fast way to make concurrent real time data streaming…


link:http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-whats-so-special.html[http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-whats-so-special.html]



==== Is there a real cycle? or just a lot of streams
