Worked on documentation but now I must rest

docs/whatis.md

@@ -0,0 +1,104 @@
+# What Is Awperative?
+
+Awperative is a passion fueled **Game Development Platform**; created by me, **Avery Norris**. With the goal of low level, customizable and event driven game design.
+It is completely **free** and **open source** and modifying it is actually encouraged!
+
+Awperative could also be considered a Game Library but the definition is rather loose. 
+I prefer to narcissistically use the term **Game Framework**. Due to the alternate nature of Awperative compared
+to most Game Development Tools.
+
+## Principles
+
+Instead of offering specific "Technology" or "Tools" Awperative's goal is to provide a platform
+and system rather than the content itself. My initial efforts have gone into purging as
+much **"Development Bias"** from Awperative as possible.
+
+[**Unity**](https://unity.com/) has a very good example of this bias. If you have worked in Unity **2D** you are
+almost certainly familiar with the fact that all *Vectors* for 2D Game Objects, are actually **3D** despite
+the 2D environment. This is becuase Unity was built as a 3D Game Engine. When they went
+to make 2D they chose to bandaid this solution by pretending the Z axis did not exist.
+
+In other words, what I call "Developmental Bias" is when Development Tools implement ideas with specific
+assumptions or panderings to a certain type of Game; It is not detrimental to development. However it can certainly muddy the waters.
+
+Modern Game engines have hundreds if not thousands of small bias' plaguing their **Renderers**, **Physics**, **Lighting**, etc. While
+Awperative does not claim to be a 100% bias
+free system. I believe it is quite close, and certainly more effective than any Game Engine by many
+many times.
+
+## Design
+
+So then how does one purge bias from a **System**? I would say there's two schools
+of thought.
+
+1. Make a system that works in any circumstance imaginable.
+2. Allow people to modify the framework such that they can make it do anything.
+
+If it's not immediately clear, one of these goals is very unrealistic. To explain why let's imagine
+we are building a different Game Engine, and we would like to provide developers with a Player Movement
+system, the system should work with any player provided transformation struct (Which should generally hold things such as position, rotation etc.).
+
+### Idea 1
+
+Following our previous rule of bias elimination, we should make it work in as many environments as possible; For the sake of this
+example we will pretend the only factor that can change how transform works in the world. For instance 2d or 3d, Quaternions or Euler Angles, etc.
+
+Making a player controller that could work from 0-∞ dimensions is nothing short of computer magic. 
+And even if we did find a way to make that, we are still restricted to one type. Because our goal is to be able to use structs provided by developers.
+Lest we modify the source code, our only option is to implement an interface or abstract class so that we can actually use the transformation struct.
+
+Even if we get past all of these problems, making a system that works for every design philosiphy is still impossible. You can only build systems with so much foresight. We
+can't make a system that uses Quaternions AND Euler Angles without manually coding them both in. Our availablility and customization relies solely on what our foresight predicted.
+
+We have no way of knowing if someone will ever make another Quaternion type of Angle. If they do and want to
+use those. Our library cannot magically support it unfortunately.
+
+### Idea 2
+
+That leaves us with one other option, which is the idea of modification. In Awperatives case I like
+to call this "Modulation". Since Awperative is already nearly unbiased you *rarely* need to remove
+specific old features. 
+
+Think of it as modding a video game. The end goal of Awperative is to provide a very special kind of
+asset store; where even Transformation profiles are something you get or make outside
+of Awperative.
+
+Imagine creating a new project and being prompted with a list of modules you can import. 
+Say "Johns Transformation Matrix", and then "Jasons Collision System", which uses Johns Matrix as a
+dependency. I'd love to eventually see a module based philosophy like this become mainstream, even if not within Awperative.
+
+## Purpose
+
+So if most of the Game-Related features you would expect from a Game Development Tool is
+something meant to be built on it's own, what is Awperative ***actually***?
+
+Well I'm glad you asked. The purpose of this documentation is to be discussing what I have been calling "Awperative",
+but I also like the call it the Awperative **"Kernel"**. The Kernel's unique strength comes from two
+core design principles
+
+ - **Generalization**
+ - **Reduction and Modulation**
+
+### Generalization
+
+Starting with Generalization; I've worked very hard to reduce redundancy and speficifcation in
+some scenarios. A good example of Generalizaiton is **Doors** and **Windows**. To us humans they are
+different things, but in General, they are both just passages that open.
+
+Awperative takes a doors and windows approach with multiple core systems; Most times we can generalize this scenario by
+having both doors and windows inherit an interface called something along the lines of "ThingsThatOpen". The same can
+be done with abstract classes and sometimes even better, we can compress both systems into one class, for instance bowls and cups can be
+combined into one joined **receptical** class.
+
+### Reduction And Modulation
+
+While filled with much lamer examples, I would say reduction is much more important to what makes Awperative special. Reduction is the affirmentioned process of simplifying what Awperative handles,
+when you purge Development Bias, that is Reduction, since it is reducing what is in the way.
+
+Modulation is almost the opposite of reduction, the process of turning some specific element
+or system into a deployable feature. For instance, if you make a sick Json Loading System, a good
+Game Framework should make it easy to share it for other projects.
+
+A good module should always work unless nefarious modules do not
+play nice with one another.
+