add: adding proper base for the engine documentations

Author: mallory-scotton

docs/intro.md docs/api/intro.mddocs/intro.md renamed to docs/api/intro.md

@@ -0,0 +1,8 @@
+{
+  "label": "C++ API Reference",
+  "position": 3,
+  "link": {
+    "type": "doc",
+    "id": "engine/cpp-api-reference/cpp-api-reference"
+  }
+}

docs/engine/cpp-api-reference/_category_.json

@@ -0,0 +1,37 @@
+---
+sidebar_position: 0
+title: C++ API Reference
+description: Graphical Playground API Reference.
+tags:
+    - c++
+---
+
+# C++ API Reference
+
+<p style={{ color: '#ffffffa6' }}>
+Graphical Playground API Reference.
+</p>
+
+Welcome to the Graphical Playground C++ API Reference! This is a reference manual for the Graphical Playground Source code.
+
+Graphical Playground's systems and features are packaged in two ways:
+- [Modules](./gp-engine-modules.md): The basic building block of Graphical Playground's software and architecture.
+- [Plugins](): Collections of modules and assets that you can enable or disable within the Editor on a per-project basis.
+
+Explore all of Graphical Playground's modules, plugins, and their members here, organized hierarchically. You can use the search bar to find a known term, such as a class or function name.
+
+You can also browse the modules and plugins below:
+
+## Modules
+
+### Developer
+
+The Developer category provides code that is compiled for every type of build target, but only in non-shipping build configurations. These include development and debug tools, and these modules are not included in Shipping builds.
+
+### Editor
+
+The Editor category provides access to in-Editor code. These modules are compiled for all build configurations, but for Editor build targets. These include tools used by the Editor and the GP Editor itself.
+
+### Runtime
+
+The Runtime category contains functionality necessary to run GP Engine. These modules are compiled for every type of build configuration and build target.

docs/engine/cpp-api-reference/cpp-api-reference.md

@@ -0,0 +1,126 @@
+---
+sidebar_position: 1
+title: Graphical Playground Engine Modules
+description: Modules are the building blocks of GP Engine's software architecture. You can organize your code into modules to create more efficient and maintainable projects.
+tags:
+    - c++
+    - architecture
+---
+
+import FileTree from '@site/src/components/FileTree';
+
+# Graphical Playground Engine Modules
+
+<p style={{ color: '#ffffffa6' }}>
+Modules are the building blocks of GP Engine's software architecture. You can organize your code into modules to create more efficient and maintainable projects.
+</p>
+
+**Modules** are the basic building block of Graphical Playground Engine's (GPE) software architecture. These encapsulate specific editor tools, runtime features, libraries, or other functionality in standalone units of code.
+
+All projects and plugins have their own **primary module** by default, however, you can define other modules outside of these to organize your code.
+
+This page provides an overview of how modules are structured and how they can benefit your GP Engine projects.
+
+:::note
+GP Engine modules are not related to C++ 20 modules.
+:::
+
+## Benefits of Using Modules
+
+Organizing your project with modules provides the following benefits:
+- Modules enforce good code separation, providing a means to encapsulate functionality and hide internal parts of the code.
+- Modules are compiled as separate compilation units. This means only modules that have changed will need to compile, and build times for larger projects will be significantly faster.
+- Modules are linked together in a dependency graph and limit header includes to code that is actually used, per the [Include What You Use (IWYU)]() standard. This means modules that are not used in your project will be safely excluded from compilation.
+- You can control when specific modules are loaded and unloaded at runtime. This provides a way to optimize the performance of your project by managing which systems are available and active.
+- Modules can be included or excluded from your project based on certain conditions, such as which platform the project is being compiled for.
+
+In summary, if you observe best practices with modules, your project's code will be better organized, will compile more efficiently, and will be more reusable than if you put all of your project's code into a single module.
+
+## Setting Up a Module
+
+The following is an overview of how to build and implement a module from scratch. If you follow these steps, you will create a gameplay module separate from the primary module that your project includes by default.
+
+1. Create a directory for your module at the top level of your project's Source folder. This directory should have the same name as your module.
+
+:::tip
+You can place modules in any subdirectory within your Source folder, at any number of levels deep. This makes it possible to use subdirectories to group modules.
+:::
+
+2. Create a `CMakeLists.txt` file inside your module's root directory and use it to define dependencies with other modules. This makes it possible for the CMake build system to discover your module.
+3. Create Private and Public subfolders inside your module's root directory.
+4. Create a `[ModuleName]Module.cpp` file in the Private subfolder for your module. Use this to provide methods for starting up and shutting down your module, as well as other common functions that GP Engine uses to manage modules.
+5. List your module as a dependency in the `CMakeList.txt` file for any module that will need to use it.
+// TODO
+
+## Understanding the Structure of a Module
+
+All modules should be placed in the Source directory for either a plugin or project. The module's root folder should have the same name as the corresponding module.
+
+There should also be a `CMakeLists.txt` file for each module in its root folder, and its C++ code should be contained in **Private** and **Public** folders.
+
+The following is an example of the recommended folder structure for a module:
+
+<FileTree
+  data={[
+    {
+      name: '[ModuleName]',
+      type: 'folder',
+      children: [
+        { name: 'CMakeLists.txt', type: 'file', highlight: true },
+        {
+          name: 'Private',
+          type: 'folder',
+          children: [
+            { name: '[ModuleName]Module.cpp', type: 'file' }
+          ]
+        },
+        {
+          name: 'Public',
+          type: 'folder',
+          children: [
+            { name: '[ModuleName].hpp', type: 'file' },
+            { name: '[ModuleName]Build.hpp', type: 'file' }
+          ]
+        },
+        {
+          name: 'Docs',
+          type: 'folder',
+          children: []
+        },
+        {
+          name: 'Tests',
+          type: 'folder',
+          children: []
+        }
+      ]
+    }
+  ]}
+/>
+
+### Configuring Dependencies in the CMakeLists.txt File
+
+// TODO
+
+### Private and Public Dependencies
+
+You should use the `PublicDependencyModuleNames` list if you use the classes from a module publicly, such as in a public `.hpp` file. This will make it possible for other modules that depend on your module to include your header files without issues.
+
+You should put a module's name in the `PrivateDependencyModuleNames` list if they are only used privately, such as in `.cpp` files. Private dependencies are preferred wherever possible, as they can reduce your project's compile times.
+
+:::tip
+You can make many dependencies private instead of public by using forward declarations in your header files.
+:::
+
+### Using the Private and Public Folders
+
+If your module is a regular C++ module, its C++ files should be placed in the Private and Public subfolders inside your module's root directory.
+
+These do not have any relation to the `Private`, `Public`, or `Protected` access specifiers in your C++ code. Instead, they control the availability of the module's code to other modules. If you use these folders, all `.cpp` files should be placed in the Private folder. Header (`.hpp`) files should be placed in the Private and Public folders per the guidelines below.
+
+If you place a header file in the Private folder, its contents will not be exposed to any modules outside its owning module. Classes, structs, and enums in this folder will be accessible to other classes inside the same module, but they will not be available to classes in other modules.
+
+If you place a header in the Public folder, the Graphical Playground build system will expose its contents to any other module that has a dependency on the current module. Classes in outside modules will be able to extend classes contained in the Public folder, and you will be able to create variables and references using classes, structs, and enums in the Public folder as well. The `Private`, `Public`, and `Protected` specifiers will take effect as normal for functions and variables.
+
+If you are working on a module that will not be made a dependency for others, you do not need to use the `Private` and `Public` folders. Any code outside of these folders will behave as if it were Private. A typical example of this would be your game's primary module, which will likely be at the end of the dependency chain.
+
+You can further organize your code by creating subfolders within the `Public` and `Private` folders. For any new folder you create within `Public`, create a corresponding folder with the same name in `Private`. Similarly, for any header file you place in `Public`, make sure its corresponding `.cpp` files are always in the corresponding folder in `Private`.

docs/engine/cpp-api-reference/gp-engine-modules.md

@@ -0,0 +1,47 @@
+---
+sidebar_position: 1
+---
+
+# Tutorial Intro
+
+Let's discover **Docusaurus in less than 5 minutes**.
+
+## Getting Started
+
+Get started by **creating a new site**.
+
+Or **try Docusaurus immediately** with **[docusaurus.new](https://docusaurus.new)**.
+
+### What you'll need
+
+- [Node.js](https://nodejs.org/en/download/) version 20.0 or above:
+  - When installing Node.js, you are recommended to check all checkboxes related to dependencies.
+
+## Generate a new site
+
+Generate a new Docusaurus site using the **classic template**.
+
+The classic template will automatically be added to your project after you run the command:
+
+```bash
+npm init docusaurus@latest my-website classic
+```
+
+You can type this command into Command Prompt, Powershell, Terminal, or any other integrated terminal of your code editor.
+
+The command also installs all necessary dependencies you need to run Docusaurus.
+
+## Start your site
+
+Run the development server:
+
+```bash
+cd my-website
+npm run start
+```
+
+The `cd` command changes the directory you're working with. In order to work with your newly created Docusaurus site, you'll need to navigate the terminal there.
+
+The `npm run start` command builds your website locally and serves it through a development server, ready for you to view at http://localhost:3000/.
+
+Open `docs/intro.md` (this page) and edit some lines: the site **reloads automatically** and displays your changes.

docs/engine/intro.md

@@ -0,0 +1,8 @@
+{
+  "label": "Programming with C++",
+  "position": 2,
+  "link": {
+    "type": "doc",
+    "id": "engine/programming-with-cpp/programming-with-cpp"
+  }
+}