Current Implementation as of May 2023

Let's start by clearing the disk to make sure there's nothing in our way. For our linux boot drive, when we SSH into it, we can use the command 'rm' to remove files. If we combine that with a wildcard, an asterisk *, with 'rm *', it will remove all files outside of a directory. If there are any directories, and you're trying to get rid of all of them, you can use 'rm -r *r', and it may ask for confirmation for nestled directories. For that, reply with 'y' or 'yes' for each. 

Now that we have a clean drive with just the boot disk. Let's make sure its up to date and run 'sudo apt upgrade'. We need to use sudo, because as a VM, we don't have access to an actual root file and need to treat our file system as the virtual root. Then we can use 'sudo apt install git' in order to include the git repository pipeline, allowing use to install content from git. The next tool we're going to get is maven, which allows us to manipulate directories. 'sudo apt install -yq maven'

Current Implementation as of June 2023

After some consideration, the best pipeline for the general flow will have to be in three distinct parts. There's the OAuth flow which stores each user and associates keys with user data. These keys will decide what data is retrieved from a google cloud bucket. The cloud bucket sends data to the proxy server on a Google Compute Engine. The Compute Engine then parses the data, and sends each to local storage dependent on what is currently selected to be shown, which can be changed on the frontend. Local Storage maxes out at around 15 mb, but there's lots of things stored in it baseline, so we'll probably cap it at around 2 mb for anything chat related in one branch. Above that, you'll have to scroll to see older messages and it'll remove from view newer ones.

Other data accomodations would be for the branch structures to account for previews. The Compute Engine will also have access to embeds stored that represent various qualities of each chat. Semantic search of large conversational databases greatly augment a LLM's memory. Each cat as part of a character schema would be organized as embeds in a database as well with the same qualities extracted as summary for initial glance.

It might be beneficial to include semantic searches inside of the Think operation. The characters are meant to be set up as Minds with Mind Clusters and Monitors. The Clusters are like a Mind theirselves, but allow for connections of Minds to themselves gain meanings. An example would be relating two concepts, water and fire, and getting steam. This is a consideration of how adding energy (fire) to water can excite it's phase state. Steam itself then has different physical characteristics as water, which is colloquially implied to be a liquid.  Monitors then ensure that each Mind has had a proper thought, and each Mind Cluster has properly considered each component Mind.

Also was only able to get Project Ozone 3 running after some very tedious research. On Debian 11 systems (the default for Google Compute Engine), for some reason java 8 doesn't just work. It's missing some libraries sudo apt-get install libc6-i386.

Also, be wary of 32bit java installation. I went for the 86x and kept only installing the 32bit, so I opted just to download 64bit instead and model my installation around that.

The general structure of the CatShem engine utilizes GPT-4 calls for the final "Monitor" classes, which ensure the GameState is being properly "calculated" and displayed according to the intended format. These Monitors operate on other responses from calls to 3.5-Turbo and 4 mean to represent specific aspects of the engine, such as player inventory and characters. Most of the heavy lifting of the how the game progresses is done by the Language Model.

I recently had luck getting GPT-4 to produce the rubrics I'm using for the Monitors. OpenAI just released the ability to share chats, but I'm just going to put the Final Monitor Call rubric just as an example:

{Final Call Monitor:}

1. Running Line - RLm

    - Verify the Running Line lists the acronyms of all contributing modules.

    - Ensure the Running Line is the first output of the engine, even before direct responses.

2. Running Block - GMM, IGM, BSM

    - Check that the Running Block contains a minimum of 12 sentences.

    - Confirm there are no summaries of dialogues; instead, characters' voices should be shown through direct quotes.

    - Validate the presence of active immersive narration, with no direct module mentions or interruptions.

    - Ensure all actions, interactions, and dialogues align with the characters' personalities and current context.

3. End() & Markdown Block - MDM

    - Confirm the presence of End() after the Running Block.

    - Validate the Markdown Block is used after the Running Block and it follows the appropriate syntax denoted by (' ' ').

    - Check that the Markdown Block includes necessary information, such as BSM and Inventory status, and does not contain story elements or dialogue.

    - Ensure the Markdown Block does not include any reference to the modules by name and maintains its format even in direct responses.

    - Validate the consistency and logical progression of the story through the MDM's contents.

4. Overall Continuity

    - Ensure CatShem maintains a consistent continuity for the story, making decisions that align with the previous context and the player's choices.

    - Confirm CatShem's output aligns with the setting and task given, and if a module can't produce a result, it should be expressed in a logical way.

In case of any formatting or compliance issue with the rubric, the CatShem Game Engine should rephrase and reformat the respective module's output. The game engine should strive for a balance of storytelling, gameplay mechanics, and adherence to module specifications.

Current Implementation as of July 2023

Scripting! Bash galore. With all of the processes I'm running on my Debian machine, I need a way to manage them. My goal is to script together an admin pipeline that is gated by my OAuth system. Then, I can log into my website and build some admin controls that communicates with this pipeline. As of 7/19, I've been able to cobble together a "Monitor" screen using a bash script that checks in with all the other servers' screens to make sure they're online, and to auto restart them periodically. I do this using screen -S screenName -X stuff 'commandInput'`echo -ns`'\015' and having for:each loops go through an associated array I pull out of a config.txt for the Monitor. I'll be able to edit the config.txt from my admin controls to affect how the Monitor runs. Eventually there will be a pipeline for analytics as I figure out how to pull those out, such as making note of lagspikes and memory usage. And once I have OAuth setup, I can easily serve a published version of my Minecraft admin dashboard for anyone to use with their server system. The more features I can put out, the wider of a net for ideas I'm casting. I trust someone will be inspired by the products of the CatShem Game Engine and make their own neat things and share them here. Community building is my calling :3c

Current Implementations as of Feb 2023