Quick-guide-to-using-LibGDX.md

+The main framework we're using for the game client is LibGDX.  It provides tons of features for creating hardware accelerated graphical applications using OpenGL and OpenAL.  With it comes quite a few convienences classes and datatypes that we use throughout the visual portions of the client.
+
+## [Screens](https://github.com/libgdx/libgdx/wiki/Extending-the-simple-game#the-screen-interface)
+LibGDX uses Screens for managing the current executable view context.  Input handling and rendering of the user interface occur within these.  The application automatically calls certain functions depending on the state that the screen is in.  As such, we must consider various conditions when deciding what to load and when.
+
+We keep track of our system's contexts within the Screens enum.  Each value hooks together one of our appropriate message dispatching listeners with an actual Screen.  Since these instances are always in memory, it is very important to keep track of your loaded assets and variables so as not to use too much RAM.
+
+All drawing and updating occurs within the render method of a Screen.  In here is where stages should be updated, the screen should be [cleared](https://github.com/libgdx/libgdx/wiki/Clearing-the-screen), and any real-time processing happens.
+
+### Recommendations
+
+Do not load all assets within the constructor of a Screen.  There is a stability concern where with our Screens declared as constant values of an enum, they may be instantiated before a graphical context (OpenGL) has been initialized.  This prevents textures from loading and will crash the application.
+
+Whenever a game switches to a Screen instance, its show method is called, and the previous screen's hide method is called.  Typically you will want to load all assets within the show method, and dispose of them within the dispose method.  If a screen is switched to often, either be sure to call dispose within hide, as dispose is not an automatically called method, or only load assets once, and use a flag to signify that they've been loaded already.
+
+By using the Show/Hide/Dispose methods of Screen, we insure a graphical context has been initialized before we load our graphical assets, and we are able to better manage our memory usage.
+
+### [AssetManagers](https://github.com/libgdx/libgdx/wiki/Managing-your-assets)
+While not currently in use, they are definitely something worth considering.  AssetManagers provide for an asynchronous manner of loading assets.  With a properly written loader, even the maps can be recognized as assets to be loaded asynchronously.  This is handy if you want to have load screens with live graphics, so it does not look as though the application has stalled.
+
+They are capable of disposing all assets loaded by them with ease, which makes managing memory into a rather trival task.  Assets that implement Disposable that are loaded by a manager will have their dispose method called as well.
+
+## Stages
+LibGDX's Stage class is an input processor and the core component of the managed scene graph.  Actors are capable of residing within a stage, and stages themselves are input processors that may listen to various events that can be sent out by LibGDX and its elements.  They also come with their own SpriteBatch and Camera for handling the perspective of the view and uploading of texture data in an efficient manner to the GPU.
+
+All of our Screens that extend ScreenBasic have a protected stage variable in them.  It, however, needs to be instantiated in the child class.
+
+99% of what the following sections are going to mention can be read in detail on [this page of the LibGDX wiki](https://github.com/libgdx/libgdx/wiki/Scene2d).
+
+### Actors
+A visual entity that can be added to a stage.  An easy way to manage a bunch of Actors is to use a Group actor.  Image actors are good for static images for the screen.  When designing UIs, it is typical to use LibGDX's Scene2D.ui classes.  They provide a flexible grid/table layout to work with.
+
+### [Skins & TextureAtlases](https://github.com/libgdx/libgdx/wiki/Skin)
+So we may have a consistent visual style, we declare the appearance of Scene2D UI elements using a Skin.  Skins must be paired with at least one [TextureAtlas](https://github.com/libgdx/libgdx/wiki/Texture-packer#textureatlas) in order to work.  When instantiating Scene2D.ui Actors, you may use a skin to automatically stylize the look of the Actor so it fits with the rest of the UI.
+
+### [Viewports](https://github.com/libgdx/libgdx/wiki/Viewports)
+Viewports specify how the internal world space should be displayed in the shape of the window.  Typically we use the ExtendViewport, which will allow graphics to render in the areas outside of the defined world space.  Other viewports such as ScaleViewport and FitViewport will scale the world to fit the window, which may result in blocky or stretched graphics.  In the case of FitViewport, if the window's aspect ratio does not match the world's it will even add black bars to the sides.
+
+Viewports contain Cameras of their own.  This means when the window is resized, the stage's viewport must be updated so the content does not become distorted.
+
+### [SpriteBatches](https://github.com/libgdx/libgdx/wiki/Spritebatch%2C-Textureregions%2C-and-Sprites#spritebatch)
+SpriteBatches are not typically used directly since we are making use of Stages.  However, MapRenderer does require one to be used so we may actually render it, since it is not an Actor of the Stage.  We also make use of a SpriteBatch directly within the ScreenMap in the case of using a ShaderProgram that adds an Aero Glass effect on transparent UI elements.
+
+Stages have their own SpriteBatches.  It most cases, if it is necessary to use one directly, use one that has already been instantiated with a stage by using `stage.getBatch()`
+
+### Actions
+Another component of Scene2D, they are used primarily for adding visual flare to the UI.  Actions provide the capability to [tween](http://en.wikipedia.org/wiki/Inbetweening) various aspects of Actors, as well as provide sequences that may fire off events dependent on animations.
+
+### Character Creation
+To create a new character, a .png file with a clear background must be created. It should reflect the same structure as the existing characters found in GameClient-desktop/data/characters. Once the .png has been added to this folder, the name of the file and the corresponding character name must be added to the PlayerType enum found in GameClient/src/view.player. 
+The characters.pack in GameClient-desktop/data must then be updated. To do this, delete the old version of the .pack file. Then run the TexturePacker program ([Download here](https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/libgdx-texturepacker-gui/gdx-texturepacker-3.2.0.zip)). In TexturePacker, select 'create new'. The 'characters' folder should be the source directory and the 'data' folder should be the destination directory. Press 'pack'; the TexturePacker should generate the new characters.pack file in /data.
\ No newline at end of file