Atom Framework Documentations

Welcome this is the main entrance of Atom framework documentation. Here you will find all the resource you need to start developing with Atom framework. First take a look at the structure of the documentation.

Structure of the Documentations

  1. Architecture Design

  2. General docs

    1. Setup

    2. Coding and project structure convention

    3. Usages of SDK

  3. Component’s docs

    1. AtomCore

    2. AtomEx

    3. AtomSDK

    4. TeeHee .. others

Download and Setup

Download and Setup instructions

Design documentation

Design & Architecture documentation page: design

The Code

Make sure that you’ve read and understanded Atom’s Design part

Programming aspects

  • Java

  • Groovy

  • XML

Polygot programming

AtomCore (pure Java) supports:

  • Functional reactive programming

  • Flow based programming

  • Component based programming

  • Composite based programming

  • Data-driven & Model-driven & Domain-driven

Because AtomScripting and others use Groovy, so it inherit (a lot of) polygot capacity from Groovy.

Read: http://groovy.codehaus.org/Polyglot+Programming+with+Groovy

How can I structure my code?

How can I structure my code in Atom framework and in JME3 games. What is the best practices, some patterns, pros cons and caveat?

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

More detailed, Code structure explained

You can also find a better examples here in my game examples: Atomix’s tutorials games

Code generation

http://en.wikipedia.org/wiki/Code_generation_%28compiler%29

Atom support code generation from multiple sources and to various targets to help speed up and unite production pipeline. CodeGen - Ultimate tools for code genration corporate with AtomExAsset - Ultimate tools for game assets management is 2 facilities in charge for the job.

Sources

  • UML

  • ECore

  • Java code or Java classes with annotations

  • Code gen diagrams (modified UML diagrams for games)

  • 3D Model and assets

Targets

  • Other Model format - via ECore, UML

  • Groovy or Java - via ECore, UML, ANTLR

  • Java bytecode - via instrument and transformation ASM

  • JavaScript - via GWT, ANTLR (supervisor translation)

  • StringTemplate, XML, Text, Configurations … and other textbased - via StringTemplate

  • Assetpack and other kind of assets - via processing pipeline

More coding convention

Configurations

Atom support configs based in Apache Commons Configurations: http://commons.apache.org/proper/commons-configuration/

Apache Commons Configurations supported configuration format:

  • Properties

  • XML

  • JMX

Additionally Atom support configuration via:

  • Java Annotations

  • GroovyConfigs

Scripting

Default scripting language of Atom framework is Groovy.

Some optional groovy facilities are also included (gpars, ASM, ANTLR…)

But note that AtomCore is not depend in Groovy.

You can also do scripting in other Java scripting frameworks like BeanScript or JavaScript.

Scripting leverage game programming a lot. You can stay inside the running game and make changes into the game enviroment (is just one small advantage aside of other super cool features!). So read about how to do scripting here:

http://hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:atom_framework:atomscripting

http://hub.jmonkeyengine.org/wiki/doku.php/jme3:scripting

The Project

Atom provide two editing facilities : AtomEditor for ingame editing and AtomSDK for desktop swing based in Netbean. Both of them working with a Project format and structure defined in AtomEditor structure.

The main format to save Project informations is XML. With default settings format is normal XML, it can be set to used a multiversion XML tree (imagine git but effective in XML).

Project details

Project structure

The project also has a folder structure (directories and files) convention just like JME3. Aware of that when coding or making assets.

Project structure

Code or Data?

First take a look at how Atom manage Data…

AtomExAsset

One question you may ask: if Atom was so Data+Model-driven and generative. Is code still code or is Data?

  1. Code is still code in almost every situations.

  2. Till it’s sent into generation pipelines (when you hit build or so), the new code and assets are generated.

  3. In pakaging phase, code (as byte code or scripts) are packed completely in jar (or packages format). Some of them are ofucased, zipped then translate via network. They are now data.

  4. In the run-time enviroment again, they are data of the JVM to execute which instruct the machine to do something (your games)

  5. Some of data are still data the whole time :Images or 3D Models and almost Assets for examples. But because some user data can be embeded in j3o (script for example) so they are also code in other perspective.

The distingish between data and code just need to be clear if you like to process on them. As long as you don’t, they are same bit, forget about the differencies totally - who give a $%it!

Project settings

Usage of SDK

For 3D editing

For project management

For code generation

Components documentations

Atom Libraries

AtomCore

AtomSripting

AtomEditor

Atom2D

Atom2DEditor

CodeGen

CityGen

AtomEx

AtomExAsset

AtomLight

AtomAnim

AtomAI

AtomTestbed

Inside AtomSDK

TeeHeeComposer

CharacterCreator

MMO-Machines