AveryNorris/Awperative
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs1

Browse Source
This commit is contained in:
Avery Norris
2026-02-11 17:14:48 -05:00
parent f5114350e1
commit c234315ee3
6 changed files with 17 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/_site/Docs/toc.pdf
View File

Binary file not shown.

BIN
docs/_site/api/toc.pdf
View File

Binary file not shown.

6
docs/_site/index.html
View File

@@ -2,9 +2,9 @@
<html>
<head>
<meta charset="utf-8">
<title>This is the HOMEPAGE. | Awperative </title>
<title> Welcome To **Awpera | Awperative </title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="This is the HOMEPAGE. | Awperative ">
<meta name="title" content=" Welcome To **Awpera | Awperative ">
<link rel="icon" href="favicon.ico">
@@ -71,7 +71,7 @@
</div>
<article data-uid="">
<h1 id="this-is-the-homepage">This is the <strong>HOMEPAGE</strong>.</h1>
<h1 id="--welcome-to-awpera-"><center> Welcome To **Awpera </center></h1>
<p>Refer to <a href="http://daringfireball.net/projects/markdown/">Markdown</a> for how to write markdown files.</p>
<h2 id="quick-start-notes">Quick Start Notes:</h2>

6
docs/_site/index.json
View File

File diff suppressed because one or more lines are too long

BIN
docs/_site/toc.pdf
View File

Binary file not shown.

23
docs/whatis.md
View File

@@ -1,6 +1,6 @@
# 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.
Awperative is a passion fueled **Game Development Platform** in **C#**; 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.
@@ -15,20 +15,19 @@ 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.
the 2D environment. This is becuase Unity was originally built as a 3D Game Engine. After initial success they decided
to make a 2D version. And when they did, rather than completely modify Unity internals, They sanely chose to bandaid this original 3D environment 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.
free system. I believe it is quite close, and certainly more effective than any Game Engine by many times.
## Design
So then how does one purge bias from a **System**? I would say there's two schools
So then how does one purge bias from a **System**? There's two schools
of thought.
1. Make a system that works in any circumstance imaginable.
@@ -44,14 +43,14 @@ Following our previous rule of bias elimination, we should make it work in as ma
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.
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
Even if we get past all of these problems, making a system that works for every design philosophy 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.
We have no way of knowing if someone will ever make another Quaternion type of Angle. And if someone happens to, and wants to
use it in the game, our library cannot magically support it unfortunately.
### Idea 2
@@ -81,13 +80,13 @@ core design principles
### Generalization
Starting with Generalization; I've worked very hard to reduce redundancy and speficifcation in
Starting with Generalization; I've worked very hard to reduce redundancy and specification 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
be done with abstract classes or 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