= structure
:author: 
:revnumber: 
:revdate: 2016/03/17 20:48
:relfileprefix: ../../../../../
:imagesdir: ../../../../..
ifdef::env-github,env-browser[:outfilesuffix: .adoc]



== How can I structure my code?


=== The question

....
How can I structure my code?

....

link:http://hub.jmonkeyengine.org/forum/topic/how-to-structure-the-game-code/[http://hub.jmonkeyengine.org/forum/topic/how-to-structure-the-game-code/]


=== The pattern

Read the explain about some design patterns in Design <<jme3/advanced/atom_framework/design#,design>>

This queston evolve several patterns like Singleton, Manager, Factory and related directly to the Central idiom of Atom's framework!


=== The central

Now talking about the long “getManager().getSubManager().getItsManagedObject().doSomeThing()”
Consider asking your self this when you code:

.  Can singleton help?
.  Can hierarchy actually help?
.  How secure is your application, is it a game or anything else?
.  How perfomance sensitive your game is?

For this particular example, related to “Law of Demeter” that @zanval88 mentioned is about “communicating range scope” and “hiding information”, appear as “encapsulation” and “reference” in Java.

.  If all your Manager classes is public, and referenced every where chances that they can be Singleton (read more about singleton for its downside).
.  If not, you should nest your Manager and its ManagedObject it arbitrary order and way. Consider this for a game, it’s almost always not necessary!
..  When you have your Managers and Object form a “tree” and obey a “cycle” or “protocol” or “common pattern”, may be contract them with an Interface or force them to extend the same base. [I DID this in my Atom framework!]
..  Actually while a lower (near the core) Manager are more powerful and can capture the whole process, the higher level Manager (extended Manager or sub manager) know better about detail and specific aspects. The split should be carefully thought first to avoid un necessary burden of too much Managers. Personally, I usually think about an interesting example about a society with many cops and few citizens to imagine about this balance.

.  For part of the game, when security are most important but not the performance, or for external services. Long indirect call is the most appropriate method, because of the availability (something should be injected, lazy loaded…) and security (some protol given, real info is hidden from our view,…etc). Without a check of availability, chance that you have NPE all the time!
.  For part of the game that need performance. I said “a big deal of performance” you should try “singleton” for final class (and bare with its other issuses) or bet in some other flatten type of reference (little bit worse performance – one level of indirect) should also be concerned:
..  array or list with an index. map via Class(Type) apear as Template in java … 
...  ex: StateManager.getState(ClassName.class).doSomething(); 
...  or even more abstract somekind of Central.get(“StateManager”).do(“ItsFunctionName”)!!! I do this in groovy and for Java 8 dynamic invoking

..  evolve your hierarchy with EntitySystem paradigm



=== The structure

I have a strong conceptual POV about video game, which affected by cinematography a lot. Because English is not my native language I can misunderstood the real meaning of the noun but I’ve tried to find the right words in decade.

This one is mine, maybe only me but noone else :p :

So consider this 5 level of separation:

.  Main : The main entry, have everything only relate to this single game, single application. Also game specific Configs should be here
.  Core : The shared part can be used in almost every application share the same base
.  Stage : The ‘Stage’ is the base of entities, activites and events… It’s not nessesary care about the gameplay but the World, Camera, Light and Effects, Cinematic. Stage contain most of the underlying logic, and the actors.
.  GamePlay: The part care about the routine of the game, the player, characters, stories, items, gameactions, techtree… it’s make the game look more like a game than an normal software or a movie. Gameplay contain most of the interactive part.
.  State : Even your game routine can be modeled by something else not States, I introduced State to be more friendly with JME3′s AppState concept. I ultilized it and leveraged it, and you should also.

Others optional:

.  *Network : For network game, blending between state, sub-routine and arbitrary events is difficult and may require other kind of paradigm, that’s why is not in Stage, but elsewhere outside.
.  *Services: If your game use external services such as Web or IAP or something like that.
.  *UI: UI stand for user interface, almost everygame have user interfaces but not all, so it’s also optional
.  *Script: For scripting, in my application, I embed Groovy everywhere, but I also preseved a place to hold “tranditional” run-time script that only be awared and executed when the game is already running.
.  *Model: If you are in a company or from a strong “standard lized” Java workflow, it’s nearly you’ll come up with some Bean like this, but it’s kind of for normal software not a game.
.  *Generated: Also if you have to embed some XML or some generated sources
.  *DB: Of course Database and persistent solution can be here( if not better be in the Service section)

…

The directory :
 * src

* my.game.name
** main
** core
** state
** gameplay
** (*)network
** (*)services
** (*)ui
** (*)others


More detailed, You can find a better example here in my game examples:
<<jme3/atomixtuts#,atomixtuts>>
