190 lines
11 KiB
HTML
190 lines
11 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<title>What Is Awperative? | Awperative </title>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta name="title" content="What Is Awperative? | Awperative ">
|
|
|
|
|
|
<link rel="icon" href="../favicon.ico">
|
|
<link rel="stylesheet" href="../public/docfx.min.css">
|
|
<link rel="stylesheet" href="../public/main.css">
|
|
<meta name="docfx:navrel" content="../toc.html">
|
|
<meta name="docfx:tocrel" content="toc.html">
|
|
|
|
<meta name="docfx:rel" content="../">
|
|
|
|
|
|
|
|
<meta name="loc:inThisArticle" content="In this article">
|
|
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
|
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
|
<meta name="loc:tocFilter" content="Filter by title">
|
|
<meta name="loc:nextArticle" content="Next">
|
|
<meta name="loc:prevArticle" content="Previous">
|
|
<meta name="loc:themeLight" content="Light">
|
|
<meta name="loc:themeDark" content="Dark">
|
|
<meta name="loc:themeAuto" content="Auto">
|
|
<meta name="loc:changeTheme" content="Change theme">
|
|
<meta name="loc:copy" content="Copy">
|
|
<meta name="loc:downloadPdf" content="Download PDF">
|
|
|
|
<script type="module" src="./../public/docfx.min.js"></script>
|
|
|
|
<script>
|
|
const theme = localStorage.getItem('theme') || 'auto'
|
|
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
|
</script>
|
|
|
|
</head>
|
|
|
|
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
|
<header class="bg-body border-bottom">
|
|
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
|
<div class="container-xxl flex-nowrap">
|
|
<a class="navbar-brand" href="../index.html">
|
|
<img id="logo" class="svg" src="../logo.svg" alt="Awperative">
|
|
Awperative
|
|
</a>
|
|
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
|
<i class="bi bi-three-dots"></i>
|
|
</button>
|
|
<div class="collapse navbar-collapse" id="navpanel">
|
|
<div id="navbar">
|
|
<form class="search" role="search" id="search">
|
|
<i class="bi bi-search"></i>
|
|
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
|
</form>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</nav>
|
|
</header>
|
|
|
|
<main class="container-xxl">
|
|
<div class="toc-offcanvas">
|
|
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
|
<div class="offcanvas-header">
|
|
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
|
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
|
</div>
|
|
<div class="offcanvas-body">
|
|
<nav class="toc" id="toc"></nav>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="content">
|
|
<div class="actionbar">
|
|
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
|
<i class="bi bi-list"></i>
|
|
</button>
|
|
|
|
<nav id="breadcrumb"></nav>
|
|
</div>
|
|
|
|
<article data-uid="">
|
|
<h1 id="what-is-awperative">What Is Awperative?</h1>
|
|
|
|
<p>Awperative is a passion fueled <strong>Game Development Platform</strong> in <strong>C#</strong>; created by me, <strong>Avery Norris</strong>. With the goal of low level, customizable and event driven game design.
|
|
It is completely <strong>free</strong> and <strong>open source</strong> and modifying it is actually encouraged!</p>
|
|
<p>Awperative could also be considered a Game Library but the definition is rather loose.
|
|
I prefer to narcissistically use the term <strong>Game Framework</strong>. Due to the alternate nature of Awperative compared
|
|
to most Game Development Tools.</p>
|
|
<h2 id="principles">Principles</h2>
|
|
<p>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 <strong>"Development Bias"</strong> from Awperative as possible.</p>
|
|
<p><a href="https://unity.com/"><strong>Unity</strong></a> has a very good example of this bias. If you have worked in Unity <strong>2D</strong> you are
|
|
almost certainly familiar with the fact that all <em>Vectors</em> for 2D Game Objects, are actually <strong>3D</strong> despite
|
|
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.</p>
|
|
<p>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.</p>
|
|
<p>Modern Game engines have hundreds if not thousands of small bias' plaguing their <strong>Renderers</strong>, <strong>Physics</strong>, <strong>Lighting</strong>, 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 times.</p>
|
|
<h2 id="design">Design</h2>
|
|
<p>So then how does one purge bias from a <strong>System</strong>? There's two schools
|
|
of thought.</p>
|
|
<ol>
|
|
<li>Make a system that works in any circumstance imaginable.</li>
|
|
<li>Allow people to modify the framework such that they can make it do anything.</li>
|
|
</ol>
|
|
<p>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.).</p>
|
|
<h3 id="idea-1">Idea 1</h3>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<h3 id="idea-2">Idea 2</h3>
|
|
<p>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 <em>rarely</em> need to remove
|
|
specific old features.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<h2 id="purpose">Purpose</h2>
|
|
<p>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 <em><strong>actually</strong></em>?</p>
|
|
<p>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 <strong>"Kernel"</strong>. The Kernel's unique strength comes from two
|
|
core design principles</p>
|
|
<ul>
|
|
<li><strong>Generalization</strong></li>
|
|
<li><strong>Reduction and Modulation</strong></li>
|
|
</ul>
|
|
<h3 id="generalization">Generalization</h3>
|
|
<p>Starting with Generalization; I've worked very hard to reduce redundancy and specification in
|
|
some scenarios. A good example of Generalizaiton is <strong>Doors</strong> and <strong>Windows</strong>. To us humans they are
|
|
different things, but in General, they are both just passages that open.</p>
|
|
<p>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 or sometimes even better, we can compress both systems into one class, for instance: bowls and cups can be
|
|
combined into one joined <strong>receptical</strong> class.</p>
|
|
<h3 id="reduction-and-modulation">Reduction And Modulation</h3>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>A good module should always work unless nefarious modules do not
|
|
play nice with one another.</p>
|
|
|
|
</article>
|
|
|
|
<div class="contribution d-print-none">
|
|
</div>
|
|
|
|
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
|
|
|
</div>
|
|
|
|
<div class="affix">
|
|
<nav id="affix"></nav>
|
|
</div>
|
|
</main>
|
|
|
|
<div class="container-xxl search-results" id="search-results"></div>
|
|
|
|
<footer class="border-top text-secondary">
|
|
<div class="container-xxl">
|
|
<div class="flex-fill">
|
|
<span>Made with <a href="https://dotnet.github.io/docfx">docfx</a></span>
|
|
</div>
|
|
</div>
|
|
</footer>
|
|
</body>
|
|
</html>
|